功能測試用例編寫指南

1、測試用例規(guī)范指南變更記錄序號修改日期修改內(nèi)容修改人審核人批準(zhǔn)人批準(zhǔn)日期12010-12-28創(chuàng)建孔春梅2前言本規(guī)范主要目的作為我們?nèi)粘９ぷ鞯闹笇?dǎo)方法，快速提高工作效率。1. 問題我們在編寫用例中實(shí)際遇到哪些問題？1. 新增“應(yīng)用“用例，用例中描述操作幾次算是一個完整的用例？2. 多個用例的前提都一致時(shí)，這個前提寫哪里？都要寫。什么情況下要寫前提？3. 功能套功能一顆粒度劃分-一個獨(dú)立功能建立一個文件夾。里面還有SRD父級功能與子功能有關(guān)聯(lián)時(shí)，可在父級下面描述4. 用例粒度：寫到什么程度就可達(dá)到標(biāo)準(zhǔn)？5. 一個用例要執(zhí)行幾次才算 pass？取決于最后一次執(zhí)行狀況。不同輪次的選擇執(zhí)行。6. 復(fù)雜度

2、較高的業(yè)務(wù)，用例如何劃分？獨(dú)立功能拆分。在業(yè)務(wù)流程里覆蓋7. 用例多為數(shù)據(jù)或場景的描述，提交bug時(shí)重現(xiàn)情景需要寫明。8. 合法校驗(yàn)的用例哪個輪次執(zhí)行？第 3輪策略里體現(xiàn)9. 公共用例：如何引用？10. 用例框架設(shè)計(jì)（左側(cè)是箱子，右側(cè)是內(nèi)容）（1）如何劃分箱子？（ 2）內(nèi)容決定結(jié)果，要設(shè)計(jì)哪些內(nèi)容？ （3）用例編寫的粒度如何把握（粗？細(xì)？）11. 如何達(dá)到用例的內(nèi)容清晰、主次程度分明？12. 問題：當(dāng)該功能點(diǎn)暫時(shí)沒想岀子功能點(diǎn)，但后期想岀來了，是否再轉(zhuǎn)為文件夾？13. 一個測試目標(biāo)有多個測試場景，有的分了多個R,有的是一個R中。14. 頁面導(dǎo)航要不要單獨(dú)拿出一個 R？15. 特殊業(yè)務(wù)的劃分，如

3、精確執(zhí)行-計(jì)劃編制2目的測試的重點(diǎn)不在于找出更多的bug，而是為了用“設(shè)計(jì)用例覆蓋業(yè)務(wù)功能/場景”的手段來保證產(chǎn)品的準(zhǔn)確性，能滿足和解決客戶實(shí)際工作的快捷高效且不發(fā)生錯誤。統(tǒng)一測試用例編寫的規(guī)范以最有效的測試用例達(dá)到最大的覆蓋率，更快速的輔助測試執(zhí)行，不僅提高軟件質(zhì)量，也提高了工作效率。形成用例庫集，不斷的補(bǔ)充和完善，積累項(xiàng)目測試經(jīng)驗(yàn)3編寫用例的好處具有計(jì)劃性、組織性、步驟性，從而避免盲目測試并提高測試效率，減少測試的不完全性；制定公共用例，不同的項(xiàng)目進(jìn)行復(fù)用，節(jié)省了不同項(xiàng)目用例設(shè)計(jì)時(shí)間用例的層次性、條理性，使得bug也有層次性，使開發(fā)人員不同階段關(guān)注不同的缺陷可以根據(jù)測試用例的優(yōu)先等級，不同

4、策略實(shí)施不同級別的測試軟件測試的實(shí)施重點(diǎn)突岀、目的明確；根據(jù)測試用例的多少和執(zhí)行難度，估算測試工作量，便于測試項(xiàng)目的時(shí)間和資源管理與跟蹤；減少回歸測試的復(fù)雜程度，在軟件版本更新后只需修正少量的測試用例便可展開測試工作，降低工作強(qiáng)度、縮短項(xiàng)目周期；若顧客有要求，測試用例會是交付產(chǎn)品中的一部分。提高軟件的可信度。4適用范圍測試部內(nèi)部成員。二測試用例設(shè)計(jì)階段1測試用例設(shè)計(jì)原則1用例設(shè)計(jì)與維護(hù)的工作原則 用例的設(shè)計(jì)不是一勞永逸的事情，要保持時(shí)時(shí)更新（用例評審后、需求變更后、有疑問的需求得以確認(rèn)后、任何時(shí)候發(fā)現(xiàn)遺漏的用例后）1）遵從測試用例組織框架劃分標(biāo)準(zhǔn)2）根據(jù)每個“獨(dú)立功能點(diǎn)”細(xì)致地設(shè)計(jì)測試用例3）

