軟件測試常見問題

1.基礎(chǔ)知識部分

1、怎樣描述一種缺陷？

看到這個問題，也許有些讀者會覺得可笑：哪個測試人員不會描述缺陷？不過現(xiàn)實中卻

真的存在諸多測試人員提交的缺陷需要向開發(fā)人員進行解釋或者演示后，才能讓人明白他真

正要體現(xiàn)的意思。實際上，與否可以清晰地描述軟件缺陷，絕對體現(xiàn)著一種測試人員的能力

水平高下O

除了極個別的不能重現(xiàn)H勺缺陷外，一種軟件缺陷至少應(yīng)當描述清晰三方面日勺內(nèi)容：缺陷

概述、詳細內(nèi)容、重現(xiàn)環(huán)節(jié)。

?缺陷概述一一用一到兩句話詳細地描述缺陷的癥狀,使管理人員一下子就能看明白大概

是什么問題。

?詳細內(nèi)容一一詳細地描述缺陷H勺癥狀，可以刊登自己對該缺陷歐I某些意見。詳細內(nèi)容重

要供程序員進行分析，

?重現(xiàn)環(huán)節(jié)一一詳細描述怎樣在系統(tǒng)中重現(xiàn)缺陷，這是非常重要的一項內(nèi)容，假如重現(xiàn)環(huán)

節(jié)描述日勺非常清晰，將大大加緊開發(fā)人員修改缺陷的速度。

一般狀況下，諸多缺陷管理軟件把“詳細內(nèi)容”與“重現(xiàn)環(huán)節(jié)”進行了合并，即只有一

種文本輸入框供測試人員錄入信息，這就導(dǎo)致諸多測試人員疏忽了去描述“重現(xiàn)環(huán)節(jié)”。

此外其他諸如測試版本、測試環(huán)境、發(fā)現(xiàn)H期等輔助信息也應(yīng)當認真錄入。

2、缺陷是誰“生產(chǎn)”的?

這是一種“老生常談”口勺問題。尤其在追究某些質(zhì)量問題責(zé)任H勺時候。常常聽測試人

員埋怨：“這些模塊簡直是垃圾！不值得測試！揮霍我的時間！”，開發(fā)人員則埋怨：“重

要的問題發(fā)現(xiàn)不了，卻成天盯著那些無關(guān)痛癢的小問題，還不如自己去測試！

不符合顧客規(guī)定的都可以稱之為缺陷，因此缺陷的來源重要有兩類：一類是沒有對H勺

理解顧客需求，由系統(tǒng)需求或者分析人員設(shè)計出來的缺陷，此類缺陷重要由設(shè)計人員“生產(chǎn)”:

此外一類是程序開發(fā)人員沒有按照設(shè)計規(guī)定進行開發(fā)或者編寫的代碼存在錯誤而引起的缺

陷，此類缺陷由程序開發(fā)人員“生產(chǎn)”。

對于那些開發(fā)流程不規(guī)范的組織，一般開發(fā)人員會包辦測試前日勺大部分工作。在這種

環(huán)境下，幾乎沒有什么設(shè)計文檔，軟件開發(fā)重要按照程序設(shè)計人員的想像來進行，這個時候

8勺缺陷則重要由開發(fā)人員“生產(chǎn)”。

測試人員不是缺陷的“生產(chǎn)”者，由于測試人員沒有寫過一行代碼，這與否意味著測

試人員可以在一旁“幸災(zāi)樂禍呢”？事實恰好相反，測試人員與缺陷關(guān)系愈加親密，他們是

“缺陷的缺陷”口勺制造者。所謂“缺陷的缺陷”，重要指測試人員提交的“不是缺陷”的缺

陷，即測試人員沒有對日勺理解需求，從而提交了主線“不是缺陷”的缺陷，這種峽陷也是測

試人員常常受到指責(zé)的重要原因。

有關(guān)上面的埋怨，測試和開發(fā)雙方都需要挖正心態(tài)；由于實際雙方都在不停的“生產(chǎn)”

著缺陷，只是發(fā)明的方式不一樣罷了。

3、缺陷產(chǎn)生的原因是什么?

在上個問題中，已經(jīng)簡介了設(shè)計人員、開發(fā)人員、測試人員都會“生產(chǎn)”軟件缺陷。在

實際工作中，缺陷產(chǎn)生的方式更是層出不窮，原因也是多種多樣。例如開發(fā)人員去接杯水，

碰巧和此外一種接水8勺同事聊了幾句，成果回到工位時忘掉了要在某個判斷語句追加此前已

經(jīng)想好的一種判斷條件，這無疑會產(chǎn)生一種缺陷。因此很難一下子把缺陷產(chǎn)生的原因所有陳

列出來，卜.面只是某些引起缺陷日勺經(jīng)典原因：

（1）開發(fā)人員不太理解需求，不清晰應(yīng)當“做什么”和“不做什么”，常常做不合需

求的事情，因此產(chǎn)生了缺陷；

（2）軟件系統(tǒng)越來越復(fù)雜，開發(fā)人員不太也許精通所有H勺技術(shù)。假如不能對的地掌握

新的技術(shù)或者知識，也許會產(chǎn)生缺陷；

（3）技術(shù)文檔普遍編寫的很差，甚至文檔自身就有缺陷，導(dǎo)致使用者產(chǎn)生更多的缺陷:

（4）軟件需求、設(shè)計匯報、程序常常發(fā)生變更，每次變更都也許產(chǎn)生新日勺缺陷：

（5）任何人在編程時都也許出錯誤，導(dǎo)致程序中有缺陷；

（6）技術(shù)人員常處在進度的壓力之下，不能靜心思索也很輕易產(chǎn)生缺陷，尤其是在

Deadline臨近之際，頻繁H勺加班是開發(fā)人員疲于應(yīng)付進度；

（7）諸多開發(fā)人員過于自信，喜歡說“沒問題”，因此對于某些代碼不進行認真日勺調(diào)

