cc（attributes components compatibilities）是
測試團 隊使用的一種建模方法，用來快速地建立產品的模型，以指導下一步的測試計畫和設計。在google內部，acc得到較普遍的應用，一些工程師還開發了支援 acc模型的web應用，並將其開源。本文將介紹acc的內容，所引用的google+的例子摘錄自《how google tests software》一書。此外，本文還將使用
啟發式測試策略模型（heuristic
teststrategy model，簡稱htsm）來分析acc。
運用acc建模的第一步是確定產品的attributes（屬性）。按照谷歌的定義，attributes是產品的形容詞（adjectives），是與競爭對手相區別的關鍵特徵。按照敏捷開發的觀點，attributes是產品所交付的核心價值（values）。從htsm的角度，attributes位於htsm->quality criteria->operation criteria，隸屬於面向使用者的質量標準。
google+的attributes如下：
● social（社交）：鼓勵使用者去分享資訊和他們的狀態
● expressive（表現力）：使用者可以運用各種功能去表達自我
● easy（容易）：讓使用者以直觀的方式做他們想做的事
● 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（人脈）：使用者已經連線的好友
● circles（圈子）：將好友分組，如把不同的好友歸於「朋友」、「同事」等小組
● notifications（通知）：當使用者被帖子提到時，向他顯示提示資訊
● posts（帖子）：使用者和好友所發表的資訊
● photos（**）：使用者和好友所上傳的**
components可以看作功能列表（function list）的頂層元素，是產品核心功能的清單。《how 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
加入群聊前，使用者可以預覽自己的形象
可將好友加入已有的群聊
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矩陣，而不必 擔心遺漏。隨著測試的進展，他會對矩陣做出必要的調整，以優化測試的價值。
測試建模 Google ACC
acc attributes components compatibilities 是google 測試團隊使用的一種建模方法，用來快速地建立產品的模型，以指導下一步的測試計畫和設計。在google內部，acc得到較普遍的應用，一些工程師還開發了支援acc模型的web應用，並將其 開源。本文將介紹a...
逆向建模軟體介紹 建模軟體介紹 1
atomsk軟體簡介 一 atomsk是一款比較適合新手的建模軟體，無論是在安裝方面還是使用方面，都很人性化，而且手冊寫的很全。atomsk軟體在自己電腦和組裡集群的安裝都比較簡單，但是在超算上安裝時，由於許可權問題，可能會出現一些小問題，今天就先介紹下在超算上安裝atomsk 2.將安裝包上傳到超...
軟體測試 軟體測試
通用技能上 1.基本計算機知識 作業系統，資料庫，通訊協議原理，熟悉至少一門程式語言 2.基本軟體測試知識 各種測試理論，測試方 測試用例編寫，缺陷界定標準，軟體質量評估 3.簡單專案管理知識 產品 系統認知 1.熟悉所測產品功能，能夠將產品文件內描述的uc轉化成tc，這個最最基本 2.熟悉所測產品...