一頁紙測試策略 | IDCF

來源：BY林子

作者：林冰玉

【摘要】測試策略文檔通常是篇幅較長、文字為主的形式，編寫成本較高，并且寫完了很少有人去看，形存實亡。本文介紹可視化的方式，將測試策略用圖來表達(dá)，并且在一頁紙上搞定，這樣的策略圖非常清晰，關(guān)鍵信息一目了然，且提供更大的討論空間，防止僵化，真正能夠發(fā)揮策略的作用。

“測試策略是什么樣的？”

“測試策略嘛，還不是包括#&~+-=～*-+$這些…”

“你們項目的策略有什么特別的嗎？”

“我們項目嘛，測試策略的內(nèi)容有點多，從哪說起呢？”

前面那個場景有沒有似曾相識？你是否清楚目前你們正在使用的測試策略是什么樣的？

一、常見測試策略

1.1 測試策略的內(nèi)容與形式

我們都知道，測試策略包括以下兩方面的內(nèi)容：

• 測什么（What）？測什么是指質(zhì)量需求是什么、需要關(guān)注質(zhì)量的哪些方面，比如應(yīng)用的功能范圍、性能、安全、易用性等非功能需求。
• 怎么測（How）？怎么測就是采用什么辦法來幫助系統(tǒng)實現(xiàn)質(zhì)量需求，而不僅僅是手動和自動化的測試方法，也包括一切為質(zhì)量保障服務(wù)的流程、環(huán)境、基礎(chǔ)設(shè)施和人員等。

為了描述清楚要測的內(nèi)容以及如何來測，測試策略通常篇幅較長的文檔，包含多個章節(jié)；以文字描述為主，只加上少量的配圖。

圖片來自網(wǎng)絡(luò)：https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html

1.2 測試策略的痛點

長篇大論的文字給人帶來諸多不便。

• 編寫困難：篇幅較長的測試策略文檔要寫好還真不是件容易的事情，尤其是對于理工科出身的不是那么擅長寫作的測試人員來說，更是比較麻煩，成本較高。
• 不易閱讀：長篇大論的測試策略文檔，要從中快速找出關(guān)鍵信息可沒那么容易，可能一不小心錯過的細(xì)節(jié)就是最關(guān)鍵的部分，因為篇幅太長，通常不太重要的信息挺多的。
• 維護(hù)、更新痛苦：策略文檔不可能一成不變，這種篇幅較長的文檔要更新和維護(hù)簡直是噩夢。往往剛開始還好，隨著時間推移，更新和維護(hù)越來越麻煩。
• 失去了策略的價值：由于不易閱讀，也不易維護(hù)和更新，事實上團(tuán)隊可能有很多人并不是很清楚策略文檔上的內(nèi)容，這樣的策略文檔形存實亡，不能真正起到策略的指南作用。
• 反敏捷：敏捷開發(fā)強(qiáng)調(diào)的是縮短反饋周期，快速交付高質(zhì)量的軟件產(chǎn)品。花費太多精力編寫、維護(hù)一份不能起到策略作用的長篇幅文檔，顯然是不利于敏捷的，也是非常痛的。

測試策略的重要性不言而喻，是否可以找到一種更好的表達(dá)方式，讓測試策略不那么痛呢？Jamie McIndoe在“Testing Stuff - A One-Page Test Strategy”中首次提出可以把測試策略圖視化，用一頁紙來搞定。

我們都知道，圖示化的表達(dá)方式直觀、清晰，容易識別關(guān)鍵信息，并且易于記憶。如果能夠用圖示化的方法將測試策略在一頁紙上搞定，一定非常棒。

下面一起來看看圖示化表達(dá)的測試策略是什么樣的。

二、圖示化測試策略

2.1 一頁紙搞定

顧名思義，圖示化就是用圖來描述測試策略的內(nèi)容，但并不是把原來文字描述的每個章節(jié)直接翻譯成圖。我們考慮用圖來表示測試策略的各個關(guān)鍵組成部分，并且繪在一頁紙上。

當(dāng)然，一頁紙的測試策略只是將關(guān)鍵信息以圖示化的方式呈現(xiàn)出來，并不是整個測試策略的全部，在一頁紙的背后是團(tuán)隊的充分溝通和對策略各個方面達(dá)成的一致認(rèn)識，是需要團(tuán)隊一起來做很多工作的。這種高度簡化的呈現(xiàn)形式，是為了給團(tuán)隊更多的討論空間，一頁紙也更易于修改，從而更能適應(yīng)變化，真正滿足需求。

基于Jamie McIndoe的可視化測試策略思想，我建議的測試策略圖包含下列信息：