試，這也是某些缺陷產(chǎn)生的原因：

（8）頻繁的拷貝代碼也會把缺陷隨之復(fù)制到新的程序中，尤其是復(fù)制其他團體組員的

代碼更輕易使某些缺陷隱藏在程序中。

4、軟件的質(zhì)量應(yīng)當由什么人來負責(zé)?

對于某些開發(fā)管理混亂或者測試剛剛起步口勺組織，產(chǎn)品質(zhì)量一發(fā)生問題，習(xí)慣上會歸

咎于測試小組，認為測試人員沒有測試好產(chǎn)品，因此才產(chǎn)生了那么多的缺陷。

對于開發(fā)管理規(guī)范某些或者測試體系己經(jīng)建立一定期間的組織，假如客戶投訴產(chǎn)品質(zhì)

量問題，則往往開發(fā)人員與測試人員會一起接受懲罰。這種處理方式多少會讓測試人員心理

稍稍平衡某些。

追根溯源，軟件發(fā)生質(zhì)量問題實際是項目管理不規(guī)范引起的。因此，假如要追究責(zé)任

的話，軟件質(zhì)量問題的責(zé)任應(yīng)當由整個團體來承擔(dān)。只有提高整個團體B勺開發(fā)水平，才能提

高質(zhì)量。

此外，也應(yīng)當認識到軟件發(fā)現(xiàn)問題是正常日勺現(xiàn)象，很少有軟件實現(xiàn)了零缺陷。做為企

業(yè)領(lǐng)導(dǎo)者，應(yīng)當詳細問題詳細分析，不要老是考慮怎樣懲罰自己的組員。

5、測試能保證質(zhì)?嗎？

在軟件質(zhì)量方面，目前多數(shù)IT企業(yè)重要采用三種措施：技術(shù)評審、過程檢查、軟件測

試。

技術(shù)評審：技術(shù)評審最初是由IBM企業(yè)為了提高軟件質(zhì)量和提高程序員工作效率而采

用的，重要指對項目計劃、軟件需求、系統(tǒng)設(shè)計等文檔進行有效評審口勺過程。技術(shù)評審可以

由專家團體構(gòu)成，也可以由組織內(nèi)部人員構(gòu)成,它可以盡量防止設(shè)計人員在某些方面發(fā)生“閉

門造車”的情形。

通過技術(shù)評審，可以盡早地發(fā)現(xiàn)工作成果中H勺缺陷.并協(xié)助開發(fā)人員及時消除缺陷，

從而有效地提高產(chǎn)品的質(zhì)量。

過程檢查：屬于質(zhì)量工程師（QA）日勺工作范圍，重要檢查軟件項目的I“工作過程和工

作成果”與否符合已經(jīng)制定口勺有關(guān)規(guī)范。在項目執(zhí)行過程中，質(zhì)量保證人員要不停的）按照項

目計劃對項目進行有效的監(jiān)督和檢查。

通過過程檢杳，可以找出明顯不符合規(guī)范日勺工作過程或者工作成果，及時糾正開發(fā)中

的錯誤。

因此，軟件測試只是保證質(zhì)量的最常用手段，僅僅通過測試是不可以保證質(zhì)量日勺，還

要輔以技術(shù)評審、過程檢宣等手段。

6、測試人員與否需要開發(fā)技能？

在諸多測試網(wǎng)站的論壇上，這個問題都是津津樂道的熱門話題。而究其本源，重要是由

于諸多測試人員做不了開發(fā)才來做測試，于是其中口勺諸多人便懷著某些“膽怯”心理，與同

行反復(fù)探討這個問題，期望其他人可以肯定“雖然不會開發(fā)也能做好測試”的觀點，以便

在心理上得到某些安慰。

與否需要開發(fā)技能與測試人員從事口勺測試工作種類有極大關(guān)系，相信諸多人都聽過微軟

曾經(jīng)聘任一名家庭主婦來;則試Windows操作系統(tǒng)的故事。實際上，假如從事單元測試、集

成測試等較靠近程序代碼的工作，無疑需要開發(fā)技能，此類工作對測試人員開發(fā)技能的規(guī)定

甚至?xí)^程序員；而從事基本的界面測試、顧客功能測試，不會開發(fā)不會有大臥J影響。

不過，原則上還是提議測試人員最佳具有一定口勺開發(fā)能力，并且是開發(fā)能力越強越好，

開發(fā)技能對測試工作可以說是“百利而無一害”，例如可以更輕易防止匯報反復(fù)的缺陷、對

缺陷原因進行更精確的1定位等等。同步，由于國內(nèi)多數(shù)企業(yè)對?測試人員沒有分類，要想得到

更多的發(fā)展機會，也應(yīng)當學(xué)會開發(fā)，便于從事多種類型的測試工作，除非只從事那些遠離代

碼的測試工作。

此外，掌握一門開發(fā)語言后，進行測試的時候可以站在程序開發(fā)的角度進行思索，并且

懂得程序怎樣編寫，就更輕易發(fā)現(xiàn)問題。

7、測試的目的是什么？

測試的目日勺是為了發(fā)現(xiàn)盡量多的缺陷，這個觀念很輕易讓人接受，不過卻很難貫徹到實

際工作中，由于測試的目時常常被定位為“證明軟件沒有問題”。軟件質(zhì)量與否優(yōu)良在投產(chǎn)

后才能有所體現(xiàn)。

對的理解測試口勺目的十分重要。假如認為測試H勺目時是為了闡明程序中沒有缺陷，那么

測試人員就會向這個目的靠攏，因而下意識地設(shè)計諸多不易暴露錯誤的測試示例，這些測試

用例恰恰證明軟件實現(xiàn)了預(yù)期功能，這樣的測試是不真實的J。成功口勺測試在于發(fā)現(xiàn)了迄今尚

