如何寫一份靠譜的軟體測試計劃

(一)——萬事開頭難

測試計劃應該是整個測試流程中第一份測試文檔了，但是一般情況下去不是測試人員學習的第一站。或許是因為萬事開頭難的緣故，測試計劃确實挺讓人糾結了。

很多有了一定的經驗的測試人員在教新人的時候第一步都不是按照測試流程先從測試計劃開始，而是讓從測試用例的執行開始——這雖是無奈之舉，但是對于測試新手來講，還是可以學習很多東西的。閑話扯得有點遠，回到我要介紹的正題上面來，計劃測試。

對，

是計劃測試，不是測試計劃。盡管我們剛才讨論了一些關于測試計劃的内容。但是我們需要關心的的确是計劃測試，而不是測試計劃。永遠要記住，我們是在做測

試，而不是在完成文檔，盡管我們經常需要諸如測試計劃測試用例測試報告之類的各種各樣的文檔，但是那些都不是測試的本質。

既然是計劃測試，那麼我們首先要搞明白測試到底要幹什麼。筆者将它抽象概括為：特定的人在特定的時間在特定的地方做了特定的事情以實作特定的目标。其實任何一項工作都可以抽象成前面這句話，是以我們還需要将這句話與我們所從事的測試工作聯系起來。

所謂人，當然是指測試人員了，而“特定的人”則堅持的是“按能力分工”各司其職的原則。測試用例設計人員做測試設計，測試用例執行人員做執行用例等等。

所謂“特定的時間”，是指我們的測試過程是分成各種階段的，各種階段所側重的測試要點是不一樣的。

所謂“特定的地方”則是指測試環境，這是指我們必須在計劃我們的測試工作的時候就要考慮到某些特殊類型的測試是需要特殊的環境的，這個環境包括了硬體設施(如手機測試你總得拿個手機來試試吧，總不能一直紙上談兵來着)環境，計算機硬體環境和軟體環境。

所謂“特定的事情”即是指我們測試技術本身了，也就是諸如測試用例設計，測試用例執行，寫測試代碼，部署測試環境等等。

所

謂“特定的目标”即是指我們測試的目的。測試是需要成本的，人力物力都是需要的，既然我們對測試有投入那麼我們是期望獲得一些東西的。測試最常喊的口号是

改善品質水準，也有一些還在喊保證品質的，這就是我們所謂“目标”。不過，可惜的是這些口号并沒有多大的用處，因為在實際的軟體項目中我們更加看重的則是

可度量的測試工作，也就是說我們要由一個可度量的“目标”——亦即“特定的目标”——可能是發現了多少bug可能是測試覆寫率達到了多少等等。

我

們在計劃測試的時候，需要考慮的不僅僅是測試本身，從上面的分析可以看出，我們要關注“人、時、地、事、責”，也就是古代中華所講究的“天時地利人和”之

類的東西。需要指出的是，在我們計劃測試的過程中，最常被人忽略的就是我們測試應該達到什麼目标這個問題了。在計劃測試的時候，切記要約定好測試的目标，

這一目标反映在測試計劃文檔中即“測試結束标準”。

關于計劃測試的内容有很多，在接下來的文章中，筆者将逐一展開與大家分享。

(二)——測試計劃

在前一篇文章中，我們提到了計劃測試要考慮到人、事、時等諸多問題，也提到了計劃測試重在計劃這個過程而不在測試計劃這個文檔。

這

篇文章卻要專門讨論一些測試計劃相關的話題。網絡上現在已經泛濫了關于測試計劃的模闆——用泛濫隻是表示很多，并沒有貶損的意思，筆者才疏一時想不到好的

詞語——這些模闆對于制作一份測試計劃文檔來講非常有用，但是生搬硬套這些文檔卻并不能幫助我們很好的計劃我們的測試工作，但是這些測試計劃中的主題卻可

