動機(jī)
測試計劃是用來指導(dǎo)測試實施的, 在實踐中, 不妨先考慮如下的幾個問題:
- 在什么時候開始編寫測試計劃? 一般用多長時間來制作出一個測試計劃?
- 在你的項目中結(jié)束時的測試計劃和最初的差異多大? 你會化多少時間來維護(hù)測試計劃?
- 你覺得測試計劃有用嗎?
- 如果僅有很少的資源可用, 你會如何分配測試資源?
如果上述問題能夠引發(fā)你的思考, 說明你是本文的讀者之一.
一份適用的測試計劃
考慮到項目自身的特殊性, 測試計劃的編寫都有"此時此地"的特質(zhì). 但是這并不妨礙我們先定義一個"好用的"測試計劃的通用標(biāo)準(zhǔn):
- 簡單直接, 沒有冗余的累述
- 易于維護(hù)和擴(kuò)展, 在簡單直接的基礎(chǔ)上, 便于在已有的維度上擴(kuò)展
- 可以用來直接指導(dǎo)測試. 測試計劃中包含測試用例
使用ACC編寫測試計劃
ACC是Attribute-Component-Capability的縮寫, 同時也ACC也暗示了編寫測試計劃的順序.
列舉產(chǎn)品特性(Attribute)
每個產(chǎn)品都有其特性, 這個特性用來描述其和同類產(chǎn)品的區(qū)別. 你可以將其理解為產(chǎn)品核心價值. 一般來說都是形容詞. 這部分的效率應(yīng)該是: 10個特性/10~20分鐘
如何得到產(chǎn)品特性?
- 產(chǎn)品文檔
- 產(chǎn)品經(jīng)理
- 開發(fā)人員
- 市場和運營
- 其他廣告文書等
列舉產(chǎn)品模塊(Component)
每個產(chǎn)品都會由一系列的模塊組成, 列出來這些模塊. 一個需要注意的問題是粒度, 不要分的太瑣碎, 保持一個完整的交互單元是最好的. 比如一個博客系統(tǒng)可以大致分成: 新建文章, 瀏覽, 評論等等.
如何得到產(chǎn)品的模塊?
- 開發(fā)人員
- 對于產(chǎn)品的使用經(jīng)驗
列舉功能(Capability)
將前兩步得到的產(chǎn)品特性和模塊組成一個矩陣, 就像下圖的表:
表中的數(shù)字代表你能想到的功能數(shù)量. 你在這一步的任務(wù)就是盡可能多的列舉每個表格中產(chǎn)品應(yīng)該具備的功能.
- 如果你的發(fā)現(xiàn)有的功能無處填寫, 那么就意味著你可能需要添加Attribute或者Component了
- 如果某一個表格中所記載的功能太多了, 遠(yuǎn)遠(yuǎn)大于其他的表格, 同樣意味著可續(xù)需要拆分Attribute或者Component.
- 如果有的表格是空的, 不用擔(dān)心, 可能這個模塊中沒有功能會反應(yīng)當(dāng)前這個產(chǎn)品特性.
同樣將你想到的功能整理成一張表單, 可能會是這樣:
測試分級
從兩個維度來評估每一個表格的重要性: 頻度和影響.
- 頻度是如果這個表格中的功能的用戶使用頻度如何, 很多, 多, 少, 很少.
- 影響是用來評估這個表格中的功能如果出現(xiàn)問題的話, 用戶對產(chǎn)品的信心的影響大小: 再也不用了, 抗議, 吐槽, 忍了.
綜合上面兩個維度的思考, 將表格分成3個或更多的級別: 很重要, 重要 , 一般, 不重要... 一定要用顏色由深到淺, 標(biāo)識出來:
不建議使用完全量化的方法去衡量, 畢竟這是一個相對問題, 我們只需要分清楚誰跟誰比更重要就好了.
測試分級是一個漸進(jìn)的討論過程, 做好分級以后盡快發(fā)出去, 獲得其他人的反饋
如果有可能, 你需要盡可能多的考慮如下人員的意見:
- 產(chǎn)品經(jīng)理
- 開發(fā)人員
- 更高級的管理層
針對不同的分級, 我們需要采取不同的測試策略和資源投入: 主測, 外包, 天使測等
一些想法
ACC是谷歌測試的一個比較好的實踐, 特別是對于互聯(lián)網(wǎng)產(chǎn)品, 快速有效實用. 實際使用中需要注意的是一定要落地成可以指導(dǎo)測試的具體功能, 必要時需要補充用戶的使用場景. 同時, ACC也可以幫助PD, 開發(fā)更好的認(rèn)識產(chǎn)品, 便于統(tǒng)一思路.
