測試用例的設計方法-理論篇
對于QA來說，測試用例就是我們的源碼庫。測試用例的重要性自然也是不言而喻的，相信每一個QA都曾在“寫不完”的測試用例文檔里掙扎過，也可能至今還有著——到底什么樣的測試用例才是是好的測試用例——這樣的疑問。
今天想從實用的角度總結一下測試用例的設計方法，本文是理論篇，內容包括什么是測試用例，為什么需要測試用例，以及常用的測試用例設計方法；后續還會有實用篇向大家分享，我在平常的工作中是怎么寫測試用例的。
1. 什么是測試用例
軟件測試員做些什么: 發現軟件缺陷 (而不是簡單得驗證功能是否實現) ; 盡可能早地找出軟件缺陷; 并確保其得以修復。 ——Ron Patton 《軟件測試》
測試用例（Test Case），就是為了驗證某個需求是否實現、是否存在缺陷，在測試執行之前設計的一套詳細的測試方案。測試用例通常由測試標題、前置條件、測試數據、測試步驟、預期結果等組成。
敏捷開發團隊中，測試用例的設計和執行通常都是一個人，這時，對測試用例文檔通常沒有嚴格的格式要求，清晰準確即可！
2. 為什么我們需要測試用例
- 如果我們不使用測試用例，難道就沒辦法檢查出缺陷嗎？
- 可以不編寫測試用例直接進行測試，但這樣是有風險的，不能夠保證全面覆蓋。除此之外，測試用例還可以：
·?體現QA了解需求的過程
敏捷開發團隊中，QA通常是從IPM階段開始接觸到新的需求，此時用戶故事的需求描述、Acceptance Criteria、原型圖等都已基本完成。QA在編寫用例的過程中，將仔細梳理整體業務流程、充分思考產品需求的細節，找出需求是否存在不合理、有矛盾、不明確等問題，從而推動BA/UX完成更加詳細的設計。
· 幫助QA理清測試思路及測試過程
測試用例的編寫，實際上是把需求轉換為一種可操作步驟的行為。QA也沒有那么強大的大腦能夠把所有的操作步驟都記在腦海里，寫下來不僅能幫我們記住，寫下來的這個過程也是梳理測試思路的過程。特別是，當你將當前需求的用例都羅列出來時，也能很清晰規劃之后的測試順序。
· 規劃測試數據的準備
我們可以看到，在測試實踐中，測試數據是與測試步驟分離的。在測試執行前，按照測試用例準備一組或若干組測試數據，特別是一些需要其他人協助準備的測試數據，這十分有助于高效的測試執行工作。
·?記錄測試所覆蓋的測試內容，同時反應測試進度
依照測試用例執行測試，并及時記錄每一個測試用例的測試結果，這樣項目成員都能夠清楚地了解到目前已經完成了哪些測試，這些測試覆蓋了哪些需求。那么在一些突發情況下，比如你被調離或離職，別人也能迅速了解測試覆蓋內容及測試進度。
· 為后續的測試提供可參考的依據
新加入的功能可能會影響已有功能，新的需求是對原來的功能進行優化，新版本要上線等，項目進行過程中有這很多情況，都需要QA進行回歸測試，有了測試用例，回歸測試就能按部就班進行。
· 是分析缺陷的標準
測試用例并不是一寫完就再也不用更新了。通過記錄的缺陷數據，與測試用例進行對比，分析是否存在漏測情況，即當前測試用例是否能夠覆蓋該缺陷，若未能覆蓋，說明當前測試用例集不完善，應補充相應測試用例；若已有相應測試用例，則表明測試執行過程中存在問題。
簡單來講，測試用例能夠幫助我們在測試執行前澄清需求、梳理測試過程，并提前規劃好測試數據；在測試執行中作為清單使用，記錄測試覆蓋的內容、反應測試進度；測試執行后也能作為回歸測試等的參考，能與缺陷記錄結合分析，來不斷完善測試用例本身。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