以很好地幫助我們計劃我們的測試工作并有效避免疏漏。

我并不會給出一份我所常用的測試計劃模闆，因為這些模闆實在已經太多，已經夠用了。筆

者在測試工作中，曾經寫出兩種測試計劃，一種類似于目前網絡上流傳的版本，另外一種則是在筆者的某篇blog文章中提到的所謂“實用主義測試計劃”——事

實上是更接近測試設計書的一個文檔，但是确實有些公司把它稱之為測試計劃，而在本系列文章中筆者将不再讨論這種測試計劃，也不會考慮細到“怎樣設計某個功

能的測試用例”的程度的計劃工作。#p#分頁标題#e#

本文前面提到，網絡上流傳的測試計劃有很多，但是雷同的也多，往往有些測試人員随便

到網絡上找幾個測試計劃的模闆，然後東拼西湊便可以作出一份像模像樣的測試計劃出來。筆者結合自己的經驗以及一些相關資料(當然包括網絡上流傳的諸多測試

計劃模闆)，列出了測試計劃中有關計劃的相關主題：

測試結束标準

一些相關約定，部分模闆中添加入“術語”一欄

測試工作中産生的文檔及定義(測試用例文檔，缺陷報告文檔等)

測試工作個團隊之前的協調工作，主要包括開發組需要對測試組提供的相關幫助

測試的範圍

測試的時間安排(時間進度表)

測試的政策

測試過程中的資源要求

測試人員的任務分派

測試中可能遇到的風險等問題

測試工作的度量和統計

測試工具相關的計劃

等等。

以

上這些主題都是常見且有助于我們做好計劃工作的内容，至于測試費用等的計劃，筆者認為适當估計但不要過分追求，因為在實際的操作過程中，測試工作延期、測

試工具購置、人員流動造成的教育訓練費用等會打亂這個計劃，并且在測試計劃中列出的費用是不會跟财務直接挂鈎的，具體費用還得依照公司專用流程，是以“測試費

用”這類主題在筆者計劃測試的過程中不會考慮太多。

PS：2009-3-9更新：

測試計劃有三重境界：

第一重：什麼都有用

第二重：什麼都沒用

第三重：僅部分有用

第四重：什麼都有用

第五重：什麼都沒用

(三)——人

在本系列文章中的第一篇，筆者就提到了計劃的實質是“特定的人在特定的時間在特定的地方做了特定的事情以實作特定的目标”,在上一篇文章的回複中，洋芋老粗回複了對于測試計劃的看法，也就是5W1H定義：

< WHY：為什麼要寫測試計劃;

< WHAT：測試什麼;

< WHEN：測試不同階段的起止時間;

< WHERE：文檔放哪;

< WHO：哪些人去做;

< HOW：怎麼測試;

個定義相對于我的來說，對于測試計劃定義得更加詳細。不過，正像筆者在部落格簽名中所宣稱的那樣：來自草根的實用主義。是以，5w1h定義就不适合三五個人

十來杆搶的軟體作坊了。對于很多剛剛起步測試活動(近兩年才擁有“專門測試人員”，注意是“專門”而不一定是“專業”)的公司來講——而這種公司，就筆者

接觸的一些同仁口中所述，在中國還不在少數——或許一些簡化版的東西會更适合現在的他們，等到漸漸成長起來，我們才逐漸步入正軌。本文中筆者繼續自己的草

根實用主義，分享自己的關于計劃測試活動中人的一些拙見。

這陣子軟體相關論壇上都多多少少有人提到了工具與人的關系，在筆者看來這是一個很扯淡的問題，人的作用是不可能被工具取代的，人之是以為人而不是跟其他動物一樣處于原始的生存狀态，是因為人會“使用”工具。不過關于人和工具的那點兒事，則是後話了。

中

國有句老話“養兵千日，用在一時”。這句話往往是在臨戰的時候将軍(測試負責人)對戰士(普通測試人員)說的。中國古代還有一個方法叫做“戰時兵閑時農”