• 指導(dǎo)性原則：團(tuán)隊為質(zhì)量負(fù)責(zé)；
• 如何測：測試左移、精益測試、測試右移，涵蓋測試流程、測試類型、測試方法等；
• 測什么：包括功能、性能和安全等。

下面將以藍(lán)鯨項目為例來介紹這幾個部分的內(nèi)容。關(guān)于藍(lán)鯨項目，是一個歷經(jīng)10年的離岸交付項目，采用的是敏捷開發(fā)的模式，每四到五周一次發(fā)布，遵循敏捷開發(fā)的各種實踐。

例如，藍(lán)鯨項目的測試策略如下圖所示：

2.2 各部分詳細(xì)介紹

下面，我們來看看該測試策略各組成部分的具體含義。

2.2.1 指導(dǎo)性原則

藍(lán)鯨項目采用的是敏捷開發(fā)模式，質(zhì)量不是某個單一角色的事情，團(tuán)隊為質(zhì)量負(fù)責(zé)是項目質(zhì)量保障的指導(dǎo)性原則，需要所有團(tuán)隊成員對此有一致的認(rèn)識，人人都要有關(guān)注質(zhì)量的意識。

2.2.2 測試左移與質(zhì)量內(nèi)建

敏捷測試最關(guān)鍵的兩點就是盡早測試和頻繁測試（Test early, test often），也就是測試左移與質(zhì)量內(nèi)建的思想。

測試左移要求在需求分析階段開始對需求本身的合理性進(jìn)行驗證，不僅要正確地構(gòu)建產(chǎn)品，更重要的是構(gòu)建正確的產(chǎn)品，這就需要把好源頭需求這一關(guān)。因此，我們可以看到策略里的流程是從需求分析開始的。

質(zhì)量內(nèi)建則是在軟件開發(fā)生命周期的每個階段都有質(zhì)量相關(guān)的活動，把質(zhì)量融入到開發(fā)的每一個步驟，通過CI/CD等方式獲取快速反饋，做好軟件缺陷的預(yù)防，以減輕缺陷暴露太晚帶來的大量修復(fù)成本。

藍(lán)鯨項目的開發(fā)生命周期主要體現(xiàn)在下圖的七個環(huán)節(jié)，每個環(huán)節(jié)都有相應(yīng)測試活動的開展，并且每個活動都有不同角色的參與。

2.2.3 精益測試

精益測試可以理解為以業(yè)務(wù)價值為目標(biāo)，以盡量少的成本交付高質(zhì)量的軟件，也就是說測試要測在能體現(xiàn)價值的點上，要做到有效覆蓋、減少浪費。藍(lán)鯨項目的策略圖里有兩個框架幫我我們更有效的測試，分別是測試象限和測試分層。

1）測試象限

在Lisa Crispin和Janet Gregory合著的書籍《敏捷軟件測試：測試人員與敏捷團(tuán)隊的實踐指南》中，我們看到了敏捷測試象限的介紹。由于該象限框架所起到的作用不僅局限于敏捷的環(huán)境，我在這里稱之為測試象限。

測試象限矩陣一共四個部分，稱為四個象限。下側(cè)是面向技術(shù)的測試，上側(cè)是面向業(yè)務(wù)的測試；左側(cè)是支持團(tuán)隊的測試，右側(cè)則是評價產(chǎn)品的測試。

• 支持團(tuán)隊的測試

支持團(tuán)隊的測試是用來告訴團(tuán)隊要寫什么代碼，起到明確需求、輔助設(shè)計的作用。其中，第一象限是面向技術(shù)的支持團(tuán)隊的測試，主要是TDD，幫助構(gòu)建產(chǎn)品的內(nèi)部質(zhì)量，也就是代碼質(zhì)量的保障，比如單元測試和API測試等；第二象限則是面向業(yè)務(wù)的支持團(tuán)隊的測試，從更高層次以業(yè)務(wù)專家可以理解的方式確定系統(tǒng)期望的行為，做到產(chǎn)品外部質(zhì)量的保障。

這兩個象限的測試能夠快速提供反饋信息，并確保快速地解決問題，既指導(dǎo)了功能的開發(fā)，又提供了防止重構(gòu)和新代碼的引入而導(dǎo)致不期望行為發(fā)生的安全網(wǎng)。

• 評價產(chǎn)品的測試

程序員編寫的代碼可以使得左側(cè)面向業(yè)務(wù)的測試通過，但也可能沒有產(chǎn)生客戶真正想要的東西，因此還需要第三、第四象限的評價產(chǎn)品的測試。

