最近反復(fù)被測試有用嗎?測試必須測試工程師完成嗎?為什么要做自動化測試?自動化測試的價值是什么?等等一系列的問題不斷地拷問,索性就把這段時間的思考記錄下來了。
軟件測試的必要性
在混沌初開之際,軟件開發(fā)和軟件測試還是一個角色獨(dú)立完成的一個事情,后來伴隨著軟件工程的發(fā)展,開發(fā)和測試逐漸的分開,那么隨著工程化的逐漸深入,研發(fā)運(yùn)營一體化的高速發(fā)展,軟件測試是否還需要單獨(dú)存在這樣的討論時不時的就會出現(xiàn)在各大團(tuán)隊(duì)內(nèi)部的會議上。軟件測試是不是存在其實(shí)蘊(yùn)含著兩方面,一方面是測試工作的獨(dú)立存在,一部分是測試工程師的存在。相信說到這里很多人第一反應(yīng)就是測試工程師必須存在,為什么呢?因?yàn)槌鰡栴}了要有人背鍋。其實(shí)并不盡然,我們先從測試工作存在的必要性開始聊起,測試工程師存在的必然性也就順理成章了。
美國質(zhì)量管理大師克勞士比(Philip Crosby)提出質(zhì)量成本(Cost of quality-COQ)是指為了防止出現(xiàn)錯誤以及產(chǎn)生錯誤而引起的一切費(fèi)用。假定你要提供一種優(yōu)質(zhì)的產(chǎn)品或服務(wù)給你的顧客,質(zhì)量成本是指你因?yàn)椴荒艿谝淮伪阕龊?Doing the right thing the first time)而產(chǎn)生的所有有關(guān)成本。質(zhì)量成本通常包括三方面: 預(yù)防成本(Prevention cost)、鑒定成本(Appraisal cost)及失效成本(Failure cost),而失效成本又可分為內(nèi)部的成本(Internal cost)和外部的成本(External cost)三者加起來就是所謂質(zhì)量成本(Cost of qualit)。
我們引用質(zhì)量成本的概念,在軟件開發(fā)過程中如果沒有測試實(shí)踐,那么軟件的缺陷就會導(dǎo)致類似傳統(tǒng)工業(yè)一樣問題,顧客會反饋“問題“,團(tuán)隊(duì)要付出努力找到問題,并修復(fù)問題,在這個過程中開發(fā)團(tuán)隊(duì)付出了鑒定成本,企業(yè)也因?yàn)橛绊懥丝蛻舻氖褂枚枰冻龈嗟某杀局匦芦@得客戶信任。測試工作就在系統(tǒng)交付給客戶之前用科學(xué)的方法設(shè)計測試用例并進(jìn)行邏輯驗(yàn)證,將問題提早暴露、提早解決的方法,讓問題不會暴露在最終用戶面前,因此賺取了額外付出挽回用戶信任的成本,同時在產(chǎn)品沒有直接交付到客戶側(cè)前就進(jìn)行了修復(fù),也大大降低了鑒定成本和修復(fù)成本。
講清楚測試的價值其實(shí)可以從測試過程發(fā)現(xiàn)的缺陷將其,相比大家都有為缺陷分類分級的經(jīng)驗(yàn),那么我們一般都會按照缺陷的嚴(yán)重程度來劃分缺陷,大部分會是致命缺陷、嚴(yán)重缺陷、一般缺陷、建議缺陷,那么這些實(shí)際代表的是如果這個缺陷交付到了客戶面前我們付出的質(zhì)量成本的高低,越嚴(yán)重的缺陷付出的質(zhì)量成本就越高,就越應(yīng)該在交付過程中解決掉,將其用內(nèi)部成本的代價付出代替外部成本損失。
測試工程師存在的必然性
軟件測試這個過程的實(shí)施主體就是測試工程師。那么多少個測試工程師比較合適呢,或者換句話說如上的事情必須要測試工程師完成嗎?開發(fā)工程師不能完成如上的工作嗎?(這里就不包含技術(shù)成熟度非常優(yōu)秀的團(tuán)隊(duì),我們還是說絕大部分團(tuán)隊(duì)的現(xiàn)狀)。這里其實(shí)要強(qiáng)調(diào)開發(fā)工程師不能做全部的測試工作,”自我檢查類“的單元測試還是需要自己完成的。我覺得”自己不能測試自己的代碼“是每一個軟件從業(yè)者都聽說過的至理名言了,那么為什么不能自己測試自己的代碼呢?這是有關(guān)于一個人類心理學(xué)的一個“自我偏見”和“選擇性注意力”的問題。當(dāng)我們欣賞自己的作品時,我們會注意到它們的優(yōu)點(diǎn),而忽略它們的缺點(diǎn)。這是因?yàn)槲覀円呀?jīng)知道了我們的作品的背景和意圖,因此我們會更容易地看到它們的優(yōu)點(diǎn)。這種現(xiàn)象被稱為“選擇性注意力”。選擇性注意力是人類注意特征之一。個人不可能同時注意所有呈現(xiàn)的刺激,總是有選擇地注意某一刺激而忽視同時呈現(xiàn)的其他多種刺激。例如,課堂上的學(xué)生不可能、也不應(yīng)該對作用于他們視覺和聽覺的刺激都作出反應(yīng),正常情況下只是集中注意教師的講授或演示。選擇性注意所指向的對象是受個體原有認(rèn)知結(jié)構(gòu)影響的,因此注意過程是一個主動的過程。同時,我們的作品通常是基于我們自己的想法和創(chuàng)意,因此,我們會對它們產(chǎn)生情感上的依戀。這種依戀可能會導(dǎo)致我們對自己的作品產(chǎn)生偏見,使我們認(rèn)為它們比它們實(shí)際上更好。這種現(xiàn)象被稱為“自我偏見”。
如果開發(fā)工程師不適合做全部的軟件測試,那么最終用戶相比就更不適合了,否則就會引起前面所說的質(zhì)量成本。測試工程師作為發(fā)現(xiàn)問題,避免付出質(zhì)量成本的主要角色還是有他存在的必要的。站在整體的視角,通過最終用戶的視角完成測試驗(yàn)證,也會避免如上的“自我偏見”和“選擇性注意力”,說白了就是測試工程師可以避免開發(fā)工程師的“燈下黑”。
服務(wù)于質(zhì)量需求的軟件測試
軟件測試和質(zhì)量的關(guān)系其實(shí)就如同軟件開發(fā)和業(yè)務(wù)需求的關(guān)系一樣,開發(fā)工程師通過編碼交付業(yè)務(wù)需求,測試工程師通過測試交付質(zhì)量需求。
這里的質(zhì)量需求有些可能是客戶顯示的提出來的,有些是隱藏在交付軟件的質(zhì)量特性里而需要被交付的。無論是哪一種,質(zhì)量需求最終都應(yīng)該可以追溯到客戶的需求中的。所以系統(tǒng)的質(zhì)量需求也是不完全一致的,有些系統(tǒng)被應(yīng)用在財務(wù)、款項(xiàng)相關(guān)的業(yè)務(wù)中,那么數(shù)據(jù)的準(zhǔn)確性的要求就非常重要,1分錢的錯誤都有可能出現(xiàn)謬之千里的問題;有些系統(tǒng)被應(yīng)用在不同的移動設(shè)備中,需要用戶自主學(xué)習(xí),那么兼容性和易學(xué)習(xí)性就應(yīng)該更加的關(guān)注。除去最終服務(wù)的行業(yè)、用戶以及行業(yè)相關(guān)監(jiān)管要求決定了質(zhì)量需求之外,系統(tǒng)的成熟度應(yīng)該也是影響質(zhì)量需求的一個關(guān)鍵因素,初創(chuàng)期的系統(tǒng)、快速開發(fā)交付的系統(tǒng),穩(wěn)定交付的系統(tǒng)和被替換的系統(tǒng),每一個階段的系統(tǒng)對于質(zhì)量的需求應(yīng)該都是不一樣的,所以也應(yīng)該有不一樣的測試實(shí)施方案。
站在質(zhì)量需求的輸入角度,可以分成“無”質(zhì)量需求、不清晰的質(zhì)量需求、關(guān)鍵要素的質(zhì)量需求以及全面的質(zhì)量需求,其實(shí)這么分無非就是為了說清楚什么樣的系統(tǒng)應(yīng)該怎么投入測試,叫什么名字只是一個代號。
“無”質(zhì)量需求往往是在項(xiàng)目的被替換期,項(xiàng)目逐漸的退出歷史舞臺,處于被其他業(yè)務(wù)替換或者不再使用,從而有很少的變更甚至沒有變更,大部分是系統(tǒng)的可用性維護(hù)上,這個階段不會有任何明確的質(zhì)量需求被驗(yàn)證,往往維護(hù)可用性就已經(jīng)足夠了,這種項(xiàng)目不需要測試實(shí)踐保證質(zhì)量,測試工程師只是在需要的時候使用原有的測試用例(如果有自動化用例就充分利用自動化用例)完成測試實(shí)踐,同時參與的測試工程師要負(fù)責(zé)再次發(fā)揮價值的測試用例是有效的和和當(dāng)前系統(tǒng)是一致的。
不清晰的質(zhì)量需求是在項(xiàng)目的初創(chuàng)期出現(xiàn)的,其中初創(chuàng)期主要是驗(yàn)證想法、最小化驗(yàn)證交付可行性,這里主要只站在商業(yè)價值角度的實(shí)驗(yàn),通過快速交付、快速驗(yàn)證能夠?qū)I(yè)務(wù)的想法最小之間周期進(jìn)行驗(yàn)證,那么這個時候,往往沒有明確的質(zhì)量需求,潛在的一些質(zhì)量需求在項(xiàng)目交付過程中也不會特別明顯的被提及,測試工程師應(yīng)該在團(tuán)隊(duì)中保證功能交付的正確性,這個時期的質(zhì)量需求重點(diǎn)就是功能性,那么測試工程師主要以手工測試為主,選擇一種測試用例管理辦法,記錄測試用例資產(chǎn),就足以滿足當(dāng)前的質(zhì)量保證要求了。
關(guān)鍵要素的質(zhì)量需求是指系統(tǒng)在快速的交付期,需求大量積壓,系統(tǒng)交付的過程中并沒有明確的質(zhì)量需求需要測試過程交付,保證需求的正確性是唯一一個被所有人注重的測試內(nèi)容,兼顧行業(yè)監(jiān)管要求。這個時候測試實(shí)踐也并不推薦使用大量的自動化測試,使用手工測試完成最終的驗(yàn)收階段的功能驗(yàn)證是這個時期最為重要的內(nèi)容,少量非功能由于手工實(shí)現(xiàn)的成本非常高,通過一些工具或者自動化技術(shù)完成。
全面的質(zhì)量需求是指系統(tǒng)已經(jīng)進(jìn)入了穩(wěn)定的交付周期,有固定的交付周期,需求無明顯積壓,團(tuán)隊(duì)保持相對穩(wěn)定的需求吞吐量,每個需求都有明確的質(zhì)量需求,質(zhì)量需求既有產(chǎn)品經(jīng)理分析的,也有最終用戶實(shí)際提出的,還有依據(jù)測試工程師的經(jīng)驗(yàn)在需求質(zhì)量保證過程中提出來的。測試工程師在這個階段應(yīng)該維護(hù)大量的自動化測試用例,少量的新業(yè)務(wù)有一些手工測試,大量的自動化測試用例全面保證了系統(tǒng)的質(zhì)量,保證了系統(tǒng)功能的正確性,非功能測試也進(jìn)行了全面的實(shí)際,測試工程師也有時間,有條件嘗試測試左移、右移的實(shí)踐。
如上僅僅是通過系統(tǒng)成熟度角度分析了什么情況怎么投入測試,這肯定不是唯一的分析問題的角度,其實(shí)這僅僅是一種思路,如果團(tuán)隊(duì)技術(shù)成熟度非常優(yōu)秀,那么測試工程師有可能就不存在,測試活動(這里還是需要一個科學(xué)的驅(qū)動開發(fā)方式,例如TDD)全靠開發(fā)角色一個人承擔(dān),那么上面的一大堆的內(nèi)容就沒什么必要了。
審核編輯:黃飛
-
自動化測試
+關(guān)注
關(guān)注
0文章
215瀏覽量
26967 -
軟件測試
+關(guān)注
關(guān)注
2文章
231瀏覽量
18664 -
測試工程師
+關(guān)注
關(guān)注
6文章
124瀏覽量
12489
原文標(biāo)題:軟件測試是質(zhì)量需求的交付實(shí)踐
文章出處:【微信號:TestinChina,微信公眾號:Testin云測】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
通用自動化測試軟件 - TAE
![通用<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>軟件 - TAE](https://file1.elecfans.com/web3/M00/04/8A/wKgZPGd2JdSAOEfOAACF3V0L3w4860.png)
串口屏自動化測試
桌面式車載網(wǎng)絡(luò)自動化測試系統(tǒng)TESTBASE-DESKNAT
![桌面式車載網(wǎng)絡(luò)<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>系統(tǒng)TESTBASE-DESKNAT](https://file1.elecfans.com/web3/M00/03/DC/wKgZO2dswMaAUDjwAADIUgbf0AY696.png)
探索Playwright:前端自動化測試的新紀(jì)元
開關(guān)電源自動化測試設(shè)備:如何實(shí)現(xiàn)自動化測試?
![開關(guān)電源<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>設(shè)備:如何實(shí)現(xiàn)<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>?](https://file1.elecfans.com/web2/M00/B7/6D/wKgaomWD-wWAI5dgAAR4rXQbF-s975.png)
XLT高速線纜自動化測試系統(tǒng)
ATECLOUD智能云測試平臺推動自動化測試發(fā)展
![ATECLOUD智能云<b class='flag-5'>測試</b>平臺推動<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>發(fā)展](https://file1.elecfans.com/web2/M00/AC/AE/wKgaomVImSuAAo-BAAI31urqQow703.png)
電源管理芯片輸出端的紋波自動化測試方法
![電源管理芯片輸出端的紋波<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>方法](https://file1.elecfans.com/web2/M00/FD/07/wKgZomaXhw2AQEFRAAInQpNhH_E155.png)
OTA自動化測試解決方案——實(shí)車級OTA測試系統(tǒng)PAVELINK.OTABOX
![OTA<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>解決方案——實(shí)車級OTA<b class='flag-5'>測試</b>系統(tǒng)PAVELINK.OTABOX](https://file.elecfans.com/web2/M00/52/D4/pYYBAGLNkrKAeFJaAAAjXRuImx0496.png)
戶外便攜儲能電源自動化測試系統(tǒng)高效完成電源測試
![戶外便攜儲能電源<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>系統(tǒng)高效完成電源<b class='flag-5'>測試</b>](https://file1.elecfans.com/web2/M00/FA/AE/wKgaomaLpUiAWax2AAECoJNm618225.png)
臺式機(jī)電源測試軟件:自動化檢測電源性能好壞
![臺式機(jī)電源<b class='flag-5'>測試</b>軟件:<b class='flag-5'>自動化</b>檢測電源性能好壞](https://file1.elecfans.com/web2/M00/C6/36/wKgaomX7-qiAYVttAADm6-0nUDY580.png)
基于TAE的數(shù)字鑰匙自動化測試解決方案
![基于TAE的數(shù)字鑰匙<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>解決方案](https://file1.elecfans.com/web2/M00/EA/1D/wKgZomZW1f2ABHFhAABt68Ive9w287.png)
納米軟件自動化測試合作:4644芯片與VPX模塊測試
![納米軟件<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>合作:4644芯片與VPX模塊<b class='flag-5'>測試</b>](https://file1.elecfans.com/web2/M00/AE/55/wKgaomVUaamAe191AAPCExpvtNc326.png)
ATECLOUD自動化測試系統(tǒng)區(qū)別于傳統(tǒng)自動化測試系統(tǒng)
![ATECLOUD<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>系統(tǒng)區(qū)別于傳統(tǒng)<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>系統(tǒng)](https://file1.elecfans.com/web2/M00/DF/46/wKgaomYvbrSAFPLDAAG171hve_c510.png)
納米軟件分享:電源管理芯片自動化測試方案
![納米軟件分享:電源管理芯片<b class='flag-5'>自動化</b><b class='flag-5'>測試</b>方案](https://file1.elecfans.com/web2/M00/D6/45/wKgZomYnSq-AALhNAAPZXCFt_TI390.png)
評論