的政策，即我們廣大的勞動人民在沒有戰争的時候安心種我們的地，一旦戰争爆發或者國家需要的時候我們就披上盔甲去作戰。這兩句話給我們一個提示：我們應該

培養我們的測試人員或者說我們的測試隊伍。

先拿“養兵千日用在一時”來講，正如我上面提到的，往往在臨戰的時候大家才想起這句話，可是我們

不妨倒過來想一想，一時的用是需要千日的積累的。這也是在提示我們，一支優秀的測試隊伍的每個人都應該是優秀的并且我們需要在“用一時”之前好好“養千

日”。這種積累不是一天兩天可以形成的，正所謂冰凍三尺非一日之寒。為什麼要在談論計劃測試的時候談論這個問題呢?原因在于“巧婦難為無米之炊”，我們在

做計劃的時候如果發現沒有一個可用之才，那我們的計劃怕是做不下去了，或者我們隻有準備另外招新人到行伍中間來，亦或者隻能外包測試給專業隊伍，這無疑又

增加了項目的風險，因為新人或者其他隊伍使我們不了解的，他們會做成什麼樣子隻有老天知道，當我們把命運交給老天的時候，這相當于在玩火。我們需要把“養

千日兵”拉到我們的計劃中來，從更加長遠的角度來計劃一下我們的測試工作，測試方向等等。對于人才的培養，一般使用的是人盡其才的分工制度，即某一個或者

一些人熟練掌握某一些測試技能，并對其他技能有所了解，最理想的情況下，我們在測試的方向(或者說是本公司主要的開發方向相關聯的各個測試技術方面)都有

“專家”，這樣才可以保證一個測試隊伍可以應付不可預知的測試任務。#p#分頁标題#e#

對于草根一族來講，一開始公司很可能就你一個測試人員，有幾種情況：

< 公司将“建立一支專業的軟體(測試)隊伍”的艱巨任務寄托在你身上時，先不要沾沾自喜襲擊已經被boss重視了;

< 公司隻是拿你來标榜自己擁有了測試，拿你來寫測試計劃，測試報告等送出給客戶看的文檔的專業測試——文檔——人員

上

面兩種是比較常見的情況，在筆者看來，這兩種情況都很好創造了給你學習的機會，第一種情況你可以打着公司的“建立一支專業的軟體(測試)隊伍”旗号學習;

第二種情況來講，如果僅僅是寫文檔的話，那剩餘的時間就可以好好利用下來了，而目的在于你想提高自己的技能。而我們的學習方向，筆者大概歸納一下：

< 測試理論(包括測試基本概念，流程，管理等等内容。對于測試來講，這才是基本)

< 測試文檔 (雖然網絡上的文檔中的内容對于目前的你來說不可能完全有用，但是知道一份專業或者說完整的文檔是怎麼寫的也是必要的)

< 測試工具(對于剛起步的測試人員，如果你不是開發大牛，建議你還是先使用别人已經寫好的工具)

< 開發知識 (有則加之，無則添之，總是是要學，因為這一點是為将來打算，這些知識有助于我們更好地測試)

筆

者在文章開頭提到了人與工具的問題。現在各種各樣的測試工具很多，有關于性能的測試工具，有關于功能自動化的測試工具等等。不過昨天看到一篇博文，博文作

者深感目前幾乎所有人讨論的問題都是測試工具怎麼用，而關于測試工具開發相關的文章卻很少，筆者也認為這是一個不正常的現象。的确，對于大多數軟體項目組

來講，自己開發一個性能測試工具并不是一個現實的想法，又鑒于性能測試的重要性，在測試組中擁有掌握主流性能測試工具的專家是很迫切的需求。如果可以的

話，我們擁有自動化測試工具的專家，我們擁有自動化測試工具自主開發的專家等等這些都是很有用的。不過這些專家的培養的順序也要順勢而行，不僅急不得而且