5、執(zhí)行完一輪測試之后，都要對測試用例進(jìn)行補(bǔ)充和整理4）測試結(jié)束之后，根據(jù)測試用例整理出測試思路進(jìn)行總結(jié)2優(yōu)先級原則 按照不同輪次所要求的測試策略來選取優(yōu)先級用例。 優(yōu)先級如何劃分？什么樣的輪次應(yīng)選取什么優(yōu)先級別的用例？ 3公共用例引用原則通過共性用例提高測試效率4. 一切以客戶為中心多從用戶的角度考慮軟件的“有用”和“好用” 。（1）有用：是指產(chǎn)品是能滿足客戶的業(yè)務(wù)需求，能給客戶帶來價(jià)值。（2）好用：是指客戶能夠非常快捷方便的使用產(chǎn)品來滿足實(shí)際工作需求。客戶使用產(chǎn)品是一個過程，包括從如何能容易 的獲得產(chǎn)品，容易安裝，容易使用，容易升級和維護(hù)，文檔清晰等。5. 測試用例編寫要求 測試用例是基于需求

6、的，寫好用例必須非常理解需求，能從全局上把握?？梢杂玫葍r(jià)類劃分、邊界值、路徑法、矩陣表、 正交法、判定表、因果圖等方法設(shè)計(jì)用例。想做到對需求的 100% 覆蓋，必須對需求進(jìn)行必要的分析，不能一上來就盲目 的寫用例 。 用例編寫完成后必須明確哪些是核心功能的用例。 編寫用例過程中，要考慮以下幾點(diǎn)：（1）有效性：本用例有明確的“測試目標(biāo)”（2）可理解性：每個 step 必須描述清晰，不能出現(xiàn)模棱兩可或重復(fù)的話語，用例寫完最好看一遍，讓單條用例流暢。（3） 清晰性：用例的驗(yàn)證點(diǎn)要明確清晰、重點(diǎn)突出，一個用例進(jìn)行一個功能點(diǎn)的驗(yàn)證。一個step 對應(yīng)一個業(yè)務(wù)場景，測 試用例包含前置條件的必須將前置條件描

7、述清楚，以及入口等。（4）可維護(hù)性：可以應(yīng)對需求的變更。當(dāng)需求變更時(shí)，及時(shí)維護(hù)用例，做到用例的實(shí)時(shí)性與有效性。 2測試需求的確定過程根據(jù)開發(fā)過程和實(shí)際工作需要將測試階段劃分為：確定測試需求、設(shè)計(jì)測試用例、執(zhí)行測試、編寫bug、回歸測試、結(jié)束測試、測試總結(jié)階段。需求階段中的主要工作和規(guī)范如下：（1）需求熟悉階段：充分理解用戶需求和產(chǎn)品需求文檔，對于歧義的要及時(shí)記錄下來，添加到需求跟蹤表，根據(jù)事先約定好的工作流程對需求問題進(jìn)行確認(rèn)；(2)需求評審結(jié)束前后：測試人員在任何階段發(fā)現(xiàn)的需求問題(有疑問的或不明確的)都要記錄下來，添加到需求跟蹤表，根據(jù)事先約定好的工作流程對需求問題進(jìn)行確認(rèn)。(若問題不多，

8、也可以私下找項(xiàng)目經(jīng)理或開發(fā)人員進(jìn)行確認(rèn)，但均需添加到需求跟蹤表中)。3 編寫測試用例的路徑(1) 熟悉和分析需求后，首先在 TD的Requirements中將需求轉(zhuǎn)化為需求測試點(diǎn)，需求粒度要細(xì)化到最 小的功能點(diǎn)(比如添加、修改等)；(2) 然后切換需求到 TESTPLAN中，在TESTPLAN中編寫測試用例。4 測試用例的設(shè)計(jì)原理編寫用例的目的就是更好的輔助測試來保證軟件質(zhì)量。那么何為質(zhì)量？基本包含兩個層次的含義，即“正確的軟件”及“軟件運(yùn)行正確”。(1 )正確的軟件：是指一個軟件要能夠滿足用戶的需求，為用戶創(chuàng)造價(jià)值。此價(jià)值可以體現(xiàn)兩方面，即為用戶創(chuàng)造利潤或者減少成本。(2)軟件運(yùn)行正確：是指

