阿里妹導讀：對於軟體測試來說，怎麼樣才算測夠了？如何評價測試的有效性？那麼多測試用例，以後怎麼刪？在軟體測試中會遇到非常多的問題，阿里研究員鄭子穎分享了18個他總結出的難題以及相關看法，希望對同學們有所啟發。
冗餘步驟：有些是浪費在一些重複的步驟上，每個用例都要去做一些類似的資料準備，每個用例都要去執行一些中間過程（這樣才能推進到下一步）。
等價類：一個支付場景，我要不要在所有的國家、所有的幣種、所有的商戶、所有的支付渠道和卡組的排列組合都測一遍？這麼測，代價太高。不這麼測，我擔心可能某個特定商戶在某個特定國家有個特定邏輯我就漏掉了。對於具體的業務，還可以進行人肉分析。有沒有更通用的、而且比較完備和可靠的等價類分析的技術手段？
我有N個用例，我猜這N個用例裡面可能存在M個用例，即使刪掉這M個用例，剩下的N-M個用例的效果和之前N個用例的效果一樣。如何識別是否存在這樣的M個用例、如果存在的話是哪M個。
一次測試執行批次開始後，資料銀行會看到這個批次中後面那些用例需要什麼樣的資料，提前先準備起來。這樣，等執行到那些用例的時候，資料銀行裡就已經有符合條件的資料準備好了。
根據每個測試用例需要什麼樣的資料、以及會產生什麼樣的資料，資料銀行可以合理的編排測試用例的執行先後次序，最大化的實現測試資料的複用，減少測試資料的量和準備開銷。
正常模式：這就是和今天的編譯構建是一樣的，產出的構建物是拿去生產環境跑的。
Mock模式：這個模式編譯出來的就是該服務的一個mock，但由於是同一套程式碼編譯出來的，最大可能的保留了原來的業務邏輯，做到最大限度的模擬。而且由於是同一套程式碼編譯出來的，後期也不會有“脫鉤”的擔心，應用程式碼裡的業務邏輯變化都能及時反映在mock裡，大大減少mock的人肉維護工作量。
壓測模式：這個模式編譯出來的也是一個mock，但這個mock是用來給（上游）做效能測試用的。過去線上下的效能壓測中經常遇到的情況是：我們想要壓的系統還沒到瓶頸，這個系統的下游系統（往往是一個測試環境）反而先到瓶頸了。壓測模式編譯出來的這個mock犧牲了一部分的業務邏輯模擬，但能確保這個mock本身效能非常好，不會成為效能瓶頸（但對lantency仍然是模擬的）。
注： [1] 我工作中還有一些其他的測試難題，那些問題在這裡沒有列出來，因為那些問題和特定的業務場景或者技術棧的相關度比較高。還有一些測試領域的挑戰，難度也很高，例如，迴歸測試達到99%以上透過率、主幹開發以及做到透過程式碼門禁的code change就是可以進入釋出的，這些也非常有難度，但難度主要是是偏工程的而不是軟體測試技術本身。 [2] 測試充分度的度量和提升是兩個問題。有一種觀點認為，測試充分的度量和提升其實是一件事情，用同樣的演算法分析資料可以進行度量，也能用同樣的演算法來基於資料進行測試充分度的提升。我不同意這個觀點。度量和提升未必是同一個演算法。這樣的例子非常多了：測試有效性的度量和提升、運維穩定性的度量和提升，等等。即便度量和提升可以用同一種演算法，我也希望可以儘量再找一些其他方法，儘量不要用同一種演算法又做度量又做提升，因為這樣容易“閉環”和產生盲區和。 [3] 當然，這句話今天可能不再是那樣了，但那是十幾年前，那時候的線上廣告和大資料還沒到今天這個水平。 [4] 具體形式上，這個資料銀行無需是一個平臺。它不一定是一個服務，它也不一定需要有UI。它可以就是一個jar包，它可以就是在測試執行時launch的一個單獨的程式。