“測試策略是什么樣的合愈？”
“測試策略嘛颅崩，還不是包括#&~+-=～*-+$這些…”
“你們項(xiàng)目的策略有什么特別的嗎？”
“我們項(xiàng)目嘛吃引，測試策略的內(nèi)容有點(diǎn)多筹陵，從哪說起呢刽锤？”
前面那個(gè)場景有沒有似曾相識(shí)？你是否清楚目前你們正在使用的測試策略是什么樣的朦佩？
一并思、常見測試策略
（一）測試策略的內(nèi)容與形式
我們都知道，測試策略包括以下兩方面的內(nèi)容：
1. 測什么（What）语稠？
測什么是指質(zhì)量需求是什么宋彼、需要關(guān)注質(zhì)量的哪些方面，比如應(yīng)用的功能范圍仙畦、性能输涕、安全、易用性等非功能需求慨畸。
2. 怎么測（How）莱坎？
怎么測就是采用什么辦法來幫助系統(tǒng)實(shí)現(xiàn)質(zhì)量需求，而不僅僅是手動(dòng)和自動(dòng)化的測試方法寸士，也包括一切為質(zhì)量保障服務(wù)的流程檐什、環(huán)境、基礎(chǔ)設(shè)施和人員等弱卡。
為了描述清楚要測的內(nèi)容以及如何來測乃正，測試策略通常篇幅較長的文檔，包含多個(gè)章節(jié)婶博；以文字描述為主烫葬，只加上少量的配圖。
常見策略文檔目錄結(jié)構(gòu)
【圖片來源：https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html】
（二）測試策略的痛點(diǎn)
長篇大論的文字給人帶來居多不便：
1. 編寫困難
篇幅較長的測試策略文檔要寫好還真不是件容易的事情凡蜻，尤其是對于理工科出身的不是那么擅長寫作的測試人員來說，更是比較麻煩垢箕，成本較高划栓。
2. 不易閱讀
長篇大論的測試策略文檔，要從中快速找出關(guān)鍵信息可沒那么容易条获，可能一不小心錯(cuò)過的細(xì)節(jié)就是最關(guān)鍵的部分忠荞，因?yàn)槠L，通常不太重要的信息挺多的帅掘。
3. 維護(hù)委煤、更新痛苦
策略文檔不可能一成不變，這種篇幅較長的文檔要更新和維護(hù)簡直是噩夢修档。往往剛開始還好碧绞，隨著時(shí)間推移，更新和維護(hù)越來越麻煩吱窝。
4. 失去了策略的價(jià)值
由于不易閱讀讥邻，也不易維護(hù)和更新迫靖，事實(shí)上團(tuán)隊(duì)可能有很多人并不是很清楚策略文檔上的內(nèi)容，這樣的策略文檔形存實(shí)亡兴使，不能真正起到策略的指南作用系宜。
5. 反敏捷
工作的軟件高于詳盡的文檔
-- 敏捷宣言
敏捷開發(fā)強(qiáng)調(diào)的是縮短反饋周期，快速交付高質(zhì)量的軟件產(chǎn)品发魄№锬粒花費(fèi)太多精力編寫、維護(hù)一份不能起到策略作用的長篇幅文檔励幼，顯然是不利于敏捷的汰寓。
測試策略的重要性不言而喻，是否可以找到一種更好的表達(dá)方式赏淌，讓測試策略不那么痛呢踩寇？
Jamie McIndoe在"Testing Stuff - A One-Page Test Strategy"中首次提出可以把測試策略圖視化，用一頁紙來搞定六水。我們都知道俺孙，圖示化的表達(dá)方式直觀、清晰掷贾，容易識(shí)別關(guān)鍵信息睛榄，并且易于記憶。如果能夠用圖示化的方法將測試策略在一頁紙上搞定想帅，一定非常棒场靴。
下面一起來看看圖示化表達(dá)的測試策略是什么樣的。
二港准、圖示化測試策略
（一）一頁紙搞定
顧名思義旨剥，圖示化就是用圖來描述測試策略的內(nèi)容，但并不是把原來文字描述的每個(gè)章節(jié)直接翻譯成圖浅缸。我們考慮用圖來表示測試策略的各個(gè)關(guān)鍵組成部分轨帜，并且繪在一頁紙上。
當(dāng)然衩椒，一頁紙的測試策略只是將關(guān)鍵信息以圖示化的方式呈現(xiàn)出來蚌父，并不是整個(gè)測試策略的全部，在一頁紙的背后是團(tuán)隊(duì)的充分溝通和對策略各個(gè)方面達(dá)成的一致認(rèn)識(shí)毛萌，是需要團(tuán)隊(duì)一起來做很多工作的苟弛。這種高度簡化的呈現(xiàn)形式，是為了給團(tuán)隊(duì)更多的討論空間阁将，一頁紙也更易于修改膏秫，從而更能適應(yīng)變化，真正滿足需求做盅。
基于Jamie McIndoe的可視化測試策略思想荔睹，我建議的測試策略圖包含下列信息：
- 指導(dǎo)性原則：團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)
- 測什么：可能包括功能狸演、性能和安全等
- 如何測：測試左移、精益測試僻他、測試右移宵距，涵蓋測試流程、測試類型吨拗、測試方法等
例如满哪，藍(lán)鯨項(xiàng)目的測試策略如下圖所示：
圖2 藍(lán)鯨項(xiàng)目策略圖
（二）各部分詳細(xì)介紹
下面，我們來看看該測試策略各組成部分的具體含義劝篷。
1. 指導(dǎo)性原則
藍(lán)鯨項(xiàng)目采用的是敏捷開發(fā)模式哨鸭，質(zhì)量不是某個(gè)單一角色的事情，團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)是項(xiàng)目質(zhì)量保障的指導(dǎo)性原則娇妓，需要所有團(tuán)隊(duì)成員對此有一致的認(rèn)識(shí)像鸡，人人都要有關(guān)注質(zhì)量的意識(shí)。更多關(guān)于團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)的內(nèi)容哈恰，請關(guān)注我的另一篇文章《說好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢只估？》
2. 測試左移與質(zhì)量內(nèi)建
敏捷測試最關(guān)鍵的兩點(diǎn)就是盡早測試和頻繁測試（Test early, test often），也就是測試左移與質(zhì)量內(nèi)建的思想着绷。
測試左移要求在需求分析階段開始對需求本身的合理性進(jìn)行驗(yàn)證蛔钙，不僅要正確的構(gòu)建產(chǎn)品，更重要的是構(gòu)建正確的產(chǎn)品荠医，這就需要把好源頭需求這一關(guān)吁脱。因此，我們可以看到策略里的流程是從需求分析開始的彬向。
質(zhì)量內(nèi)建則是在軟件開發(fā)生命周期的每個(gè)階段都有質(zhì)量相關(guān)的活動(dòng)兼贡，把質(zhì)量融入到開發(fā)的每一個(gè)步驟，通過CI/CD等方式獲取快速反饋娃胆，做好軟件缺陷的預(yù)防紧显，以減輕缺陷暴露太晚帶來的大量修復(fù)成本。藍(lán)鯨項(xiàng)目的開發(fā)生命周期主要體現(xiàn)在圖示的七個(gè)環(huán)節(jié)缕棵，每個(gè)環(huán)節(jié)都有相應(yīng)測試活動(dòng)的開展，并且每個(gè)活動(dòng)都有不同角色的參與涉兽。
圖3 藍(lán)鯨項(xiàng)目生命周期的測試活動(dòng)
3. 測試精益
測試精益可以理解為以業(yè)務(wù)價(jià)值為目標(biāo)招驴，以盡量少的成本交付高質(zhì)量的軟件，也就是說測試要測在能體現(xiàn)價(jià)值的點(diǎn)上枷畏，要做到有效覆蓋别厘、減少浪費(fèi)。藍(lán)鯨項(xiàng)目的策略圖里有兩個(gè)框架幫我我們更有效的測試拥诡，分別是測試象限和測試分層触趴。
（1）測試象限
在Lisa Crispin和Janet Gregory合著的書籍《敏捷軟件測試：測試人員與敏捷團(tuán)隊(duì)的實(shí)踐指南》中氮发，我們看到了敏捷測試象限的介紹。由于該象限框架所起到的作用不僅局限于敏捷的環(huán)境冗懦，我在這里稱之為測試象限爽冕。
測試象限矩陣一共四個(gè)部分，稱為四個(gè)象限披蕉。下側(cè)是面向技術(shù)的測試颈畸，上側(cè)是面向業(yè)務(wù)的測試；左側(cè)是支持團(tuán)隊(duì)的測試没讲，右側(cè)則是評價(jià)產(chǎn)品的測試眯娱。
a. 支持團(tuán)隊(duì)的測試
支持團(tuán)隊(duì)的測試是用來告訴團(tuán)隊(duì)要寫什么代碼，起到明確需求爬凑、輔助設(shè)計(jì)的作用徙缴。其中，第一象限是面向技術(shù)的支持團(tuán)隊(duì)的測試嘁信，主要是TDD于样，幫助構(gòu)建產(chǎn)品的內(nèi)部質(zhì)量，也就是代碼質(zhì)量的保障吱抚，比如單元測試和api測試等百宇；第二象限則是面向業(yè)務(wù)的支持團(tuán)隊(duì)的測試，從更高層次以業(yè)務(wù)專家可以理解的方式確定系統(tǒng)期望的行為秘豹，做到產(chǎn)品外部質(zhì)量的保障携御。
這兩個(gè)象限的測試能夠快速提供反饋信息，并確奔热疲快速的解決問題啄刹，既指導(dǎo)了功能的開發(fā)，又提供了防止重構(gòu)和新代碼的引入而導(dǎo)致不期望行為發(fā)生的安全網(wǎng)凄贩。
b. 評價(jià)產(chǎn)品的測試
程序員編寫的代碼可以使得左側(cè)面向業(yè)務(wù)的測試通過誓军，但也可能沒有產(chǎn)生客戶真正想要的東西，因此還需要第三疲扎、第四象限的評價(jià)產(chǎn)品的測試昵时。
第三象限是面向業(yè)務(wù)的評價(jià)產(chǎn)品的測試，通過模仿真實(shí)用戶使用應(yīng)用的方式椒丧，幫助確認(rèn)是否構(gòu)建了真正需要的產(chǎn)品壹甥；第四象限是面向技術(shù)評價(jià)產(chǎn)品的測試，主要采用工具和相應(yīng)的技術(shù)來評價(jià)產(chǎn)品的性能壶熏、健壯性和安全性等非功能特性句柠，并且在開發(fā)周期的每一步都要考慮這些測試的開展。
這兩個(gè)象限的測試中產(chǎn)生的信息應(yīng)該反饋到象限矩陣的左側(cè)，并用于創(chuàng)建新的測試來驅(qū)動(dòng)下一步開發(fā)溯职，形成良性的增強(qiáng)環(huán)路精盅。
c. 測試象限的使用
象限的順序跟測試執(zhí)行的順序無關(guān)，敏捷開發(fā)往往開始于客戶測試（面向業(yè)務(wù)的測試）谜酒。與測試執(zhí)行時(shí)機(jī)相關(guān)的因素通常有：
- 產(chǎn)品發(fā)布的風(fēng)險(xiǎn)
- 客戶方對產(chǎn)品目標(biāo)的要求
- 是基于遺留系統(tǒng)的開發(fā)還是從零開始構(gòu)建的新系統(tǒng)
- 可利用的測試資源等
測試象限提供一種需要哪些測試來保障質(zhì)量的思考框架叹俏，可以根據(jù)項(xiàng)目具體情況，結(jié)合考慮以開展對應(yīng)的測試甚带。策略圖所示藍(lán)鯨項(xiàng)目的測試象限體現(xiàn)的測試類型跟Lisa書里介紹的就不太一樣她肯，這是根據(jù)項(xiàng)目當(dāng)前跟客戶的合作方式、業(yè)務(wù)需求鹰贵、質(zhì)量要求等來確定的當(dāng)下需要執(zhí)行的測試晴氨，比如其中的安全測試就分為業(yè)務(wù)部分和技術(shù)部分。
（2）測試分層
關(guān)于測試分層的思想碉输，大家可能比較熟悉的是測試金字塔籽前，主要是針對自動(dòng)化測試，根據(jù)測試所能覆蓋的范圍分成不同的層敷钾。金字塔的含義是測試比例的多少枝哄，體現(xiàn)為底層單元測試較多，越往上層測試比例越少阻荒，呈現(xiàn)為金字塔結(jié)構(gòu)挠锥。
越往底層的測試越接近代碼，編寫成本更低侨赡、執(zhí)行速度更快蓖租、定位問題也更準(zhǔn)確，但是離業(yè)務(wù)較遠(yuǎn)羊壹，不能很好的體現(xiàn)業(yè)務(wù)價(jià)值蓖宦；越往上層的測試越接近業(yè)務(wù)，更能反應(yīng)業(yè)務(wù)價(jià)值油猫，但有著不夠穩(wěn)定稠茂、執(zhí)行速度慢沫浆、實(shí)現(xiàn)成本較高的不足哄辣。因此，需要權(quán)衡利弊窑滞，根據(jù)項(xiàng)目具體情況毡证，真實(shí)的目標(biāo)來確定每層測試的比例电爹。
至于具體的比例是金字塔結(jié)構(gòu)，還是蜂巢結(jié)構(gòu)或其他情竹，并不是一定的，也不會(huì)是一成不變的，可能受到價(jià)值目標(biāo)秦效、痛點(diǎn)雏蛮、質(zhì)量要求、技術(shù)架構(gòu)阱州、技能水平等因素的影響挑秉。
藍(lán)鯨項(xiàng)目的策略圖里的是當(dāng)前的測試分層結(jié)構(gòu)，類似于蜂巢機(jī)構(gòu)苔货，那是因?yàn)榛谖⒎?wù)架構(gòu)的特點(diǎn)犀概，藍(lán)鯨項(xiàng)目更多的自動(dòng)化測試是保障服務(wù)間連通性的API測試部分，而對于單元測試和端到端測試的比例則都有減弱夜惭。更多的關(guān)于藍(lán)鯨項(xiàng)目測試分層策略的詳情姻灶，請參考我的博客文章《微服務(wù)測試的思考與實(shí)踐》。
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)境。這就是測試右移的思想鸥昏，其實(shí)也就是生產(chǎn)環(huán)境下的QA(QA in Production)塞俱。
生產(chǎn)環(huán)境有著不同于測試環(huán)境的特點(diǎn)，生產(chǎn)環(huán)境的QA并不是測試環(huán)境的QA的直接后延吏垮，而是需要利用其特點(diǎn)通過技術(shù)手段收集生產(chǎn)環(huán)境一切可利用的數(shù)據(jù)障涯，包括日志、用戶行為惫皱、用戶反饋等像樊，利用這些數(shù)據(jù)來分析和優(yōu)化業(yè)務(wù)以及開發(fā)過程的開發(fā)和測試工作，形成一個(gè)開發(fā)過程與生產(chǎn)環(huán)境信息分析的良性循環(huán)系統(tǒng)旅敷。
藍(lán)鯨項(xiàng)目在這方面做了不少工作生棍，更多相關(guān)的詳細(xì)內(nèi)容，請參考我的另兩篇文章《生產(chǎn)環(huán)境下的QA》和《QA與Ops通力合作打造反脆弱的軟件系統(tǒng)》媳谁。
5. 測什么
之所以把這個(gè)放到最后介紹涂滴，是因?yàn)榍懊娼榻B“怎么測”的各個(gè)部分都已經(jīng)涵蓋到要測試的內(nèi)容，藍(lán)鯨項(xiàng)目的測試內(nèi)容主要有：功能晴音、性能和安全柔纵。
這三個(gè)方面的測試類似，都是從需求分析到生產(chǎn)環(huán)境每個(gè)環(huán)節(jié)都要考慮相關(guān)測試锤躁，做到質(zhì)量內(nèi)建搁料、安全內(nèi)建和持續(xù)的性能測試。
圖4 藍(lán)鯨項(xiàng)目的非功能測試
三、測試策略的正確打開方式
一頁紙搞定的測試策略郭计，優(yōu)勢非常明顯霸琴，比傳統(tǒng)策略文檔更加簡潔、清晰昭伸，關(guān)鍵信息一目了然梧乘。我們再來看一下測試策略圖示化以后，還有哪些需要注意的方面庐杨。
1. 目標(biāo)驅(qū)動(dòng)
雖然上網(wǎng)搜索能找到很多測試策略模板选调，但測試策略不應(yīng)該是千篇一律的，不可以死搬硬套通用的模板灵份。測試策略受到多種因素的影響仁堪，比如：業(yè)務(wù)價(jià)值、質(zhì)量要求各吨、當(dāng)時(shí)痛點(diǎn)枝笨、技術(shù)架構(gòu)、技術(shù)能力揭蜒、工作重心横浑、績效要求、項(xiàng)目狀態(tài)等等屉更。
制定測試策略需要明確目標(biāo)徙融，綜合考慮各種因素，權(quán)衡利弊瑰谜，找到最適合自己項(xiàng)目當(dāng)前狀態(tài)的策略欺冀。也就是說，測試策略應(yīng)該是目標(biāo)驅(qū)動(dòng)的萨脑。
2. 演進(jìn)式
項(xiàng)目處于不同階段會(huì)有不同的質(zhì)量目標(biāo)隐轩，同時(shí)隨著架構(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)容很重要茫孔，需要以價(jià)值目標(biāo)驅(qū)動(dòng)叮喳，持續(xù)度量，并根據(jù)項(xiàng)目特定情況適時(shí)調(diào)整缰贝、演進(jìn)嘲更。策略文檔不要拘泥于形式，利用圖示化的方法揩瞪，直觀、清晰的表達(dá)篓冲，是非常好的組織形式李破，能有效克服常規(guī)文字為主的文檔所帶來的痛，推薦大家使用壹将。
延伸閱讀
1.Jamie McIndoe的一頁紙測試策略：https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
2.說好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢：
https://insights.thoughtworks.cn/team-is-responsible-for-quality/
3.QA in Production：https://martinfowler.com/articles/qa-in-production.html
4.生產(chǎn)環(huán)境下的QA：https://insights.thoughtworks.cn/qa-in-production-practice/
5.QA與Ops通力合作打造反脆弱的軟件系統(tǒng)：https://insights.thoughtworks.cn/anti-fragile-software-system/
文/ThoughtWorks 林冰玉
