一、測試策略是什么？

引自查字典：

策略：

基本含義：指為達到某種目的而制定的行動方案或計劃。

詳細解釋：策略是指在特定情況下為達到某種目的而采取的有系統性的行動方案或計劃。它通常包括分析、決策和執行三個階段。策略的制定需要綜合考慮各種因素，包括目標、資源、環境和競爭等。策略的好壞直接關系到目標的實現效果。

策略是為目的/目標服務的，且策略是自帶背景/特定情況的，一定要識別到背景形勢的發展和變化，然后才能制定針對性的謀略、計策。

測試策略有兩層背景疊加：業務大背景和項目小背景。下文提到的測試策略有時指代業務級測試策略，有時指代項目級測試策略，如果無特指強調，則是在探討兩類測試策略的共同特點。

1.1 什么前提下開始探討測試策略呢？

當你有多種測試方案時。如果你只有一個測試方案一條路，那就沒什么選擇余地；只有當多種測試方案都滿足基本要求，但又各有優劣時，才會涉及到如何選擇、取舍。每一次的選擇取舍，抽象出的方法論，就是策略。就像棋類大師在每一步棋的選擇上各有理由，但背后都有著同一套分析和決策思路，那套思路就是策略。

1.2 什么時候迫切需要測試策略呢？

當你的測試方案差異比較大的時候。測試方案有三個方向的指標：質量、效率、成本，這三者同時也是一個不可能三角：

質量，先結合業務發展和研發模式綜合制定質量標準，再以多維度指標衡量質量結果。（敲黑板：質量是被定義出來的。）

效率和成本，要放在人工和機器兩個視角下同時看：

效率通常以項目為衡量單位，即人工效率和機器執行效率雙重影響下的項目交付/發布效率。除此之外，效率也包括了自動化研發效率、自動化運行效率、協同效率等局部效率。

成本則包括了項目內成本和項目外成本，效率驅動下，質量同學大多會追求自動化率，自動化率就體現了項目內成本從人工轉化到機器的程度。從人成本看，項目外的成本主要是平臺工具的開發運維投入，這部分成本會大幅高于單次項目使用時的人力成本，從機器成本看，則涉及多次多方使用的平攤，追求環境利用率也就是盡可能攤薄單次使用成本。另外，成本還有時間因素，初期建設成本要在后面多次使用中逐步攤平。大家吐槽的重復造輪子，問題不是輪子不好用，而是反復付出的建設成本和使用者的學習成本太多。

圖片

不可能三角的相互影響舉例：

1)提升質量=>提高測試覆蓋率=>增加測試點，其他條件相同情況下，會導致效率降低，增加成本

2)提升效率=>提升執行效率=>提升自動化程度，其他條件相同情況下，會導致項目外的自動化建設成本增加。

3)降低成本=>降低人成本或降低機器成本，兩種方式通常都會對質量產生負向影響，效率有可能提升也可能下降。

以上例子可以看到，三角的任一角正向提升時，都對另外一角或兩角產生了負向影響，工作中，我們需要讓三角關系處于平衡狀態，每一角的表現都保持在可接受范圍。

綜上，當你具備多種測試方案/路徑，且他們的質量、效率、成本三角指標表現差異明顯時，你需要分析并決策測試策略，使三角保持在適當的平衡態。

1.3 測試策略和測試方案的關系是怎樣的？

前文提到，測試策略是用來選擇測試方案的，那么是現有測試方案，再抽象出選擇原則作為測試策略？還是先有測試策略，再生成測試方案？

我們先把測試策略和測試方案拆分到業務級和項目級兩個語境之下，探討業務級測試策略、業務級測試方案（業務級測試方案這個概念不常用，可以等同于日常工作中講的業務質量體系）、項目級測試策略、項目級測試方案四者的關系。

以我的個人經驗來看，在新業務（新產品或新技術棧）初始期、發展期、成熟期：這四者的關系分別對應下面三張圖：

圖片

圖片

如果是成熟質量團隊承接新業務，就可以直接進入下圖四象限循環、螺旋式上升狀態。這也是大公司在新開業務時，都會主動調撥一些經驗豐富同學的原因，這時候，個體經驗需要從項目抽象到業務，從測試方案抽象到測試策略，才能更快的做遷移復用。

圖片

小結：測試策略是測試方案的抽象，測試策略又指導了測試方案的具象化。兩者就是雞生蛋，蛋生雞的關系。    

