測試用例設(shè)計的一點感想優(yōu)先級與拆分合并

關(guān)于測試用例設(shè)計的一點感想(優(yōu)先級與拆分合并設(shè)計by:授歡迎加入軟件性能測試交 廢話不多說，直奔1、用例優(yōu)解析：以“用戶”為主，兼顧程序“依即以用戶為中心，從用戶的角度考慮，同時遵循序功能模塊彼此之間的“依賴”關(guān)系展開對用例的設(shè)計。以下為例進(jìn)行說明核(商戶全稱，商戶簡稱，資料商戶全稱，第一次提交時間，提交來源，資料類型等)和上傳附件(可通過“”查看)，所以，結(jié)論是：需要先對記錄數(shù)據(jù)準(zhǔn)確性校驗，先對“。問題：這里為何不以“程序依賴”為主呢？按我的理解，打開支付資料審核頁面時，默認(rèn)的也會進(jìn)行查詢，要進(jìn)行審核就必須先把記錄查詢出來，如果以“程序依賴”為主，那這里就應(yīng)該先對查詢進(jìn)行用例設(shè)計。但是我沒有，因為通常情況下，如果存在列表記錄，那么打開類似這種頁面應(yīng)該能自動顯示數(shù)據(jù)的，也就說打開頁面測試的必經(jīng)已默認(rèn)解決了這種“依賴”關(guān)系，即審核需要查詢出數(shù)據(jù)2、用例設(shè)計拆 （圖，里關(guān)注資料能否提交成功，數(shù)據(jù)庫是否正確；b從數(shù)據(jù)庫數(shù)據(jù)并展示，這里是否正確，如果對該功能對應(yīng)的數(shù)據(jù)庫、數(shù)據(jù)庫表比較庫校驗(推薦)，如果沒權(quán)限或者對數(shù)據(jù)庫、數(shù)據(jù)庫表不話，也可通過本終端相關(guān)web設(shè)計web展示數(shù)據(jù)功能用例時，用例的校驗重點是看是否正確。這種情況下，可web展示變化，當(dāng)然這也建立在對數(shù)據(jù)庫、 哪些是由web 不會導(dǎo)致web等數(shù)據(jù)發(fā)生變化，因為它可能是從緩存的數(shù)據(jù)，所以如果是在對程 pos這塊的，涉及支付寶收款，收款等，通常這些功能都會涉及到一些序操作，比如執(zhí)行支付寶收款，執(zhí)行不同場景的收款）3、用例設(shè)計合用例合并，沒看錯吧？對，沒看錯，就是用例合并。之前提過，一條用例一個點--g:收款成功頁可券臺“可券臺“卡券”：如果是會員折扣則顯示“員x-￥金額；如果是代金券，且只核銷一張，則-￥*數(shù)量-￥示為“折扣券名稱-￥金小票其中抹零金額0則視為無抹零收自動打?。喝绻渲昧俗詣哟蛴∏掖蛴⌒∑睌?shù)不 0，收款成功后自動答應(yīng)小按常規(guī)思維，有的人就可能會這么設(shè)計用例2、按照需求，一條用例一個驗證點用例1，看起來似乎很有邏輯性，但是從等價類的角度來看，這里有兩種輸入，分別對應(yīng)這兩種輸切的說應(yīng)該是邏輯分支，即一條邏輯分n條測試數(shù)據(jù)，對應(yīng)到自動化時也是這樣，方便處理。所以推薦按用2的方式編寫。用例2，看起來也沒問題，根據(jù)等價類劃分，可用1條測試數(shù)據(jù)、1次操作進(jìn)行覆蓋n條正向用測試收款“結(jié)果頁”字段信息執(zhí)行支付寶收款->測試打印小票字段信息（雖然按經(jīng)）那咋整按我的理解，這里，支付寶收款，自動打印小票，打印在業(yè)務(wù)角度看，都是緊密關(guān)聯(lián)的（用值得注意的是，這里需要對實際業(yè)務(wù)邏輯比較深入的理解，結(jié)合業(yè)務(wù)邏輯進(jìn)行用例的設(shè)計（這點很重要，要知道數(shù)據(jù)怎么走，數(shù)據(jù)傳遞時在哪里會發(fā)生變化，否則很容易因覆蓋不全導(dǎo)致出問題。是否有可不可金額（有不可金額，無不可金額使用（使用會員折扣，使用折扣券，使用代金券，不使用得到如下用【功能校驗】支付寶收款-有不可金額，不使【功能校驗】支付寶收款-無不可金額，不使【功能校驗】使用-有不可金額，折扣券，支付寶收【功能校驗】使用-有不可金額，多張代金券，支付寶收【功能校驗】使用-有不可金額，單張代金券，支付寶收【功能校驗】使用-有不可金額，會員折扣，支付寶收【功能校驗】使用-無不可金額，折扣券，支付寶收【功能校驗】使用-無不可金額，多張代金券，支付寶收【功能校驗】使用-無不可金額，單張代金券，支付寶收【功能校驗】使用-無不可金額，會員折扣，支付寶收【功能校驗】支付寶收款-不抹【功能校驗】支付寶收款-有抹零(抹零金額為【功能校驗】支付寶收款-有抹零(抹零金額不為【功能校驗】支付寶收款-無平臺金【功能校驗】支付寶收款-有平臺金【功能校驗】支付寶收款-有商家【功能校驗】支付寶收款-無商家【功能校驗】支付寶收款-無訂單【功能校驗】支付寶收款-有訂單支付抹零用【功能校驗】支付抹零-四舍五入到【功能校驗】支付抹零-往下抹零到【功能校驗】支付抹零-四舍五入到【功能校驗】支付抹零-往下抹零到4可注1、有人會問，這里為何不進(jìn)行類似如下的組用-可臺驗理由：組合不是不可以，但是這樣組合起來后，一眼看去就有點分不清這些“影響因素”之間的關(guān)系了，相互制約還是互不影響，這個真不清楚，而且分不清這條用例的測試重點在哪里，整個邏輯顯得很亂，影響因素比較少的情況下，可以考慮這樣組合下。2、根據(jù)上面說的，你用例預(yù)期里也有xxxxxxx，否則。。。?！边@樣的描述，這不自相？3、有人又會問，金額啥的還不是重點解答：是重點，根