軟件測試常見問題

軟件測試常見問題

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

1、怎樣描述一種缺陷？

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

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

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

水平高下O

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

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

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

是什么問題。

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

要供程序員進(jìn)行分析，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

稍稍平衡某些。

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

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

高質(zhì)量。

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

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

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

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

試。

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

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

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

門造車”的情形。

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

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

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

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

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

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

的錯(cuò)誤。

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

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

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

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

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

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

在心理上得到某些安慰。

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

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

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

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

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

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

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

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

碼的測試工作。

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

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

7、測試的目的是什么？

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

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

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

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

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

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

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

缺陷。

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

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

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

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

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

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

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

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

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

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

無法保證可以發(fā)現(xiàn)所有的錯(cuò)誤。尚有就是一般狀況下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)出比的原則：不充足的測試是不負(fù)責(zé)任的：過度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多少。

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

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

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

2.測試管理部分

1、測試負(fù)責(zé)人要進(jìn)行嚴(yán)格的測試進(jìn)度跟蹤嗎？

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

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

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

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

工作：

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

?每個(gè)測試員提交的缺陷狀況：

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

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

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

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

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

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

或無效。

3、怎樣處理測試人員的流動(dòng)問題？

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

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

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

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

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

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

作。

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

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

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

象？

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

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

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

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

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

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

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

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

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

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

往往臨時(shí)找?guī)追N程序員充當(dāng)測試人員。也有些單位盡管認(rèn)識到了組建測試團(tuán)體的重要性，但

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

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

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

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

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

些自動(dòng)化測試工具運(yùn)用嫻熟或能輕而易舉地編寫自動(dòng)化測試腳本等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

處理這種問題的方案?般有兩個(gè)：

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

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

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

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

員某些功能沒有缺陷。

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

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

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

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

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

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

的減少這種影響。

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

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

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

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

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

損失。

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

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

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

唯一不能做的就是盯著下屬口勺錯(cuò)誤不放。總盯著下屬日勺失誤，是一種領(lǐng)導(dǎo)者日勺最大失誤。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

種狀況下一般效率很低。

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

步還要鼓勵(lì)他們每周不要超過40小時(shí)，甚至可以基于他們在40個(gè)小時(shí)可以完畢的工作量給

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

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

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

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

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

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

事情，尤其是管理人員認(rèn)為對自己負(fù)責(zé)的項(xiàng)目小組承認(rèn)出錯(cuò)也許會(huì)失去尊嚴(yán)。假如我們不是

常常出錯(cuò)，承認(rèn)錯(cuò)誤的時(shí)候其實(shí)可以贏得尊敬.例如我們忘掉一次會(huì)議，然后為此向同事或

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

不管做了什么，不要否認(rèn)或故意忽視自己日勺失誤.故意忽視不會(huì)讓錯(cuò)誤消失，這只會(huì)讓

錯(cuò)誤成長為怪物。

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

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

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

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

一般采用下面幾種措施：

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

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

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

處。當(dāng)每個(gè)人做不一樣的項(xiàng)目，這會(huì)有助于每個(gè)人理解你小組所有的工程。

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

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

各個(gè)方面互相得到提高。

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

非常精通，可以迅速提高整個(gè)測試團(tuán)體的水平。也可以通過測試小組簡介某些朋友來進(jìn)行培

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

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

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

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

14、時(shí)間上不容許進(jìn)行所有測試，測試負(fù)責(zé)人應(yīng)當(dāng)怎樣做？

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

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

容。

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

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

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

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

逐漸來完畢和改善工作：

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

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

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

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

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

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

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

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

理問題。

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

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

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

在這種狀況下，測試負(fù)責(zé)人仍要?jiǎng)褴浖|(zhì)量負(fù)重要責(zé)任。在這種環(huán)境下，測試負(fù)責(zé)人應(yīng)當(dāng)怎

樣開展工作呢？

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

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

漸健全測試體系。

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

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

試工作。

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

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

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

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

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

工作好的多。

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

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

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

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

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

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

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

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

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

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

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

3.測試流程部分

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

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

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

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

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

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

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

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

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

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

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

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

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

行測試。

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

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

試需求的評審。

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

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

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

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

耽誤進(jìn)度。

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

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

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

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

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

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

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

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

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

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

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

起的非整合費(fèi)用。

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

4、什么是冒煙測試？

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

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

不用參照測試用例。

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

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

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

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

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

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

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

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

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

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

6、什么是測試方略？

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

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

等）。

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

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

（2）制定測試啟動(dòng)、停止、完畢原則；

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

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

7、代碼會(huì)審是怎樣進(jìn)行的？

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

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

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

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

代碼審查、單元測試、集成測試和驗(yàn)收測試。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

召開項(xiàng)目會(huì)議進(jìn)行討論，對不一樣打勺問題采用不一樣口勺處理方式：

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

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

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

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

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

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

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

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

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

首先要對?此類缺陷進(jìn)行分析：

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

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

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

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

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