1.4 測試策略的要素包括哪些？

測試策略包括的維度很廣，核心要素是測什么：即測試范圍、測試目標；向內細分怎么測，即測試工作的時空分布，什么時候，以什么測試方法測；向外要求測試基礎設施支撐：環境、工具、數據；

測什么、怎么測、測試基礎設施支撐、這三個要素都和質量、效率、成本三目標有相關性，但側重點有所區分：測什么和質量強相關，怎么測，目標是為了質量，同時也影響了效率成本的表現。測試基礎設施則同時關聯三個維度，能不能測（質量），測的快不快（效率），測的費不費勁（成本）。

說到這，測試策略的全景就呼之欲出了:

先從質量維度，定義測什么（測試范圍、測試目標），同時也就定義了不測什么（極端異常測不測？用戶體驗是不是目標？）質量維度要求越高，測試范圍越大，測試目標越高。放在業務背景下：如金融業務和搜索業務相比，質量要求高，測試覆蓋率要求高，測試精準度要求也更高。

從質量目標和當下能力確定怎么測（從多種方案中選擇）之后，再從效率成本角度，進行平衡評估。同樣考慮到背景信息：如果當下業務對效率要求更高，那么可以增大成本提高并發執行效率，如果成本有上限，那么為了效率可以對質量目標打一點小折扣，或者為了質量可以接受一定程度的低效率，把三者調整成符合業務需求的平衡狀態。

測試基礎設施呢？測試基礎設施為了同時支撐質量效率成本三目標，以技術的方式，綜合提升三目標的整體表現，即用技術做到：質量更好，效率更高，同時成本持平甚至更低。這也是為什么對測試團隊考核時，測試工程能力的權重會日益增加。就是因為靠人只能做到三目標的相對平衡，靠工程（測試基礎設施）才能做到三目標絕對總分的提升。

細心的同學可能會看出，三角指標中，我總是會把質量放在最前面。因為質量是測試的首要職責，是測試工作存在的基礎前提。也更因為質量是業務存活以及發展的前提。大家日常可能會吐槽說某某團隊不重視質量，仔細回想下，這個團隊能接受質量極差，天天故障的狀態嗎？不可能的。換句話說，有什么業務會嫌棄質量太好嗎？。。。如果你感知到你的主管或業務方對質量的要求不高，和你標準不一致，可以細細分析下，是不是高質量標準帶來的效率、成本，有點拖后腿了？如果我們能解決效率成本問題，高質量絕對是我們的一貫追求。所以在三角指標中，我會把質量放在引領地位。

最后，測試策略還有一個非常重要的要素：組織協同：什么角色測，其他角色如何協作。

可能有讀者看到“什么角色測”，會覺得多此一問：不就是因為測試人員負責測試，我們才來探討測試策略么？這個問題的答案太顯而易見了吧。注意，如果有這種想法，可以把此處作為一個提醒，要先練習跳出測試角色看測試工作。

業務級測試策略是為業務服務的，項目級測試策略是為項目服務的。既然測試策略是服務于業務、項目的，那么所有業務、項目的干系人，都有責任和義務支持最優的測試策略落地應用，那么“什么角色測”，取決于各角色知識、技能、工作流程的最優匹配，而不應被已有分工所限定。

比如單元測試，為什么通常是開發在測？不是因為測試做不了單元測試，而是測試負責單元測試的信息成本太高（開發寫代碼自然知道代碼的設計細節，而測試需要額外付出了解成本）。

再比如為什么要有pd/業務驗收環節？是因為驗收過程不僅能驗證產品實現是否符合prd設計，還能兼顧prd沒有覆蓋的用戶體驗部分，pd/業務在這方面也比技術角色更擅長。

最后還有開發自測項目這個經典場景。我個人始終如一的支持部分項目由開發自測，原因是，對于改動小，風險小的項目，開發、測試完全能夠達成一致的質量結果，且如果測試方法明確，測試工具易用，開發也能夠做到和測試持平的效率表現，兩角表現相等情況下，開發還能夠節省一份溝通協作成本（類似單元測試，節省自我溝通成本），那么這部分協作成本就是開發自測在不可能三角的正向收益。那么什么樣的項目不適合開發自測？從上文可以看出，適合的項目前提是兩個角色在質量、效率表現相同，如果這個前提被打破（由于崗位職責、專業能力差異，測試比開發表現更優），這類項目就需要做取舍：成本的正向收益 Vs 質量效率的負向收益。這也就是為什么：復雜、大體量業務中只有部分項目能夠開發自測，高風險項目一定需要專職測試團隊承接。（有些外部公司據說是沒有專職測試團隊的，那么需要確認業務風險類型，以及是否有專職保障此類風險的團隊。）

