其實(shí)軟件測試這件事情本身的難度一點(diǎn)都不亞于軟件開發(fā),甚至可能更難一點(diǎn),常見的難題主要有以下這些。
1、測夠了嗎?
其實(shí)這是一個(gè)測試充分度的問題。
代碼覆蓋率是衡量測試充分性的起點(diǎn),但遠(yuǎn)遠(yuǎn)不是終點(diǎn)。要回答”測夠了嗎“,至少還要考慮是否測了所有的場景、所有的狀態(tài)、所有的狀態(tài)轉(zhuǎn)移路徑、所有的事件序列、所有可能的配置、所有可能的數(shù)據(jù)等等等等。
即便如此,我們可能還是無法100 %確信我們已經(jīng)測夠了??赡芪覀冏罱K只能做到非常趨近于測夠了。
2、bug發(fā)現(xiàn)能力如何?
如何評價(jià)一組測試用例的發(fā)現(xiàn)bug的能力,屬于測試有效性的問題。
評價(jià)測試用例有效性可以通過正向的分析進(jìn)行,例如,分析測試用例是否校驗(yàn)了所有在測試過程中SUT落庫的數(shù)據(jù)。更具有通用性的做法是變異測試(Mutation Testing),即在被測代碼里注入不同的“人造bug”,統(tǒng)計(jì)多少能被測試用例感知到。
3、哪些測試用例是在浪費(fèi)時(shí)間?
那么多用例,要花那么多時(shí)間去跑,這里面一定有很多時(shí)間是浪費(fèi)掉的,但如何才能知道哪些是浪費(fèi)掉的呢?
浪費(fèi)的形式包括:
冗余步驟:有些是浪費(fèi)在一些重復(fù)的步驟上,每個(gè)用例都要去做一些類似的數(shù)據(jù)準(zhǔn)備,每個(gè)用例都要去執(zhí)行一些中間過程。
等價(jià)類:一個(gè)支付場景,要不要在所有的國家、所有的幣種、所有的商戶、所有的支付渠道和卡組的排列組合都測一遍?這么測,代價(jià)太高。有沒有更通用的、而且比較完備和可靠的等價(jià)類分析的技術(shù)手段?
有N個(gè)用例,推測這N個(gè)用例里面可能存在M個(gè)用例,即使刪掉這M個(gè)用例,剩下的N-M個(gè)用例的效果和之前N個(gè)用例的效果一樣。如何識(shí)別是否存在這樣的M個(gè)用例、如果存在的話是哪M個(gè)。
據(jù)說阿里內(nèi)部職級(jí)晉升P9評審,曾經(jīng)就出現(xiàn)過“測試用例很多,你怎么刪”的問題,看似簡單,其實(shí)很難。
4、要不要做全鏈路回歸?
很多團(tuán)隊(duì)都會(huì)糾結(jié)到底要不要做全鏈路回歸、做到什么程度。
這個(gè)問題的核心點(diǎn)就是:有沒有可能,只要把系統(tǒng)間的邊界約定的足夠好足夠完整,就可以做到在改動(dòng)一個(gè)系統(tǒng)的代碼后,不需要和上下游系統(tǒng)進(jìn)行集成測試,只要按照邊界約定驗(yàn)證好自己的代碼就可以確保沒有任何regression了。
很多人相信那是可能的,但既無法證明,也不敢在實(shí)操中就完全不跑集成。
5、如何減少分析遺漏?
分析遺漏是很多故障的原因。
開發(fā)做系分的時(shí)候,有一個(gè)corner case沒考慮到、沒有處理。測試做測分的時(shí)候,忘記考慮某個(gè)特殊場景了。兼容性評估,評估下來沒有兼容性問題的,但結(jié)果是有的。
而且很多時(shí)候,分析遺漏屬于unknown unknowns,我們壓根就不知道我們不知道。
6、用例自動(dòng)生成
Fuzz Test、Model Based Test、錄制回放、Traffic Bifurcation(引流)等都是自動(dòng)生成用例的手段。有些已經(jīng)比較成熟(例如單系統(tǒng)的錄制回放、引流),有些多個(gè)團(tuán)隊(duì)都在探索(例如Fuzz),有些則一直沒有大規(guī)模的成功實(shí)踐(例如MBT)。
7、問題自動(dòng)排查
包括線上和線下。對于比較初級(jí)的問題,自動(dòng)排查方案往往有兩個(gè)局限性。
首先,方案不夠通用,多多少少比較定制化。其次,比較依賴人工積累規(guī)則(說的好聽點(diǎn)叫“專家經(jīng)驗(yàn)”),主要是通過記錄和重復(fù)人肉排查的步驟來實(shí)現(xiàn)。然而,每個(gè)問題都不完全一樣,問題稍微一變,之前的排查步驟可能就不工作了。
8、缺陷自動(dòng)修復(fù)
阿里的Precfix、Facebook的SapFix等是目前比較知名的一些工業(yè)界的做法。但總的來說,現(xiàn)有的技術(shù)方案,都有這樣那樣的局限性和不足,這個(gè)領(lǐng)域還在相對早期階段,后面的路還很長。
9、測試數(shù)據(jù)準(zhǔn)備如何提高效率?
測試用例的一個(gè)重要設(shè)計(jì)原則是:測試用例之間不應(yīng)該有依賴關(guān)系,一個(gè)測試用例的執(zhí)行結(jié)果不應(yīng)該受到其他測試用例的執(zhí)行結(jié)果(包括是否執(zhí)行)的影響。
但如果每個(gè)用例所需要用到的測試數(shù)據(jù)都是自己來從頭準(zhǔn)備的,執(zhí)行效率就比較低。怎么既不違背“測試用例之間不應(yīng)該有依賴關(guān)系”的大原則,又能減少測試數(shù)據(jù)的準(zhǔn)備時(shí)間?
10、兼容性測試
代碼和數(shù)據(jù)的兼容性問題有很多形式。例如,如何確保新代碼能夠正確的處理所有的老數(shù)據(jù)?有時(shí)候,老數(shù)據(jù)是幾個(gè)月前的老代碼產(chǎn)生的,例如,一個(gè)正向支付單據(jù)可能會(huì)到幾個(gè)月以后才發(fā)生退款退票。
有時(shí)候,老數(shù)據(jù)可能就是幾分鐘前產(chǎn)生的:用戶的一個(gè)操作,背后的流程執(zhí)行到中間的時(shí)候代碼被升級(jí)了。
驗(yàn)證這些場景下的兼容性的難度在于:需要驗(yàn)證的可能性太多了。今天的退款請求對應(yīng)的正向單據(jù),可能是過去很多個(gè)版本的代碼產(chǎn)生的。一個(gè)業(yè)務(wù)流程執(zhí)行到中間具體什么地方代碼被升級(jí)了,可能性也非常多。
11、防錯(cuò)設(shè)計(jì)
嚴(yán)格來說,防錯(cuò)設(shè)計(jì)并不是software testing范疇內(nèi)的。
但做測試做久了就發(fā)現(xiàn),有很多bug、很多故障,如果設(shè)計(jì)的更好一點(diǎn),就壓根不會(huì)發(fā)生(因此也就談不上需要測試了)。