9、在軟件符合用戶需求的基礎(chǔ)上，軟件沒有或不影響正常功能的小缺陷，擴(kuò)展性很強(qiáng)，性能良好，易用性高等。為了用例達(dá)到最大覆蓋率，我們設(shè)計(jì)用例是從“用戶實(shí)際業(yè)務(wù)應(yīng)用”、“需求開發(fā)實(shí)現(xiàn)”(即縱向和橫向)2個維度設(shè)計(jì)用例，目前我們較好的方式就是用這種冗余的辦法來保證軟件質(zhì)量。我們在編寫用例時(shí)，要對需求進(jìn)行科學(xué)合理的顆粒度 劃分，我們先來看下以下幾種負(fù)面例子。用例框架每個UserCase都要有對應(yīng)的一個用例集合對其進(jìn)行測試負(fù)面例子：在界面或者需求里經(jīng)常會岀現(xiàn)很多功能寫在一起的需求，所以會導(dǎo)致編寫的測試用例也放在了一起，這樣就會發(fā)現(xiàn)很大的功能卻只有一個用例對應(yīng)，所以導(dǎo)致測試用例無法展開。所以我們在實(shí)際測試用例框

10、架搭 建中，要考慮對立的用戶操作(比如日記錄入、日記補(bǔ)給、日記修改、日記審閱等等)設(shè)計(jì)獨(dú)立功能測試目錄 集，在這個目錄集下存放所有用于驗(yàn)證它的測試用例。用例框架協(xié)助功能要建立在主功能下，根據(jù)復(fù)雜度建立子目錄或者R用例每個協(xié)助功能(比如日記錄入時(shí)的導(dǎo)入計(jì)劃)，由于其不作為一個獨(dú)立日記功能存在所以在建立框架時(shí)要把它建立在錄入日記下測試點(diǎn)要求每個用例都是針對于某個測試點(diǎn)在進(jìn)行測試針對于某個UserCase,需要通過設(shè)計(jì)多個測試點(diǎn)來全面對其進(jìn)行測試，而每個測試用例必須是針對于某個測試點(diǎn)展開驗(yàn)證測試點(diǎn)要求測試點(diǎn)要重業(yè)務(wù)數(shù)據(jù)測試設(shè)計(jì)負(fù)面例子：以前寫的很多測試過多的是在描述測試什么，描述步驟，缺少怎么測試的

11、內(nèi)容；所以現(xiàn)在必須強(qiáng)調(diào)輕步驟、重業(yè)務(wù)數(shù)據(jù)設(shè)計(jì)。步驟用于測試導(dǎo)航公共用例通過共性用例提高測試效率基于以上情況，我們對用例框架設(shè)計(jì)從以下3方面著手：功能測試用例 FVT、業(yè)務(wù)數(shù)據(jù)流用例FIVT用戶驗(yàn)收用例UAT4.1功能測試用例FVT功能用例設(shè)計(jì)思路是從開發(fā)實(shí)現(xiàn)角度測試，描述功能的邏輯規(guī)則及頁面元素，分層描述邏輯規(guī)則，對邏輯規(guī)則細(xì)化可直接作為用例的操作步驟描述。以正向和逆向思維考慮設(shè)計(jì)用例。(1)正向思維：驗(yàn)證被測對象是不是做了它該做的事情。? ( 2)逆向思維：驗(yàn)證被測對象有沒有做它不該做的事情。?01冒煙S/基礎(chǔ)的操作（包括所有屬性的輸入）?02規(guī)則R/詳細(xì)的業(yè)務(wù)規(guī)則，如唯一性，權(quán)限，數(shù)據(jù)（計(jì)

12、算正確性、完整性，排序），邏輯等?03接口 D/定義與使用。如定義處對 使用處的影響。?04邊界B/數(shù)據(jù)臨界、事務(wù)操作臨界，即一般人很少用到的情況?05并發(fā)0/實(shí)時(shí)、異步并發(fā)?06合法檢測E/數(shù)據(jù)項(xiàng)的完整性約束，包括異常的情況，事務(wù)中斷等以上6類用例統(tǒng)一記為“ F”規(guī)則。功能用例框架劃分規(guī)則目的是保持用例層次結(jié)構(gòu)分明、清晰和設(shè)計(jì)風(fēng)格一致性。1. 框架劃分原則（1）原則一：基礎(chǔ)的增刪改查用例框架的文件夾，按功能特性逐級進(jìn)行劃分，直到細(xì)化為具體的獨(dú)立“功能點(diǎn)”（如增加、修改等）。用例應(yīng)該按照增刪改的順序進(jìn)行安排，這樣執(zhí)行的時(shí)候效率比較高，避免不必要的重復(fù)測試。當(dāng)某功能點(diǎn)為獨(dú)立時(shí)（不可再拆分），則寫