小結：測試策略的四大要素：測什么，怎么測，測試基礎設施支撐，組織協同，共同服務業務、項目的三角指標（質量、效率、成本）

二、測試策略背后的boss：三角指標

2.1 測試策略如何保持三角平衡？

既然測試策略是服務于三角指標，那么三角指標的整體表現就是測試策略的評價標準。好的測試策略能做到三角表現平衡，特別是業務級測試策略，它能持續作用于業務發展各階段，跨越周期更長。在這個過程中，外部壓力或內部發展變化都會擾動三角的平衡態。我們要做的是先感知到失衡，并且判斷具體失衡位置和程度，再通過測試策略進行調整，回歸平衡。

質量維度：如果線上出現重大質量問題，即質量表現嚴重偏離預期時，需要以質量為牽引，先要讓質量回歸到穩定態，這時候通常組織會投入更多成本（包括不限于人、組織、機器資源），不論是手工測試還是自動化測試，都以增加質量覆蓋率為目的，同時容忍效率的降低。

效率維度：當研發效率或業務發布效率被頻繁提及時，說明效率維度偏離了組織預期，可能是預期提高了，也可能是效率表現降低了，在重新明確效率預期后，不可能三角要圍繞效率做再平衡。這時候先通過增加成本，即增加人或機器的并發工作來提高執行效率，如果還不能達到要求，則需慎重考慮質量預期是否可調，以減少執行時間，提高效率。注意，如果要下調質量預期，一定要得在所有角色層面達成一致。

成本維度：如果質量效率都表現ok，成本就是默認的內在驅動力。由于成本可以細分為人、機器兩個視角，組織期望降低人成本或降低機器成本時，都需要調整測試策略，進行再平衡。

總結來說，當組織內部的聲音開始在三角的某一角上逐步聚集時，特別是有一些badcase出現時，就說明三角開始失衡，需要我們主動去做再平衡。而再平衡的策略也很簡單：質量優先，效率其次，最后由成本作為持續驅動。

還有一個反向小技巧：如果在某一個角上頻繁獲獎或獲得高度評價，說明此處表現已經顯著超出預期，需要適當多考慮一下其他兩個角。

2.2 不可能三角真的不可能嗎？

三角指標真的不可能一起提升嗎？其實從前面分析已經提供了線索：技術。只有通過技術創新，才有可能整體性提升質量、效率、成本表現。技術的成本收益的規律如圖所示：

圖片

新技術在初期付出研發成本，在后期應用時收回收益，質量領域的技術不論是質量收益（不可測變可測），還是效率收益（同等交付下效率更快），都遵循上述投入、回本、持續收益三大階段的規律，如果我們能到持續收益期，那么不可能三角就可以全局性提升。如何在長周期變化情況下，選擇正確的技術方案，在未來的某日能夠通過質量效率收益收回技術投入成本，進入持續收益期，這就是測試負責人的終極考驗。反之，如果技術無用或技術本身投入或維護成本過大，要么平白增加投入成本，要么回收期就會很長，而且很可能碰到業務變化，等不到回本的那一天。

從上圖可以看出：成本相比質量效率，需要更長的周期才能全面衡量，同時成本有項目內和項目外兩種成本（類似表內和表外），最典型的測試工具平臺開發、技術架構改造，這類工作有時會包含在某一個業務項目內完成，有時獨立為技術項目自運作，更多時候，這類成本會散落在項目間隙中，比如工具維護，排查，答疑等等。

對于測試負責人，除了關注項目內成本，更要關注整體性成本。一是長周期下收益的變化，一些技術效果會逐步腐化削弱，是否還能提供足夠的收益沖抵成本，需要持續關注，二是成本積累效應，散落成本會隨時間逐步積累到一定規模，要考慮歷史積累到現在的維護成本，組織是否還能支撐。

2.3 有沒有成本減少后，質量效率降低的情況？

這種情況可接受嗎？

有。