也急不了。

當一個優秀的測試團隊成立起來之後，“米”的問題就解決了，這個時候再來針對某一個具體的項目考慮怎樣“炊”的問題就簡單很多

了。簡單，并不代表可以不費吹灰之力就可以把事情擺平了。要知道，人是一個複雜的動物，人的心情會有陰晴圓缺，人會有喜怒哀樂，關于這些跟技術不搭調的問

題筆者就不扯了，畢竟筆者的人生閱曆還沒有精彩到可以教讀者怎麼做人的地步~關于計劃測試中人有關的話題，在本系列的後續文章中會結合“特定的事”“特定

的時間”等等繼續探讨。

(四)——地

正所謂，天時地利人和，前面的一片裡面筆者花費了大堆口水在“用兵一時，養兵千日”的怎麼“養兵”和“兵”自己怎麼實作自我修行。 人有了，該是考慮“地利”的問題了。所謂地利，即指軟體的測試環境，這與開發環境有着很大的不同，同時也保持了一定的聯系(廢話)。

測試不會憑空出現，正是因為之前有過太多的教訓，人們開始對品質重視起來。從這個意義上來講，相關組織是為了避免損失而測試，而減少支出其實是賺了錢，是以他們進行測試是為了擷取利潤的。從另外一個方面來看，測試也要投資，而測試環境則在這些支出中免不了分一杯“羹”。

先看一個筆者趕制的一個草圖

對于上面的圖，簡單說明一下，或者“按圖索骥”吧。 在我們計劃測試的過程中，我們使用由頂向下的分析政策。

所謂測試環境(我們這裡指的是實體意義上的環境)，對于軟體測試來講“咔嚓”一聲分成兩半：硬體環境和軟體環境。

把硬體環境拿出來講，包括了測試項目依賴的硬體環境，測試工作本身依賴的硬體環境。

謂測試項目依賴的硬體環境，舉例來講我們測試一個手機作業系統，總得要拿出個手機來試一試吧;如果拖拉機也需要軟體配備，那麼一台拖拉機也是需要的，另外

還需要弄一個庫房或者至少一個空地來放這個拖拉機;所謂測試工作本身依賴的硬體環境，至少得一台測試用的機器吧，對于特殊要求，比如開發一個嵌入式程式用

來監控室内二氧化碳的濃度，這個時候一個特殊的工作室可能也是必要的，至少有一個工具可以改變二氧化碳濃度，有個地方可以困住這些二氧化碳吧。關于機器，

我們還需要考慮到機器的配置等等問題。#p#分頁标題#e#

接着就是軟體環境了，跟硬體環境一樣，包括了測試項目依賴的軟體和測試工作本身依賴的軟體，當然最重要的是要有個作業系統，還要搭上待測的應用程式。

關

于待測應用程式就不講了，想想如果沒有待測程式那我們還測什麼啊，是不?測試項目依賴的軟體，這裡面的彎彎繞就顯得多了一點了。首先，待測程式引用或者操

作的一些應用程式得準備齊整，比如說某應用程式用于監測某個人每天打開了多少次Outlook并收發了多少郵件，如果機器上沒有裝上outlook的那我

們就隻能測試沒有outlook下該應用程式的的表現這一種情況了，雖然這也是一個很重要的用例，但是更多的有用的用例還是需要我們配備上

outlook來測測的。其次待測程式運作的平台，.NET開發的你總得安裝上相應的.NET

Framework吧，web應用程式沒個浏覽器也是不行的。

測試工作本身依賴的軟體，說明白點主要就是測試工具了，這裡面的彎彎繞太多，筆者就不繞進去了。

作業系統，對于基于windows作業系統的軟體，我們就需要考慮到微軟這些年來給我們貢獻的這麼多版本，如果考慮到其他作業系統，我們就不得不考慮到蘋果等等的貢獻了。