13、為 F規(guī)則。當(dāng)某功能點(diǎn)又能拆分岀多個子功能點(diǎn)，則形成文件夾。里面再分自己的F規(guī)則。（2 ）原則二：父功能下存在子功能（a）當(dāng)子功能為獨(dú)立功能點(diǎn)，則在父功能文件夾下建立子功能的文件夾。該文件夾下包含用例：子功能自身的F規(guī)則/注：這里的F規(guī)則，請參考：父子功能的邏輯關(guān)聯(lián)規(guī)則。當(dāng)子功能有N種不同類的輸出作為父功能的輸入時(shí)，則需要有N個此類用例。/即子功能的多種輸岀都會對父功能產(chǎn)生不同的影響。命名方式請見下面第 4條。（b）子功能又有子功能時(shí)，用例劃分方法同（a）2. 文件夾層級要求子業(yè)務(wù)模塊（如計(jì)劃錄入）按根節(jié)點(diǎn)算起，其下屬子文件夾最好不要超過 3層級。比如超岀3層級時(shí)，若子功能對父 功能相對獨(dú)立時(shí)

14、，則可把子功能放到父功能的同級。（具體情況具體分析）3. 文件夾及用例的命名方式要求：所有文件夾用01打頭的數(shù)字標(biāo)識其順序。如：同級的文件夾以 01、02、03等打頭標(biāo)識。 如上圖所示，子業(yè)務(wù)模塊計(jì)劃錄入文件夾記為父功能（或根節(jié)點(diǎn)）舉例：計(jì)劃錄入這個父功能體現(xiàn)在“保存”這個動作上，所以把計(jì)劃錄入作為父功能文件夾。文件夾/用例命名規(guī)則舉例備注父功能文件夾編號+父功能01計(jì)劃錄入，02計(jì)劃查詢父功能用例命名0仆VT_功能 _S01_xx0仆VTJ+劃錄入_S01_xx方式0仆VT_功能 _R01_xx子功能文件夾父功能_子功能_BP01計(jì)劃錄入加入任務(wù)_BP01子功能用例0仆VT_功能_子功能_S

15、01_xx0仆VT_劃錄入加入任務(wù)_S01_xx父子功能的業(yè)務(wù)02FVT_功能 _子功能 _RP01_R01_:x02FVT_n入任務(wù)任務(wù)查詢_RP01_R02_:x邏輯用例提醒2:上述用例中的xx,是指該用例是驗(yàn)證什么的一個描述。舉例：0仆VT/位新增_S01_驗(yàn)證給單位添加崗位，02FVT.崗位新增_R03驗(yàn)證必填用例框架舉例：上圖解釋：父功能記為L,子功能記為 M子功能的子功能記為 N父功能文件夾命名：編號+L/編號從01、02 o。開始子功能文件夾命名：L_M_RP01注意：是下劃線子功能的子功能文件夾命名：M_N_RP01功能用例粒度劃分4.131用例顆粒度劃分的規(guī)范何謂“測試目標(biāo)”

16、，假設(shè)你要測試一個新增界面某些字段的必填項(xiàng)，那么對新增【必填項(xiàng)】的驗(yàn)證就可以分出一個用例，即稱為唯一的“測試目標(biāo)”。具體劃分請參考VER系統(tǒng)測試 么共用例.xlsx（1） 一個用例對應(yīng)唯一的“測試目標(biāo)”。（2）一個用例內(nèi)部包含驗(yàn)證該“測試目標(biāo)”的多種場景。a）有多種場景，則分別用不同 step描述。b）每個step，在stepname列要簡要描述本步驟的目的。（3） 一個用例應(yīng)該有多少步驟？分步測試的一個比較好的長度最大到10-15步驟，達(dá)到更高的用例可測性。a）每個step，被執(zhí)行測試的時(shí)間很短b）測試人員不太可能迷失方向，犯錯誤或需要援助c ）測試組長可以估算需要多少時(shí)間來進(jìn)行測試d）結(jié)果

17、更容易追蹤（4）當(dāng)多個功能點(diǎn)之間存在制約關(guān)系時(shí)，可以采用矩陣表、路徑或正交法進(jìn)行用例編寫。用例顆粒度劃分的例子下圖為“尋呼發(fā)布”的界面，我們?nèi)绾伟盐沼美６饶兀拷酉聛砦覀兛慈绾畏纸庥美河美那爸脳l件前置條件：主要是對特殊情況的描述說明。大家公認(rèn)的默認(rèn)規(guī)則可不寫。1. 一個用例中需要描述公共的前置條件時(shí)，則第1個step為公共的前置條件（第 2個step為導(dǎo)航）2. 一個用例中不同的step有各自的前置條件時(shí)，則在本step的Description 中進(jìn)行前置條件的描述。什么時(shí)候必須加前置條件？具體情況具體分析。舉一個刪除“已使用的組織”的例子：Stepname （描述目的）Descripti

