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