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