于測試用例設計的一點感想(優先級與拆分合并設計)
by:授客 QQ：1033553122
歡迎加入軟體性能測試交流QQ群：7156436
廢話不多說，直奔主題吧
1、用例優先級
大家都知道，用例有優先級之分，但是實際執行過程中如果沒有養成良好的思維習慣，又容易把這個給忽略，那麼問題來了，怎麼破？
解析：以“使用者”為主，兼顧程式“依賴”
即以使用者為中心，從使用者的角度考慮，同時遵循序功能(子產品)彼此之間的“依賴”關系展開對用例的設計。
以下為例進行說明。
如上，這是個支付資料進件的需求原型圖，站在使用者的角度考慮，這個頁面的核心功能就是“稽核資料”，其它的功能，比如，查詢，清單标題旁的下拉篩選，清單排序等都是為了更好的服務這個功能而設定的，是以結論是：“稽核”功能--清單的“操作”的用例設計優先于查詢，下拉篩選，清單排序等功能的用例設計。
再從使用者的角度出發，如果想使用者送出的支付資料被“稽核”通過，那麼必須對這些資料進行查閱，包括清單記錄項(商戶全稱，商戶簡稱，資料商戶全稱，第一次送出時間，送出來源，資料類型等)和上傳附件(可通過“下載下傳”檢視)，是以，結論是：需要先對記錄資料準确性校驗，先對“下載下傳“功能進行用例設計。
問題：這裡為何不以“程式依賴”為主呢？按我的了解，打開支付資料稽核頁面時，預設的也會進行查詢，要進行稽核就必須先把記錄查詢出來，如果以“程式依賴”為主，那這裡就應該先對查詢進行用例設計。但是我沒有，因為通常情況下，如果存在清單記錄，那麼打開類似這種頁面應該能自動顯示資料的，也就說打開頁面(測試的必經之路)已預設解決了這種“依賴”關系，即稽核需要查詢出資料
2、用例設計拆分
如下圖，這是很常見的一種設計，見圖1（這裡的“終端”可以是某個app，可以是某個web背景、web頁面等）
(圖1) （圖2）
拆分思路：見圖2，以資料庫為中心，“一刀兩段”，分成兩部分：終端送出資料到資料庫，這裡關注資料能否送出成功，資料庫存儲是否正确；web背景從資料庫讀取資料并展示，這裡關注展示是否正确。
按這種思路來，那麼設計送出(新增、修改)資料功能用例時，用例的校驗重點是看資料庫存儲是否正确，如果對該功能對應的資料庫、資料庫表比較熟的話，可以通過直接檢視資料庫校驗(推薦)，如果沒權限或者對資料庫、資料庫表不熟的話，也可通過本終端相關web頁面（比如記錄詳情頁面，修改資料頁面等，如果有的話）檢視“可見部分”的資料資料是否正确
設計web背景展示資料功能用例時，用例的校驗重點是看讀取是否正确。這種情況下，可通過直接修改資料庫相關字段的值後，檢視web背景展示變化，當然這也建立在對資料庫、資料表對應關系比較熟悉的情況下，如果不熟悉、對資料庫表等沒操作權限的情況下咋辦？可借助“終端操作”,即通過終端送出(新增、修改)資料來修改資料庫對應記錄的值，這裡不需要對終端是怎麼新增，怎麼修改的等細節展開細緻描述，因為這塊在寫送出資料的時候已經寫了，僅簡單的把其當作用例中的一個操作步驟來寫，一句話概況。
注：驗證展示時需厘清
哪些資料會動态改變，且由終端改變的（比如稽核拒絕後再次送出稽核，會改變稽核狀态，在驗證資料展示時，需要針對這部分，構造對應的資料，否則容易漏測）；
哪些是由web背景自己的操作改變的（比如稽核操作，這部分的資料變化比如稽核狀态，可以放在稽核操作的用例步驟預期結果裡進行校驗）。
注意：因為程式可能使用類似redis，mongodb等緩存功能，是以直接修改資料庫可能并不會導緻web背景等資料發生變化，因為它可能是從緩存讀取的資料，是以如果是在對程式實作不了解的情況下，靠譜起見，還是建議通過借助“終端操作”的方式來實作對資料庫的更改（有些程式實作會在執行終端操作時調用重新整理緩存指令，使得緩存的資料更新為資料庫中最新的值）。
再舉個 “支付收款”的例子。
我公司做智能pos這塊的，涉及支付寶收款，微信收款等，通常這些功能都會涉及到一些關鍵的配置，要正常收款，必須做正确的參數配置，是以從依賴角度看，設計用例時分兩大塊，一塊是測試配置，看配置儲存能否成功，資料庫存儲是否正确，另一大塊呢，檢視正确、錯誤配置下的功能是否正常、是否做了容錯處理，檢視讀取配置是否正确（通過動态執行程式操作，比如執行支付寶收款，執行不同場景的微信收款）
3、用例設計合并
用例合并，沒看錯吧？對，沒看錯，就是用例合并。之前提過，一條用例一個點--就驗證一個點，出發點是沒錯的，但是考慮到實際執行效率，我們要做一些取舍，把部分用例合并到一起。
eg:
如上圖，左圖是收款成功界面，暫且我們稱之為“收款成功頁”，右圖是收款成功後列印的發票，暫且稱之為“發票”。關于這兩個界面，分别提了一些業務規則，如下：
1）收款成功頁：
“不可優惠金額”，“卡券優惠”，“商家活動”，“抹零”，“平台優惠金額”，“交易備注”，這幾項如果有則顯示，否則不顯示,其中抹零金額為0則視為無抹零
“卡券優惠”：如果是會員折扣則顯示“會員x折-￥金額”；如果是代金券，且隻核銷一張，則顯示“代金券名稱-￥金額”，如是多張則顯示“代金券名稱*數量-￥金額”；如果是折扣券則顯示為“折扣券名稱-￥金額”
2）發票：
“不可優惠金額”，“不可優惠金額”，卡券優惠（“會員xx折”\“折扣券名稱”\“代金券名稱”\“金券名稱*xx張”），“商家活動”，“抹零”，“平台優惠金額”，這幾項如果有則顯示，否則不顯示,其中抹零金額為0則視為無抹零
如是門店帳号登入收款，則“交易流水憑證”下方的擡頭顯示“門店名稱”，如果是商戶帳号收款則顯示為“商戶簡稱”。
3）自動列印：如果背景配置了自動列印且列印發票數不為0，收款成功後自動答應發票
4）列印按鈕：點選列印後，再次列印發票，基本同自動列印的發票，但是需要在此基礎上增加“重印”二字
按正常思維，有的人就可能會這麼設計用例:
Ø 1、按照需求，複制黏貼，資料和邏輯分離，比如，[限制限制]列印發票-“不可優惠金額”有則顯示，無則不顯示
Ø 2、按照需求，一條用例一個驗證點，比如
[限制限制]列印發票-沒有“不可優惠金額”；
[限制限制]列印發票-有“不可優惠金額”；
[限制限制]支付寶收款-無不可優惠金額
問題：這樣設計有啥不好？
解析：以上用例為例
用例1，看起來似乎很有邏輯性，但是從等價類的角度來看，這裡有兩種輸入，分别對應這兩種輸出，每種輸出走了一條邏輯分支，我們提倡“邏輯”和“資料”分離，但個人認為這裡的“邏輯”确切的說應該是邏輯分支，即一條邏輯分支對應n條測試資料，對應到自動化時也是這樣，友善處理。是以推薦按用例2的方式編寫。
用例2，看起來也沒問題，根據等價類劃分，可用1條測試資料、1次操作進行覆寫n條正向用例，問題出在執行，這樣設計用例，如果動手測試前沒規劃好，可能會造成這種結果：
收款時，針對“收款結果頁”部分字段有則不顯示，無則顯示的規則把那些字段顯示規則都校驗一次，然後測試完成，再對發票部分字段有則不顯示，無則顯示的規則把那些字段顯示規則再校驗一次，這樣會造成重複的投入，如下：
執行支付寶收款 ->
測試收款“結果頁”字段資訊
測試列印發票字段資訊
另外，這裡的列印按鈕，列印的發票也要遵守這個規則，這樣不得不再次做同樣的操作（雖然按經驗，這裡的列印和自動列印調用的應該是同一個接口，但是我們沒法保證它真的是那樣，因為程式不是我們寫的）
那咋整？
按我的了解，這裡，支付寶收款，自動列印發票，列印在業務角度看，都是緊密關聯的（用例劃分要适當，需要考慮執行），執行效率起見，我們可以把用例合并起來，确切的說是串聯起來：
支付寶收款->>驗證收款結果頁面->>驗證自動列印的發票資訊->>驗證重印的發票資訊
值得注意的是，這裡需要對實際業務邏輯比較深入的了解，結合業務邏輯進行用例的設計（這點很重要，要知道資料怎麼走，資料傳遞時在哪裡會發生變化，否則很容易因覆寫不全導緻出問題）。
如上圖，我們可以看到，如果把判斷是否抹零前的計算結果，即應付金額，作為中間結果，那麼“是否有可不可優惠金額”和“使用優惠”則是影響應付金額的兩個因素，這裡考慮使用強一般等價類劃分：
是否有可不可優惠金額（有不可優惠金額，無不可優惠金額）
使用優惠（使用會員折扣，使用折扣券，使用代金券，不使用優惠）
得到如下用例：
【功能校驗】支付寶收款-有不可優惠金額，不使用優惠
【功能校驗】支付寶收款-無不可優惠金額，不使用優惠
【功能校驗】使用優惠-有不可優惠金額，折扣券，支付寶收款
【功能校驗】使用優惠-有不可優惠金額，多張代金券，支付寶收款
【功能校驗】使用優惠-有不可優惠金額，單張代金券，支付寶收款
【功能校驗】使用優惠-有不可優惠金額，會員折扣，支付寶收款
【功能校驗】使用優惠-無不可優惠金額，折扣券，支付寶收款
【功能校驗】使用優惠-無不可優惠金額，多張代金券，支付寶收款
【功能校驗】使用優惠-無不可優惠金額，單張代金券，支付寶收款
【功能校驗】使用優惠-無不可優惠金額，會員折扣，支付寶收款
搞定這個，接下來的就比較簡單了，基本的等價類，
如下:
【功能校驗】支付寶收款-不抹零
【功能校驗】支付寶收款-有抹零(抹零金額為0)
【功能校驗】支付寶收款-有抹零(抹零金額不為0)
【功能校驗】支付寶收款-無平台優惠金額
【功能校驗】支付寶收款-有平台優惠金額
【功能校驗】支付寶收款-有商家活動
【功能校驗】支付寶收款-無商家活動
同時，收款結果頁，發票的字段有則顯示，無則不顯示的規則，在上面的用例中未覆寫到的，需要再針對性的設計用例，如下：
【功能校驗】支付寶收款-無訂單備注
【功能校驗】支付寶收款-有訂單備注
-----------------------支付抹零用例---------------------------------
【功能校驗】支付抹零-四舍五入到角
【功能校驗】支付抹零-往下抹零到角
【功能校驗】支付抹零-四舍五入到元
【功能校驗】支付抹零-往下抹零到元
注：我們的抹零有4中，如上，測試抹零用例時，實際需要再覆寫以上四種情景的用例
附用例步驟：【功能校驗】使用優惠-有不可優惠金額，多張代金券，支付寶收款
注：
1、有人會問，這裡為何不進行類似如下的組合：
【功能校驗】使用優惠-無不可優惠金額，無商家活動，無平台優惠，無備注，無抹零，掃碼驗證，會員折扣，支付寶收款
【功能校驗】使用優惠-有不可優惠金額，無商家活動，有平台優惠，有備注，有抹零，掃碼驗證，會員折扣，支付寶收款
理由：組合不是不可以，但是這樣組合起來後，一眼看去就有點分不清這些“影響因素”之間的關系了，互相制約還是互不影響，這個真不清楚，而且分不清這條用例的測試重點在哪裡，整個邏輯顯得很亂，影響因素比較少的情況下，可以考慮這樣組合下。
2、根據上面說的，你用例預期裡也有，類似“如果xxx則xxxx，否則。。。。”這樣的描述，這不自相沖突呢？
理由：是有，但是這裡有針對性的，這部分不是用例的核心校驗點，但是也可能是用例結果的組成部分，不能丢棄
3、有人又會問，金額啥的還不是重點呀？
解答：是重點，根據測試用例等價類設計思想，我們驗證用例時，我們可以稍微組合下，一次收款操作，可以覆寫n條正向用例，這樣在驗證用例時，可能會把備注2中非重點部分也當作重點部分進行校驗（某條用例中不是重點，但是在其它用例中是重點）。
pdf版本下載下傳：關于測試用例設計的一點感想(優先級與拆分合并設計).pdf
作者：授客
QQ：1033553122
全國軟體測試QQ交流群：7156436
Git位址：https://gitee.com/ishouke
友情提示：限于時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額随意，您的支援将是我繼續創作的源動力，打賞後如有任何疑問，請聯系我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群