總

結一下，對于測試人員來講，在項目裡面不需要考慮到所有的部分(圖的葉子部分)，但非葉子節點部分還是得好好琢磨琢磨。對于開發人員來講，比較常出現的一

個情況是軟體工作的環境問題：應用Team

Foundation管理團隊項目的時候，項目開發人員A引用了外部DLL(假設為C.DLL)，當簽入源代碼的時候這個DLL是不被簽入到TFS上的，

這就會導緻伺服器上的版本編譯不通過，提示無法找到DLL之類的錯誤資訊。這是一個常見的環境錯誤。另外，如果項目組成員使用的開發環境不一緻，也可能導

緻應用程式內建失敗或者BVT運作不通過;如果開發團隊開發環境一緻，那麼在對應用程式有相容性要求的時候，相關的系統相容性測試是必需的。

(五)——時

到

了“時”了，這是計劃測試過程中最讓人糾結的地方了。計劃本來就是一件很麻煩的事情，關鍵點就在于計劃的時候很難拿捏準時間的長度。在一本稱之為《軟體工

程中的事實與謬誤》的書籍中，作者提到一條軟體項目走向失敗的兩大因素中的一條就是估算不準，由此可見計劃之難了。Aaron現在對于時間計劃搞得也是沒

模沒樣。

初一的時候計劃在十五月圓之夜一起賞月對飲，可是天有不測風雲，到了十五那天天氣轉陰了，月亮連個影子都沒有更不要提月圓了。在項

目中也會經常遇到這種情況，我們預計某年某月某日我們實作某項功能，可是等真的到了那一天，才發現原來我們想象中的那項功能依然隻能存在與想象之中了。

那我們怎麼做時間計劃呢? 在Aaron看來，因項目性質而異，要知道我們從事的項目大緻可以分為兩種：産品性質的和外包性質的。這兩種性質的項目對于時間的要求，對于測試強度的要求是大不一樣的。

對

于一般外包項目來講，對于測試要求相對較低，而時間是固定的。目前大多數标榜使用螺旋開發的團隊其實隻是變相的甚至是變質的瀑布模型，對于測試的現狀更是

如此。測試先行，測試與項目同時啟動在大多數項目中都隻是一句口号而已，因為大家心裡都明白，口号是不要錢的，是以空喊口号這種最廉價的朝臉上貼金的方式

廣受軟體作坊主們的歡迎甚至推崇。廢話不扯了，對于這種項目的測試工作來講，一般是标準的段段式的，即計劃測試，測試用例設計，測試用例執行及bug管

理，測試報告送出等等階段。這就好弄多了，根據經驗(如果一點經驗都沒有，那還有直覺)我們把這幾個階段換算成比例，然後把測試總時間瓜分了，需要提醒大

家的就是記得在瓜分之後留點“緩沖時間”來，否則到時候出了點意外就麻煩了，記住是在每段時間之後加上一個緩沖期，而不是最後加上一次。

于産品來講，測試要求會比較高，時間當然也是需要考慮的，套用IT界最常被引用的一句話，“在這個瞬息萬變的時代”，把握時機對于一個産品來講無疑是很重

要的。不過，由于衆公司都不願意自己的産品一出生生了滿身毒瘡——bug。輕則産品銷量受損，重則産夭折，甚至嚴重影響公司形象乃至導緻公司運轉等嚴重問

題。這個時候我們還是先将測試分段，對于這種項目，我們首先站在測試品質的角度，實事求是按照功能點數目、難度，測試經驗等來估計測試時間，然後将總時間

加起來，如果時間充裕，我們考慮加入更多測試面，如果時間緊迫，我們考慮是否删除部分非核心功能，以降低開發和測試的時間成本，進而為測試品質保駕護

航。#p#分頁标題#e#

回到上面的“月圓之夜”的劇情片段上來，這個片段提醒了我們在時間計劃的時候還有一些問題需要注意。上面提到計劃

