關於測試用例設計的一點感想
by:授客qq：1033553122
直接上例子，如下，要測的是乙個卡券驗證功能：
描述：開啟***掃瞄卡券，可對卡券進行驗證。支援的卡券分三種，會員主卡，折扣券，代金券，點選手動輸入按鈕
(不知為何，拍照時顯示成那熊樣了
)，彈出如下介面
描述：輸入編號，點選「優惠券」，「會員卡」圖示，可對輸入的卡券
(會員主卡，代金券，折扣券
)編號驗證，另外，如果輸入是手機號，則對手機號關聯會員的會員主卡進行驗證
如果不考慮逆向用例，考慮正向用例，你會咋樣設計用例？是否如下：
掃碼驗證會員主卡
掃碼驗證折扣券
掃碼驗證代金券
手動輸入會員主卡編號，優惠券驗證
手動輸入會員主卡編號，
vip驗證
手動輸入手機號，
vip驗證
……這樣設計用例帶來的結果是啥呢？用例數比較多，進而花費的測試時間也跟著變長，如果再加上一些條件
(本例子中還有個條件：是否攜帶「不可優惠金額」，驗證結果會受到其影響
)，那就更多了，咋辦呢？
實踐中，我是這麼做的，先不著急寫用例，寫操作，操作時用
fiddler
等工具，抓取傳送的請求介面，進行觀察，結果發現：
1、相同前提下，掃碼或者是手動輸入編號，呼叫的都是同一介面，掃碼主要是讀取卡券編號
2、相同前提下，手動輸入卡券編號驗證，點選
「優惠券」，「會員卡」圖示，呼叫的也是同乙個介面
呼叫介面
接下來就簡單多了，對「掃碼」進行詳細的用例設計，然後針對手動輸入編號，分是否輸入手機號，如果是手機號，介面實現中必須根據傳入的手機號查詢對應會員的會員主卡，並進行校驗；如果是非手機號，確保正確呼叫了介面即可。
綜上，我們在測試用例不能僅停留在用例設計原理上，很多時候還應該從實現角度來進行設計分析，減少不必要的時間投入，特別是邏輯複雜的情況，通常我們可以做如下事情：
1、分析呼叫的介面請求
檢視不同(相似
)入口，發起的請求呼叫是否一樣
2、分析**實現
常檢視**邏輯，檢視影響用例設計的因素之間的制約關係，舉例如下
if條件1==
真:do something
else if條件2
==真:do something
if條件1==
真:do something
if條件2==
真:do something
如上，不同的**實現，影響用例設計的條件
1和條件
2之間的關係是不一樣的，對應的，用例設計也就不一樣了。
3、檢視呼叫的實現相關的
sql語句
有時候，我們也可以通過日誌獲取開發**呼叫的
sql語句，作為用例設計中結果校驗的手段。通過
sql語句來分析介面資料是怎麼展示出來的，資料取值是否正確。
測試面試 設計測試用例
第一篇，先說一下測試用例。首先呢，關於測試用例呢，我認為是比較重要的。但是在實際的工作過程中，這個東西往往是受到多方面的影響的 公司規模小，測試用例沒有乙個清晰或者完整的規範。用例寫的再好，也沒有任何的表揚和實質性的獎勵 用例寫的再含糊，領導說行那就行，那誰還會用心寫？公司有完整的用例規範和要求，但...
測試思想 測試設計 測試用例設計需要注意的幾個點
測試用例設計需要注意的幾個點 摘取 摘錄by 授客qq 1033553122宣告 非原創，摘取自網路，取其精華測試用例需要注意以下幾點 1 單個用例覆蓋最小化原則下面舉個例子來介紹，假如要測試乙個功能 a，它有三個子功能點a1，a2 和 a3，可以有下面兩種方法來設計測試用例 方法 1 用乙個測試用...
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...