1，當你是一個項目的的測試負責人的時候，你有沒有過質問過項目成員為什么沒測試出某個具體的bug，或者因為某人沒有測出bug而直接責備他？

2，當你提升了測試覆蓋率的時候你有沒有發現產品的bug數量其實沒有發生變化？

3，你有沒有在發布之前花費了大量的時間去進行測試卻最終發現一無所獲，而發布之后bug卻不期而至？

4，開發可以測試他們自己的代碼嗎？

5，bug真的是發現的越晚修復成本就越高嗎？

6，你有沒有過以不按套路出牌的方式來進行軟件的測試，并稱之為“探索性測試”？

7，你是否需要通過QA活動來提升產品質量？

真相1：測試并不能找出所有的bug

很不幸這是真的，沒有任何一種測試方式可以保證找出所有的bug。

一些測試活動跟直接上手點點點相比確實效率要低一些，所以我們可以不用那么關注測試的類型，相反我們要做的是選擇合適的測試類型并綜合使用，從而以最少的工作量打到較好的效果。（比如ui的自動化測試如果要做到非常復雜那么將花費相當大的開發和維護成本，但沒有ui的自動化，每輪測試都靠人肉點來點去也不現實，所以比較合適的做法是一些穩定的核心路徑可以用ui自動化去實現，平衡投入產出比，用較少的工作量達到效率最大化）

當有人抱怨為什么測試沒有發現某些問題的時候麻煩提醒他們：測試確實沒有辦法保證一定會發現某些特定的缺陷。

我們會經常復盤測試的漏測情況，很不幸，這是落后的想法，這就像是在魔術揭秘了之后再馬后炮的說其實這個戲法很簡單，很容易被識破一樣。事后做漏測復盤并不是一個有效的分析手段。

永遠不要責備測試工程師，他們并沒有寫出bug，相反，他們一直在努力找出開發過程中引入的缺陷。沒有什么是完美的，測試同學在接受現實的同時也需要記住千萬別立flag，因為測試不可能發現所有的bug。

真相2：測試覆蓋率與測試的效果幾乎沒有相關性

是的，你沒有看錯。我們已經有足夠的科學證據表明，增加單元測試覆蓋率不一定會提高我們測試套件發現bug的效率！也許是時候關注與測試相關的內容而不是正在測試的代碼量了。（這里作者的原話是We already have enough scientific evidence to say that increasing unit test coverage may not necessarily increase your test suite effectiveness in finding defects!直譯過來就是單元覆蓋率的提升并不會提升測試套件發現缺陷的效率，說實話，我覺得單元測試覆蓋率跟測試中發現bug的效率本來就沒有什么關系，覆蓋率代表的是代碼被測試的程度，而發現bug的效率指的是時間和產出的關系，發現bug的效率高并不代表著產品的質量就好，反之亦然。不過看下文引用資料時的描述，我們可以看到作者的舉證基本上都透露了一個信息，那就是單元測試覆蓋率與bug的數量之前沒有太多的關聯，換句話說就是并不是單元測試覆蓋率越高，產品的質量就越好，因為產品的質量好一般意味著可被觀察到的bug相對少，而bug又跟單元測試覆蓋率無關。這里為了嚴謹，作者的引用我就不做翻譯了。）

1. *A. Mockus, N. Nagappan, and T.T. Dinh-Trong, “Test Coverage and Post-verification Defects: A Multiple Case Study,” Proc. 3rd Int’l Symp. Empirical Software Eng. and Measurement (ESEM 09), 2009, pp. 291–301.*The correlation between coverage and defects was **none or very weak**. Moreover, the effort required to increase the coverage from a certain level to 100% increased exponentially. 

2. *M.R. Lyu, J. Horgan, and S. London, “A Coverage Analysis Tool for the Effectiveness of Software Testing,” IEEE Trans. Reliability, vol. 43, no. 4, 1994, pp. 527–535.*Qualitative analysis found **no association** between the defects and coverage. 

3. *B. Smith and L.A. Williams, A Survey on Code Coverage as a Stopping Criterion for Unit Testing, tech. report TR-2008

22, Dept. of Computer Science, North Carolina State Univ., 2008, pp. 16.*The results **did not support the hypothesis of a causal dependency** between test coverage and the number of defects when testing intensity was controlled for.

4. *L. Briand and D. Pfahl, “Using Simulation for Assessing the Real Impact of Test Coverage on Defect Coverage,” Proc. 10th Int’l Symp. Software Reliability Eng., 1999, pp. 148157.*The results **did not support the hypothesis of a causal dependency** between test coverage and the number of defects when testing intensity was controlled for.