失敗是因為“月圓”這個外界因素沒有達到要求，這就提醒我們在計劃的過程中，應當盡量減少對于外界的依賴，如果依賴是必需的，那麼對于依賴可能導緻的意外

我們要多出幾套應急方案。另外，在項目執行過程中，及時檢查項目進度也是必要的，這可以避免我們跑在錯誤的道路上，那樣隻會越錯越遠，這部分不屬于計劃測

試的範疇，是以不做考慮了，如果有興趣可以看一下持續內建相關的資料。

(六)——事

本計劃的上一篇《計劃測試系列(五)——時》，是Aaron的軟肋，寫得很糟糕，但為了保持完整性，Aaron還是貼出來了，看着寥寥幾人的通路量，Aaron覺得應該加油寫出更好的東西出來。廢話少說，開始念叨計劃測試系列中關于事的部分。

測

試是做什麼事的呢?測試是為了……趕緊打住，Aaron指的“事”

是一個測試項目過程中所做的具體的事，不是拿着《軟體測試》或者其他的經典來念句子的。按照Aaron自己在上一篇中的了解，軟體項目流程或者說一個疊代

必定要經過計劃實施總結這幾個階段。對于測試來講我們可以将各個階段再細分，然後就成了下面這個樣子：

制定測試計劃

至于計劃

的作用就不再贅述了，而測試計劃作為計劃測試活動的結晶，理應受到重視。在實際項目中Aaron發現自己寫出來的測試計劃這個文檔本身意義并不大，至少沒

有計劃測試的過程那般有意義。在很多軟體作坊之中，測試計劃自一出生便被打入冷宮，測試計劃的意義僅僅是作坊主朝自己臉上貼金而使用的一種手段。

Aaron推薦的方法是完成一個交差的測試計劃後，維護一個名為測試計劃實質上更像測試設計(Test Design

Spec)的文檔，在整個測試執行過程中該文檔都起着提綱的作用，而且任何讀者都可以通過這份Test Design

Spec中了解Aaron對項目測試的想法和測試思路。Aaron在自己所處的項目組中争取到了Test Design

Spec的Review機會。Aaron是這樣告訴他們的：Aaron擔心自己了解錯誤了PM的意思，Aaron擔心自己想的跟Dev不一樣，Aaron

想先把事情說清楚，是以Aaron要Review。

關于測試計劃的内容Aaron在本系列文章的第二篇也聊過——《計劃測試系列(二)——測試計劃 》。

測試軟體需求

軟

件需求是測試應該覆寫到的地方，這也是為什麼很多軟體方法提倡測試盡早介入到軟體開發程序中的原因之一。對于PM提供的那份Feature清單或者

Feature

Spec，我們應該抱着懷疑的态度，PM不是項目對象領域的專家，他會犯錯，他也會馬虎，他也會有腦袋短路的時候，是以這個時侯需要包括測試人員在内的很

多項目成員來一起檢查這個list或者spec，稱之為Review。對于測試人員及其他參與Review的人員應該實作閱讀文檔并了解項目相關領域的知

識。Aaron剛才提到的Test Design Spec的Review工作比較好地完成了任務，當然限于相關業務知識和經驗，Test Design

Spec的品質會有高有低，Reivew的效果也就可能很不一樣。Aaron建議先不斷錘煉自己的Test Design

Spec之後再送出Review，Aaron自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。

測試用例設計

有關測試用例設計的方法，諸如等價類劃分，邊界值分析，甚至需求矩陣方法等等，Aaron在這裡就不在閑聊，這些東西網絡上已有的文檔要比Aaron講的專業的多，更何況這些内容也不是本文的目的所在。

執行測試

主

要是指測試用例的執行，但是還應該包括測試用例的更新，還包括bug的送出和管理等等内容。Aaron在周期稍長的疊代中還會每周發一個Weekly

Test