未發(fā)現(xiàn)的缺陷，測試人員的職責(zé)是設(shè)計這樣的測試用例一一它能有效地揭示潛伏在軟件里口勺

缺陷。

8、一種軟件產(chǎn)品測試結(jié)束時沒有發(fā)現(xiàn)任何新的缺陷，這樣日勺軟件質(zhì)量一定好嗎？

測試只能證明缺陷存在，不能證明缺陷不存在。而徹底的、全面的測試又難以成為現(xiàn)實,

現(xiàn)實中要考慮時間、費用等限制，不容許無休止地測試。一般的測試結(jié)束，只是滿足一定條

件下的測試結(jié)束，最終的“測試”還是交給了顧客。

因此，雖然測試結(jié)束了，質(zhì)量也不一定好。例如測試小組在時間緊迫日勺狀況卜，只測試

了關(guān)鍵模塊，這樣的軟件系統(tǒng)質(zhì)量一般不會好。

9、測試中的80-20原則是什么？

測試中的180-20原則是說一般狀況下，在分析、設(shè)計、實現(xiàn)階段口勺復(fù)審和測試工作可以

發(fā)現(xiàn)和防止80%的Bug,而系統(tǒng)測試乂能找出其他Bug中的80%,最終的5%口勺Bug也許只

有在顧客的大范圍、長時間使用后才會暴露出來。由于測試只可以保證盡量多地發(fā)現(xiàn)錯誤，

無法保證可以發(fā)現(xiàn)所有的錯誤。尚有就是一般狀況下80%日勺缺陷匯集在20%的關(guān)鍵關(guān)鍵業(yè)

務(wù)模塊中。

10、測試到Zero-bug是測試工作的目的和原則嗎？

一般對于相對第雜的產(chǎn)品或系統(tǒng)來說,Zero-hug是一種理想.Good-enough是我優(yōu)的J原

則。

Good-enough原則就是一種權(quán)衡投入/產(chǎn)出比的原則：不充足的測試是不負責(zé)任的：過度

的測試是一種資源的揮霍，同樣也是一種不負責(zé)任的體現(xiàn)。執(zhí)行測試工作的關(guān)鍵在于：怎樣

界定什么樣的測試是不充足的，什么樣的測試是過度的。處理這一問題的一般措施是制定最

低測試通過原則和測試內(nèi)容，然后詳細問題詳細分析。

11、一般測試工作要到達什么目的？

(I)保證產(chǎn)品完畢了它所承諾或公布的I功能.這一目的就是軟件要符合需求，開發(fā)出H勺軟

件應(yīng)當?shù)竭_所有功能均有明確H勺書面闡明---在某種意義上與IS09001是同一種思想，測

試的首要目的就是保證所有預(yù)定功能是存在并且通過規(guī)苑的I測試。

當然書面文檔的I不健全甚至不對口勺會導(dǎo)致測試效率低下、測試目日勺不明確和測試范圍不

充足，進而導(dǎo)致最終測試的作用不能充足發(fā)揮、測試效果不理想。因此詳細問題一定要詳細

分析，一種好H勺測試負責(zé)人盡量來彌補這些文檔缺陷。

（2）保證產(chǎn)品滿足性能和效率的規(guī)定。目前日勺顧客對軟件的性能方面日勺規(guī)定越來越高，使

用起來系統(tǒng)運行效率低（性能低）、或顧客界面不友好、顧客操作不以便（效率低）的產(chǎn)品市場

空間肯定會越來越小。因此通過測試改善性能也是測試工作一種目的。

實際上顧客最關(guān)懷的不是軟件的技術(shù)的多先進、功能々?多強大，而是能從這些技術(shù)、這

些功能中得到多少好處。也就是說，顧客關(guān)懷的是他能從中取出多少，而不是你已經(jīng)放進去

多少。

（3）保證產(chǎn)品是強健的、適應(yīng)顧客環(huán)境的。強健性即稔定性，是產(chǎn)品質(zhì)量的基本規(guī)定，尤

其對于?種用于事務(wù)關(guān)鍵或時間關(guān)鍵的工作環(huán)境中的I應(yīng)用系統(tǒng)。軟件只有穩(wěn)定的運行，才會

不致于中斷顧客日勺工作，為此通過強健性測試是軟件測試工作的又?種目日勺。

2.測試管理部分

1、測試負責(zé)人要進行嚴格的測試進度跟蹤嗎？

諸多時候，由于人力資源的局限性，測試項目負責(zé)人都是在執(zhí)行測試，這樣就使整個項

目缺乏控制，某些問題（例如：有些組員I內(nèi)缺陷質(zhì)量不夠合格；開發(fā)人員修改不及時，系統(tǒng)

某些功能發(fā)生嚴重問題導(dǎo)致部分功能無法測試。）得不到處理，耽誤了進度。因此測試負責(zé)

任必須全程監(jiān)控項目，盡量多的I掌握信息。一般，測試負責(zé)人需要完畢下面這些內(nèi)容的管理

工作：

?測試用例執(zhí)行狀況；

?每個測試員提交的缺陷狀況：

?測試中與否發(fā)生突發(fā)問題。

2、測試也有版本控制嗎？

這里口勺版本重要是指測試對象口勺版本控制，也就是指對開發(fā)部提交的產(chǎn)品進行版本控

制。在開發(fā)小組版本管理不規(guī)范的I狀況下，測試小組進行版本控制十分重要，要保證測試對

象是可以控制H勺。提議開發(fā)和測試雙方進行明確口勺約定，可以各自指定專門的J測試版本負責(zé)

人，制定提交原則，對提交狀況進行詳細的記錄，這樣基本防止了版本失控導(dǎo)致的測試失誤

或無效。

3、怎樣處理測試人員的流動問題？

人員流動不僅僅是測試部門，這是IT行業(yè)的普遍現(xiàn)象。從管理者角度，主管需要多多

和團體內(nèi)組員進行溝通，建立一種融洽的團體環(huán)境，及時掌握狀況，可以早些進行對應(yīng)的調(diào)