第三象限是面向業(yè)務(wù)的評價產(chǎn)品的測試，通過模仿真實用戶使用應(yīng)用的方式，幫助確認(rèn)是否構(gòu)建了真正需要的產(chǎn)品；第四象限是面向技術(shù)評價產(chǎn)品的測試，主要采用工具和相應(yīng)的技術(shù)來評價產(chǎn)品的性能、健壯性和安全性等非功能特性，并且在開發(fā)周期的每一步都要考慮這些測試的開展。

這兩個象限的測試中產(chǎn)生的信息應(yīng)該反饋到象限矩陣的左側(cè)，并用于創(chuàng)建新的測試來驅(qū)動下一步開發(fā)，形成良性的增強(qiáng)環(huán)路。

• 測試象限的使用

象限的順序跟測試執(zhí)行的順序無關(guān)，敏捷開發(fā)往往開始于客戶測試（面向業(yè)務(wù)的測試）。與測試執(zhí)行時機(jī)相關(guān)的因素通常有：

• 產(chǎn)品發(fā)布的風(fēng)險；
• 客戶方對產(chǎn)品目標(biāo)的要求；
• 是基于遺留系統(tǒng)的開發(fā)還是從零開始構(gòu)建的新系統(tǒng)；
• 可利用的測試資源等。

測試象限提供一種需要哪些測試來保障質(zhì)量的思考框架，可以根據(jù)項目具體情況，結(jié)合考慮以開展對應(yīng)的測試。策略圖所示藍(lán)鯨項目的測試象限體現(xiàn)的測試類型跟Lisa書里介紹的就不太一樣，這是根據(jù)項目當(dāng)前跟客戶的合作方式、業(yè)務(wù)需求、質(zhì)量要求等來確定的當(dāng)下需要執(zhí)行的測試，比如其中的安全測試就分為業(yè)務(wù)部分和技術(shù)部分。

2）測試分層

關(guān)于測試分層的思想，大家可能比較熟悉的是測試金字塔，主要是針對自動化測試，根據(jù)測試所能覆蓋的范圍分成不同的層。金字塔的含義是測試比例的多少，體現(xiàn)為底層單元測試較多，越往上層測試比例越少，呈現(xiàn)為金字塔結(jié)構(gòu)。

越往底層的測試越接近代碼，編寫成本更低、執(zhí)行速度更快、定位問題也更準(zhǔn)確，但是離業(yè)務(wù)較遠(yuǎn)，不能很好地體現(xiàn)業(yè)務(wù)價值；越往上層的測試越接近業(yè)務(wù)，更能反應(yīng)業(yè)務(wù)價值，但有著不夠穩(wěn)定、執(zhí)行速度慢、實現(xiàn)成本較高的不足。因此，需要權(quán)衡利弊，根據(jù)項目具體情況、真實的目標(biāo)來確定每層測試的比例。

至于具體的比例是金字塔結(jié)構(gòu)，還是蜂巢結(jié)構(gòu)或其他，并不是一定的，也不會是一成不變的，可能受到價值目標(biāo)、痛點、質(zhì)量要求、技術(shù)架構(gòu)、技能水平等因素的影響。

藍(lán)鯨項目的策略圖里的是當(dāng)前的測試分層結(jié)構(gòu)，類似于蜂巢機(jī)構(gòu)，那是因為基于微服務(wù)架構(gòu)的特點，藍(lán)鯨項目更多的自動化測試是保障服務(wù)間連通性的API測試部分，而對于單元測試和端到端測試的比例則都有減弱。

2.2.4 測試右移

由于軟件系統(tǒng)所處生態(tài)環(huán)境越來越復(fù)雜，技術(shù)架構(gòu)的演進(jìn)、業(yè)務(wù)復(fù)雜度和數(shù)據(jù)量的增加、基礎(chǔ)設(shè)施的發(fā)展帶來更多的不確定性，軟件系統(tǒng)的質(zhì)量保障在測試環(huán)境已經(jīng)搞不定了，我們需要把目光右移到生產(chǎn)環(huán)境。這就是測試右移的思想，其實也就是生產(chǎn)環(huán)境下的QA(QA in Production)。

生產(chǎn)環(huán)境有著不同于測試環(huán)境的特點，生產(chǎn)環(huán)境的QA并不是測試環(huán)境的QA的直接后延，而是需要利用其特點通過技術(shù)手段收集生產(chǎn)環(huán)境一切可利用的數(shù)據(jù)，包括日志、用戶行為、用戶反饋等，利用這些數(shù)據(jù)來分析和優(yōu)化業(yè)務(wù)以及開發(fā)過程的開發(fā)和測試工作，形成一個開發(fā)過程與生產(chǎn)環(huán)境信息分析的良性循環(huán)系統(tǒng)。

