軟件測試中常見的11個難題

其實軟件測試這件事情本身的難度一點都不亞于軟件開發(fā)，甚至可能更難一點，常見的難題主要有以下這些。

1、測夠了嗎？

其實這是一個測試充分度的問題。

代碼覆蓋率是衡量測試充分性的起點，但遠遠不是終點。要回答”測夠了嗎“，至少還要考慮是否測了所有的場景、所有的狀態(tài)、所有的狀態(tài)轉移路徑、所有的事件序列、所有可能的配置、所有可能的數(shù)據(jù)等等等等。

即便如此，我們可能還是無法100 %確信我們已經測夠了。可能我們最終只能做到非常趨近于測夠了。

2、bug發(fā)現(xiàn)能力如何？

如何評價一組測試用例的發(fā)現(xiàn)bug的能力，屬于測試有效性的問題。

評價測試用例有效性可以通過正向的分析進行，例如，分析測試用例是否校驗了所有在測試過程中SUT落庫的數(shù)據(jù)。更具有通用性的做法是變異測試（Mutation Testing），即在被測代碼里注入不同的“人造bug”，統(tǒng)計多少能被測試用例感知到。

3、哪些測試用例是在浪費時間？

那么多用例，要花那么多時間去跑，這里面一定有很多時間是浪費掉的，但如何才能知道哪些是浪費掉的呢？

浪費的形式包括：

冗余步驟：有些是浪費在一些重復的步驟上，每個用例都要去做一些類似的數(shù)據(jù)準備，每個用例都要去執(zhí)行一些中間過程。

等價類：一個支付場景，要不要在所有的國家、所有的幣種、所有的商戶、所有的支付渠道和卡組的排列組合都測一遍？這么測，代價太高。有沒有更通用的、而且比較完備和可靠的等價類分析的技術手段？

有N個用例，推測這N個用例里面可能存在M個用例，即使刪掉這M個用例，剩下的N-M個用例的效果和之前N個用例的效果一樣。如何識別是否存在這樣的M個用例、如果存在的話是哪M個。

據(jù)說阿里內部職級晉升P9評審，曾經就出現(xiàn)過“測試用例很多，你怎么刪”的問題，看似簡單，其實很難。

4、要不要做全鏈路回歸？

很多團隊都會糾結到底要不要做全鏈路回歸、做到什么程度。

這個問題的核心點就是：有沒有可能，只要把系統(tǒng)間的邊界約定的足夠好足夠完整，就可以做到在改動一個系統(tǒng)的代碼后，不需要和上下游系統(tǒng)進行集成測試，只要按照邊界約定驗證好自己的代碼就可以確保沒有任何regression了。

很多人相信那是可能的，但既無法證明，也不敢在實操中就完全不跑集成。

5、如何減少分析遺漏？

分析遺漏是很多故障的原因。

開發(fā)做系分的時候，有一個corner case沒考慮到、沒有處理。測試做測分的時候，忘記考慮某個特殊場景了。兼容性評估，評估下來沒有兼容性問題的，但結果是有的。

而且很多時候，分析遺漏屬于unknown unknowns，我們壓根就不知道我們不知道。

6、用例自動生成

Fuzz Test、Model Based Test、錄制回放、Traffic Bifurcation（引流）等都是自動生成用例的手段。有些已經比較成熟（例如單系統(tǒng)的錄制回放、引流），有些多個團隊都在探索（例如Fuzz），有些則一直沒有大規(guī)模的成功實踐（例如MBT）。

7、問題自動排查

包括線上和線下。對于比較初級的問題，自動排查方案往往有兩個局限性。

首先，方案不夠通用，多多少少比較定制化。其次，比較依賴人工積累規(guī)則（說的好聽點叫“專家經驗”），主要是通過記錄和重復人肉排查的步驟來實現(xiàn)。然而，每個問題都不完全一樣，問題稍微一變，之前的排查步驟可能就不工作了。

8、缺陷自動修復

阿里的Precfix、Facebook的SapFix等是目前比較知名的一些工業(yè)界的做法。但總的來說，現(xiàn)有的技術方案，都有這樣那樣的局限性和不足，這個領域還在相對早期階段，后面的路還很長。

9、測試數(shù)據(jù)準備如何提高效率？

測試用例的一個重要設計原則是：測試用例之間不應該有依賴關系，一個測試用例的執(zhí)行結果不應該受到其他測試用例的執(zhí)行結果（包括是否執(zhí)行）的影響。

但如果每個用例所需要用到的測試數(shù)據(jù)都是自己來從頭準備的，執(zhí)行效率就比較低。怎么既不違背“測試用例之間不應該有依賴關系”的大原則，又能減少測試數(shù)據(jù)的準備時間？

10、兼容性測試

代碼和數(shù)據(jù)的兼容性問題有很多形式。例如，如何確保新代碼能夠正確的處理所有的老數(shù)據(jù)？有時候，老數(shù)據(jù)是幾個月前的老代碼產生的，例如，一個正向支付單據(jù)可能會到幾個月以后才發(fā)生退款退票。

有時候，老數(shù)據(jù)可能就是幾分鐘前產生的：用戶的一個操作，背后的流程執(zhí)行到中間的時候代碼被升級了。

驗證這些場景下的兼容性的難度在于：需要驗證的可能性太多了。今天的退款請求對應的正向單據(jù)，可能是過去很多個版本的代碼產生的。一個業(yè)務流程執(zhí)行到中間具體什么地方代碼被升級了，可能性也非常多。

11、防錯設計

嚴格來說，防錯設計并不是software testing范疇內的。

但做測試做久了就發(fā)現(xiàn)，有很多bug、很多故障，如果設計的更好一點，就壓根不會發(fā)生（因此也就談不上需要測試了）。