舉兩個質量表現降低的例子：一種情況是某種原因導致測試投入被動減少（比如出現測試人員離職轉崗），線上問題有增加，但沒有出嚴重故障。另一種情況是業務發生變化，如業務量下降，線上問題的嚴重程度下降，組織主動減少了測試投入，線上問題有增加。這兩種情況都出現了投入成本的降低和質量表現的下降，唯一區別是因果順序，主動被動之分），兩種情況的共同點是，質量表現仍在業務允許范圍內。請注意：質量指標是多維度指標，問題數量、問題影響面（時長、用戶量）、問題對客表現等質量子指標都是獨立變動的。如果有某個質量子指標下降時，就需要考慮這個子指標對全局質量影響的權重，以及具體下降程度，來判斷質量整體表現是否可接受。畢竟我們的質量表現不是每天都在生死存亡線上勉強維持，所以總有一部分空間是可以接受波動的。這個話題更適合總結為“業務質量標準制定”, 本文不做過多展開。

成本降低時，如果原本資源就很緊張，那效率一定會體現出降低，而且更容易體現在主觀體感上：不論是投訴測試太慢的聲音變多，或是測試排期開始變得困難，或是大家感覺測試周期比預期長了，這些都是短期效率下降的信號。注意：主觀體感和客觀指標的差異在于，主觀體感對個別異常case會感受強烈，放大短期表現，而客觀指標觀察的是一段時間周期內的均值表現，通常不會劇烈變化，如發布周期、測試周期、回歸周期、測試開發周期比等指標，也就更適合做中長期評價。那么短期效率表現降低時，是否一定要解決呢？是否一定要補充資源（增加投入成本）來解決呢？我個人的思路是，先觀察分析當下成本結構（人、機器）和效率要求的沖突點在哪里，未來發展趨勢是什么，是短期波動還是長期影響，客觀效率指標變化趨勢如何，整體效率表現（主觀+客觀）是否仍在大組織可接受范圍內，再決策是否解決以及如何解決。對解決方法的探討更適合總結為“測試模式與測試梯隊能力建設”，本文也不做過多展開。

從以上的探討可以看出，對質量、效率來說，都沒有絕對客觀的衡量標準，即使各個維度都有客觀指標，最終也需要有一個主觀定義的目標值。而目標值的設定和業務發展、組織要求息息相關，有時還要參考同行表現，以保持團隊競爭力。

三、測試策略怎么落地？

就像把大象關進冰箱一樣，三個步驟：

1.打開冰箱門=瞄準目標：確定三角指標的具體衡量指標和目標值。這一步是在制定質量標準、團隊kpi/OKR時就應該已經完成的。重點是冰箱（業務）本身。

2.評估測試策略在三角指標的表現。這個步驟就是“把大象放進去”，即問題的本質步驟。上文講了很多測試策略和三角指標的聯動關系、觀測信號、調優方式等，但每個測試策略的實際表現必須放在具體的業務、技術、團隊中衡量，即對應到具體的大象、冰箱實例場景中。

3.選擇匹配度最高的測試策略。像關冰箱門一樣簡單直接。如果這一步沒法對比匹配度，請回到上一步。

舉幾個場景：

1. 大體量業務上新啟動了一個戰略項目，如何制定項目級測試策略？

先解題，幾個關鍵詞：大體量、新、戰略項目。

業務體量大=業務質量要求高，并且一定已經有了一些基礎測試體系，新啟動，代表有新功能新特性甚至新產品新業務模式出現。戰略項目說明重要程度，也代表了對質量、效率（交付進度）的高標準要求。

接下來就是先明確項目質量目標和發布時間目標，再參考目前團隊人員，初步判斷是否能以現行業務級測試策略支撐。如果新功能部分所需要的人員技能是目前人員技能無法支撐的，那么招聘、借調、培訓都需要盡快做起來，如果以現有人員配置能夠支撐質量工作，但效率目標和質量目標有沖突，那么一定要確認成本、效率、質量三角權重關系。對戰略項目而言，優選增加成本投入，保障質量效率目標，其次選擇微調質量或效率目標。微調質量效率目標都需要以質量為key：按照功能或按照質量風險的表現型，區分出重大風險和小風險，優先保障重大風險，小風險則可以進行風險報備、風險緩釋（灰度觀察）、延后保障（發布后補測）等。

實際上，戰略項目的重要程度，通常值得團隊做一些前置工作，比如在開發階段同步做自動化測試用例開發，或提前開發測試工具，都可以提升測試階段的執行效率。本質是把一部分測試階段的工作量折疊到開發階段同步進行，減小測試階段質量效率目標的沖突程度。

