📢博客主頁：🏀敲代碼的布萊恩特🏀
📢歡迎點贊 👍 收藏 ?留言 📝 歡迎討論！👏
📢本文由 【敲代碼的布萊恩特】 原創，首發于 CSDN🙉🙉🙉
📢由于博主是在學小白一枚，難免會有錯誤，有任何問題歡迎評論區留言指出，感激不盡！?
📖精品專欄（不定時更新）【JavaSE】 【Java數據結構】【LeetCode】

【測試開發】用例篇

• 測試用例的基本要素
• 測試用例的給我們帶來的好處
• 測試用例的設計方法
• • 測試用例的總體設計方法
  • • 基于需求的設計方法
  • 具體的設計方法
  • • 等價類
    • 邊界值
    • 因果圖
    • 場景設計法
    • 錯誤猜測法
• 測試用例的有效性
• 測試用例的粒度和評價
• • 測試用例的粒度
  • 測試用例的評價
  • 面試案例

測試用例的基本要素

測試用例（Test Case）是為了實施測試而向被測試的系統提供的一組集合
這組集合包含：
測試環境、操作步驟、測試數據、預期結果等要素。

評價測試用例的標準：對比好壞代碼的評價標準

• 用例表達清楚，無二義性。。
• 用例可操作性強。
• 用例的輸入與輸出明確。一條用例只有一個預期結果。
• 用例的可維護性好。
• 用例對需求的覆蓋率高，
• 暴露程序Bug的能力強力。

用例的基本要素可以參見如下例子：

測試用例的給我們帶來的好處

• 測試執行者的依據
• 使得工作可重復，自動化測試的基礎
• 評估需求覆蓋率
• 用例的復用
• 積累測試的方法思路以供后續借鑒

使用中帶來困擾
測試用例的設計是費時費力的工作，往往設計測試用例所花費的時間比執行所花費的時間還多

解決如下問題：
不知道是否較全面的測試了所有功能 測試的覆蓋率無法衡量 對新版本的重復測試很難實施 存在大量冗余測試影響測試效率

測試用例的設計方法

測試用例的總體設計方法

基于需求的設計方法

RBT( Requirements-Based Testing)是基于需求的測試方法，會使測試更加有效，因為 它使測試專注于質量問題產生的根源，即需求。

基于需求的測試是一種最根本的軟件測試，重點關注以下兩大關鍵問題。
（1）驗證需求是否正確、完整、無二義性，并且邏輯一致。
（2）要從“黑盒”的角度，設計出充分并且必要的測試集，以保證設計和代碼都能完全符合需求

案例1：
用戶需求:
購買3000塊錢以內的華為智能手機
測試用例：
1.價格<=3000元
2.品牌為華為
3.智能手機
4.手機功能驗證：
4-1.打電話
4-2.接電話
4-3.發短信
4-4.收短信
…
案例2：
軟件需求：
1.1.1.1.5.3 事件流
1.若用戶未收到激活郵件，可在登錄界面錄入電子郵件及密碼后，再次發送激活郵件。
2.每次發送的激活郵件，僅在發送郵件后起24小時之內有效，超過24小時后需重新發送激活郵件。

測試用例：
1-1、未收到郵件，登錄時輸入電子郵件及密碼后，再次發送激活郵件
1-2、已收到郵件，登錄時輸入電子郵件及密碼后，不發送激活郵件
2-1、收到郵件，24小時內進行激活
2-2、收到郵件，24小時后鏈接過期進行激活。
2-3、收到郵件，已激活，24小時后鏈接過期，再次點擊激活？
頁面檢查：
1、收到激活郵件
2、郵件內容正確
3、激活URl正確，可激活
4、再次激活提示已激活
5、過期激活提示已過期

具體的設計方法

等價類

超市買水果
有效等價類：蘋果、桃子、梨
無效等價類：青菜、米、飲料，…

邊界值

因果圖

因果圖是一種簡化了的邏輯圖，能直觀地表明程序輸入條件（原因）和輸出動作（結果）之間的相互關系。因果圖法是借助圖形來設計測試用例的一種系統方法，特別適用于被測試程序具有多種輸入條件、程序的輸出又依賴于輸入條件的各種情況。
因果圖需要掌握的基本知識

• 恒等

• 與

• 或

• 非

因果圖法設計測試用例的步驟如下：
(1)分析所有可能的輸入和可能的輸出。
(2)找出輸入與輸出之間的對應關系。
(3)畫出因果圖。
(4)把因果圖轉換成判定表。
(5)把判定表對應到每一個測試用例。

案例：

步驟如下：

場景設計法

現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。該方法可以比較生動地描繪出事件觸發時的情景，有利于測試設計者設計測試用例，使測試用例更容易理解和執行。