Report給項目組成員，幫助他們了解一周來測試工作的進展(以測試用例的數量趨勢，分布)，還會報告目前的bug相關的資訊(Bug總數，趨勢，嚴重

bug分布，區域分布等)，這些對于幫助項目順利進行很有幫助。

報告測試結果

Aaron在周期稍長的疊代中會每周發一個

Weekly Test

bug分布，區域分布等)，這些對于幫助項目順利進行很有幫助。當然，在一個疊代結束或者項目結束之後我們也要送出一個測試報告，這是一份總結性的報

告。#p#分頁标題#e#

安裝測試

考慮軟體所使用的各種硬軟體環境等問題，不僅僅在計劃的過程中展現到，還要檢查部署文檔或者産品說明書中是否包含了安裝環境的定義和介紹。

自動化測試

自動化測試的範疇及涉及的内容很多，根據項目組的實際情況引入和實施自動化測試是軟體測試發展的趨勢。

性能測試

性能測試的範疇又包括了壓力測試，負載測試，性能測試(狹義)，大容量測試等等，這些都要根據實際需求加以取舍和安排，并在計劃中展現出來。

更新(軟體變更)測試

主要指版本的更新測試，尤其對于産品性質的軟體更應該注意這方面的問題。

試工作本身還包括了其他很多内容，Failover和Switchover測試等等很多内容都需要考慮，有時候還要對軟體的邏輯關系，軟體的實體關系進行

測試，還有更常見的界面測試，可用性測試，驗收測試等。這些測試及測試程度的取舍則取決與項目實際情況(時間，成本等等)以及測試人員個人的經驗等等。

(七)——我們什麼時候停止?

我們什麼時候停止我們的項目?我們應該在我們達到目标的時候停止。可是，目标是什麼?Aaron認為所謂目标，即測試應該實作的可度量的要求，這個東西更常見的叫法——測試停止标準。

不

知道有沒有程式員會笑話Aaron說：我們項目就是一個測試人員在點點，甚至不要測試人員點點我們也可以順利傳遞給客戶很有用的産品;不知道有沒有測試人

員會講：我們測試的時候除了用例之外什麼都沒有，更不用說什麼無聊的測試停止标準 =!

不過Aaron告訴你，真要在項目裡面有了這麼個東西，隻會對大家都好。你想，測試停止标準就是那可以止渴的“梅”，有了它咱就有了奮鬥的方向，有了等到

出頭之日的盼頭。同時因為一些項目組中測試标準也會作為版本釋出标準——盡管這兩者還是有差別的——是以測試停止标準對于開發人員和PM也是有用的。

當然，并不是所有的測試停止标準都會有這般功效，在Aaron看來，一個合格的測試停止标準應該滿足一下條件：

在計劃階段盡早訂立測試停止标準

沒有規矩不成方圓，先定下規矩可以幫助我們一開始就計劃的時候就在畫着“方圓”，而不是等畫了一點點之後才發現用的“規矩”不是标準版的，那樣浪費了時間。

測試停止标準應該獲得項目負責人的确認

這一條尤其适用于并不是那麼和諧的項目組以及習慣優柔寡斷的項目負責人上司的項目組。還要注意口說無憑，是以立字為據有時候也是需要的~我們的目的是要使規矩“定”下來。

對于這一條，存在這兩個風險：

一

是容易導緻不和諧：如果項目負責人簽了，感覺像是兄弟們在給他上枷鎖似的，更像是把一些責任推到他的身上去了。(因為存在這樣一種情況，大家訂立一個規

矩，可是後來做的東西讓top

leader不滿意，普通組員這個時候好歹還可以推說我們組的規矩是這樣做的，不需要問，當時簽字确認的項目負責人這下子責任就大了。)

二是因為需求變化，因為測試停止标準要求滿足可度量性(具體内容在後文詳談)，是以可能會涉及到比較細緻的東西，比如某個核心子產品應該怎麼樣才算行——如果在後期需求變了，會不得不更改“定”下來的測試停止标準了。