2.2.5 測什么

之所以把這個放到最后介紹，是因為前面介紹“怎么測”的各個部分都已經(jīng)涵蓋到要測試的內(nèi)容，藍(lán)鯨項目的測試內(nèi)容主要有：功能、性能和安全。

這三個方面的測試類似，都是從需求分析到生產(chǎn)環(huán)境每個環(huán)節(jié)都要考慮相關(guān)測試，做到質(zhì)量內(nèi)建、安全內(nèi)建和持續(xù)的性能測試。

三、測試策略的正確打開方式

一頁紙搞定的測試策略，優(yōu)勢非常明顯，比傳統(tǒng)策略文檔更加簡潔、清晰，關(guān)鍵信息一目了然。我們再來看一下測試策略圖示化以后，還有哪些需要注意的方面。

3.1 目標(biāo)驅(qū)動

雖然上網(wǎng)搜索能找到很多測試策略模板，但測試策略不應(yīng)該是千篇一律的，不可以死搬硬套通用的模板。測試策略受到多種因素的影響，比如：業(yè)務(wù)價值、質(zhì)量要求、當(dāng)時痛點、技術(shù)架構(gòu)、技術(shù)能力、工作重心、績效要求、項目狀態(tài)等等。

制定測試策略需要明確目標(biāo)，綜合考慮各種因素，權(quán)衡利弊，找到最適合自己項目當(dāng)前狀態(tài)的策略。也就是說，測試策略應(yīng)該是目標(biāo)驅(qū)動的。

3.2 演進(jìn)式

項目處于不同階段會有不同的質(zhì)量目標(biāo)，同時隨著架構(gòu)的演進(jìn)和業(yè)務(wù)的發(fā)展，對軟件系統(tǒng)的質(zhì)量保障工作也需要隨之調(diào)整。因此，測試策略還應(yīng)該是演進(jìn)式的、隨需調(diào)整的。

圖示化的測試策略是高度精簡的，具有更大的討論和發(fā)揮空間，在防止僵化、保持演進(jìn)方面的優(yōu)勢明顯。

四、總結(jié)

測試策略舉足輕重，內(nèi)容很重要，需要以價值目標(biāo)驅(qū)動，持續(xù)度量，并根據(jù)項目特定情況適時調(diào)整、演進(jìn)。策略文檔不要拘泥于形式，利用圖示化的方法，直觀、清晰的表達(dá)，是非常好的組織形式，能有效克服常規(guī)文字為主的文檔所帶來的痛，推薦大家使用。

延伸閱讀

1. 一頁紙測試策略圖解
2. Jamie McIndoe的Testing Stuff - A One-Page Test Strategy：https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
3. 說好的團(tuán)隊為質(zhì)量負(fù)責(zé)呢：https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
4. QA in Production：https://martinfowler.com/articles/qa-in-production.html
5. 藍(lán)鯨項目測試策略之微服務(wù)測試的思考與實踐：https://www.bylinzi.com/2018/06/28/microservices-testing/
6. 生產(chǎn)環(huán)境下的QA：https://www.bylinzi.com/2016/06/13/qa-in-production/
7. QA與Ops通力合作打造反脆弱的軟件系統(tǒng)：https://www.bylinzi.com/2018/10/15/qaops/

7月【冬哥有話說】研發(fā)效能工具專場。今晚8點，極狐(GitLab)解決?案架構(gòu)師-張揚(yáng)老師分享《基礎(chǔ)設(shè)施即代碼的?動化測試探索》，關(guān)注公眾號回復(fù)“效能”可獲取直播地址。

【“研發(fā)效能工具”專場話題一覽】

• 7月8日（已結(jié)束），LEANSOFT-周文洋分享《微軟DevOps工具鏈的 "愛恨情仇"（Azure DevOps）》（公眾號回復(fù)“回放”可獲取回放地址。）

• 7月15日（已結(jié)束），阿里云智能高級產(chǎn)品專家-陳遜分享《復(fù)雜型研發(fā)協(xié)作模式下的效能提升實踐》（公眾號回復(fù)“回放”可獲取回放地址。）

• 7月29日（周四）晚8點，字節(jié)跳動產(chǎn)品經(jīng)理-胡賢彬分享《自動化測試，如何做到「攻防兼?zhèn)洹梗俊?/span>

• 8月5日（周四）晚8點，聲網(wǎng)Agora CICD System 負(fù)責(zé)人-王志分享《從0到1打造軟件交付質(zhì)量保證的閉環(huán)》