整。不過只有企業(yè)建立好II勺用人制度，給員工提高廣闊的發(fā)展空間和好的培訓(xùn)學(xué)習(xí)機會，才

能從主線上處理這一問題，

加強項目管理，強化文檔管理并保證文檔II勺有效性，可以大大減少由于人員流失帶來的

損失。同步，測試部門要建立培訓(xùn)機制，使新到員工接受直接或者間接的培訓(xùn)，迅速適應(yīng)工

作。

4、為何開發(fā)人員常常埋怨測試工程師提交的缺陷質(zhì)?太差？

我們常常聽開發(fā)人員說：“這不是缺陷！”，“這個缺陷沒有，由于我的1系統(tǒng)上運行正常！:

測試工程師自身就是做質(zhì)量工作的I，提交的成果自身就應(yīng)當質(zhì)量高些，為何還會有這種現(xiàn)

象？

提交的缺陷引起爭議是一種正常H勺現(xiàn)象，例如測試人員描述不清晰就會引起爭議。減少

甚至防止這種現(xiàn)象口勺措施是交叉測試，交又測試是提高測試質(zhì)量的一種有效手段，當然交叉

測試會增長一定口勺測試成本投入。在測試任務(wù)完畢后，測試工程師之間互相驗證彼此提交口勺

缺陷，就會防止了缺陷描述不清、因運行環(huán)境而產(chǎn)生的I缺陷等一系列問題，從而大大減少了

回歸測試以及交流口勺成本，因而這種投入也是值得H勺，實際開發(fā)人員在單元測試階段也會進

行交叉測試，來提高開發(fā)質(zhì)量。

此外，測試人員一定要按照規(guī)范描述測試中發(fā)現(xiàn)H勺缺陷，一種缺陷至少描述清晰概要描

述、詳細描述、重現(xiàn)環(huán)節(jié)三方面的內(nèi)容。

5、“讓那些新手來做測試，反正他們也不會什么“對的嗎？

在實際項目開發(fā)中，我們常?？吹接行﹩挝缓鲆暅y試團體存在的意義，當要實行測試時,

往往臨時找?guī)追N程序員充當測試人員。也有些單位盡管認識到了組建測試團體的重要性，但

在詳細貫徹U勺時候往往安排某些毫無開發(fā)經(jīng)驗的行業(yè)新手去做測試工作，這常常導(dǎo)致測試效

率低下，測試人員對測試工作索然無味。

根據(jù)筆者H勺經(jīng)驗，測試團體應(yīng)首先聘任一名資深口勺測試領(lǐng)域?qū)＜?，他?yīng)具有極為豐富的

同類項目軟件測試經(jīng)驗，對軟件開發(fā)過程中常見口勺缺陷或錯誤了然于胸；此外，他還具有很

好的親和力和人格魅力。另一方面，項目測試團體還具有諸多具有一技之長H勺組員，如對某

些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試腳本等。

此外，測試團體還應(yīng)聘任某些兼職組員，如驗證測試實行過程中，同行評審是最常使用

的一種形式，這些同行專家就屬于兼職測試團體組員的）范圍。至于測試團體里里H勺測試新手,

這部分人可?以安排去從事交付驗證或黑盒測試之類日勺工作。

6、測試同化現(xiàn)象是什么？

同化現(xiàn)象是指伴隨時旬的推移，開發(fā)人員會逐漸影響測試人員H勺思維和對缺陷的判斷能

力，尤其是針對同一產(chǎn)品，同一組開發(fā)人員和同一組測試人員共同配合了很長時間，諸多本

來是缺陷的問題，由于測試人員對軟件“習(xí)慣成自然”的使用，會不被當成缺陷，尤其是在

開發(fā)人員的解釋和說服下，同化現(xiàn)象發(fā)生也許意味著“惡性循環(huán)”的開始：測試人員會幫著

開發(fā)人員解釋一種個缺陷的合理性，一輪有一輪叢J測試都不會發(fā)現(xiàn)問題。

招聘新及1人員，不一樣的測試項目組輪換去測試不一樣的產(chǎn)品，就可以防止。同步提議

產(chǎn)品可以公布測試版，更多的人對其進行測試，就可以發(fā)現(xiàn)更多的問題。

7、測試工程師怎樣防止定位效應(yīng)？

社會心理學(xué)家曾作過一種試驗：在召集會議時先讓人們自由選擇位子，之后到室外休息

半晌再進入室內(nèi)入座，如此五至六次，發(fā)現(xiàn)大多數(shù)人都選擇他們第一次坐過的位子。這種現(xiàn)

象稱為定位效應(yīng)，闡明人們習(xí)慣上但凡自己認定的，人們大都不想輕易變化它。

定位效應(yīng)在開發(fā)人員和測試人員身上均有體現(xiàn)。例如開發(fā)工程師針對某一自己寫口勺功

能，常常進行代碼移植，這種復(fù)制的“功能”，由于上一次通過調(diào)試，在新日勺地方往往不會

認真調(diào)試，這些代碼往往會帶來共享變量沖突等許多種類型的缺陷。

定位效應(yīng)體目前測試人員身上就是測試過時功能不再進行認真測試：在回歸測試時，之

前由于進行過認真的測試，往往會認為某些功能是可靠，只要驗證某些此前發(fā)現(xiàn)的缺陷與否

修改完畢就可以了。這種現(xiàn)象在反復(fù)多次回歸時體現(xiàn)日勺愈加突出，由于回歸測試中諸多功能

都會進行多次反復(fù)測試。眾所周知，開發(fā)人員在修改缺陷時往往會引入新日勺缺陷，測試人員

的味于防備就會把這些峽監(jiān)帶到顧客這里。

處理這種問題的方案?般有兩個：

(1)完整的執(zhí)行測試用例：這種措施投入較大，不過在開發(fā)產(chǎn)品時最佳在最終一次回

