|
測試工程師有一樣很重要的工作就編寫測試用例。測試用例是對(duì)需求的另一種描述,它能引導(dǎo)大家進(jìn)一步加深對(duì)系統(tǒng)的理解和對(duì)特性的全面關(guān)注,從而幫助產(chǎn)品和開發(fā)重新審核需求的合理性和一致性,所以應(yīng)該是測試工程師最重要的一項(xiàng)產(chǎn)出。一般的測試用例分為輸入,行為,和希望結(jié)果三個(gè)部分。這三個(gè)部分通常的測試用例都能滿足,但是怎樣的測試用例才能算上優(yōu)秀的測試用例呢?基于以往之測試經(jīng)驗(yàn),我總結(jié)了優(yōu)秀測試用例的幾個(gè)特點(diǎn)。
1:正確性:毫無疑問,測試用例必須是需求的正確描述。但是我們往往忘記了多想一步:這是用戶正確需要的嗎?我曾經(jīng)有個(gè)一個(gè)失敗的testcase,當(dāng)一個(gè)條件輸入異常的時(shí)候系統(tǒng)返回-1給前端接口,然后前端返回錯(cuò)誤信息,這是當(dāng)時(shí)對(duì)異常的處理需求,可是如果多想一步,當(dāng)一個(gè)條件異常的時(shí)候難道我們不能返回滿足部分條件的結(jié)果給用戶嗎?讓用戶的體驗(yàn)更加良好嗎?
2:完整性:就測試用例本身而言,是無窮盡的,只要是鍵盤的任意組合都可以算作測試用例。而一個(gè)優(yōu)秀的測試工程師就是從無窮中找到最能保證質(zhì)量,最能發(fā)現(xiàn)bug的測試用例出來,發(fā)現(xiàn)無窮的最小集,通常功能測試用例的找尋方法有等價(jià)類和邊界值是最簡單的方法,建議結(jié)合使用,先劃分等價(jià)類,再把等價(jià)類中的邊界值找出來。我見過很多在=和>=之間徘徊的bug。正交法出來的用例一般太多,所以需要測試工程師在正交法的結(jié)果中再做組合,建議結(jié)合錯(cuò)誤定位法減少用例的執(zhí)行。狀態(tài)圖在數(shù)據(jù)統(tǒng)計(jì),結(jié)算中的使用概率最高。每個(gè)狀態(tài)和流程都需要一一考慮正常和異常的分支,正常的流程一個(gè)靠譜的開發(fā)能自己保證,但是異常的分支很少有開發(fā)考慮清楚,這就是體現(xiàn)測試工程師價(jià)值的地方了。但是完整性絕不僅僅是功能測試,除了功能測試之外,常見的還有性能測試,安全測試,兼容性測試,安裝友好測試,地域語言測試和用戶體驗(yàn)測試(usability)。
3:輸入具體:對(duì)于這三個(gè)部分我們都希望它是固定的,具體的,比如輸入框的輸入,我們可以寫成具體“諾基亞”,但是不要寫“正確的輸入”,或者“中文的輸入”,這些都會(huì)導(dǎo)致測試用例的不確定性。模糊的輸入應(yīng)該在具體輸入的上一級(jí)結(jié)構(gòu),作為測試的思路和分類使用。
4:用詞無歧義:很多詞在不同場景會(huì)有不同的含義,比如價(jià)格一詞在不同的表中就代表不同的價(jià)格,甚至在同一表中也有原始價(jià)格和賣出價(jià)格,所以應(yīng)該盡量具體的描述關(guān)鍵詞的具體信息,如果能貼上專用的id和原始表中的item會(huì)對(duì)避免歧義有很大的幫助。
5:用例細(xì)化:輸入的一種組合,或者一條流程線對(duì)應(yīng)一個(gè)測試用例,盡量不要在一個(gè)用例中融和多種情況,在自動(dòng)化測試的腳本中為了提高效率我們會(huì)在一個(gè)自動(dòng)化腳本中融入各種情況的輸入,然后一個(gè)動(dòng)作,所有的輸出一次生成,針對(duì)這種情況,建議在腳本中對(duì)各種輸入對(duì)應(yīng)的案例一一備注說明,運(yùn)行失敗的時(shí)候也方便新人定位問題。
6:判斷點(diǎn)準(zhǔn)確無歧義:我經(jīng)常看到這樣的檢查點(diǎn):“結(jié)果正確”,“速度合理”,這些檢查點(diǎn)對(duì)其他人沒有絲毫的幫助。所以應(yīng)該盡量做出讓機(jī)器也能識(shí)別的檢查點(diǎn),比如輸出“8”,或者“rt<30m”。
7:合理區(qū)分優(yōu)先級(jí):在Bugfree中有4個(gè)級(jí)別的優(yōu)先級(jí),從1到4,1表示最重要的測試用例,4表示最不重要的測試用例。不同的缺陷管理平臺(tái)對(duì)優(yōu)先級(jí)的定義會(huì)有不同,但是都會(huì)有優(yōu)先級(jí)的概念。在時(shí)間緊張的情況下,優(yōu)先級(jí)的作用會(huì)特別大,我們會(huì)優(yōu)先執(zhí)行比較重要,對(duì)系統(tǒng)功能,用戶體驗(yàn)影響大的測試用例,將級(jí)別比較低的測試用例留在后期或者指派給一些新人來執(zhí)行。
加分點(diǎn):
1:用例自動(dòng)化:有自動(dòng)化腳本的地址能夠一一對(duì)應(yīng),對(duì)于淘寶的bugfree就已經(jīng)和自動(dòng)化框架mmt打通,通過測試用例可以直接鏈接到腳本,方便對(duì)用例的理解。
2:記錄每輪的測試結(jié)果:對(duì)于有些功能的測試用例,結(jié)果只是簡單的pass我們不需要記錄,但是對(duì)于性能測試這些結(jié)果不確定的測試用例,如果能保留每次測試的結(jié)果對(duì)于之后的測試是很有幫助的。對(duì)于fail的部分用例,如果能和bug產(chǎn)生一一對(duì)應(yīng)關(guān)系對(duì)之后的回歸也產(chǎn)生很大的便利。
3:對(duì)檢查點(diǎn)進(jìn)行邏輯說明:很多用例有了結(jié)果的檢查點(diǎn),但是為什么是這個(gè)結(jié)果,對(duì)于新人來說必須重新翻看需求或者設(shè)計(jì)文檔才能理解。尤其對(duì)于算法的測試,理解需求和邏輯是一個(gè)比較痛苦的過程,如果能夠?qū)γ總€(gè)結(jié)果進(jìn)行一些備注和邏輯上的說明,會(huì)和方便自己今后以及新人對(duì)用例的理解。
以上是對(duì)測試用例特性的一些總結(jié),真正編寫測試用例的時(shí)候,mm圖由上到下的樹形結(jié)構(gòu)會(huì)對(duì)測試用例的結(jié)構(gòu)和思路提供很大的幫助,在測試用例評(píng)審的時(shí)候也方便展示和說明,所以強(qiáng)烈推薦作為附件上傳。而且對(duì)系統(tǒng)越加深入的了解越能寫出完善的測試用例,很多開發(fā)錯(cuò)誤的理解測試工程師只需要知道需求就可以了,不需要對(duì)程序有代碼級(jí)別的了解,但是無數(shù)的實(shí)踐證明測試工程師越了解系統(tǒng)的設(shè)計(jì),編碼的邏輯越能發(fā)現(xiàn)潛在的bug和風(fēng)險(xiǎn)。Unit test通常由開發(fā)完成比較高效,但是Integration Test開始就必須有測試工程師開始真正介入,這期間能發(fā)現(xiàn)很多潛在的問題,如果把風(fēng)險(xiǎn)全部留到System Test的階段風(fēng)險(xiǎn)是很大的,大量case的回歸和問題的定位都會(huì)變得更加復(fù)雜,成本更加的巨大。所以在時(shí)間允許的情況下毫無疑問是前期的測試越完善整體效率越高。
it知識(shí)庫:霜波說測試(一)– 優(yōu)秀的測試用例,轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除,多謝。