18、on（測試點(diǎn)描述）ExpectedResult（期望結(jié)果）前置條件xxxx導(dǎo)航點(diǎn)擊左側(cè)菜單系統(tǒng)管理一組織管理進(jìn)入組織管理頁面，當(dāng)前路徑顯示正確刪除特殊狀態(tài)的組織前置條件：組織為啟用狀態(tài)選中已啟用狀態(tài)的組織，執(zhí)行刪除不允許刪除，給出友好提醒刪除被其他模塊引用的組織選中已被其他模塊使用的組織，執(zhí)行刪除不允許刪除，給出友好提醒用例的公共導(dǎo)航所有用例都涉及進(jìn)入當(dāng)前路徑的描述，我們統(tǒng)一稱為“導(dǎo)航”，即路徑。格式舉例:Stepname （描述目的）Description（測試點(diǎn)描述）ExpectedResult （期望結(jié)果）導(dǎo)航1. 點(diǎn)擊左側(cè)菜單 xx xx xx2. 點(diǎn)擊“新增”按鈕1. 正常進(jìn)入xx頁

19、面，當(dāng)前路徑顯示正確2. 彈岀新增頁面5用例的step要求及格式1、一個step有自己獨(dú)立的明確的測試目的，即不同的step是對本測試目標(biāo)進(jìn)行怎么測的業(yè)務(wù)場景。要重業(yè)務(wù)數(shù)據(jù)，輕步驟。格式：step的書寫規(guī)范StepnameDescriptionExpectedResult （期望結(jié)果）描述本step的目的該目的輸入信息輸岀信息，本輸岀可能存在多個驗(yàn)證點(diǎn)。（分別用1,2,3標(biāo)識出。）注意：“描述”和“期望結(jié)果”二者一定要明確，不要互相混淆；不能存在模棱兩可的字樣；比如幾乎、大概、一般等。2、各步驟順序依次為前提、導(dǎo)航、各場景。舉例：組織管理-新增頁面2有個“必填項(xiàng)”（組織名稱、組織編號），驗(yàn)證必

20、填項(xiàng)的用例如下。Stepname （描述目的）Description（測試點(diǎn)描述）ExpectedResult （期望結(jié)果）1導(dǎo)航1. 點(diǎn)擊左側(cè)菜單系統(tǒng)管理一組織 管理2. 選中某組織，點(diǎn)擊“新增”按鈕1. 正常進(jìn)入組織管理頁面，當(dāng)前路徑顯示正確2. 彈岀新增頁面2查看必填標(biāo)識檢測所有必填項(xiàng)的標(biāo)識對必填項(xiàng)都已進(jìn)行紅星標(biāo)識3不填寫組織名稱4不填寫組織編號5必填項(xiàng)都不填寫Step中的標(biāo)題簡述必須要有，數(shù)字可以根據(jù)自己習(xí)慣而定。4.2業(yè)務(wù)數(shù)據(jù)流用例FIVT業(yè)務(wù)流用例設(shè)計(jì)思路注重?cái)?shù)據(jù)傳遞，側(cè)重業(yè)務(wù)邏輯的場景。可以先畫岀業(yè)務(wù)數(shù)據(jù)流，針對主流程與備選流程進(jìn)行用例設(shè)計(jì)。? FIVT_cycle_C01 /周

21、期性，如與時(shí)間相關(guān)，跨周、月、年，先分析業(yè)務(wù)數(shù)據(jù)的時(shí)間特性，考慮最適中的周期。? FIVT_data_S01 /基本數(shù)據(jù)流（主業(yè)務(wù)數(shù)據(jù)流）? FIVT_flow_A01 /路徑（包含所有路徑、所有分支的用例覆蓋），以業(yè)務(wù)數(shù)據(jù)為節(jié)點(diǎn)，每個分支路徑為一個用例。? FIVT_status_B01 /業(yè)務(wù)數(shù)據(jù)的狀態(tài)變化性（如流程狀態(tài)、會議室閑忙狀態(tài)），以狀態(tài)為節(jié)點(diǎn)，不同的狀態(tài)流轉(zhuǎn) 路徑為一個用例? FIVT_colateral ?_D01業(yè)務(wù)數(shù)據(jù)的并發(fā)處理（實(shí)時(shí)、異步）注：上述中的 A B、C、D分別代表用例的重要程度。以高到低排序。業(yè)務(wù)流用例粒度劃分一個流程路徑：分一個用例。建議按照流程順序進(jìn)行用例

22、安排，從第一個驗(yàn)證點(diǎn)到最后一個驗(yàn)證點(diǎn)，組成流程的開始到結(jié)束，方便測試執(zhí)行。4.3用戶驗(yàn)收用例UAT用戶驗(yàn)收用例設(shè)計(jì)思路UAT： UserAcceptanceTest*脫離系統(tǒng)提供功能，站在用戶角度來設(shè)計(jì)用例，從用戶實(shí)際可能的操作場景考慮。*基本是按業(yè)務(wù)特性制定的用例，模擬用戶實(shí)際操作，描述用戶的主要業(yè)務(wù)目標(biāo)，包含完整的系統(tǒng)級場景和模擬用戶實(shí)際操作的不同場景，幾個功能點(diǎn)的組合也算是用戶場景。432用戶驗(yàn)收用例粒度劃分業(yè)務(wù)應(yīng)用是面向不同的使用對象：普通員工、經(jīng)理級、總裁級、管理員等。主要體現(xiàn)：員工級、管理者所關(guān)注的信息。用戶驗(yàn)收測試的每一個相對獨(dú)立的部分，都應(yīng)該有目標(biāo)（本步驟的目的）、啟動標(biāo)準(zhǔn)（著

