前言：
對於軟體測試來說，怎麼樣才算測夠了?如何評價測試的有效性?那麼多測試用例，以後怎麼刪?在軟體測試中會遇到非常多的問題，阿里研究員鄭子穎分享了18個他總結出的難題以及相關看法，希望對同學們有所啟發。
十多年前我在上一家公司的時候看到過內部有個**有乙個hard problems in test的列表，上面大概有三四十個問題的樣子，是各個部門的測試同學提供的。但可惜後來那個list失傳了，我很後悔自己當時沒有儲存乙份。後來很多次我都想要找到那份list，因為上面列的那些問題指出了測試專業在自身專業性上的巨大發展空間。那份list上的問題讓當時的我相信，軟體測試這件事情本身的難度一點都不亞於軟體開發，甚至可能更難一點。
如果今天要重建這麼乙份hard problems in test列表，下面這些問題是我會加到這份列表上的，好了話不多說，接下來我們來看一下今天我們要講的軟體測試的9個難題。
正文：
一、測試充分度
如何回答「測夠了嗎「(包括測新和測舊)。**覆蓋率是衡量測試充分性的起點，但遠遠不是終點。要回答」測夠了嗎「，至少還要考慮是否測了所有的場景、所有的狀態、所有的狀態轉移路徑、所有的事件序列、所有可能的配置、所有可能的資料等等等等。即便如此，我們可能還是無法100%確信我們已經測夠了。可能我們最終只能做到非常趨近於測夠了。
二、測試有效性
如何評價一組測試用例的發現bug的能力。有效性(發現bug的能力)和充分性(測夠了沒有)是兩個正交的屬性。評價測試用例有效性可以通過正向的分析進行，例如，分析測試用例是否校驗了所有在測試過程中sut落庫的資料。更具有通用性的做法是變異測試(mutation testing)，即在被測**裡注入不同的「人造bug」，統計多少能被測試用例感知到。目前變異測試我們已經有工程化規模化的落地了，後續的工作重點有：1)如何防止鈍化(或曰「殺蟲劑效應」)，2)不但對被測**進行注入，還能對配置、資料等進行更全面的注入。
三、測試用例**
以前廣告行業有句話：我知道廣告費有一半是浪費掉的，但不知道哪一半是浪費掉的。
軟體測試也有類似的困惑：那麼多用例，要花那麼多時間去跑，我知道這裡面有很多時間是浪費掉的，但我不知道哪些時間是浪費掉的。浪費的形式包括：
冗餘步驟：有些是浪費在一些重複的步驟上，每個用例都要去做一些類似的資料準備，每個用例都要去執行一些中間過程(這樣才能推進到下一步)。
等價類：乙個支付場景，我要不要在所有的國家、所有的幣種、所有的商戶、所有的支付渠道和卡組的排列組合都測一遍?這麼測，代價太高。不這麼測，我擔心可能某個特定商戶在某個特定國家有個特定邏輯我就漏掉了。對於具體的業務，還可以進行人肉分析。有沒有更通用的、而且比較完備和可靠的等價類分析的技術手段?
我有n個用例，我猜這n個用例裡面可能存在m個用例，即使刪掉這m個用例，剩下的n-m個用例的效果和之前n個用例的效果一樣。如何識別是否存在這樣的m個用例、如果存在的話是哪m個。
我參加過內部一場質量線晉公升到p9的評審，當時有個評委問了那位同學乙個問題：「那麼多測試用例，以後你怎麼刪」。這個問題看似簡單，其實非常難。我覺得，從原理上來說，如果測試充分度和測試有效性的度量都做的非常好了、度量成本非常低了，我們是可以通過大量的不斷的嘗試來刪用例的。這是一種工程化的思路，也許還有其他的理論推導的思路。
四、測試分層
很多團隊都會糾結到底要不要做全鏈路回歸、做到什麼程度。這個問題的核心點就是：有沒有可能、有沒有一種做法，只要把系統間的邊界約定的足夠好足夠完整，就可以做到在改動乙個系統的**後，不需要和上下游系統進行整合測試，只要按照邊界約定驗證好自己的**就可以確保沒有任何regression了。
包括我在內的很多人相信那是可能的，但既無法證明，也不敢在實操中就完全不跑整合。我們也缺乏可以完全複製的成功經驗，缺乏一套完整的方**指導開發團隊和qa團隊要怎麼做就可以達到回歸無需整合上下游。
有時候，我覺得我現在就像是哥德堡的市民，不斷的走啊走，嘗試找出一條一次性不重複的走過那7座橋的路線。但也許就有那麼一天，有乙個像尤拉那樣的人會出現在我面前，用理論證明告訴我，那是不可能的。
五、減少分析遺漏
分析遺漏是很多故障的原因。開發做繫分的時候，有乙個corner case沒考慮到、沒有處理。測試做測分的時候，忘記考慮某個特殊場景了。相容性評估，評估下來沒有相容性問題的，但結果是有的。而且很多時候，分析遺漏屬於unknown unknowns，我壓根就不知道我不知道。有沒有一套方法和技術，可以減少分析遺漏，可以把unknown unknowns轉化為knowns?
六、用例自動生成
fuzz test、model based test、錄製回放、traffic bifurcation(引流)等都是自動生成用例的手段。有些已經比較成熟(例如單系統的錄製回放、引流)，有些多個團隊都在探索(例如fuzz)，有些則一直沒有大規模的成功實踐(例如mbt)。我們也有過探索如何從prd裡通過nlp來生成用例。用例自動生成中，有時候難點還不是生成test steps，難度反而是怎麼生成test oracle。anyway，測試用例自動生成是乙個非常大的領域，這個方向上未來可以做的還非常多。
七、問題自動排查
包括線上和線下。對於比較初級的問題，自動排查方案往往有兩個侷限性。首先，方案不夠通用，多多少少比較定製化。其次，比較依賴人工積累規則(說的好聽點叫「專家經驗」)，主要是通過記錄和重複人肉排查的步驟來實現。然而，每個問題都不完全一樣，問題稍微一變，之前的排查步驟可能就不work了。現在有一些技術，比如呼叫鏈路的自動比對，對排查問題和缺陷自動定位很有幫助。
八、缺陷自動修復
阿里的precfix、facebook的sapfix等是目前比較知名的一些工業界的做法。但總的來說，現有的技術方案，都有這樣那樣的侷限性和不足，這個領域還在相對早期階段，後面的路還很長。
九、測試資料準備
測試用例的乙個重要設計原則是：測試用例之間不應該有依賴關係，乙個測試用例的執行結果不應該受到其他測試用例的執行結果(包括是否執行)的影響。基於這個原則，傳統的最佳時間是確保每個測試用例都應該是自給自足的：乙個用例需要觸發的後台處理流程應該由這個用例自己來觸發，乙個測試用例需要的測試資料應該自己來準備，等等。但如果每個用例所需要用到的測試資料都是自己來從頭準備的，執行效率就比較低。怎麼既不違背「測試用例之間不應該有依賴關係」的大原則，又能減少測試資料的準備時間?
我設想的是一種更加完備的資料銀行。每個測試用例執行完後，都會把它自己產生的資料交給資料銀行，例如，乙個在某個特定國家的已經通過kyc、已經綁了一張卡的會員，一筆已經支付成功的交易，乙個已經完成入駐簽約流程的商戶。下乙個測試用例開始的時候，會先問一下資料銀行：「我要乙個滿足這樣這樣條件的商戶，你有沒有」。上個用例跑出來的那個商戶正好符合條件，資料銀行就會把商戶「借」給這個用例用。而且一旦借出，直到被歸還前，這個商戶不會被借給其他用例。
經過一段時間的執行，資料銀行能夠學習到每個測試用例需要什麼樣的資料、以及會產生什麼樣的資料。這個知識是通過學習得到的，不需要人肉去新增描述，所以也能適用於老系統的存量用例。有了這個知識，資料銀行可以實現兩個優化：
一次測試執行批次開始後，資料銀行會看到這個批次中後面那些用例需要什麼樣的資料，提前先準備起來。這樣，等執行到那些用例的時候，資料銀行裡就已經有符合條件的資料準備好了。
根據每個測試用例需要什麼樣的資料、以及會產生什麼樣的資料，資料銀行可以合理的編排測試用例的執行先後次序，最大化的實現測試資料的復用，減少測試資料的量和準備開銷。
測試銀行把測試資料「借」給用例的時候，可以有多種不同的模式。可以是獨佔(exclusive)的，也可以是共享的。共享的也可以指定共享讀、共享寫、還是都唯讀不能寫(例如，乙個商戶可以被多個用例用來測試下單支付結算場景，但這些用例都不可以去修改這個商戶本身，例如重新簽約)。
如果把開關、定時任務等resource也作為一種廣義的測試資料由資料銀行來管理，能實現測試用例盡可能並行執行。例如，有n個用例都需要修改乙個開關值，這n個用例如果並行執行的話就會相互影響，他們相互之間應該序列執行。但n個用例中的任何乙個，都可以和這n個用例之外的用例並行執行。資料銀行掌握了每個用例對各種資源的使用模式的詳細情況，再加上每個用例的平均執行時間等資料，就可以最優化、最準確的對一批測試用例進行編排，做到可以並行的都盡可能並行、不能並行的確保不並行，而且還可以在乙個批次的執行過程中不斷的調整餘下還未執行的用例的編排。
這樣乙個資料銀行是普遍適用的，不同業務之間的差異無非是具體的業務物件和resource不一樣。這些差異可以通過外掛程式形式實現。如果有這麼乙個通用的資料銀行，可以很方便的adopt，大量的中小軟體團隊的測試效率都可以得到明顯的提高。這樣的乙個更加完備的資料銀行的想法，我到目前為止還只是想法，一直沒有機會實踐。
寫在最後：
撐不住的時候，可以對自己說聲「我好累」，但永遠不要在心裡承認說「我不行」。不要在最該奮鬥的年紀選擇了安逸，沒什麼好說的，一無所有就是奮鬥的理由，我們試著長大，一路跌跌撞撞，然後遍體鱗傷，總有一天，你會站在最亮的地方，活成自己曾經渴望的模樣。
不忘初心，繼續堅持，相信你終會開出一朵屬於你自己的花兒來。
軟體測試中的 測試
地球我來啦，同志們，今天分享關於 測試的有關內容。一 常用來表示軟體測試過程中的三個階段 是第一階段，一般只供內部測試使用 alpha測試 由使用者 測試人員 開發人員共同參與的內部測試 是第二個階段，已經消除了軟體中大部分的不完善之處，但仍有可能還存在缺陷和漏洞，一般只提供給特定的使用者群來測試使...
軟體測試中的 測試
地球我來啦，同志們，今天分享關於 測試的有關內容。一 常用來表示軟體測試過程中的三個階段 是第一階段，一般只供內部測試使用 alpha測試 由使用者 測試人員 開發人員共同參與的內部測試 是第二個階段，已經消除了軟體中大部分的不完善之處，但仍有可能還存在缺陷和漏洞，一般只提供給特定的使用者群來測試使...
軟體測試中的 測試
一 常用來表示軟體測試過程中的三個階段 是第一階段，一般只供內部測試使用 alpha測試 由使用者 測試人員 開發人員共同參與的內部測試 是第二個階段，已經消除了軟體中大部分的不完善之處，但仍有可能還存在缺陷和漏洞，一般只提供給特定的使用者群來測試使用 beta測試 內測後的公測，交給終端使用者測試...