2. 新啟動的業務，如何制定初始期業務級測試策略？

新啟動業務，如果完全沒有可繼承的三角目標、標準、質量體系積累，甚至團隊都還在組建過程，那么先恭喜你，這是一個沒有技術負債的場景。沒有歷史包袱，就大膽的追求完美吧！

首先基于業務形態，分析業務質量表現維度，定義指標和目標值，可以參考同類業務的現行指標和目標值，然后和業務、研發團隊探討業務研發模式，確定效率目標，如項目制、班車制、獨立發布or全局發布。最后參考技術棧和業務經驗兩類能力要求搭建測試梯隊。

定好了目標，就在實踐中進行迭代優化。每一個項目的測試方案都是我們迭代的基礎，每一個bug都是我們優化的線索。項目測試方案不僅是為了保障單個項目，還要在項目后復盤總結測試方案的優劣，從質量、效率、成本三個角度綜合評價。漏測指標是質量的抓手，重復性的工作量是效率的抓手，測試方案優化后也不僅是用于當下的項目測試，還可以用過往的項目做回溯分析，時刻記住，除了當下的項目，更重要是面向未來交付業務級測試策略。參考業務復雜度和人員經驗，一般3-6個月內就可以完成初版業務測試策略了。

3. 成熟業務順利運轉中，如何定期刷新業務級測試策略？

既然是成熟業務，潛臺詞是目前三角表現平衡，那么此時需要分析未來半年、一年甚至三年期間，業務會面臨什么樣的變化，質量效率目標會有什么變化。比如市場中出現了新的強大競對，競爭態勢會對迭代效率提出更高要求；比如業務進入高增長期，用戶量業務量急遽增加，此時會對穩定性、性能提出更高要求；再比如產品形態發生變化，從原本異步交互轉為實時交互，這也是對質量的挑戰。識別到三角目標的變化趨勢，才能提前布局，建設技術能力，在業務需要時就能直接落地應用，產生收益。

在預判未來趨勢過程中，尤其要注意業務模式或產品形態的變化，它們通常會帶來風險類型的變化。如原本獨立經營的金融業務，引入了合作機構，轉變為平臺生態型時，風險引入和風險表現都增加了機構端，會對三角指標都帶來顯著影響。再比如原本免費的業務開始對某些場景進行收費，或營銷活動增加了現金類優惠，這些業務變化都代表著業務有了資金屬性，那么相應的資金類風險也應全盤考慮。

除了分析未來變化趨勢，還需要對現狀有更全面細致的了解，雖然是三角平衡，但三角不可能都是完美表現，針對每一角的具體表現提出更高要求，分析現狀的差距，也能夠指明我們的提升方向：質量優先、效率其次、成本持續驅動。

這個場景說來簡單，實操最難。因為成熟業務下，從業務團隊、研發團隊傳導到質量團隊的壓力相對可控，如果質量負責人自驅力不足，很容易陷入戰術性的忙碌中，畢竟項目一個接一個，peer只關心我們交付的結果，對測試策略難以感知、也很少提出建議和要求。質量負責人必須要持續跟蹤質量、效率、成本表現，定期回溯分析質量策略執行情況，主動刷新測試策略，調優三角表現。

4. 再舉一個極端場景，有一個大項目（開發+測試工時>1000人日），因為種種原因需要倒排發布，倒排后只有正常周期的一半，怎樣保證發布質量和發布時間？

這個場景的問題本質是效率和質量的明確沖突，最簡單方案是調整第三角 -- 成本目標，也就是加人/加班增加投入時間來解決。此處極端場景強調了倒排只有一半周期，基本已經無法通過單純加班解決（個人經驗值：加班極限是同等自然日內增加50%工作量，很難做到增加100%）。加人也有可能無人可加，或即使有其他項目人員可以借調，如果沒有匹配的經驗積累，加人并不能等比例提高效率，還會因為新加成員需要有經驗成員的傳幫帶，更加占用原有項目人員的投入。

所以如果增加成本不能解決效率和質量沖突時，我們還有哪些策略可做？

倒排等同于效率目標中的交付日期鎖定。那么效率目標的其他目標是否有可調空間？列舉幾個可調整角度：

1)提測日期提前，把測試周期盡可能拉長。分批提測也是類似思路，都是把實際測試工作執行的時間盡可能往前提。把測試時間窗口拉長，以容納工作量。

2)在開發階段提前準備測試工具，提高測試執行階段效率。