5. *P.S. Kochhar, F. Thung, and D. Lo, “Code Coverage and Test Suite Effectiveness: Empirical Study with Real Bugs in Large Systems,” Proc. IEEE 22nd Int’l Conf. Software Analysis, Evolution, and Reengineering (SANER 15), 2015, pp. 560-564.*A **moderate to strong correlation was found** between coverage and defects. However, the **coverage was manipulated and calculated manually**.

6. *L. Inozemtseva and R. Holmes, “Coverage Is Not Strongly Correlated with Test Suite Effectiveness,” Proc. 36th Int’l Conf. Software Eng. (ICSE 14), 2014, pp. 435445.*A **weak to moderate correlation** was found between coverage and defects. The type of coverage did not have an impact on the results.

7. *X. Cai and M.R. Lyu, “The Effect of Code Coverage on Fault Detection under Different Testing Profiles,” ACM SIGSOFT Software Eng. Notes, vol. 30, no. 4, 2005, pp. 1–7.*A **moderate correlation** was found between coverage and defects, but the **defects were artificially introduced**. The correlation was different for different testing profiles. 8. *G. Gay et al., “The Risks of Coverage-Directed Test Case Generation,” IEEE Trans. Software Eng., vol. 41, no. 8, 2015, pp. 803–819.*Coverage measures were **weak indicators for test suite adequacy**. **High coverage did not necessarily mean effective testing**.

真相3：測試工作量呈指數增加

許多消息來源指出，測試人員會在測試活動開始時發現更多缺陷，而在結束時發現缺陷則更少。有跡象表明，為了找到下一個缺陷，增加覆蓋率和執行測試的工作量呈指數增長。

在論文“Test Coverage and Post-verification Defects: A Multiple Case Study,” (A. Mockus, N. Nagappan, and T.T. Dinh-Trong, Proc. 3rd Int’l Symp. Empirical Software Eng. and Measurement (ESEM 09), 2009, pp. 291–301.)中透露：將覆蓋率從某個水平增加到 100% 所需的努力呈指數增長。

根據“Implementing automated software testing: How to save time and lower costs while raising quality.” (Dustin, E., Garrett, T., & Gauf, B. (2009). Pearson Education.),的闡述：軟件可靠性模型表明，隨著在測試中投入更多時間，每單位時間發現的缺陷數量呈指數減少。

真相4：開發者偏差

如果開發人員在開發階段直接把一個需求理解錯了，那么他寫出來的代碼就是錯的，對于測試人員來說情況也一樣。

如果開發同學直接忘記在代碼中處理某些情況，比如特定的條件驗證，那么他也很可能不會記得對這種場景進行測試。

為了避免這種情況，開發人員可以互相測試彼此的代碼，但他們最好不要測試自己的代碼，這就是所謂的交叉測試。

在沒有設計任何測試用例的情況下，開發同學還是可以測試自己的代碼的，這樣就可以盡可能的避免一些先入為主的偏差。

測試驅動開發可能會降低開發忘記做某事概率，但不會減少誤解某些需求的概率。

真相5：晚期發現的缺陷可能不會花費更多來修復

這上面的數字可能是有水分的，Laurent Bossavit 是巴黎軟件咨詢公司 CodeWorks 的敏捷方法論專家和技術顧問，他在github上的文章“Degrees of intellectual dishonesty”就透露了這些信息可能是被捏造出來的。

