(一)——萬事開頭難
測試計劃應該是整個測試流程中第一份測試文檔了，但是一般情況下去不是測試人員學習的第一站。或許是因爲萬事開頭難的緣故，測試計劃確實挺讓人糾結了。
很多有了一定的經驗的測試人員在教新人的時候第一步都不是按照測試流程先從測試計劃開始，而是讓從測試用例的執行開始——這雖是無奈之舉，但是對於測試新手來講，還是可以學習很多東西的。閒話扯得有點遠，回到我要介紹的正題上面來，計劃測試。
對， 是計劃測試，不是測試計劃。儘管我們剛纔討論了一些關於測試計劃的內容。但是我們需要關心的的確是計劃測試，而不是測試計劃。永遠要記住，我們是在做測 試，而不是在完成文檔，儘管我們經常需要諸如測試計劃測試用例測試報告之類的各種各樣的文檔，但是那些都不是測試的本質。
既然是計劃測試，那麼我們首先要搞明白測試到底要幹什麼。筆者將它抽象概括爲：特定的人在特定的時間在特定的地方做了特定的事情以實現特定的目標。其實任何一項工作都可以抽象成前面這句話，所以我們還需要將這句話與我們所從事的測試工作聯繫起來。
所謂人，當然是指測試人員了，而“特定的人”則堅持的是“按能力分工”各司其職的原則。測試用例設計人員做測試設計，測試用例執行人員做執行用例等等。
所謂“特定的時間”，是指我們的測試過程是分成各種階段的，各種階段所側重的測試要點是不一樣的。
所謂“特定的地方”則是指測試環境，這是指我們必須在計劃我們的測試工作的時候就要考慮到某些特殊類型的測試是需要特殊的環境的，這個環境包括了硬件設施(如手機測試你總得拿個手機來試試吧，總不能一直紙上談兵來着)環境，計算機硬件環境和軟件環境。
所謂“特定的事情”即是指我們測試技術本身了，也就是諸如測試用例設計，測試用例執行，寫測試代碼，部署測試環境等等。
所 謂“特定的目標”即是指我們測試的目的。測試是需要成本的，人力物力都是需要的，既然我們對測試有投入那麼我們是期望獲得一些東西的。測試最常喊的口號是 改善質量水平，也有一些還在喊保證質量的，這就是我們所謂“目標”。不過，可惜的是這些口號並沒有多大的用處，因爲在實際的軟件項目中我們更加看重的則是 可度量的測試工作，也就是說我們要由一個可度量的“目標”——亦即“特定的目標”——可能是發現了多少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 Report給項目組成員，幫助他們瞭解一週來測試工作的進展(以測試用例的數量趨勢，分佈)，還會報告當前的bug相關的信息(Bug總數，趨勢，嚴重 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個/周，此時所發現缺陷低於預定義的上限）；
》若開發暫停，則相應測試也應暫停，並備份暫停點數據；
》軟件系統通過驗收測試；
》軟件項目在其開發生命週期內出現重大估算和進度偏差，需暫停或終止時，測試應隨之暫停或終止，並備份暫停或終止點數據；
》項目負責人申明停止項目；
》團隊集體（開發，管理，測試，市場，銷售人員）同意停止項目（因市場及利益等原因）；
……
上 面幾張便籤來自網絡和個人實踐，Aaron只是摘選部分，切不可直接拿來作模板，否則就是 Aaron的誤人子弟的罪過了~這幾張便籤紙並不能直接幫助讀者建立起一個適合自己項目的“測試停止標準”，因爲Aaron相信大家的能力。Aaron將 測試停止標準扯到計劃測試系列的目的，是要提醒讀者在計劃的時候就要有看到我們的結果的眼光。項目也好，測試過程也好，都是以結果爲導向的，沒有最後的成 功，中間過程即使很完美，對於項目(產品)自身是沒有任何意義的(大多數情況下，項目成員在吞食失敗的挫折感的同時，至少還收穫了經驗，所以可能還會有人 會享受失敗項目中的“美好的過程”)。