對于這些風險的預防和處理，Aaron雖然有些心得，但是考慮到各個作坊情況不一樣，Aaron就不誤導各位了。

測試停止标準應該是可度量的

Aaron

看來，對于測試停止标準，“可度量”這個要求是必需的，用抽象的語言來描述測試停止标準是無意義的。如在測試停止标準裡面出現“在适當的時間停止測試”這

句話是不對的，所謂“合适的時間”這類詞彙，要麼讓人不解其意，要麼出現“一千個觀衆眼中有一千個哈姆萊特”這種情況，是以一個準确的定義是必需的。

測試停止标準都是可以達到的

個很容易了解，如果标準裡面出現了要我們三五個人十來杆搶在一個月内造一個跟windows

Xp一模一樣的作業系統給客戶，那定這個标準的人怕是跟Aaron前天一樣SB了~測試停止标準之中切忌出現不可能實作的或者很難達到的目标，比如在測試

停止标準裡面出現“修複所有的bug”這種條文，我們就要考慮實際情況中我們是否可能修複所有的bug，項目的要求是否如此嚴格——所有的bug都必須修

複，而不是被處理(修複，延遲并報告等處理方式)，是否允許部分bug推遲修複?#p#分頁标題#e#

測試停止标準的檢查者

試停止标準作為一個驗收标準，還需要明确規定标準執法者。沒有規矩不成方圓，但是有了規矩而不執行，也是成不了“方圓”的，是以需要執法者或者說護法者，

在這裡展現為檢查和核實我們的測試是否達到了标準。有時候，為了表示民主，大家一起說了算在人數不多的項目組也是一個可取的方式。

Aaron講了自己的一些了解，但看着過于抽象，是以就繼續具體點講一下。開發人員貼code，Aaron這邊沒Code，隻好貼幾張便簽紙

測試标準應該包含的内容：

》有效測試用例（功能）執行率達到X%？

》單元測試代碼行覆寫率達到X%？

》單元測試用例通過率X%？

》單元測試用例設計通過評審

》核心子產品（A,;B,D等子產品）測試覆寫

》所發現缺陷均納入缺陷管理系統

》優先級最高的bug全部修複

》其他bug全部被處理（修複，延遲并報告等處理方式）

》功能測試用例子產品，功能點覆寫率達到？ 按照測試類型來的測試停止标準：

比如單元測試活動在滿足以下所有條件之後可停止：

》核心子產品代碼100％ 經過Code Review

》測試用例執行率100%

》最新版本的單元測試通過率為100%

》單元測試全局代碼行覆寫率不低于80%

》單元測試單個子產品代碼行覆寫率不低于70%

》單元測試中被測單元發現的bug産生率不低于3個/千行代碼

》所有發現缺陷都納入缺陷追蹤系統

》優先級1類bug全部被修複

》優先級2，3類bug全部被處理（修複或者不處理并明确在測試報告指出且獲得通過）

》完成了單元測試報告并通過評審

…… 實際工作中會出現的停止“标準”

測試活動在滿足下列條件之一時需要暫停或者終止：

》新的需求變更過大，測試活動應暫停，待需求定義穩定後繼續；

》測試超過了預定時間，且測試時間不可能繼續增加的情況下應停止測試；

》測試成本增高（Bug發現率低于1個/周，此時所發現缺陷低于預定義的上限）；

》若開發暫停，則相應測試也應暫停，并備份暫停點資料；

》軟體系統通過驗收測試；

》軟體項目在其開發生命周期内出現重大估算和進度偏差，需暫停或終止時，測試應随之暫停或終止，并備份暫停或終止點資料；

》項目負責人申明停止項目；

》團隊集體（開發，管理，測試，市場，銷售人員）同意停止項目（因市場及利益等原因）；

……