23、手本步驟必須滿足的條件）、活動（構(gòu)成本步驟的具體活動）、完成標(biāo)準(zhǔn)（完成本步驟要滿足的條件）和度量（應(yīng)該收集的產(chǎn)品與過程數(shù)據(jù)）。5.測試用例優(yōu)先級接收軟件測試前，我們已獲取明確的質(zhì)量目標(biāo)。在制定測試計(jì)劃時(shí)，會根據(jù)質(zhì)量目標(biāo)制定不同的測試策略。包含：測試重點(diǎn)要求、測試技術(shù)類型的選取、測試活動的先后序列、資源調(diào)度與安排等。各優(yōu)先級所占全部測試用例比例通常如下：P130%-45%，P240%-60%，P310%-15%。1. 劃分優(yōu)先級前，我們先對功能用例進(jìn)行細(xì)分：前提：版本控制到位。該問題如何避免？ （ QTP錄制回放）01冒煙S基礎(chǔ)的操作（包括所有 屬性的輸入）每輪執(zhí)行回歸測試02規(guī)則R詳細(xì)的業(yè)務(wù)規(guī)

24、則，如唯 一性，權(quán)限，數(shù)據(jù)（計(jì) 算正確性、完整性，排 序），邏輯等R1 （核心主業(yè)務(wù)）必經(jīng)業(yè)務(wù)，缺少它 則不可繼續(xù)下一步 業(yè)務(wù)操作。如發(fā)尋 呼，必須先添加組 織/用戶，否則無法 發(fā)送尋呼。每輪執(zhí)行回歸測試R2（經(jīng)常使用的規(guī)則）如尋呼中“轉(zhuǎn)發(fā)”尋呼每輪執(zhí)行回歸測試R3（較少使用的規(guī) 則）如尋呼中“發(fā)短信” 功能執(zhí)行2次R4（極少使用的復(fù)執(zhí)行1次雜業(yè)務(wù)邏輯）03 接口 D定義與使用。D1:定義處新增， 使用處獲取更新【崗位管理】新增 后，【用戶管理】 中可選擇使用執(zhí)行2次如定義處對使用處的影響D2定義處修改， 使用處獲取更新【崗位管理】修改，【用戶管理】中同步更新執(zhí)行2次D3:定義處刪除，【崗位管

25、理】刪除，執(zhí)行2次使用處已獲取更新【用戶管理】中不再顯示04邊界B數(shù)據(jù)臨界、事務(wù)操作臨 界，即一般人很少用到 的情況以刪除為例：1）無數(shù)據(jù)時(shí)，點(diǎn)擊 刪除2）同時(shí)刪除“未被 引用”和“已被引 用”的記錄執(zhí)行1次05并發(fā)C實(shí)時(shí)并發(fā)執(zhí)行1次異步并發(fā)06合法檢測E數(shù)據(jù)項(xiàng)的完整性約束， 包括異常的情況，事務(wù) 中斷等執(zhí)行1次FIVT_cycle_C01周期性，如與時(shí)間相關(guān)，跨周、月、年后期執(zhí) 行1次FIVT_data_S01基本數(shù)據(jù)流（主業(yè)務(wù)數(shù) 據(jù)流）每輪執(zhí)行FIVT_flow_A01路徑（包含所有路徑、 所有分支的用例覆蓋）執(zhí)行2-3次FIVT_status_B01業(yè)務(wù)數(shù)據(jù)的狀態(tài)變化性（如流程狀態(tài)、會議

26、室閑忙狀態(tài)）執(zhí)行2-3次FIVT_colateral ?_D01業(yè)務(wù)數(shù)據(jù)的并發(fā)處理（實(shí)時(shí)、異步）執(zhí)行1次驗(yàn)收用例執(zhí)行1次2. 優(yōu)先級原則需求優(yōu)先級高，涉及的各類用例優(yōu)先級也高使用頻度高、業(yè)務(wù)失敗對客戶產(chǎn)生嚴(yán)重影響、失敗風(fēng)險(xiǎn)3. 優(yōu)先級別可以分為以下4類級別：P1、P2、P3、P4，高到低。級別定義用例執(zhí)行要求舉例備注P1冒煙測試用例確保系統(tǒng)基本功能及主業(yè)務(wù)流的用例。該級用例，每個測試版本都需執(zhí) 行且通過S、R1 （核心主業(yè)務(wù)）考慮場景被使用頻 度、使用人員的比例， 角色重要程度。如員 工/管理者/管理員有 80%勺頻率在使用某 功能P2關(guān)鍵路徑測試用例經(jīng)常使用的核心業(yè)務(wù)。 是確保系統(tǒng)功能的完