典型的應用是是用業務流把各個孤立的功能點串起來，為測試人員建立整體業務感覺，從而避免陷入功能細節忽視業務流程要點的錯誤傾向

錯誤猜測法

基于經驗和直覺，找出程序中你認為可能出現的錯誤，有針對性地設計測試用例。經驗可能來自于在對某項業務的測試較多，也可以來自于售后用戶的反饋意見，或者從故障管理庫中整理bug。梳理出產品以往哪些地方容易出現問題，問題越多的地方，潛在的bug也就越多。

案例：
以注冊為例

校驗中特殊字符空格的處理?

密碼校驗中的大小寫？

姓名中的特殊字符？

密碼發送是否明文?

測試用例的有效性

測試用例對應的功能已刪除，不可操作了

微信剛出來時與QQ可互發消息，下一個版本后就不可以發消息。

執行一條測試用例未發現BUG，實際該處有BUG

蘋果7手機微信添加了mobile單車小程序，掃碼不能開鎖，只能使用mobile APP開鎖，測試用例未涉及到蘋果7微信小程序掃碼開鎖。

執行一條測試用例發現了BUG

蘋果7手機微信添加了mobile單車小程序，用例已寫到了蘋果7微信添加mobile小程序掃碼開鎖，問題被發現

執行一條測試用例未發現BUG，實際該處BUG已修改

蘋果7手機微信添加了mobile單車小程序掃碼開鎖，可以正常開鎖

測試用例的粒度和評價

測試用例的粒度

粒度：指測試用例編寫的詳細程度。

測試用例可以寫得很簡單，也可以寫得很復雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試中的測試設計，僅會指出需要測試產品的哪些要素、需要達到的質量目標、需要使用的測試方法等。

而最復雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項數據，期待的結果及檢驗的方法， 具體到界面元素的操作步驟，指定測試的方法和工具等。

(1)測試用例寫得過于復雜或詳細，會帶來兩個問題：一個是效率問題，另一個是維護成本問題。另外，測試用例設計得過于詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。

(2)測試用例寫得過于簡單，則可能失去了測試周例的意義。過于簡單的測試用例設計其實并沒有進行“設計”，只是把需要測試的功能模塊記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，并把對軟件系統的測試方法的思路記錄下來，以便指導將來的測試。

大多數測試團隊編寫的測試用例的粒度介于兩者之間。而如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。應該根據項目的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。

主要考慮可以參考如下內容：

• 產品的質量要求
• 項目對用例的要求
• 測試時間和資源是否充分

測試用例的評價

測試用例設計出來了，如何提高測試用例設計的質量？就像軟件產品需要通過各種手段來保證質量一樣，測試用例的質量保證也需要綜合使用各種手段和方法。

評審分為正式和非正式評審。

同行評審
用戶檢查
項目組評審

（1）測試用例的檢查可以有多種方式 但是最敏捷的應當屬臨時的同行評審。同行評審，尤其是臨時的同行評審，應該演變成類似結對編程一樣的方式。從而體現敏捷的“個體和交互比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過討論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設計測試用例。

（2）除了同行評審，還應該盡量引入用戶參與到測試用例的設計中來，讓用戶參與評審，從而體現敏捷的“顧客的協作比合同談判更有價值”這一原則。這里顧客的含義比較廣泛，關鍵在于如何定義測試，如果測試是對產品的批判，則顧客應該指最終用戶或顧客代表（在內部可以是市場人員或領域專家）；如果測試是被定義為對開發提供幫助和支持，那么顧客顯然就是程序員了。

（3）由測試負責人組織協調開展會議，用例編寫人對用例進行講解，參會人員有異議的當場提出。

面試案例

某公司招聘測試工程師時，有一道這樣的筆試題：
”某手機軟件有用TF卡導出數據的功能，請寫出測試此功能點的思路”

考慮方向檢查點測試思路描述

正向	導出數據正確性	導出數據，驗證數據正確性
逆向	導出數據有效性	無數據時，導出功能是否正確
邊界容量	TF卡空間不足	只能容納部分數據
邊界容量	TF卡容量已滿
容錯	TF卡寫保護
容錯	TF卡無法識別
容錯	人為中斷	導出時拔掉TF卡
容錯	導出時斷電、關機等	再開機后檢查能否正確導出
性能	連續多次導出	腳本實現，大量導出，查看數據是否正確
性能	檢查導出速度
兼容性	不同品牌和容量
兼容性	不同分區格式FAT,FAT32，NTFS	不使用手機自帶的T卡格式化功能

總結

以上是生活随笔為你收集整理的【测试开发】用例篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。