如何在軟件項目中做測試設計

　　項目級測試設計 軟件測試

　　在測試設計階段，要考慮的因素有很多，比如：測試覆蓋率，測試質量標準，信息來源，人員工作態度，技能，團隊組成，計劃的可執行性，測試階段，被測軟件技術背景，被測軟件開發過程，缺陷信息，評價度量元，測試用例粒度，設計用的技術等等。當然，從不同的角度，不同預期，我們需要考慮的因素還有更多。

　　因此，個人認為測試設計不是盡可能多的考慮問題，而是應該把握住最關鍵的因素。作為項目級別的測試設計，繼承項目一次性的特點，同時時間，人員素質，可用資源相對固定。如果計劃這樣的測試任務，我們從哪里入手呢?

　　要是把覆蓋率作為基準的話，測試活動會更容易被評價和度量。從管理上來說，覆蓋率這個標準簡單，有說服力，也容易度量，可以說沒有理由不作為首要指標。不過測試覆蓋率是個計算值，并不準確。舉個例子，一個ERP產品，可以從需求，代碼塊，邏輯路徑，崗位職責，頁面劃分等角度進行覆蓋。但是在項目初期，我們可以按照這些標準決定我們要做那些工作嗎?當然可以，但是像85%，60%，或100%這樣的數據能給我們任何啟發嗎?做一個各種覆蓋率均為100%的設計大概只需要五分鐘，但是它對項目而言是毀滅性的決定，因為它讓我們喪失了集中力量的機會。因此，我覺得覆蓋率是個評價測試方案用的數據，但是不能作為設計測試的指標?；蛘哒f，當你的測試設計中有覆蓋率這樣的數據時，你應該討論數據背后的意義，而不是馬上執行。

　　相比之下，人員情況是個相對穩定又實際的標準。測試人員的多少，測試人員的技術結構，工作的積極程度，已經測試團隊的組成結構，這些因素都會影響到測試的執行能力，以及管理的難度。測試人員能進行什么樣的測試?每天的工作量是多少?能同時進行多少獨立的任務?在那些方面和程度測試人員是可以信任的呢?如何確定測試人員符合項目要求的標準是什么，怎么去檢驗這些標準?人員需要進行什么樣的培訓會對項目更有幫助?

　　另外一個，項目的開發模式，也就是測試的大環境。一個正常的瀑布模式，你應該考慮項目每個階段的聯系，并做到心中有數。需求和設計的聯系緊密嗎?設計能貫徹到編碼嗎，如果不能可以找到相關的負責人嗎?代碼的可測試性能支持單元測試嗎?需求由誰來更新?完整的設計是書面形式的嗎，還是在某個人的腦子里?測試工作的重點是整個開發過程，還是等代碼進入可測試狀態以后?整個開發過程能被暫?；蛉∠麊?，什么樣的情況能導致以上結果，然后呢?

　　測試本身的質量，諸如強大程度，缺陷的信賴度，測試過程的可見性，合適的負責度，以及提升測試強度的方法。這些值能夠度量嗎?我們度量這些值的目的是什么?

　　可能，設計本身需要考慮的東西太多了。大概可分為對內測試活動如何安排以提高效率，對外測試的產出對整個項目，或項目以外能提供什么要的貢獻，包括缺陷本身，缺陷的相關信息(項目級的度量元)，非功能性測試報告，以及為項目提供風險識別的手段。

　　雖然說得很亂，但是這是我為某個項目設計測試時會考慮到的內容。能夠分析哪些因素對測試設計有影響，而那些因素對整體測試沒有影響。之后可能得出一個非常簡單的結論：需要3個初級測試人員，一個中級測試人員作為管理者(實際只有2個人可用1初+1中)，僅僅安裝需求說明進行功能測試，大概進行5個版本的回歸和一定的探索測試。這就是我正在給出的計劃，我個人把這種行為理解為知白守黑。

原文轉自：http://www.anti-gravitydesign.com