過去的一段時(shí)間，我總被炸了毛測(cè)試人員怒懟： 供應(yīng)商釋放的軟件版本就像叛逆期少年的褲衩子——漏洞百出。你是零件的爸爸，崽子這樣了都不要管管的嘛？
在多次促膝長談后，我捕捉到了測(cè)試人員的痛點(diǎn)。
因?yàn)楣?yīng)商趕工期，軟件釋放前缺少自測(cè)環(huán)節(jié)，導(dǎo)致功能嚴(yán)重失效問題暴露到驗(yàn)收測(cè)試處。驗(yàn)收測(cè)試收到新功能軟件版本后，即按照全量測(cè)試的方式測(cè)試，測(cè)到一半發(fā)現(xiàn)軟件的許多關(guān)鍵功能不ok，而這時(shí)已經(jīng)投入了較多的人力成本；或者，對(duì)bug修復(fù)部分功能做復(fù)測(cè)，發(fā)現(xiàn)原bug功能已修復(fù)后，再執(zhí)行全量測(cè)試，結(jié)果測(cè)到一半，原本正常的關(guān)鍵功能，現(xiàn)在不正常了。
軟件肯定是不能用的，已經(jīng)投入的大量測(cè)試時(shí)間和人力就打了水漂。畢竟智能件動(dòng)輒幾千的測(cè)試case可不是隨便鬧著玩的。
在普遍趕工期的新能源車企里，我趕腳這種情況不是個(gè)例。
軟件工程里有自成體系的測(cè)試方法論，但從傳統(tǒng)汽車模式轉(zhuǎn)型SDV汽車模式的過渡中，很多軟件工程的方法論都還沒有為汽車人所用。
比如，上面舉的這個(gè)例子。后面的解決辦法是，我和測(cè)試人員一起制定了功能驗(yàn)收測(cè)試的快速點(diǎn)檢表。從模塊化的功能里提取關(guān)鍵的測(cè)試用例case。這個(gè)case如果能跑通，則基本說明這個(gè)模塊的功能是正常的。例如，測(cè)試BLE近場(chǎng)車控，從中選擇了功能較為復(fù)雜的虛擬鑰匙權(quán)限釋放。
而在對(duì)這部分再進(jìn)行深入了解后，發(fā)現(xiàn)這些問題完全是可以借助軟件工程的標(biāo)準(zhǔn)測(cè)試流程規(guī)避的。我所謂的 “功能快速點(diǎn)檢表”，其實(shí)就是冒煙測(cè)試用例。
類似地，還有常常出現(xiàn)在軟件供應(yīng)商或來自互聯(lián)網(wǎng)公司同事嘴里常常蹦出來的增量測(cè)試、回歸測(cè)試，增量回歸測(cè)試、全量回歸測(cè)試等等。
本著盡量把知識(shí)系統(tǒng)化的原則，我對(duì)這些行話做了些功課。整理成文，供自己常看常新，也給相關(guān)領(lǐng)域的朋友做拋磚引玉之用。
首先是兩個(gè)關(guān)鍵的行話：冒煙測(cè)試、回歸測(cè)試。
冒煙測(cè)試
使用場(chǎng)景：
冒煙測(cè)試原本是硬件測(cè)試的行話，后來引入到軟件測(cè)試中，是指，完成一個(gè)新版本的開發(fā)后，先投入較少的人力和時(shí)間，對(duì)該版本最基本/核心的功能進(jìn)行測(cè)試，保證基本/核心的功能和流程能走通。如果不通過，則打回開發(fā)那邊重新開發(fā)；如果通過測(cè)試，才會(huì)進(jìn)行下一步的測(cè)試(功能測(cè)試，集成測(cè)試，系統(tǒng)測(cè)試等等)。
冒煙測(cè)試?yán)碚撋鲜且蓽y(cè)試人員做。但這樣無法約束開發(fā)代碼人員的發(fā)版質(zhì)量，所以現(xiàn)在一般讓開發(fā)代碼人員做。跑通了基本/核心功能后，再提交測(cè)試人員后續(xù)測(cè)試。冒煙測(cè)試的優(yōu)點(diǎn)是節(jié)省測(cè)試時(shí)間。缺點(diǎn)是用例覆蓋率比較低。
開發(fā)與測(cè)試人員充分溝通，利用冒煙的優(yōu)勢(shì)特點(diǎn)，制定合適的冒煙用例。使其既可作為版本的快速校驗(yàn)工具，管控提測(cè)版本質(zhì)量；也可以在緊急發(fā)版的客觀要求下，作為軟件發(fā)版的測(cè)試用例，點(diǎn)檢關(guān)鍵功能。像我上面所述的“功能快速點(diǎn)檢表”，就可以視為冒煙測(cè)試用例。
回歸測(cè)試
回歸測(cè)試主要是指修改舊代碼修復(fù)bug后，重新進(jìn)行測(cè)試，以確認(rèn)修改有沒有生效，或者有沒有引進(jìn)新的錯(cuò)誤。回歸測(cè)試可以分為增量回歸測(cè)試（選擇性回歸測(cè)試）和全量回歸測(cè)試。
新增功能開發(fā)完成，或bug修復(fù)后，回歸測(cè)試時(shí)，只針對(duì)新增功能或出現(xiàn)問題的這些功能進(jìn)行驗(yàn)證，沒有涉及到的功能就不進(jìn)行測(cè)試。
重點(diǎn)測(cè)試修改的功能，節(jié)約時(shí)間和人力成本。但非常容易出現(xiàn)bug修改后，潛在的關(guān)聯(lián)功能可能從正常變?yōu)槭?，而?dǎo)致測(cè)試遺漏。
(1) 前期功能充分溝通，測(cè)試用例備注關(guān)聯(lián)模塊。前期在開發(fā)和測(cè)試人員功能分析時(shí)，需要充分溝通，了解功能/函數(shù)之間調(diào)用關(guān)系，了解可能的關(guān)聯(lián)項(xiàng)。并在測(cè)試用例中注明關(guān)聯(lián)項(xiàng)。最了解功能之間關(guān)聯(lián)項(xiàng)的是開發(fā)人員。因此開發(fā)人員在新增功能或修復(fù)bug時(shí)，務(wù)必注明，這個(gè)bug是由什么原因引起的、bug修復(fù)的邏輯，以及可能會(huì)對(duì)關(guān)聯(lián)功能產(chǎn)生的影響。小小舉動(dòng)，事半功倍。雖然，分析下來，有些關(guān)鍵功能跟本次的修改沒有直接關(guān)聯(lián)，但出于保險(xiǎn)起見，關(guān)鍵功能最好也趟一遍測(cè)試用例。因?yàn)檫@是用戶權(quán)重占比較高的功能，一旦失效，影響會(huì)比較大。在測(cè)試和開發(fā)人員的長期拉鋸中，對(duì)對(duì)方的能力水平心里大概都有了數(shù)。好的開發(fā)修改缺陷時(shí)，關(guān)聯(lián)功能會(huì)直接就改好，提測(cè)的bug修復(fù)版本不會(huì)出現(xiàn)按下葫蘆浮起瓢的情況。而部分能力不足的人員可能考慮的較少，解起bug來顧頭不顧腚。那對(duì)于這種總會(huì)出現(xiàn)2次bug的開發(fā)，測(cè)試人員就要加大測(cè)試力度，如果時(shí)間充裕的話可能要對(duì)整個(gè)模塊進(jìn)行回歸。
字面意思，不管之前查出多少個(gè)問題，提測(cè)后，所有功能，全，都，測(cè)，試。全都測(cè)試的優(yōu)點(diǎn)是對(duì)所有功能進(jìn)行驗(yàn)證，盡最大可能地確保系統(tǒng)沒有問題。缺點(diǎn)也顯而易見，測(cè)試人力、時(shí)間成本大大提高。動(dòng)輒三千多的臺(tái)架測(cè)試用例，一千多的實(shí)車用例，認(rèn)認(rèn)真真干一遍，沒個(gè)兩三周下不來。 而且，長期反復(fù)全量回歸還涉及到測(cè)試心理學(xué)問題：隨著測(cè)試的不斷迭代，測(cè)試的心理會(huì)發(fā)生變化，從“捉蟲式”測(cè)試，逐漸變成了“無罪證明式”測(cè)試。 （1）充分利用冒煙測(cè)試、增量測(cè)試，降低全量回歸測(cè)試次數(shù)；（2）面對(duì)不可避免的多次全量回歸測(cè)試，合理調(diào)度測(cè)試人員的測(cè)試模式，全量回歸測(cè)試和冒煙測(cè)試/增量測(cè)試輪換著進(jìn)行，以免出現(xiàn)測(cè)試心理的變態(tài)，額，變異。
軟件測(cè)試流程
對(duì)軟件的測(cè)試流程做個(gè)基本的梳理吧。
（1）零件的爸爸（FOP）提交功能文件給測(cè)試人員；（2）FOP和測(cè)試人員review功能文件（必要時(shí)引入供應(yīng)商開發(fā)人員），標(biāo)注關(guān)聯(lián)功能，細(xì)化功能實(shí)現(xiàn)邏輯；（3）FOP和測(cè)試人員評(píng)審全量和冒煙用例（3）測(cè)試人員全量測(cè)試后，輸出測(cè)試報(bào)告（用例執(zhí)行結(jié)果+bug清單）；（4）開發(fā)修改bug。修改完后，注明可能影響的關(guān)聯(lián)功能。完成后，冒煙。（5）冒煙通過后，增量回歸測(cè)試。重點(diǎn)測(cè)試修改bug的部分及關(guān)聯(lián)部分。輸出測(cè)試報(bào)告。注： （4）-（5）多輪循環(huán)，直至增量測(cè)試無bug。（6）測(cè)試人員全量測(cè)試，輸出測(cè)試報(bào)告。注： （4）-（5）-（6）多輪循環(huán)，直至無bug，或bug不影響功能發(fā)版。大小bug，沒有什么bug是一杯情真意切的咖啡解決不了的。作者非軟件專業(yè)科班出身，只是結(jié)合專業(yè)人士的科普以及工作中摸索出的經(jīng)驗(yàn)所做總結(jié)，如有偏頗，還望專家指正。
廣告
廣告 