歸測試時測試的執(zhí)行一次所有的測試用例。

(2)交叉測試：測試人員交叉測試，就可以很大程度H勺防止定位效應(yīng)。測試工程師在

回歸測試時互相互換任務(wù)，反復(fù)測試某一功能的機會大大減少，從而也就不會“主觀的”人

員某些功能沒有缺陷。

一般上面的兩個措施都是結(jié)合使用的，既要進行交叉測試，又要全面執(zhí)行測試用例，測

試覆蓋面要盡量H勺廣泛。

8、測試人員忽然辭職怎么辦？

目前IT行業(yè)人員流動較大已經(jīng)成為一種不爭日勺事實，員工小J辭職大多數(shù)都會給組織帶

來一定的影響，而議.種影響基本是不也許防止H、J。在測試領(lǐng)域，員工忽然辭職也會帶來很大

的負面影響，尤其測試隊伍規(guī)模較小時。面對這種狀況，我們所能做H勺，就是怎樣最大程度

的減少這種影響。

根據(jù)作者H勺經(jīng)驗，重要有兩種措施：第一種是在測試人員內(nèi)部建立一種良好口勺學(xué)習(xí)環(huán)境,

大家互相學(xué)習(xí)，這樣某些特有技術(shù)不會被某一種人所掌握，而互相學(xué)習(xí)和提高自身，也是大

多數(shù)組員樂意做H勺；第二種就是在組織中進行知識管理，把技術(shù)作為知識沉淀卜.來，這樣新

的員工在接手工作時輕易上手，通過學(xué)習(xí)迅速適應(yīng)環(huán)境。

此外，平常還要注意工作規(guī)范化，例如形成盡量多的文檔，都可以減少員工離職帶來日勺

損失。

9、測試人員工作發(fā)生問題測試經(jīng)理應(yīng)當怎樣做？

測試人員工作發(fā)生問題是測試經(jīng)理常常要面對的問題，作為測試部門的領(lǐng)導(dǎo)，首先要做

的是指出測試人員所犯的錯誤，使其盡快改正錯誤。