在一篇名為“Are delayed issues harder to resolve? Revisiting cost-to-fix of defects throughout the lifecycle” (Menzies, T., Nichols, W., Shull, F. et al. Empir Software Eng 22, 1903–1935 (2017) https://doi.org/10.1007/s10664-016-9469-x)的論文指出：沒有發現任何證據表明在代碼投入生產后進行缺陷的修復需要花費更長的時間。

論文“What We Have Learned About Fighting Defects” (Forrest Shull, Vic Basili, Barry Boehm, et al., Proceedings of the 8th International Symposium on Software Metrics (METRICS ‘02). IEEE Computer Society, USA, 249. 2002.)中，作者指出：修復某些非關鍵bug的成本在整個生命周期階段幾乎保持不變（項目早期平均 1.2 小時，項目后期平均 1.5 小時）。

不過很多的研究都在度量定位錯誤和修復bug的工作量，那么他們忽略了什么？

回歸測試：在發布之前我們要進行頻繁的回歸，為了驗證某些重要的bug已經被修復了，我們就需要一次又一次的對主流程甚至是大部分的邏輯進行回歸測試，這顯然是很巨大的工作量；
機會成本：在項目的晚期發現問題的時候，很多人往往會將bug排到下一個版本或項目，這很可能導致項目延期交付；
企業商譽成本：企業可能會被罰款，客戶可能會虧錢，用戶體驗自然也就不好。2020 年 12 月，游戲《賽博朋克 2077》因發售時出現諸多技術問題而從索尼商店下架。索尼提供全額退款。隨后，開發商CD Projekt Red宣布對PS4和Xbox玩家進行退款。在投資者電話會議上，CD Projekt Red 表示“與恢復公司聲譽相比，《賽博朋克 2077》修復的成本“無關緊要”。該公司的股票已從 2020 年 12 月的每股 31 美元跌至 2021 年 6 月的每股 10 美元。
bug并不是在代碼中引入的。比如在項目的初期做技術設計的時候就存在缺陷，或者需求本身就是個bug，那么越晚發現災難就越大。

因此，雖然發布后修復代碼錯誤的工作量可能不會增加那么多，但早期修復bug可以節省大量精力、金錢和麻煩。

真相6：探索性測試需要流程和文檔

很多人認為如果他們對產品做一些無法預料結果的操作，比如在表單胡亂輸入并且提交，那么他們就是在做探索性測試。

其實探索性測試并不意味著你要對系統或者產品做一些特別的事情，它往往意味著我們需要了解系統是如何真正工作的，并且與普通的功能測試同時進行。

換句話說探索性測試可以（并且最好應該）得到現有文檔的支持，例如需求文檔和設計文檔。這里的區別在于探索性測試的測試用例不是預先編寫好的。

探索性測試可以腳本化，一旦發現問題就可以把bug記錄在案，然后可重復執行的腳本又可以在后面的測試過程中反復使用。（比如探索測試時可以使用瀏覽器自帶的錄制功能，發現bug之后就把錄制好的腳本保存下來，給后面的回歸測試使用，chrome現在已經自帶了錄制能力了）。

測試用例仍然應該使用邊界值分析、等價類劃分等技術來設計。我們沒有理由設計一些隨機的測試用例，因為它們在檢測缺陷方面可能不具有成本優勢或有效性。

真相7：改進流程中的非質量保證活動可以提高產品質量

（這里原文的論述我實在是沒弄明白并且找不到合適的數據支持，所以就簡單的粘貼英文版本了）

A 2009 study in Brazil (in Portuguese) involving 135 software development organizations had their capacity to identify and fix defects increased by improving their processes. These companies were part of a Brazilian software process improvement program called “MPS.Br,” where they should adhere to a software process improvement model (the MPS Model).

This model has stages, and 58 of these companies were in the first stage, where they were required to improve their Project Management and Requirements Management processes.

While it’s unclear why this happened, we can reasonably expect that projects that identify the right people to participate in the team, training needs, and proper budget and schedule will likely have the people, the time, and other resources to improve quality.

獎勵關（有趣的事實）：百慕大計劃

好吧，這是一個有趣的，但沒有解釋的事實，它可能真的不起作用。

百慕大計劃是更快完成項目的戰略名稱。將團隊的一部分派往百慕大（即，將他們從項目中移除），項目會更快完成。

它被認為是對布魯克斯定律（Brooks’s law）的回應（對軟件項目管理的一種觀察，根據該定律，“在延期的軟件項目中增加人力會讓項目交付的更慢一些”）。那么，如果您移除人員，項目是否應該進行的更加迅速？

根據我的經驗，加入團隊的每個新人都會占用一個老人工作時間的 1/3 左右，直到新人們逐漸提高生產力。

因此，踢走最近加入的人可能真的會提高工作效率。

如果團隊中有太多沖突，它可以起作用的其他原因是：移除與團隊目標不一致的人可能會對團隊有所幫助。

如果團隊中有太多人，那么溝通開銷可能會大到足以阻礙生產力。在這種情況下，拆分團隊可能效果很好（這在技術上與從項目中移除人員不同）。

否則，移除人員只會降低團隊在短期內的輸出。

無論如何，我只是在分享百慕大計劃，因為談論它總是很有趣。

本文由培訓無憂網長沙牛耳教育課程顧問老師整理發布，希望能夠對想參加長沙軟件測試培訓的學生有所幫助。更多軟件測試培訓課程信息可關注培訓無憂網電腦IT培訓或添加老師微信：15033336050

      注：尊重原創文章,轉載請注明出處和鏈接 http://m.dedgn.cn/news-id-11359.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注軟件測試頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050