測試建模：Google ACC(2)

　　Capabilities通常是面向用戶的(user-oriented)，反映了用戶視角的產品行為。測試人員也應該保持Capabilities矩陣的簡潔，他們應該關注對用戶而言最有價值、最有吸引力的能力，并在合適的抽象層次(right level of abstraction)記錄Capabilities。最重要的是，Capabilities應該是可測的(testable)，測試人員能夠設計測試來檢查產品實現了預期的Capabilities。

　　有了Capabilities矩陣，測試團隊就完成初始的測試計劃。這就是前Google測試總監James Whittaker所說的10分鐘測試計劃(The Ten Minutes Test Plan)。其基本思路是專注于核心屬性、核心功能和核心能力，而省略一切不必要的細節。之后，測試團隊會利用矩陣去指導測試設計，通常矩陣中的一條Capability就是一個測試對象、測試策略或測試情景，而復雜的Capability會演化出更多的測試設計。

　　Google所提供的開源Web應用可以分析項目信息，包括測試用例、代碼變更、產品缺陷等，以確定Capabilities矩陣中的高風險區域。下圖引用自James Whittaker在GTAC 2010的閉幕演講的幻燈片，是Chrome OS的Capabilities矩陣的熱點圖(heap map)。圖中綠色表示低風險區域，紅色表示高風險區域，粉紅色和橙色則表示風險居于前兩者之間。測試人員可以根據熱點圖，更好地確定測試優先級，將有限的資源運用在最需要的地方。

　　許多團隊的風險分析依賴于測試人員的經驗和猜測，Google的ACC工具則通過分析項目元素(測試用例、代碼變更、產品缺陷等)來識別風險。這些被分析的元素位于HTSM->Project Environment，是項目環境的一部分。即便不使用Google的工具，測試人員也可以利用電子表格記錄Capabilities矩陣，并自行計算各個條目的風險(一些Google的測試人員也是這么做的)。在評估風險時，他可以考慮如下因素：

　　自動化測試用例：該區域有自動化測試用例嗎?測試在定期運行嗎?測試通過率是多少?測試用例覆蓋了哪些方面，沒有覆蓋哪些方面?

　　手動測試：有人手動測試該區域嗎?經過測試，他們對該區域有信心嗎?如果滿分是10分，他們會打幾分?

　　代碼變更：該區域近期存在代碼變更嗎?變更頻繁嗎?變更是新增功能、代碼重構、還是缺陷修復?

　　代碼復雜度：代碼的規模是多少?代碼是否復雜?如果復雜度的滿分是10分，該區域的代碼能得幾分?

　　產品缺陷：該區域的缺陷多嗎?有哪些典型缺陷?哪些缺陷已經被修復?哪些缺陷還沒有被修復?活躍的缺陷是在快速增加還是穩步下降?

　　在計算此類風險因素時，測試人員可以采用盡可能簡單的度量方法。一方面，簡單的方法更容易解釋度量值的含義，從而有助于針對度量值采取相應的行動。另一方面，復雜的方法增大了分析的難度，卻往往不能提供更多的收益。通過測試去獲得直接的反饋，并定期重新度量風險因素，是更注重實效的方法。這也符合ACC的風格：快速的前進，持續的迭代。在測試計劃時，測試人員只要快速地確定Capabilities矩陣，而不必擔心遺漏。隨著測試的進展，他會對矩陣做出必要的調整，以優化測試的價值。

原文轉自：http://www.kjueaiud.com