本文轉(zhuǎn)自【林子的空間】
【摘要】測試策略文檔通常是篇幅較長、文字為主的形式忽洛，編寫成本較高，并且寫完了很少有人去看环肘，形存實(shí)亡欲虚。本文介紹可視化的方式，將測試策略用圖來表達(dá)悔雹，并且在一頁紙上搞定复哆，這樣的策略圖非常清晰，關(guān)鍵信息一目了然腌零，并且提供更大的討論空間梯找，防止僵化，真正能夠發(fā)揮策略的作用益涧。
“測試策略是什么樣的锈锤？”
“測試策略嘛，還不是包括#&~+-=～*-+$這些…”
“你們項(xiàng)目的策略有什么特別的嗎闲询？”
“我們項(xiàng)目嘛久免，測試策略的內(nèi)容有點(diǎn)多，從哪說起呢扭弧？”
前面那個場景有沒有似曾相識妄壶？你是否清楚目前你們正在使用的測試策略是什么樣的？
01. 常見測試策略
測試策略的內(nèi)容與形式
我們都知道寄狼，測試策略包括以下兩方面的內(nèi)容：
-
測什么（What）？
測什么是指質(zhì)量需求是什么氨淌、需要關(guān)注質(zhì)量的哪些方面泊愧，比如應(yīng)用的功能范圍、性能盛正、安全删咱、易用性等非功能需求。
-
怎么測（How）豪筝？
怎么測就是采用什么辦法來幫助系統(tǒng)實(shí)現(xiàn)質(zhì)量需求痰滋，而不僅僅是手動和自動化的測試方法，也包括一切為質(zhì)量保障服務(wù)的流程续崖、環(huán)境敲街、基礎(chǔ)設(shè)施和人員等。
為了描述清楚要測的內(nèi)容以及如何來測严望，測試策略通常篇幅較長的文檔多艇，包含多個章節(jié)；以文字描述為主像吻，只加上少量的配圖峻黍。
【圖片來自網(wǎng)絡(luò)：https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html】
測試策略的痛點(diǎn)
長篇大論的文字給人帶來居多不便：
1. 編寫困難
篇幅較長的測試策略文檔要寫好還真不是件容易的事情复隆，尤其是對于理工科出身的不是那么擅長寫作的測試人員來說，更是比較麻煩姆涩，成本較高挽拂。
2. 不易閱讀
長篇大論的測試策略文檔，要從中快速找出關(guān)鍵信息可沒那么容易骨饿，可能一不小心錯過的細(xì)節(jié)就是最關(guān)鍵的部分亏栈，因?yàn)槠L，通常不太重要的信息挺多的样刷。
3. 維護(hù)仑扑、更新痛苦
策略文檔不可能一成不變，這種篇幅較長的文檔要更新和維護(hù)簡直是噩夢置鼻。往往剛開始還好镇饮，隨著時間推移，更新和維護(hù)越來越麻煩箕母。
4. 失去了策略的價值
由于不易閱讀储藐，也不易維護(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á)方式直觀拍屑、清晰，容易識別關(guān)鍵信息坑傅，并且易于記憶丽涩。如果能夠用圖示化的方法將測試策略在一頁紙上搞定，一定非常棒。
下面一起來看看圖示化表達(dá)的測試策略是什么樣的矢渊。
02. 圖示化測試策略
一頁紙搞定
顧名思義继准，圖示化就是用圖來描述測試策略的內(nèi)容，但并不是把原來文字描述的每個章節(jié)直接翻譯成圖矮男。我們考慮用圖來表示測試策略的各個關(guān)鍵組成部分移必，并且繪在一頁紙上。
當(dāng)然毡鉴，一頁紙的測試策略只是將關(guān)鍵信息以圖示化的方式呈現(xiàn)出來崔泵，并不是整個測試策略的全部，在一頁紙的背后是團(tuán)隊(duì)的充分溝通和對策略各個方面達(dá)成的一致認(rèn)識猪瞬，是需要團(tuán)隊(duì)一起來做很多工作的憎瘸。這種高度簡化的呈現(xiàn)形式，是為了給團(tuán)隊(duì)更多的討論空間陈瘦，一頁紙也更易于修改幌甘，從而更能適應(yīng)變化，真正滿足需求痊项。
基于Jamie McIndoe的可視化測試策略思想锅风，我建議的測試策略圖包含下列信息：
- 指導(dǎo)性原則：團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)
- 如何測：測試左移、精益測試鞍泉、測試右移皱埠，涵蓋測試流程、測試類型咖驮、測試方法等
- 測什么：包括功能边器、性能和安全等
下面將以藍(lán)鯨項(xiàng)目為例來介紹這幾個部分的內(nèi)容。關(guān)于藍(lán)鯨項(xiàng)目托修，是一個歷經(jīng)10年的離岸交付項(xiàng)目忘巧，采用的是敏捷開發(fā)的模式，每四到五周一次發(fā)布诀黍，遵循敏捷開發(fā)的各種實(shí)踐。
例如仗处，藍(lán)鯨項(xiàng)目的測試策略如下圖所示：
各部分詳細(xì)介紹
下面眯勾，我們來看看該測試策略各組成部分的具體含義。
1. 指導(dǎo)性原則
藍(lán)鯨項(xiàng)目采用的是敏捷開發(fā)模式婆誓，質(zhì)量不是某個單一角色的事情吃环，團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)是項(xiàng)目質(zhì)量保障的指導(dǎo)性原則，需要所有團(tuán)隊(duì)成員對此有一致的認(rèn)識洋幻，人人都要有關(guān)注質(zhì)量的意識郁轻。更多關(guān)于團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)的內(nèi)容，請參考我的博客文章說好的團(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ā)生命周期的每個階段都有質(zhì)量相關(guān)的活動，把質(zhì)量融入到開發(fā)的每一個步驟杨名，通過CI/CD等方式獲取快速反饋脏榆，做好軟件缺陷的預(yù)防，以減輕缺陷暴露太晚帶來的大量修復(fù)成本台谍。
藍(lán)鯨項(xiàng)目的開發(fā)生命周期主要體現(xiàn)在下圖的七個環(huán)節(jié)须喂，每個環(huán)節(jié)都有相應(yīng)測試活動的開展，并且每個活動都有不同角色的參與典唇。
3. 精益測試
精益測試可以理解為以業(yè)務(wù)價值為目標(biāo)镊折，以盡量少的成本交付高質(zhì)量的軟件，也就是說測試要測在能體現(xiàn)價值的點(diǎn)上介衔，要做到有效覆蓋恨胚、減少浪費(fèi)。藍(lán)鯨項(xiàng)目的策略圖里有兩個框架幫我我們更有效的測試炎咖，分別是測試象限和測試分層赃泡。
測試象限
在Lisa Crispin和Janet Gregory合著的書籍《敏捷軟件測試：測試人員與敏捷團(tuán)隊(duì)的實(shí)踐指南》中，我們看到了敏捷測試象限的介紹乘盼。由于該象限框架所起到的作用不僅局限于敏捷的環(huán)境升熊，我在這里稱之為測試象限。
測試象限矩陣一共四個部分绸栅，稱為四個象限级野。下側(cè)是面向技術(shù)的測試，上側(cè)是面向業(yè)務(wù)的測試粹胯；左側(cè)是支持團(tuán)隊(duì)的測試蓖柔，右側(cè)則是評價產(chǎn)品的測試。
- 支持團(tuán)隊(duì)的測試
支持團(tuán)隊(duì)的測試是用來告訴團(tuán)隊(duì)要寫什么代碼风纠，起到明確需求况鸣、輔助設(shè)計的作用。其中竹观，第一象限是面向技術(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ì)量的保障由驹。
這兩個象限的測試能夠快速提供反饋信息，并確蔽粼埃快速的解決問題蔓榄，既指導(dǎo)了功能的開發(fā)，又提供了防止重構(gòu)和新代碼的引入而導(dǎo)致不期望行為發(fā)生的安全網(wǎng)默刚。
- 評價產(chǎn)品的測試
程序員編寫的代碼可以使得左側(cè)面向業(yè)務(wù)的測試通過甥郑，但也可能沒有產(chǎn)生客戶真正想要的東西，因此還需要第三荤西、第四象限的評價產(chǎn)品的測試澜搅。
第三象限是面向業(yè)務(wù)的評價產(chǎn)品的測試，通過模仿真實(shí)用戶使用應(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ù)項(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ù)部分拱层。
測試分層
關(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í)行速度慢虚循、實(shí)現(xiàn)成本較高的不足同欠。因此，需要權(quán)衡利弊横缔，根據(jù)項(xiàng)目具體情況铺遂，真實(shí)的目標(biāo)來確定每層測試的比例。
至于具體的比例是金字塔結(jié)構(gòu)茎刚，還是蜂巢結(jié)構(gòu)或其他襟锐，并不是一定的，也不會是一成不變的斗蒋，可能受到價值目標(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)目更多的自動化測試是保障服務(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ā)和測試工作，形成一個開發(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. 測什么
之所以把這個放到最后介紹蚓峦，是因?yàn)榍懊娼榻B“怎么測”的各個部分都已經(jīng)涵蓋到要測試的內(nèi)容，藍(lán)鯨項(xiàng)目的測試內(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)鍵信息一目了然。我們再來看一下測試策略圖示化以后叙身，還有哪些需要注意的方面渔扎。
目標(biāo)驅(qū)動
雖然上網(wǎng)搜索能找到很多測試策略模板，但測試策略不應(yīng)該是千篇一律的信轿，不可以死搬硬套通用的模板晃痴。測試策略受到多種因素的影響妓忍，比如：業(yè)務(wù)價值、質(zhì)量要求愧旦、當(dāng)時痛點(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ū)動的峦睡。
演進(jìn)式
項(xiàng)目處于不同階段會有不同的質(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)勢明顯。
04. 總結(jié)
測試策略舉足輕重唆垃，內(nèi)容很重要五芝，需要以價值目標(biāo)驅(qū)動，持續(xù)度量辕万，并根據(jù)項(xiàng)目特定情況適時調(diào)整与柑、演進(jìn)。策略文檔不要拘泥于形式蓄坏，利用圖示化的方法价捧，直觀、清晰的表達(dá)涡戳，是非常好的組織形式结蟋，能有效克服常規(guī)文字為主的文檔所帶來的痛，推薦大家使用渔彰。
05. 延伸閱讀
- Jamie McIndoe的Testing Stuff - A One-Page Test Strategy：https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
- 說好的團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)呢：https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
- QA in Production：https://martinfowler.com/articles/qa-in-production.html
- 藍(lán)鯨項(xiàng)目測試策略之微服務(wù)測試的思考與實(shí)踐：https://www.bylinzi.com/2018/06/28/microservices-testing/
- 生產(chǎn)環(huán)境下的QA：https://www.bylinzi.com/2016/06/13/qa-in-production/
- QA與Ops通力合作打造反脆弱的軟件系統(tǒng)：https://www.bylinzi.com/2018/10/15/qaops/