27、善方面的用例該級用例，每個測試版本都需執(zhí) 行且通過R2 （經(jīng)常使用的規(guī)則）D?S2該級測試用例均通 過，意味著軟件功能 趨于穩(wěn)定。P3可接受級關(guān)于用戶體驗(yàn)，輸入輸岀的驗(yàn)證及其他較少該級用例，只要執(zhí)行一次通過即 可B，E, C, R3（較少使用的規(guī)則）測試用例使用或輔助功能的用 例。D?S3P4建議執(zhí)行用例極少被使用如果有時(shí)間，最好執(zhí)行該級用 例，但不作為發(fā)布的必要條件。R4 （極少使用的復(fù)雜業(yè)務(wù)邏輯）6 測試用例維護(hù)與共享6.1測試用例維護(hù)當(dāng)前版本的用例維護(hù)需求用例庫目錄用例需求增加按顆粒度劃分規(guī)則，來決策是否需要建立文件夾增加新用例需求修改在本模塊一級目錄下增加【無效用例】子文件夾1）在【無

28、效用例】文件夾下先建立“無 效用例”的所在目錄2）復(fù)制“原無效用例”到 1 ）中3）在“原無效用例”中修改“已變更” 需求的用例需求刪除若存在【無效用例】文件夾，則無需再建立1）將“原無效用例”剪切到【無效用例】 文件夾下注：【無效用例】文件夾只建立一個即可。主要目的是儲存垃圾用例，以便預(yù)防需求來回變更的情況。不同版本的用例維護(hù)一個產(chǎn)品，隨著時(shí)間會不斷發(fā)布多個版本，使測試用例不斷完善，同時(shí)也與產(chǎn)品功能、特性的變化保持一致，所以測試 用例是和產(chǎn)品版本相關(guān)聯(lián)的。當(dāng)產(chǎn)品有多個版本共存，為不同客戶群提供服務(wù)，這時(shí)測試用例勢必也會存在版本之分。根據(jù)測試用例與產(chǎn)品需求保持一致性的原則，分以下幾種情況:產(chǎn)品

29、需求用例變更原因?qū)εf版本用例的影響對新版本用例的影響1新版本中需求未變新版本發(fā)現(xiàn)了 bug或用例需要 補(bǔ)充有效。如何保證新版本中修改的同步更新舊版本？有效。新版本中修改用例2新版本中需求變化（功能 增強(qiáng)）非新功能，是對原功能的功能 增強(qiáng)有效。當(dāng)前用例不可修改新版本中修改或增加用例3新版本中需求取消需求刪除有效當(dāng)前新版本的對應(yīng)用例無 效。置為無效4新版本中完全新增的需求需求新增無效新版本中增加用例2 用例是否要有狀態(tài)標(biāo)識？要制定幾個狀態(tài)？有效、無效、維護(hù)中6.2測試用例共享在編寫用例過程中，常常遇到不同模塊下有相同功能的情況。這種情況下，我們在設(shè)計(jì)用例時(shí)，就可以考慮公共用例的復(fù) 用。1 公共用例

30、的框架公共用例單獨(dú)制定一個文件夾，里面包含各類可以共享的功能。舉例：2 公共用例的引用當(dāng)其他模塊需要引用公共用例時(shí)，我們要求復(fù)制粘貼的方式，然后調(diào)整為適合本功能的用例。好處有以下幾點(diǎn)：（ 1） 共享過來的全部用例不一定吻合本功能點(diǎn)，需要適當(dāng)修改調(diào)整；（ 2） 為了用例集的完整性；（ 3） 統(tǒng)計(jì)時(shí)要考慮用例的個數(shù)，更好的評估工作量3 公共用例的變更（1）當(dāng)公共用例的變更會對“引用處”產(chǎn)生影響時(shí)，則“引用處”要及時(shí)做適當(dāng)調(diào)整。 （2）被引用公共用例文件夾的“描述”處記錄由誰誰引用，方便公共用例變更后的可追蹤更改。三測試用例評審測試用例的評審能夠使用例的結(jié)構(gòu)更清晰， 覆蓋的用戶場景更全面； 對于測試