唯一不能做的就是盯著下屬口勺錯誤不放?？偠⒅聦偃丈资д`，是一種領(lǐng)導(dǎo)者日勺最大失誤。

英國行為學(xué)家波特說：當遭受許多批評時，下級往往只記住開頭的某些，其他就不聽了，由

于他們忙于?思索論據(jù)來反駁開頭的批評。身為測試經(jīng)理要根據(jù)測試人員的心理來進行指導(dǎo)，

最大程度的調(diào)動每個人員的積極性來參與工作。

10、不深入到詳細測試工作時，測試經(jīng)理怎樣考核員工？

這種現(xiàn)象在測試規(guī)模較大II勺組織中很常見。測試經(jīng)理應(yīng)當盡量II勺安排每周與每個組員在

不被打擾的環(huán)境下進行談話，這樣可以盡早發(fā)現(xiàn)和處理諸多問題。

做為一種測試經(jīng)理，重要工作之一就是定期歐）評估組織做了些什么并且是怎樣做的。同

步還要為員工做一種匯報一一有關(guān)充足理解測試人員正在做什么和怎樣做H勺匯報，以此來給

測試人員做做工作成績考核。這份匯報要理解到每個人的動態(tài)。

測試經(jīng)理和每個員工重點是談?wù)勀壳暗墓ぷ?，例如大家在工作中H勺問題或意見；與否需

要協(xié)助等。許多管理者常常埋怨沒有時間在一周會見每一種員工來談他們的工作。不過根據(jù)

作者的經(jīng)驗，假如不能安排時間和員工進行每周日勺談話，員工會來打擾測試經(jīng)理的工作，由

于員工諸多問題還要要來找測試經(jīng)理商議。

同步看待員工要用他們能接受的方式，而不是我們自己可以接受的方式?！凹核挥瑁?/p>

勿施于人”，這條黃金法則也許會對許多生活中的純粹的社交原因杓效，不過并不是總對工

作有用。有效率日勺管理者懂得應(yīng)當逐漸理解每?種員工需要怎樣的看待方式。

總之，只有盡量多的和員工接觸，才能更精確日勺進行考核。

11、測試經(jīng)理怎樣面對加班問題？

大多數(shù)狀況下，作者是不主張加班的。當員工每周工作超過40個小時的時候，他們開

始在工作的時候關(guān)懷自己的事。他們花錢，會給很久沒有聯(lián)絡(luò)的人打，由于員工們一直

都在工作。員工不能在太疲勞的狀態(tài)下完畢工作，這是由于他們在工作時不能關(guān)懷自己，這

種狀況下一般效率很低。

測試管理工作的重要任務(wù)之一就是要發(fā)明一種環(huán)境，讓員工在工作時間內(nèi)完畢工作，同

步還要鼓勵他們每周不要超過40小時，甚至可以基于他們在40個小時可以完畢的工作量給

他們酬勞。一般狀況卜這樣做可以提高發(fā)明力，從而會逐漸提高效率。

測試工作自身日勺一種突出特點就是不停反復(fù)枯燥、冗長的I測試，假如在疲勞狀態(tài)下，很

有也許精力不集中，略過某些重要H勺測試環(huán)節(jié)。并且有II勺時候測試需要編寫測試驅(qū)動程序，

這種狀況更需要很好的狀態(tài)來工作。

12、測試管理者怎樣面對自己的錯誤？

每個人都會出錯。我們也許會由于忘掉開會而使客戶發(fā)火，承認自己出錯是一件尷尬口勺

事情，尤其是管理人員認為對自己負責(zé)的項目小組承認出錯也許會失去尊嚴。假如我們不是

常常出錯，承認錯誤的時候其實可以贏得尊敬.例如我們忘掉一次會議，然后為此向同事或

者客戶道歉，其他日勺人會理解我們的。

不管做了什么，不要否認或故意忽視自己日勺失誤.故意忽視不會讓錯誤消失，這只會讓

錯誤成長為怪物。

13、為何計劃定期的培訓(xùn)？

測試工作和開發(fā)工作同樣，不僅要面對日新月異H勺新技術(shù)，還要學(xué)習(xí)有關(guān)系統(tǒng)H勺領(lǐng)域知

識。只有在不停口勺學(xué)習(xí)中，才能做好工作，跟上行業(yè)口勺發(fā)展。假如測試管理者沒有基于不停

的變化而培訓(xùn)員工，就會給組織帶來一定R勺損失。平常培訓(xùn)可以是有關(guān)特定項目或者是技術(shù),

一般采用下面幾種措施：

(1)測試部門內(nèi)自由交流方式的培訓(xùn)。這種培訓(xùn)FI勺交流比較隨意，可以在周五的例會

上進行交流，也可以大家一起坐在茶館里進行交流。措施可以采用“頭腦風(fēng)暴法”，讓每個

組員討論一種特定H勺領(lǐng)域，這種交流措施尤其對同步要做諸多不一樣項目的小組比較有益

處。當每個人做不一樣的項目，這會有助于每個人理解你小組所有的工程。

(2)跨部門的互相學(xué)習(xí)。測試工作需要諸多領(lǐng)域以及技術(shù)知識，這些知識單靠自學(xué)是

遠遠不夠歐和其他部門內(nèi)同事進行交流是一種相稱好的措施，大家在工作中可以在技術(shù)等

各個方面互相得到提高。

（3）外部培訓(xùn)。外剖培訓(xùn)盡管投入較高，但也是值得日勺。這些專家一般在自己的領(lǐng)域

非常精通，可以迅速提高整個測試團體的水平。也可以通過測試小組簡介某些朋友來進行培

訓(xùn)，這種方式可以減少成本。

培訓(xùn)是構(gòu)造學(xué)習(xí)型組織的基本條件，也是提高員工水平的重要措施。常常的定期培訓(xùn)I,

可以增強組織凝聚力，使員工愈加樂意長期留在組織中發(fā)展。做為測試負責(zé)人，定期的進行

培訓(xùn)是十分必要H勺。

14、時間上不容許進行所有測試，測試負責(zé)人應(yīng)當怎樣做？

這個問題也許卜分可笑，可是現(xiàn)實中我們的測試經(jīng)理們卻不得不面對這個問題。這里口勺

所有測試不是指對軟件進行遍歷測試，而是指測試負責(zé)人制定的測試計劃包括的所有測試內(nèi)

容。

一般，不管是開發(fā)產(chǎn)品還是做詳細的項目，都會發(fā)生耽誤進度的狀況。一旦整體進度不

能向后延遲，項目有關(guān)人員習(xí)慣上口勺做法就是縮減測試時間。尤其在功能還沒有開發(fā)完畢口勺

狀況下，這種現(xiàn)象更為突出。

肩負著質(zhì)量重任的測試經(jīng)理，怎樣來處理這個問題呢？比很好日勺做法是按照下面的環(huán)節(jié)

逐漸來完畢和改善工作：

（I）按照測試任務(wù)的輕重緩急，盡最大努力完畢測試任務(wù)。在時間局限性依J狀況下，

我們應(yīng)當對測試任務(wù)按照優(yōu)先級來劃分，重要緊急的任務(wù)先完畢。這個時候的測試任務(wù)是一

種輔助性工作，其目的就是盡最大努力來提高質(zhì)量。因此，面對這種狀況，測試負責(zé)人要做

的就是帶領(lǐng)測試小組充足這用所有資源來保訐質(zhì)曷。

（2）在實際工作中和開發(fā)人員共同配合，逐漸改善工作。只有整個團體的軟件開發(fā)能

力提高了，才能從本源上處理問題。因此，測試負責(zé)人要帶領(lǐng)團體和開發(fā)小組共同尋找適合

自己的開發(fā)模式，從而使項目規(guī)劃H勺愈加合理，進而按照預(yù)定計劃來開展測試工作。

總之，在任何狀況下，測試負責(zé)人都不應(yīng)當埋怨。只有積極歐I面對問題，才能更好口勺處

理問題。

15、企業(yè)不重視測試，測試負責(zé)人怎樣開展測試工作？

目前國內(nèi)的軟件企業(yè)不重視測試仍然是一種普遍現(xiàn)象。盡管諸多企業(yè)在意識上已經(jīng)開始

重視測試，不過在詳細工作中，往往由于追趕進度、節(jié)省資源等方面原因而忽視測試工作.

在這種狀況下，測試負責(zé)人仍要勸軟件質(zhì)量負重要責(zé)任。在這種環(huán)境下，測試負責(zé)人應(yīng)當怎

樣開展工作呢？

首先，要積極去配合開發(fā)人員完畢工作。尤其是不能埋怨環(huán)境，在任何狀況下埋怨是不

能處理問題小J,只能加重矛盾口勺激化。在此基礎(chǔ)上，逐漸顯出測試工作日勺重要性，然后再逐

漸健全測試體系。

另一方面，用實際行動來證明測試工作的J重要性。只有測試工作的業(yè)績逐漸體現(xiàn)出來，

人們才會真正H勺注意到測試的重要性。因此，測試負責(zé)人從點滴開始做起，才能逐漸做好測

試工作。

要想做好軟件，把開發(fā)的）軟件產(chǎn)品形成商品，測試工作必須和開發(fā)同樣重視。否則，質(zhì)

量不好的產(chǎn)品，很快會被市場淘汰的?，F(xiàn)代的軟件規(guī)模越來越大，測試工作也會越來越重要,

因此測試負責(zé)人只要堅持做好工作，可發(fā)揮作用B勺空間會越來越大。

最終要說口勺是，假如其日勺是在一種沒有但愿日勺團體里，測試負責(zé)人可以考慮辭職。辭職

也是一種不錯日勺選擇，到新的）環(huán)境去發(fā)揮自己的能力，要比長時間的I懷著“郁悶”日勺心情去

工作好的多。

16、測試管理者需要是技術(shù)專家嗎？

測試管理者在測試項目中口勺重要任務(wù)是制定測試方略，管理測試計劃時貫徹狀況，并且

還要為測試項目的進行發(fā)明良好的執(zhí)行環(huán)境。同步還要調(diào)動員工的發(fā)明性，對員工的工作作

出評估。這些工作不一定規(guī)定測試管理者到達專家的I水平。

不過在實際工作中，由于?測試人員的短缺，測試管理者常常做為測試員來執(zhí)行詳細日勺測

試任務(wù).尤其在規(guī)模較小內(nèi)測試團體，測試管理者日勺平常工作一般以詳細的測試執(zhí)行工作為

主，這個時候更需要測試管理者有很好日勺背景知識。

總體說來，技術(shù)方面的背景知識對測試管理者是十分有益的。例如：分派工作任務(wù)、做

進度預(yù)算，以及某些詳細FJ執(zhí)行工作，都需要一定的背景知識。當然，做為一種測試管理者,

沒有必要精通所有口勺技術(shù)，那也是辦不到的。測試管理者做到對《加勺協(xié)助員工最佳地完畢工

作，并且提供最佳的完畢工作日勺環(huán)境就可以了。

3.測試流程部分

1、測試人員要需要何時參與需求分析？

原則上，測試人員對需求理解得越深入對測試工作越有利，因此最佳一開始就應(yīng)當參與

需求分析工作。這樣可以帶來如卜得好處：

?測試人員全程參與需求分析，對需求理解很深刻，減少了諸多與開發(fā)人員口勺交互，節(jié)省

了時間。測試人員參與前期開發(fā)討論，直接掌握了不清晰的需求點；

?初期確定測試用例的J編寫思緒，為測試打好了基礎(chǔ)：

?可以獲取某些測試數(shù)據(jù)，為測試用力設(shè)計提供協(xié)助；

?可以發(fā)現(xiàn)需求不合理的地方，減少了測試成本。

測試人員重要的工作之一就是確認系統(tǒng)與否對口勺實現(xiàn)了需求。測試人員不參與前建H勺工

作，就只能依賴最終形成H勺需求文檔，甚至由開發(fā)人員來講解需求，而這些缺求也許發(fā)生了

“問題”，由于這個需求是已經(jīng)通過度析日勺需求，諸多的內(nèi)容也許與顧客日勺真正規(guī)定發(fā)生了

偏差。同步假如只看最終形成的需求文檔，對需求也會有理解上的偏差。因此作為測試人員

要盡量的獲取到“第?線”的需求資料，才能真正地埋解顧客的'也務(wù)，從而更好的對系統(tǒng)進

行測試。

當然，假如測試人員不能參與需求環(huán)節(jié)，一定要通過其他途徑保證需求H勺精確性，例如

和開發(fā)人員進行集中討論需求疑問日勺項目會議，并且?定要加強測試案例評審，甚至于是測

試需求的評審。

2、系統(tǒng)測試階段低級缺陷較多怎么辦？

在系統(tǒng)測試階段，假如仍有諸多低級缺陷，闡明測試對象是不合格日勺，沒有到達測試原

則。假如系統(tǒng)階段發(fā)現(xiàn)日勺簡樸缺陷（也就是不應(yīng)當有日勺缺陷）較多，最佳停止測試，轉(zhuǎn)由開

發(fā)人員進行測試，發(fā)現(xiàn)問題立即修改，由于這種由測試人員進行的成本較高，反愛交互還會

耽誤進度。

提議建立預(yù)測試制度：系統(tǒng)測試前對關(guān)鍵模塊進行抽查測試，假如問題較多（例如平均

每個關(guān)鍵模塊發(fā)現(xiàn)10個以上缺陷），就可以停止本次測試，直到抽測后發(fā)現(xiàn)問題較少才可以

啟動系統(tǒng)測試。

3、缺陷流落到客戶那里有什么后果？

假如軟件缺陷被遺落并流落到客戶那里，成果就是代價高昂時或者現(xiàn)場支持費用，

還也許需要修復(fù)、重新測試和公布新R勺產(chǎn)品，更糟糕的狀況是產(chǎn)品要被召回甚至被客戶起訴。

這種成本付出非常高，幾乎是在內(nèi)部修改缺陷的幾何級數(shù)倍。

質(zhì)量之父PhilipCrosby把質(zhì)量的費用分為整合費用和非整合費用兩類，整合費用是指與

一次性計劃和執(zhí)行測試有關(guān)的所有費用，用于保證軟件按照預(yù)期方式進行。假如發(fā)現(xiàn)缺陷，

通過一系列的缺陷處理流程而處理缺陷，這種跋用就是非整合㈱用.PhilipCrcshy在自己日勺

作品中詳細論述了內(nèi)部的整合費用和內(nèi)部的非整合費用之和遠遠不大于?外部也就是客戶引

起的非整合費用。

總之，軟件缺陷一定要盡量的J在內(nèi)部處理，這對?節(jié)省成本、提高產(chǎn)品著名度都大有裨益。

4、什么是冒煙測試？

冒煙測試從操作上是一種隨機H勺測試，操作對象一般是關(guān)鍵業(yè)務(wù)模塊。測試員任意操作，

要是發(fā)現(xiàn)多數(shù)功能走不下去（大概20%）,那么這個冒煙測試就算是結(jié)束了。冒煙測試一般

不用參照測試用例。

執(zhí)行冒煙測試R勺目的是對要測試H勺產(chǎn)品進行一種大概H勺度量。假如冒煙測試不能通過，

一般不會啟動測試計劃。由于軟件缺陷較多的狀況下，后動測試計劃會揮霍更多的人力和物

力。通俗R勺說，對“垃圾”產(chǎn)品執(zhí)行測試實際是測試人員搶了程序設(shè)計人員FI勺工作，這些缺

陷應(yīng)當在開發(fā)階段消滅，只有這樣才可以真正的節(jié)省成本。

5、在集成測試的時候，已經(jīng)對某些子系統(tǒng)進行了功能測試、性能測試等等，那

么在系統(tǒng)測試時能否跳過相似內(nèi)容的測試？

由于集成測試是在仿真環(huán)境中開展的，那不是真正的目的系統(tǒng)。再者，單元測試和集成

測試一般由開發(fā)小組執(zhí)行。根據(jù)測試心理學(xué)的分析，開發(fā)人員測試自己的I工作成果雖然是必

要時，但不能作為成果已經(jīng)通過測試口勺根據(jù)。

為了保證測試日勺客觀性，應(yīng)當由機構(gòu)的獨立測試小組來執(zhí)行系統(tǒng)測試。

6、什么是測試方略？

測試方略描述測試工程的總體措施和目電描述目前在進行哪一階段口勺測試（單元測試、

集成測試、系統(tǒng)測試）以及每個階段內(nèi)在進行的測試種類（功能測試、性能測試、覆蓋測試

等）。

測試方略口勺制定重要包括三個方面的I內(nèi)容：

（1）確定測試過程要使用的J測試技術(shù)和工具；

（2）制定測試啟動、停止、完畢原則；

（3）進行風(fēng)險分析和應(yīng)對方案。例如測試與外部接口或者模擬物理損壞、安全性威脅。

測試計劃最關(guān)鍵日勺一步就是將軟件分解成單元，按照需求編寫測試計劃。

7、代碼會審是怎樣進行的？

在研發(fā)小組將所開發(fā)的程序經(jīng)驗證后，提交測試組后，測試實行工作基本開始了。這個

時候，測試人員要仔細閱讀有關(guān)資料，包括規(guī)格闡明、設(shè)計文檔、使用闡明書及在設(shè)計過程

中形成的測試大綱、測試內(nèi)容及測試的通過準則，全面熟悉系統(tǒng)，編寫測試計劃，設(shè)計測試

用例，作好測試前的J準備工作。為了保證測試的質(zhì)量，我們一般測試過程提成幾種階段，即：

代碼審查、單元測試、集成測試和驗收測試。

代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態(tài)分析日勺過程。會審小組由組

長，2?3名程序設(shè)計和測試人員及程序員構(gòu)成。會審小組在充足閱讀待審程序文本、控制

流程圖及有關(guān)規(guī)定、規(guī)范等文獻基礎(chǔ)上，召開代碼會審會，程序員逐句講解程序的邏輯，并

展開熱烈的討論甚至爭議，以揭示錯誤的關(guān)鍵所在。實踐表明，程序員在講解過程中能發(fā)現(xiàn)

許多自己本來沒有發(fā)現(xiàn)的錯誤，而討論和爭議則深入促使了問題H勺暴露。例如，對某個局部

性小問題修改措施的討論，也許發(fā)現(xiàn)與之有牽連的I甚至能波及到模塊口勺功闡明、模塊間接口

和系統(tǒng)總構(gòu)造H勺大問題，導(dǎo)致對需求定義的重定義、重設(shè)計驗證，大大改善了軟件的質(zhì)量。

代碼會審盡管需要一定的成本，不過在大型軟件中，是必不可少的U

8、回歸測試中未處理的缺陷怎樣處理？

軟件口勺后期測試就是一種反復(fù)回歸日勺工作，有些問題也許修改多次才能處理，尤其是那

些在開發(fā)環(huán)境下不存在的問題，這些問題很輕易被程序員忽視，拖到最終才處理。因此大部

分回歸測試就是和開發(fā)人員反及配合處理那些上次測試中沒有處理的缺陷。

這里重點討論的I是最終一次回歸測試后，仍然發(fā)既有些缺陷沒有處理時測試經(jīng)理應(yīng)當怎

樣做。在管理不規(guī)范的組織中，由于進度或者其他方面時壓力，開發(fā)工作已經(jīng)停止，一般會

將這些問題置之不理。對內(nèi)口勺做法時把這些沒有處理日勺問題形成一種未處理缺陷匯報，然后

召開項目會議進行討論，對不一樣打勺問題采用不一樣口勺處理方式：

(1)嚴重性H勺問題：有些問題較難處理，往往會被拖到最終，假如此類缺陷導(dǎo)致軟件功能發(fā)

生障礙，則必須處理，這也是質(zhì)量控制的職賁所在;

⑵功能性的問題：可以考慮升級時處理；

(3)一般性問題：不影響使用，可以不處理或者升級處理。

此類項目會議一般需要技術(shù)總監(jiān)或者更高級別日勺人來參與。最終，需要對最終討論沒有

處理的缺陷列表進行簽字并存檔，形成一種基線。尤其要注意口勺某些缺陷與否修改不能由程

序員或者測試人員來決定，這樣有也許帶來嚴重日勺后果一一導(dǎo)致缺陷失控，最終形成沒有人

對質(zhì)量負責(zé)日勺局面。

9、狀態(tài)為已經(jīng)修改的缺陷沒有修改怎么辦？

首先要對?此類缺陷進行分析：

(I)有些問題在開發(fā)環(huán)境下沒有重現(xiàn)，而開發(fā)人員迫于進度壓力，往往會把它標識為

已經(jīng)修改。這種條件下測試人員應(yīng)當和開發(fā)人員進行直接溝通；

(2)有些問題測試人員沒有描述清晰，開發(fā)人員認為問題不存在也也許把問題標識為

已經(jīng)修改(對日勺日勺做法是標識問題為商討或者不存在狀態(tài))。測試人員應(yīng)當清晰的描述問題，

減少此類問題口勺發(fā)生，尤其要描述清晰運行環(huán)境以及缺陷