軟件測試中7個(gè)令人震驚的真相
2021-12-30點(diǎn)擊量：148
1，當(dāng)你是一個(gè)項(xiàng)目的的測試負(fù)責(zé)人的時(shí)候，你有沒有過質(zhì)問過項(xiàng)目成員為什么沒測試出某個(gè)具體的bug，或者因?yàn)槟橙藳]有測出bug而直接責(zé)備他？2，當(dāng)你提升了測試覆蓋率的時(shí)候你有沒有發(fā)現(xiàn)產(chǎn)品的bug數(shù)量其實(shí)沒有發(fā)生變化？3，你有沒有在發(fā)布之前花費(fèi)了大量的時(shí)間去進(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í)候麻煩提醒他們：測試確實(shí)沒有辦法保證一定會發(fā)現(xiàn)某些特定的缺陷。我們會經(jīng)常復(fù)盤測試的漏測情況，很不幸，這是落后的想法，這就像是在魔術(shù)揭秘了之后再馬后炮的說其實(shí)這個(gè)戲法很簡單，很容易被識破一樣。事后做漏測復(fù)盤并不是一個(gè)有效的分析手段。永遠(yuǎn)不要責(zé)備測試工程師，他們并沒有寫出bug，相反，他們一直在努力找出開發(fā)過程中引入的缺陷。沒有什么是完美的，測試同學(xué)在接受現(xiàn)實(shí)的同時(shí)也需要記住千萬別立flag，因?yàn)闇y試不可能發(fā)現(xiàn)所有的bug。真相2：測試覆蓋率與測試的效果幾乎沒有相關(guān)性是的，你沒有看錯(cuò)。我們已經(jīng)有足夠的科學(xué)證據(jù)表明，增加單元測試覆蓋率不一定會提高我們測試套件發(fā)現(xiàn)bug的效率！也許是時(shí)候關(guān)注與測試相關(guān)的內(nèi)容而不是正在測試的代碼量了。（這里作者的原話是Wealreadyhaveenoughscientificevidencetosaythatincreasingunittestcoveragemaynotnecessarilyincreaseyourtestsuiteeffectivenessinfindingdefects!直譯過來就是單元覆蓋率的提升并不會提升測試套件發(fā)現(xiàn)缺陷的效率，說實(shí)話，我覺得單元測試覆蓋率跟測試中發(fā)現(xiàn)bug的效率本來就沒有什么關(guān)系，覆蓋率代表的是代碼被測試的程度，而發(fā)現(xiàn)bug的效率指的是時(shí)間和產(chǎn)出的關(guān)系，發(fā)現(xiàn)bug的效率高并不代表著產(chǎn)品的質(zhì)量就好，反之亦然。不過看下文引用資料時(shí)的描述，我們可以看到作者的舉證基本上都透露了一個(gè)信息，那就是單元測試覆蓋率與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,andT.T.Dinh-Trong,“TestCoverageandPost-verificationDefects:AMultipleCaseStudy,”Proc.3rdInt’lSymp.EmpiricalSoftwareEng.andMeasurement(ESEM09),2009,pp.291–301.*Thecorrelationbetweencoverageanddefectswas**noneorveryweak**.Moreover,theeffortrequiredtoincreasethecoveragefromacertainlevelto100%increasedexponentially.2.*M.R.Lyu,J.Horgan,andS.London,“ACoverageAnalysisToolfortheEffectivenessofSoftwareTesting,”IEEETrans.Reliability,vol.43,no.4,1994,pp.527–535.*Qualitativeanalysisfound**noassociation**betweenthedefectsandcoverage.3.*B.SmithandL.A.Williams,ASurveyonCodeCoverageasaStoppingCriterionforUnitTesting,tech.reportTR-200822,Dept.ofComputerScience,NorthCarolinaStateUniv.,2008,pp.16.*Theresults**didnotsupportthehypothesisofacausaldependency**betweentestcoverageandthenumberofdefectswhentestingintensitywascontrolledfor.4.*L.BriandandD.Pfahl,“UsingSimulationforAssessingtheRealImpactofTestCoverageonDefectCoverage,”Proc.10thInt’lSymp.SoftwareReliabilityEng.,1999,pp.148157.*Theresults**didnotsupportthehypothesisofacausaldependency**betweentestcoverageandthenumberofdefectswhentestingintensitywascontrolledfor.5.*P.S.Kochhar,F.Thung,andD.Lo,“CodeCoverageandTestSuiteEffectiveness:EmpiricalStudywithRealBugsinLargeSystems,”Proc.IEEE22ndInt’lConf.SoftwareAnalysis,Evolution,andReengineering(SANER15),2015,pp.560-564.*A**moderatetostrongcorrelationwasfound**betweencoverageanddefects.However,the**coveragewasmanipulatedandcalculatedmanually**.6.*L.InozemtsevaandR.Holmes,“CoverageIsNotStronglyCorrelatedwithTestSuiteEffectiveness,”Proc.36thInt’lConf.SoftwareEng.(ICSE14),2014,pp.435445.*A**weaktomoderatecorrelation**wasfoundbetweencoverageanddefects.Thetypeofcoveragedidnothaveanimpactontheresults.7.*X.CaiandM.R.Lyu,“TheEffectofCodeCoverageonFaultDetectionunderDifferentTestingProfiles,”ACMSIGSOFTSoftwareEng.Notes,vol.30,no.4,2005,pp.1–7.*A**moderatecorrelation**wasfoundbetweencoverageanddefects,butthe**defectswereartificiallyintroduced**.Thecorrelationwasdifferentfordifferenttestingprofiles.8.*G.Gayetal.,“TheRisksofCoverage-DirectedTestCaseGeneration,”IEEETrans.SoftwareEng.,vol.41,no.8,2015,pp.803–819.*Coveragemeasureswere**weakindicatorsfortestsuiteadequacy**.**Highcoveragedidnotnecessarilymeaneffectivetesting**.真相3：測試工作量呈指數(shù)增加許多消息來源指出，測試人員會在測試活動開始時(shí)發(fā)現(xiàn)更多缺陷，而在結(jié)束時(shí)發(fā)現(xiàn)缺陷則更少。有跡象表明，為了找到下一個(gè)缺陷，增加覆蓋率和執(zhí)行測試的工作量呈指數(shù)增長。在論文“TestCoverageandPost-verificationDefects:AMultipleCaseStudy,”(A.Mockus,N.Nagappan,andT.T.Dinh-Trong,Proc.3rdInt’lSymp.EmpiricalSoftwareEng.andMeasurement(ESEM09),2009,pp.291–301.)中透露：將覆蓋率從某個(gè)水平增加到100%所需的努力呈指數(shù)增長。根據(jù)“Implementingautomatedsoftwaretesting:Howtosavetimeandlowercostswhileraisingquality.”(Dustin,E.,Garrett,T.,&Gauf,B.(2009).PearsonEducation.),的闡述：軟件可靠性模型表明，隨著在測試中投入更多時(shí)間，每單位時(shí)間發(fā)現(xiàn)的缺陷數(shù)量呈指數(shù)減少。真相4：開發(fā)者偏差如果開發(fā)人員在開發(fā)階段直接把一個(gè)需求理解錯(cuò)了，那么他寫出來的代碼就是錯(cuò)的，對于測試人員來說情況也一樣。如果開發(fā)同學(xué)直接忘記在代碼中處理某些情況，比如特定的條件驗(yàn)證，那么他也很可能不會記得對這種場景進(jìn)行測試。為了避免這種情況，開發(fā)人員可以互相測試彼此的代碼，但他們最好不要測試自己的代碼，這就是所謂的交叉測試。在沒有設(shè)計(jì)任何測試用例的情況下，開發(fā)同學(xué)還是可以測試自己的代碼的，這樣就可以盡可能的避免一些先入為主的偏差。測試驅(qū)動開發(fā)可能會降低開發(fā)忘記做某事概率，但不會減少誤解某些需求的概率。真相5：晚期發(fā)現(xiàn)的缺陷可能不會花費(fèi)更多來修復(fù)這上面的數(shù)字可能是有水分的，LaurentBossavit是巴黎軟件咨詢公司CodeWorks的敏捷方法論專家和技術(shù)顧問，他在github上的文章“Degreesofintellectualdishonesty”就透露了這些信息可能是被捏造出來的。在一篇名為“Aredelayedissueshardertoresolve?Revisitingcost-to-fixofdefectsthroughoutthelifecycle”(Menzies,T.,Nichols,W.,Shull,F.etal.EmpirSoftwareEng22,1903–1935(2017)https://doi.org/10.1007/s10664-016-9469-x)的論文指出：沒有發(fā)現(xiàn)任何證據(jù)表明在代碼投入生產(chǎn)后進(jìn)行缺陷的修復(fù)需要花費(fèi)更長的時(shí)間。論文“WhatWeHaveLearnedAboutFightingDefects”(ForrestShull,VicBasili,BarryBoehm,etal.,Proceedingsofthe8thInternationalSymposiumonSoftwareMetrics(METRICS‘02).IEEEComputerSociety,USA,249.2002.)中，作者指出：修復(fù)某些非關(guān)鍵bug的成本在整個(gè)生命周期階段幾乎保持不變（項(xiàng)目早期平均1.2小時(shí)，項(xiàng)目后期平均1.5小時(shí)）。不過很多的研究都在度量定位錯(cuò)誤和修復(fù)bug的工作量，那么他們忽略了什么？回歸測試：在發(fā)布之前我們要進(jìn)行頻繁的回歸，為了驗(yàn)證某些重要的bug已經(jīng)被修復(fù)了，我們就需要一次又一次的對主流程甚至是大部分的邏輯進(jìn)行回歸測試，這顯然是很巨大的工作量；機(jī)會成本：在項(xiàng)目的晚期發(fā)現(xiàn)問題的時(shí)候，很多人往往會將bug排到下一個(gè)版本或項(xiàng)目，這很可能導(dǎo)致項(xiàng)目延期交付；企業(yè)商譽(yù)成本：企業(yè)可能會被罰款，客戶可能會虧錢，用戶體驗(yàn)自然也就不好。2020年12月，游戲《賽博朋克2077》因發(fā)售時(shí)出現(xiàn)諸多技術(shù)問題而從索尼商店下架。索尼提供全額退款。隨后，開發(fā)商CDProjektRed宣布對PS4和Xbox玩家進(jìn)行退款。在投資者電話會議上，CDProjektRed表示“與恢復(fù)公司聲譽(yù)相比，《賽博朋克2077》修復(fù)的成本“無關(guān)緊要”。該公司的股票已從2020年12月的每股31美元跌至2021年6月的每股10美元。bug并不是在代碼中引入的。比如在項(xiàng)目的初期做技術(shù)設(shè)計(jì)的時(shí)候就存在缺陷，或者需求本身就是個(gè)bug，那么越晚發(fā)現(xiàn)災(zāi)難就越大。因此，雖然發(fā)布后修復(fù)代碼錯(cuò)誤的工作量可能不會增加那么多，但早期修復(fù)bug可以節(jié)省大量精力、金錢和麻煩。真相6：探索性測試需要流程和文檔很多人認(rèn)為如果他們對產(chǎn)品做一些無法預(yù)料結(jié)果的操作，比如在表單胡亂輸入并且提交，那么他們就是在做探索性測試。其實(shí)探索性測試并不意味著你要對系統(tǒng)或者產(chǎn)品做一些特別的事情，它往往意味著我們需要了解系統(tǒng)是如何真正工作的，并且與普通的功能測試同時(shí)進(jìn)行。換句話說探索性測試可以（并且最好應(yīng)該）得到現(xiàn)有文檔的支持，例如需求文檔和設(shè)計(jì)文檔。這里的區(qū)別在于探索性測試的測試用例不是預(yù)先編寫好的。探索性測試可以腳本化，一旦發(fā)現(xiàn)問題就可以把bug記錄在案，然后可重復(fù)執(zhí)行的腳本又可以在后面的測試過程中反復(fù)使用。（比如探索測試時(shí)可以使用瀏覽器自帶的錄制功能，發(fā)現(xiàn)bug之后就把錄制好的腳本保存下來，給后面的回歸測試使用，chrome現(xiàn)在已經(jīng)自帶了錄制能力了）。測試用例仍然應(yīng)該使用邊界值分析、等價(jià)類劃分等技術(shù)來設(shè)計(jì)。我們沒有理由設(shè)計(jì)一些隨機(jī)的測試用例，因?yàn)樗鼈冊跈z測缺陷方面可能不具有成本優(yōu)勢或有效性。真相7：改進(jìn)流程中的非質(zhì)量保證活動可以提高產(chǎn)品質(zhì)量（這里原文的論述我實(shí)在是沒弄明白并且找不到合適的數(shù)據(jù)支持，所以就簡單的粘貼英文版本了）A2009studyinBrazil(inPortuguese)involving135softwaredevelopmentorganizationshadtheircapacitytoidentifyandfixdefectsincreasedbyimprovingtheirprocesses.ThesecompanieswerepartofaBraziliansoftwareprocessimprovementprogramcalled“MPS.Br,”wheretheyshouldadheretoasoftwareprocessimprovementmodel(theMPSModel).Thismodelhasstages,and58ofthesecompanieswereinthefirststage,wheretheywererequiredtoimprovetheirProjectManagementandRequirementsManagementprocesses.Whileit’sunclearwhythishappened,wecanreasonablyexpectthatprojectsthatidentifytherightpeopletoparticipateintheteam,trainingneeds,andproperbudgetandschedulewilllikelyhavethepeople,thetime,andotherresourcestoimprovequality.獎勵(lì)關(guān)（有趣的事實(shí)）：百慕大計(jì)劃好吧，這是一個(gè)有趣的，但沒有解釋的事實(shí)，它可能真的不起作用。百慕大計(jì)劃是更快完成項(xiàng)目的戰(zhàn)略名稱。將團(tuán)隊(duì)的一部分派往百慕大（即，將他們從項(xiàng)目中移除），項(xiàng)目會更快完成。它被認(rèn)為是對布魯克斯定律（Brooks’slaw）的回應(yīng)（對軟件項(xiàng)目管理的一種觀察，根據(jù)該定律，“在延期的軟件項(xiàng)目中增加人力會讓項(xiàng)目交付的更慢一些”）。那么，如果您移除人員，項(xiàng)目是否應(yīng)該進(jìn)行的更加迅速？根據(jù)我的經(jīng)驗(yàn)，加入團(tuán)隊(duì)的每個(gè)新人都會占用一個(gè)老人工作時(shí)間的1/3左右，直到新人們逐漸提高生產(chǎn)力。因此，踢走最近加入的人可能真的會提高工作效率。如果團(tuán)隊(duì)中有太多沖突，它可以起作用的其他原因是：移除與團(tuán)隊(duì)目標(biāo)不一致的人可能會對團(tuán)隊(duì)有所幫助。如果團(tuán)隊(duì)中有太多人，那么溝通開銷可能會大到足以阻礙生產(chǎn)力。在這種情況下，拆分團(tuán)隊(duì)可能效果很好（這在技術(shù)上與從項(xiàng)目中移除人員不同）。否則，移除人員只會降低團(tuán)隊(duì)在短期內(nèi)的輸出。無論如何，我只是在分享百慕大計(jì)劃，因?yàn)檎務(wù)撍偸呛苡腥ぁ１疚挠膳嘤?xùn)無憂網(wǎng)長沙牛耳教育課程顧問老師整理發(fā)布，希望能夠?qū)ο雲(yún)⒓娱L沙軟件測試培訓(xùn)的學(xué)生有所幫助。更多軟件測試培訓(xùn)課程信息可關(guān)注培訓(xùn)無憂網(wǎng)電腦IT培訓(xùn)或添加老師微信：15033336050...
人氣：6521五三教育廊坊市
人氣：29758咸陽海文考研咸陽市渭城區(qū)文林路1號咸陽師范學(xué)院大學(xué)生服務(wù)中心2樓東側(cè)
人氣：4833寶雞海文考研寶雞市渭濱區(qū)寶光路44號寶雞文理學(xué)院老區(qū)大門口東側(cè)20米
人氣：10216西安海文考研西安市雁塔區(qū)小寨嘉匯漢唐書城寫字間9樓海文考研(長安中路111號)
人氣：29592深圳思學(xué)佳教育深圳市寶安區(qū)寶安中心創(chuàng)業(yè)一路宏發(fā)領(lǐng)域3樓（寶安中心地鐵站B出口30米）
人氣：7344溫州海文考研浙江省溫州市甌海區(qū)茶山街道中心東路茶山創(chuàng)榮廣場2棟
人氣：6897金華海文考研浙江省金華市婺城高村瓦云路77號（浙江師范大學(xué)北門右側(cè)20米）
人氣：6355寧波海文考研浙江省寧波市江北區(qū)孔浦街道風(fēng)華路928弄云創(chuàng)小鎮(zhèn)C4號樓
人氣：6594紹興海文考研浙江省紹興市越城區(qū)城南大道835號
人氣：6561嘉興海文考研培訓(xùn)浙江省嘉興市南湖區(qū)中環(huán)南路2608號福地廣場
