測試建模 Google ACC

2021-06-06 02:44:22 字數 3758 閱讀 5891

acc(attributes components compatibilities)是google

測試團隊使用的一種建模方法,用來快速地建立產品的模型,以指導下一步的測試計畫和設計。在google內部,acc得到較普遍的應用,一些工程師還開發了支援acc模型的web應用,並將其

開源。本文將介紹acc的內容,所引用的google+的例子摘錄自《

how google tests software

》一書。此外,本文還將使用

啟發式測試策略模型

(heuristicteststrategy model,簡稱htsm)來分析acc。

運用acc建模的第一步是確定產品的attributes(屬性)。按照

谷歌的定義

,attributes是產品的形容詞(adjectives),是與競爭對手相區別的關鍵特徵。按照敏捷開發的觀點,attributes是產品所交付的核心價值(values)。從htsm的角度,attributes位於htsm->quality criteria->operation criteria,隸屬於面向使用者的質量標準。

google+的attributes如下:

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如下:

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的測試人員也是這麼做的)。在評估風險時,他可以考慮如下因素:

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

軟體測試建模 Google ACC

cc attributes components compatibilities 是 google 測試團 隊使用的一種建模方法,用來快速地建立產品的模型,以指導下一步的測試計畫和設計。在google內部,acc得到較普遍的應用,一些工程師還開發了支援 acc模型的web應用,並將其開源。本文將介紹...

測試建模 功能列表(Function List)

功能列表 function list 是一種功能測試 function testing 的建模方法,在啟發式測試策略模型 heuristic test strategy model 中位於 htsm product elements function 分支中。雖然它只覆蓋了很小的測試領域,不適合作為...

介面測試之資料建模

下面我們從入參到出參,也就是斷言開始分析。入參分正常情況與異常情況兩種 1 必填入參典型值 邊界值內的邊界值 所有入參的邊界值可以形成乙個測試用例來執行,不需要太多,看起來繁瑣 2 可選項預設及部分預設 3 重要入參的各種合法的有效值 4 正常預設值 注意點 1 入參支援多個值時,多值輸入,介面會不...