軟件測試中7個令人震驚的真相

1，當(dāng)你是一個項(xiàng)目的的測試負(fù)責(zé)人的時候，你有沒有過質(zhì)問過項(xiàng)目成員為什么沒測試出某個具體的bug，或者因?yàn)槟橙藳]有測出bug而直接責(zé)備他？

2，當(dāng)你提升了測試覆蓋率的時候你有沒有發(fā)現(xiàn)產(chǎn)品的bug數(shù)量其實(shí)沒有發(fā)生變化？

3，你有沒有在發(fā)布之前花費(fèi)了大量的時間去進(jìn)行測試卻最終發(fā)現(xiàn)一無所獲，而發(fā)布之后bug卻不期而至？

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

5，bug真的是發(fā)現(xiàn)的越晚修復(fù)成本就越高嗎？

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

7，你是否需要通過QA活動來提升產(chǎn)品質(zhì)量？

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

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

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

當(dāng)有人抱怨為什么測試沒有發(fā)現(xiàn)某些問題的時候麻煩提醒他們：測試確實(shí)沒有辦法保證一定會發(fā)現(xiàn)某些特定的缺陷。

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

永遠(yuǎn)不要責(zé)備測試工程師，他們并沒有寫出bug，相反，他們一直在努力找出開發(fā)過程中引入的缺陷。沒有什么是完美的，測試同學(xué)在接受現(xiàn)實(shí)的同時也需要記住千萬別立flag，因?yàn)闇y試不可能發(fā)現(xiàn)所有的bug。

真相2：測試覆蓋率與測試的效果幾乎沒有相關(guān)性

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

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：測試工作量呈指數(shù)增加

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

在論文“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% 所需的努力呈指數(shù)增長。

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

真相4：開發(fā)者偏差

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

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

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

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

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

真相5：晚期發(fā)現(xiàn)的缺陷可能不會花費(fèi)更多來修復(fù)

這上面的數(shù)字可能是有水分的，Laurent Bossavit 是巴黎軟件咨詢公司 CodeWorks 的敏捷方法論專家和技術(shù)顧問，他在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)的論文指出：沒有發(fā)現(xiàn)任何證據(jù)表明在代碼投入生產(chǎn)后進(jìn)行缺陷的修復(fù)需要花費(fèi)更長的時間。

論文“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.)中，作者指出：修復(fù)某些非關(guān)鍵bug的成本在整個生命周期階段幾乎保持不變（項(xiàng)目早期平均 1.2 小時，項(xiàng)目后期平均 1.5 小時）。

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

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

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

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

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

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

換句話說探索性測試可以（并且最好應(yīng)該）得到現(xiàn)有文檔的支持，例如需求文檔和設(shè)計文檔。這里的區(qū)別在于探索性測試的測試用例不是預(yù)先編寫好的。

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

測試用例仍然應(yīng)該使用邊界值分析、等價類劃分等技術(shù)來設(shè)計。我們沒有理由設(shè)計一些隨機(jī)的測試用例，因?yàn)樗鼈冊跈z測缺陷方面可能不具有成本優(yōu)勢或有效性。

真相7：改進(jìn)流程中的非質(zhì)量保證活動可以提高產(chǎn)品質(zhì)量

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

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.

獎勵關(guān)（有趣的事實(shí)）：百慕大計劃

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

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

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

根據(jù)我的經(jīng)驗(yàn)，加入團(tuán)隊的每個新人都會占用一個老人工作時間的 1/3 左右，直到新人們逐漸提高生產(chǎn)力。

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

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

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

否則，移除人員只會降低團(tuán)隊在短期內(nèi)的輸出。

無論如何，我只是在分享百慕大計劃，因?yàn)檎務(wù)撍�總是很有趣�?/span>

本文由培訓(xùn)無憂網(wǎng)長沙牛耳教育課程顧問老師整理發(fā)布，希望能夠?qū)ο雲(yún)⒓娱L沙軟件測試培訓(xùn)的學(xué)生有所幫助。更多軟件測試培訓(xùn)課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)或添加老師微信：15033336050

      注：尊重原創(chuàng)文章,轉(zhuǎn)載請注明出處和鏈接 http://www.elsolbar.com/news-id-11359.html 違者必究！部分文章來源于網(wǎng)絡(luò)由培訓(xùn)無憂網(wǎng)編輯部人員整理發(fā)布,內(nèi)容真實(shí)性請自行核實(shí)或聯(lián)系我們，了解更多相關(guān)資訊請關(guān)注軟件測試頻道查看更多，了解相關(guān)專業(yè)課程信息您可在線咨詢也可免費(fèi)申請試課。關(guān)注官方微信了解更多：150 3333 6050