從事測試工作了一段時(shí)間，對開(kāi)始書(shū)本中的理解和實(shí)際工作的經(jīng)驗寫(xiě)了這篇文章希望能幫助新來(lái)的朋友吧。
測試用例的編寫(xiě)，對于每一個(gè)Tester來(lái)說(shuō)都是不可避免的，平時(shí)很一部分的工作內容就是編寫(xiě)測試用例，如何寫(xiě)一個(gè)好的用例呢？如果你的用例只是用于ISO的審核，那沒(méi)必要再這里探討這個(gè)問(wèn)題。好的Case，是Tester的勞動(dòng)成果，它應該是充滿(mǎn)智慧的，具有可復用性，啟發(fā)性，能充分體現一個(gè)Tester的水平。很多人的Case雖然寫(xiě)的很不錯，可惜只有他自己才能看懂其中的內容和體會(huì )Case的意思，為什么？因為它寫(xiě)的Case描述不清楚，只有他自己看了才明白，一個(gè)好的Case必須有良好的書(shū)寫(xiě)格式與習慣，能讓所有看的人都能理解，也就是說(shuō)，當你離開(kāi)這個(gè)項目，其他人來(lái)接受你的工作時(shí)，只要看你的Case就能明白項目的目標與需求。如果做到這一點(diǎn)呢？
第一步，我想應該是Case格式的確立，擁有好的，清晰的格式，有利于幫助Tester來(lái)組織他的Case，會(huì )讓你事半功倍，反之亦然，一個(gè)結構不合理的格式，會(huì )讓你覺(jué)得蹩手蹩腳，影響你的發(fā)揮。如果選擇一個(gè)良好的結構，要根據具體工作的情況，項目的結構，以及用例的目標（功能測試用例，性能測試用例以及其他）我認為不同的測試手段要使用不同的用例結構。確定好這些因素后，在來(lái)談?wù)劀y試用例中涉及到的一些東西，理解Case所需要的東西，我認為這些東西是比不可少的，1：軟件版本編號。2：測試用例編號，編號的格式可根據軟件版本號+用例號來(lái)確定，這樣不會(huì )應為Case的日積越累或軟件版本的不停升級而混亂。
3：用例的優(yōu)先級，在一個(gè)時(shí)間緊湊的測試環(huán)境下，為了跟效率的完成測試用例，我們所能做的是完成那些優(yōu)先級高的用例，至于優(yōu)先級如何來(lái)確定，可以根據項目需求，或者用戶(hù)那邊的需求來(lái)確定，也可以根據實(shí)際經(jīng)驗對那些很容易產(chǎn)生缺陷的模塊設置為高優(yōu)先級。4：用例步驟。5：輸入數據。 6：實(shí)際輸出數據。
7：期望輸出數據。某個(gè)步驟下，輸入了某條數據，你期望程序會(huì )輸出什么數據?？梢砸粊?lái)可以與實(shí)際輸出的數據相比較。8：備注。為什么要備注，可能你在思考這個(gè)Case的時(shí)候有一個(gè)好的點(diǎn)子或者思路，可以寫(xiě)在備注里面?；蛘邔@個(gè)用例還有一些必要的補充說(shuō)明等。9：測試環(huán)境。10：用例編寫(xiě)人/日期。11：測試執行者/日期?？赡芨鶕煌捻椖窟€需要一些補充，可以根據具體情況具體分析。
第二步。設計測試用例，通常情況下在你編寫(xiě)測試用例之前，你必須要有一個(gè)測試計劃，這里我只討論測試用例。嗯，開(kāi)始設計之前還有一些準備工作，必須熟讀軟件需求說(shuō)明，一定要清晰的了解每一條需求，明白軟件的性能指標，綜合考慮測試環(huán)境，人員配置，要根據自己的實(shí)際能力，測試工具使用狀況寫(xiě)出符合自己測試團隊的用例。用例的劃分有很多種方法，根據測試的類(lèi)型，比如功能性測試，你可以按照功能模塊劃分用例，劃分科學(xué)的模塊你可以組織這些用例直接進(jìn)行集成測試，組合部分模塊或者所有模塊來(lái)測試。性能測試，可以根據性能指標來(lái)確定用例劃分，對于用例環(huán)境的不同來(lái)劃分用例等等。也可以根據測試工具在組織測試用例，比如那些Case可以在測試工具上完成，那些需要手動(dòng)去完成，劃分的方法很多，但是有一點(diǎn)必須保證，就是測試覆蓋率，是否覆蓋了所有的需求。寫(xiě)好一個(gè)用例，需要工作經(jīng)驗的積累，需要對項目需求的了解，我覺(jué)得Tester應該是公司里最了解軟件需求與功能的人。測試的技術(shù)很多，可以在Case中體現出來(lái)，比如說(shuō)邊界值測試，溢出測試，等價(jià)類(lèi)劃分測試法，等等。按照這些來(lái)編寫(xiě)你的Case也可以提高你的技能。
第二步。審核你的Test Case，怎么樣才能完美你的Case呢？最好的辦法就是進(jìn)行同行評審，也就是讓你的同事來(lái)看你的Case，同時(shí)與開(kāi)發(fā)部門(mén)負責人進(jìn)行溝通，討論你的Case。進(jìn)行這兩步后可能要對你的Case進(jìn)行一些修改。但并不是這樣一個(gè)好的Case就產(chǎn)生了，在執行測試用例的過(guò)程中，你可能還會(huì )發(fā)現很多問(wèn)題，這也是一個(gè)Case的完善過(guò)程。對于從一個(gè)項目中成長(cháng)起來(lái)的Tester，會(huì )隨著(zhù)對項目的不停理解與思考而隨時(shí)修改自己的Case，我是這樣理解的。
嗯！以上就是我對Test Case的理解，還有很多東西沒(méi)有寫(xiě)進(jìn)去，其實(shí)要寫(xiě)的東西太多太多，我想盡力過(guò)一段時(shí)間的測試工作后你也會(huì )有我同樣的思考吧，在這里希望能幫助一些在編寫(xiě)測試用例中遇到問(wèn)題的朋友。