3)在開發階段提前準備測試自動化用例，提高測試case并發效率。還能充分利用夜間時間，擴展case執行周期。

以上兩條的測試工具和自動化用例就不用再遵從默認的成本收益回收策略，而是專注于解決此次項目交付要求，增加執行并行度。這也是通過增加投入解決效率問題，只不過不是增加新人，而是用項目原有測試人員，在研發階段進行提前投入。

如果調整成本、效率，都不能解決，就需要慎重考慮質量目標這個角了。同樣列舉幾個可調整角度：

1）部分功能延后發布。如理財業務中，有一種最低持有期的理財產品，申購后一定日期后才能贖回，那么可以和業務技術協商，先保證申購功能的測試覆蓋，再在項目發布后，贖回功能尚未打開這個短短的小窗口內，補充保證贖回功能的測試覆蓋。這樣可以把一些功能的質量保證工作后置，減少倒排周期的影響。

2）評估后裁剪部分回歸測試用例集。回歸用例顧名思義是此次變更不涉及修改，仍應保持原有功能的用例，如果時間充裕，回歸用例需要實際執行并確認結果，但如果時間非常緊張，且沒有過往成熟的回歸自動化快速執行，那么可以通過評估系統實現方案+CR后確認是否有部分回歸功能不受此次變更影響，然后裁剪該部分回歸測試用例。

特別提醒！！評估后裁剪部分回歸用例集，能顯著減小工作量，但評估不全（系統歷史設計未考慮到，CR不全等）導致這部分回歸用例產生漏測的案例也比比皆是。所以這個策略風險極高，對核心回歸功能不建議采用該策略。對非核心回歸功能也要謹慎進行。

3）對核心回歸功能，更建議做功能場景覆蓋調整。一個功能的用例集可以細分為多種觸發場景條件的具體用例（case），這里也基本遵循二八原理：80%的用戶場景（用戶操作流量或業務數據等價類）密集落在20%的場景上，而剩下80%的場景，流量分布更稀疏，觸發概率更小。舉例某個業務功能用例集涉及150個用例：

這種情況下，從150個場景用例中，優先選擇用戶操作流量占比最大的用例（如選擇80個用例，可覆蓋99%流量），即可大幅減少測試時間。這樣可以保證大范圍業務沒問題，讓可能遺漏的問題只表現在小范圍業務流量上，減小影響面。未選擇的用例，是發布后觀察線上表現，還是在發布后驗證或補測，也可以根據具體業務情況進行策略再確認。

灰度也是類似道理，通過灰度比例控制新代碼生效的業務流量占比，以此控制可能問題的影響面。

特別提醒！！該策略僅能用于問題影響在業務上可接受的情況，如果是高風險場景，如高客單業務的資損風險，一筆操作可能就會觸發一個P1，仍然不建議采用該策略。

4)發布后進行線上驗證。和第一條延后發布不同，如果存在線下測試成本極高，線上測試成本很低的情況（如一些歷史數據構造成本大，使用線上數據成本小），可以基于效率考慮，在發布后在線上進行驗證。由于項目已發布，那么一定要同步發布線上監控核對觀察線上表現，且第一時間進行線上驗證，把可能的問題影響面控制到最小。

5)以上除了第一條延后發布不會帶來實際質量風險外，2,3,4都有質量風險，那么要補充兩點：

a)已知線下測試裁剪或未覆蓋的場景，必須要有線上主動發現能力。

b)已知會產生線上問題可能的場景，必須要測算線上風險敞口（線上pv *時長 * 影響表現，如果涉及客訴的，要計算客訴轉化率），并進行相應業務報備。

以上是比較簡化的幾個場景。其實業務的變化時刻在發生，每個團隊也一直以專業能力見招拆招，是著眼于一個月的變化，還是預判一年的變化？對業務級測試負責人而言，需要把視野拉到業務全局，把目標放到三角整體，每一個測試策略的決策，要兼顧當下和未來，避免只見樹木不見森林。更重要的是，如果沒有明顯的當下的問題，要把成本作為默認驅動，用技術的方法持續優化三角表現。

總結：測試策略對測試中長期布局有著非常重要的意義，對測試負責人來說，解決問題只是基礎要求，在多種有效方案中選擇最優解，才是更大的挑戰。通過三角目標做牽引，對業務做預判，刷新目標，主動規劃，時刻調整，和業務共同應對不確定的未來，才能持續為業務保駕護航。