本文轉(zhuǎn)自【林子的空間】

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

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

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

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

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

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

01. 常見測試策略

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

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

1. 測什么（What）？

   測什么是指質(zhì)量需求是什么、需要關(guān)注質(zhì)量的哪些方面，比如應(yīng)用的功能范圍、性能、安全、易用性等非功能需求。

2. 怎么測（How）？

   怎么測就是采用什么辦法來幫助系統(tǒng)實現(xiàn)質(zhì)量需求，而不僅僅是手動和自動化的測試方法，也包括一切為質(zhì)量保障服務(wù)的流程、環(huán)境、基礎(chǔ)設(shè)施和人員等。

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

常見測試策略目錄結(jié)構(gòu)

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

測試策略的痛點

長篇大論的文字給人帶來居多不便：

1. 編寫困難

篇幅較長的測試策略文檔要寫好還真不是件容易的事情，尤其是對于理工科出身的不是那么擅長寫作的測試人員來說，更是比較麻煩，成本較高。

2. 不易閱讀

長篇大論的測試策略文檔，要從中快速找出關(guān)鍵信息可沒那么容易，可能一不小心錯過的細節(jié)就是最關(guān)鍵的部分，因為篇幅太長，通常不太重要的信息挺多的。

3. 維護、更新痛苦

策略文檔不可能一成不變，這種篇幅較長的文檔要更新和維護簡直是噩夢。往往剛開始還好，隨著時間推移，更新和維護越來越麻煩。

4. 失去了策略的價值

由于不易閱讀，也不易維護和更新，事實上團隊可能有很多人并不是很清楚策略文檔上的內(nèi)容，這樣的策略文檔形存實亡，不能真正起到策略的指南作用。

5. 反敏捷

敏捷開發(fā)強調(diào)的是縮短反饋周期，快速交付高質(zhì)量的軟件產(chǎn)品?；ㄙM太多精力編寫、維護一份不能起到策略作用的長篇幅文檔，顯然是不利于敏捷的，也是非常痛的。

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

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

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

02. 圖示化測試策略

一頁紙搞定

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

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

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

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

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

例如，藍鯨項目的測試策略如下圖所示：

藍鯨項目測試策略圖

各部分詳細介紹

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

1. 指導(dǎo)性原則

藍鯨項目采用的是敏捷開發(fā)模式，質(zhì)量不是某個單一角色的事情，團隊為質(zhì)量負責(zé)是項目質(zhì)量保障的指導(dǎo)性原則，需要所有團隊成員對此有一致的認識，人人都要有關(guān)注質(zhì)量的意識。更多關(guān)于團隊為質(zhì)量負責(zé)的內(nèi)容，請參考我的博客文章說好的團隊為質(zhì)量負責(zé)呢。

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

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

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

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

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

藍鯨項目開發(fā)生命周期的測試活動

3. 精益測試

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

測試象限

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

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

1. 支持團隊的測試

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

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

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

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

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

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

3. 測試象限的使用

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

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

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

測試分層

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

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

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

藍鯨項目的策略圖里的是當(dāng)前的測試分層結(jié)構(gòu)，類似于蜂巢機構(gòu)，那是因為基于微服務(wù)架構(gòu)的特點，藍鯨項目更多的自動化測試是保障服務(wù)間連通性的API測試部分，而對于單元測試和端到端測試的比例則都有減弱。更多的關(guān)于藍鯨項目測試策略的詳情，請參考我的博客文章微服務(wù)測試的思考與實踐。

4. 測試右移

由于軟件系統(tǒng)所處生態(tài)環(huán)境越來越復(fù)雜，技術(shù)架構(gòu)的演進、業(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)。

藍鯨項目在這方面做了不少工作，更多相關(guān)的詳細內(nèi)容，請參考我的博客文章生產(chǎn)環(huán)境下的QA和QA與Ops通力合作打造反脆弱的軟件系統(tǒng)。

5. 測什么

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

這三個方面的測試類似，都是從需求分析到生產(chǎn)環(huán)境每個環(huán)節(jié)都要考慮相關(guān)測試，做到質(zhì)量內(nèi)建、安全內(nèi)建和持續(xù)的性能測試。關(guān)于功能方面的質(zhì)量內(nèi)建，前面【測試左移和質(zhì)量內(nèi)建】部分有介紹，對于安全和性能方面的策略，可以參考如下圖示，由于篇幅有限，本文不做贅述。

藍鯨項目的跨功能測試

03. 測試策略的正確打開方式

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

目標驅(qū)動

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

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

演進式

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

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

04. 總結(jié)

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

05. 延伸閱讀

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