CC（Attributes Components Compatibilities）是
Google測試團 隊使用的一種建模方法，用來快速地建立產品的模型，以指導下一步的測試計劃和設計。在Google內部，ACC得到較普遍的應用，一些工程師還開發了支持 ACC模型的Web應用，并將其開源。本文將介紹ACC的內容，所引用的Google+的例子摘錄自《How Google Tests Software》一書。此外，本文還將使用
啟發式測試策略模型（Heuristic
Test Strategy Model，簡稱HTSM）來分析ACC。
運用ACC建模的第一步是確定產品的Attributes（屬性）。按照谷歌的定義，Attributes是產品的形容詞（adjectives），是與競爭對手相區別的關鍵特征。按照敏捷開發的觀點，Attributes是產品所交付的核心價值（values）。從HTSM的角度，Attributes位于HTSM->Quality Criteria->Operation Criteria，隸屬于面向用戶的質量標準。
Google+的Attributes如下：
● Social（社交）：鼓勵用戶去分享信息和他們的狀態
● Expressive（表現力）：用戶可以運用各種功能去表達自我
● Easy（容易）：讓用戶以直觀的方式做他們想做的事
● Relevant（相關）：只顯示用戶感興趣的內容
● Extensible（可擴展）：能夠與Google的已有功能、第三方網站和應用（Application）集成
● Private（隱私）：用戶數據不會泄漏
ACC以Attribute開始，是產品競爭的自然選擇，也符合Google的開發實踐。在Google的項目中，開發人員和測試人員的比例通常是10：1或更高。開發人員會編寫大量的自動化測試用 例，對產品實施周密的測試，因此測試人員主要關注用戶價值和系統級測試。即便如此，測試人員也沒有足夠的資源測試所有用戶行為。所以，測試人員需要通過確 定Attributes來明確產品的核心價值，從而區分出測試對象的輕重緩急（priorities）。獲取Attributes的信息源可以是產品經 理、市場營銷人員、技術布道者、商業宣傳材料、產品廣告等。測試人員也可以使用“賣點漫游”（The Money Tour）來發掘和檢驗產品的賣點。
第二步是確定產品的Components（部件）。Components是產品的名詞（nouns），可以理解為產品的主要模塊、組件、子系統。從 HTSM的角度，Components位于HTSM->Product Elements->Structure和HTSM->Product Elements->Function，即同時具備代碼結構和產品功能的特征。
Google+的Components如下：
● Profile（個人資料）：用戶的帳戶信息和興趣愛好
● People（人脈）：用戶已經連接的好友
● Stream（信息流）：由帖子、評論、通知、照片等組成的有序的信息流
● Circles（圈子）：將好友分組，如把不同的好友歸于“朋友”、“同事”等小組
● Notifications（通知）：當用戶被帖子提到時，向他顯示提示信息
● Hangouts（視頻群聊）：視頻對話的小組
● Posts（帖子）：用戶和好友所發表的信息
● Comments（評論）：對帖子、照片、視頻等的評論
● Photos（照片）：用戶和好友所上傳的照片
Components可以看作功能列表（Function List）的頂層元素，是產品核心功能的清單?！禜ow Google Tests Software》建議Components列表要盡可能簡單，10個Components很好，20個就太多了。其目的是重點考慮對產品、對用戶最重要 的功能與代碼，并避免漫長的Components列表所導致的分析癱瘓。
第三步是確定產品的Compatibilities（能力）。 Compatibilities是產品的動詞（verbs），描述了一個Component提供了何種能力來實現一個Attribute。在HTSM的角 度，Compatibilities位于HTSM->Product Elements->Function和HTSM->Quality Criteria->Operation Criteria->Compatibility，刻畫了產品實現其核心價值的手段。
Google+的Compatibilities矩陣如下：
| Social | Expressive | Easy | Relevant | Extensible | Private |
| Profile | 在好友中分享個人資料和興趣愛好 | 用戶可以在網上表達自我 | 很容易創建、更新、傳播信息 |
| 向被批準的、擁有恰當訪問權限的應用提供數據 | -
用戶可以保密隱私信息 -
只向被批準、擁有恰當訪問權限的應用提供信息
|
| People | 用戶能夠連接他的朋友 | 用戶可以定制個人資料，使自己與眾不同 | 提供工具讓管理好友變得輕松 | 用戶可以用相關性規則過濾好友 | 向應用提供好友數據 | 只向被批準、擁有恰當訪問權限的應用提供信息 |
| Stream | 向用戶提示其好友的更新 |
|
| 用戶可以根據興趣過濾好友更新 | 向應用提供信息流 |
|
| Circles | 將好友分組 | 根據用戶的語境創建新圈子 | 鼓勵創建和修改圈子 |
| 向應用提供圈子數據 |
|
| Notifications |
|
| 簡明地展示通知 |
| 向應用提供通知數據 |
|
| Hangouts | | 加入群聊前，用戶可以預覽自己的形象 | -
只要一次點擊就可以關閉視頻和音頻輸入 -
可將好友加入已有的群聊
|
| -
用戶可以在群聊中使用文字交流 -
YouTube視頻可以加入群聊 -
在“設置”中可以配置群聊的硬件 -
沒有攝像頭的用戶可以音頻交談
| -
只有被邀請的用戶才能加入群聊 -
只有被邀請的用戶才能收到群聊通知
|
| Posts |
| 表達用戶的想法 |
|
| 向應用提供帖子數據 | 帖子只向被批準的用戶公布 |
| Comments |
| 用評論表達用戶的想法 |
|
| 向應用提供評論數據 | 評論只向被批準的用戶公布 |
| Photos | 用戶可以分享他的照片 |
| -
用戶能方便地上傳照片 -
用戶能方便的從其他來源導入照片
|
| 與其他照片服務集成 | 照片只向被批準的用戶公布 |
Compatibilities通常是面向用戶的（user-oriented），反映了用戶視角的產品行為。測試 人員也應該保持Compatibilities矩陣的簡潔，他們應該關注對用戶而言最有價值、最有吸引力的能力，并在合適的抽象層次（right level of abstraction）記錄Compatibilities。最重要的是，Compatibilities應該是可測的（testable），測試人員 能夠設計測試來檢查產品實現了預期的Compatibilities。
有了Compatibilities矩陣，測試團隊就完成初始的測試計劃。這就是前Google測試總監James Whittaker所說的10分鐘測試計劃（The Ten Minutes Test Plan）。其基本思路是專注于核心屬性、核心功能和核心能力，而省略一切不必要的細節。之后，測試團隊會利用矩陣去指導測試設計，通常矩陣中的一條 Compatibility就是一個測試對象、測試策略或測試情景，而復雜的Compatibility會演化出更多的測試設計。
Google所提供的開源Web應用可以分析項目信息，包括測試用例、代碼變更、產品缺陷等，以確定Compatibilities矩陣中的高 風險區域。下圖引用自James Whittaker在GTAC 2010的閉幕演講的幻燈片，是Chrome OS的Compatibilities矩陣的熱點圖（heap map）。圖中綠色表示低風險區域，紅色表示高風險區域，粉紅色和橙色則表示風險居于前兩者之間。測試人員可以根據熱點圖，更好地確定測試優先級，將有限 的資源運用在最需要的地方。
許多團隊的風險分析依賴于測試人員的經驗和猜測，Google的ACC工具則通過分析項目元素（測試用例、代碼變 更、產品缺陷等）來識別風險。這些被分析的元素位于HTSM->Project Environment，是項目環境的一部分。即便不使用Google的工具，測試人員也可以利用電子表格記錄Compatibilities矩陣，并自 行計算各個條目的風險（一些Google的測試人員也是這么做的）。在評估風險時，他可以考慮如下因素：
● 自動化測試用例：該區域有自動化測試用例嗎？測試在定期運行嗎？測試通過率是多少？測試用例覆蓋了哪些方面，沒有覆蓋哪些方面？
● 手動測試：有人手動測試該區域嗎？經過測試，他們對該區域有信心嗎？如果滿分是10分，他們會打幾分？
● 代碼變更：該區域近期存在代碼變更嗎？變更頻繁嗎？變更是新增功能、代碼重構、還是缺陷修復？
● 代碼復雜度：代碼的規模是多少？代碼是否復雜？如果復雜度的滿分是10分，該區域的代碼能得幾分？
● 產品缺陷：該區域的缺陷多嗎？有哪些典型缺陷？哪些缺陷已經被修復？哪些缺陷還沒有被修復？活躍的缺陷是在快速增加還是穩步下降？
在計算此類風險因素時，測試人員可以采用盡可能簡單的度量方法。一方面，簡單的方法更容易解釋度量值的含義，從而有 助于針對度量值采取相應的行動。另一方面，復雜的方法增大了分析的難度，卻往往不能提供更多的收益。通過測試去獲得直接的反饋，并定期重新度量風險因素， 是更注重實效的方法。這也符合ACC的風格：快速的前進，持續的迭代。在測試計劃時，測試人員只要快速地確定Compatibilities矩陣，而不必 擔心遺漏。隨著測試的進展，他會對矩陣做出必要的調整，以優化測試的價值。
版權聲明：本文出自 liangshi 的51Testing軟件測試博客：http://www.51testing.com/?298785