31、工程師來說也是一個快速提高測試用例 設(shè)計(jì)能力的過程。1.需要評審原因和目的 測試用例是軟件測試的準(zhǔn)則，但它并不是一經(jīng)編制完成就成為準(zhǔn)則。由于用例編寫人員的設(shè)計(jì)經(jīng)驗(yàn)和對需求理解 的深度各不相同，所以用例的質(zhì)量難免會有不同程度的差異。用例評審的主要目的就是集眾人的經(jīng)驗(yàn)及認(rèn)識于一體， 對測試用例進(jìn)入查漏補(bǔ)缺，使得測試用例的有效性進(jìn)一步提升。2、進(jìn)行評審的時(shí)機(jī) 一般會有兩個時(shí)間點(diǎn)。第一，是在用例的初步設(shè)計(jì)完成之后進(jìn)行評審；第二是在整個詳細(xì)用例全部完成之后進(jìn)行二 次評審。如果項(xiàng)目時(shí)間比較緊張，盡可能保證對用例設(shè)計(jì)進(jìn)行評審，提前發(fā)現(xiàn)其中的不足之處。3、參與評審人員這里會分為多個級別進(jìn)行評審。1）內(nèi)部評審，

32、測試部門全體成員參與的評審。2）組織評審，這里包括了項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、需求人員、架構(gòu)師、開發(fā)人員、UE 和測試人員。3）客戶評審，包括了客戶方的開發(fā)人員和測試人員。這種情況在外包公司比較常見。4、評審的內(nèi)容 見測試用例檢查單5、評審的方式1）非正式評審：通過通訊工具或少數(shù)相關(guān)人口頭交流 2）正式評審：召開評審會議。與會者在設(shè)計(jì)人員講解之后給出意見和建議，同時(shí)進(jìn)行詳細(xì)的評審記錄。 方式只是手段，得到其它人員對于用例的反饋信息才是目的。無論采用那種方式， 都應(yīng)該在溝通之前把用例設(shè)計(jì)的相關(guān)文檔發(fā)送給對方進(jìn)行前期的熟悉和了解，以節(jié)省溝通成 本。6、評審結(jié)束標(biāo)準(zhǔn) 在評審活動中會收集到用例的反饋信息，在

33、此基礎(chǔ)上進(jìn)行用例更新，直到通過評審。四測試用例執(zhí)行階段1建立測試套件首先在TESTLAB建立測試集，在此建立的目錄結(jié)構(gòu)與TESTPLAN中一致。2選擇用例將TESTPLAN中編寫的用例轉(zhuǎn)到 TESTLAB（鼠標(biāo)拖拽）。3執(zhí)行用例嚴(yán)格按照測試用例來執(zhí)行測試。(1) 首次執(zhí)行測試集時(shí)選擇手動運(yùn)行；若需要執(zhí)行上次未執(zhí)行完的測試，下次再執(zhí)行測試集時(shí)選 擇繼續(xù)手工運(yùn)行即可；若下次想放棄上次的執(zhí)行，重新執(zhí)行的話，則選擇手動運(yùn)行，系統(tǒng)會新建 一個運(yùn)行歷史；(2) 執(zhí)行用例時(shí)若不通過，則將此用例的Status修改為Failed，并填寫bug;若通過的話將此用例的 狀態(tài)修改為Passed。附錄1 冒煙測試定義(

34、1) 冒煙測試的含義顧名思義，最基本的測試，能保證系統(tǒng)能簡單跑起來。包含基礎(chǔ)功能和主業(yè)務(wù)流的測試。冒煙的原始說法：汽車生產(chǎn)出來以后，首先發(fā)動汽車，看汽車能否冒煙，如果能，證明汽車最起碼可以 開動了。說明完成了最基本的功能。(2) 冒煙用例的定義所有屬性都有輸入。(3) 什么情況下需要寫冒煙用例子功能為獨(dú)立的增、刪、改、查。(4) 冒煙用例的級別定義S1:最基礎(chǔ)的增刪改查、不可缺少的核心功能、主業(yè)務(wù)流S2:關(guān)鍵功能、備選流S3:輔助功能如查詢-新增-快速查詢(這個“快速查詢”就是輔助功能)2.什么是核心業(yè)務(wù)優(yōu)先級分類高頻率使用核心業(yè)務(wù)。不可缺少的主功能，高頻率使用(80%)的功能中頻率使用次核心業(yè)務(wù)。備選功能低頻率使用輔助業(yè)務(wù)。舉個手機(jī)例子高頻率使用：如打電話、接聽電話、收/發(fā)短信是核心功能。中頻率使用：拍照，聽音樂、玩游戲低頻率使用：購物消費(fèi)3. 用例設(shè)計(jì)方法4. 如何避免漏測(1) 需求評審進(jìn)行嚴(yán)格的需求評審，在編碼前找出需求的bug，雖然不可能找出所有不合理的地方，這是減少風(fēng)險(xiǎn)的一種手段。Q1 :需求總是不能固定？不固定就會引出問題，然后