檢驗(yàn)用例編寫示范

1、測試用例編寫規(guī)范技術(shù)部賴文舉編寫人賴文舉編寫日期2019年3月1日審核人審核日期批準(zhǔn)人批準(zhǔn)日期變更歷史序號變更內(nèi)容變更頁變更類別變更者1.0新建/引言1.背景為保證測試用例對需求的覆蓋率，即對一個(gè)系統(tǒng)從整體功能到單個(gè)功能，都盡可能的高的覆蓋。而單個(gè)功能點(diǎn)主要強(qiáng)調(diào)的是不同的輸入及其組合所帶來的各種輸入動(dòng)作,系統(tǒng)是否都做了處理;測試用例設(shè)計(jì)首先要明確該系統(tǒng)存在多少功能點(diǎn)，要通過各種常用的測試方法來保證用例的完整性，然后再對各功能點(diǎn)的邊界范圍進(jìn)行考慮。所以要保證測試用例的設(shè)計(jì)按照一種合理的結(jié)構(gòu)組織進(jìn)行，這樣才能夠更有效的保證系統(tǒng)所有功能點(diǎn)的覆蓋率。2.目的為測試用例的質(zhì)量負(fù)責(zé)， 使測試工作能有序、

2、合理化的進(jìn)行，從而提高實(shí)施測試時(shí)對所使之設(shè)測產(chǎn)品、系統(tǒng)或者模塊的測試質(zhì)量， 也是作為各測試人員在設(shè)計(jì)用例時(shí)的一種規(guī)范, 計(jì)的用例能有效的被管理。3.概念是指為了實(shí)施測試而編寫的一組有規(guī)范性、有據(jù)可依的輸入數(shù)據(jù)與輸出數(shù)據(jù)的組合，也指為了實(shí)施測試而向被測對象提供的一組輸入、輸出數(shù)據(jù)以及由各種執(zhí)行條件和期望結(jié)果相 組合的一個(gè)特定集合，以便測試某個(gè)程序路徑或者來核實(shí)是否滿足某個(gè)特定的需求。4.適用范圍本文檔適用于測試人員 本文檔適用于系統(tǒng)進(jìn)行測試時(shí)的測試案例設(shè)計(jì) 本文檔適用于案例補(bǔ)充時(shí)的測試案例用例規(guī)范用途指導(dǎo)測試工作有序進(jìn)行，使實(shí)施測試的數(shù)據(jù)有據(jù)可依 確保所實(shí)現(xiàn)的功能與客戶預(yù)期的需求相符合 完善軟件

3、不同版本之間的重復(fù)性測試 跟蹤測試進(jìn)度，確定測試重點(diǎn) 評估測試結(jié)果的度量標(biāo)準(zhǔn) 增強(qiáng)軟件的可信任度 分析缺陷的標(biāo)準(zhǔn)。設(shè)計(jì)依據(jù)需求說明書 項(xiàng)目測試需求功能點(diǎn) 所屬行業(yè)的業(yè)務(wù)知識(shí)掌握程度 測試工程師本人的理解程度（個(gè)人經(jīng)驗(yàn)）用例內(nèi)容用用例編號唯一標(biāo)識(shí)。規(guī)則“模塊名-功能點(diǎn)-編寫人-001，單詞或中文例首字母。實(shí)模塊名稱模塊名稱際功能點(diǎn)測試的功能點(diǎn)內(nèi)用例標(biāo)題對測試項(xiàng)簡短的描述容用例級別確定用例執(zhí)行的級別P 0, P1, P2,P356前提條件執(zhí)行用例時(shí)需要的預(yù)置條件7操作步驟執(zhí)行該動(dòng)作需要完成的操作，需要明確輸入數(shù)據(jù)。8預(yù)期結(jié)果執(zhí)行完該動(dòng)作后程序的表現(xiàn)結(jié)果9執(zhí)行 結(jié) 果執(zhí)行狀態(tài)用例的執(zhí)行結(jié)果通過，失敗

4、，延后10實(shí)際結(jié)果實(shí)際輸出的結(jié)果11問題描述執(zhí)行該用例出現(xiàn)后系統(tǒng)顯示的錯(cuò)誤12BUG編號填寫bug庫中對應(yīng)此用例的 BUG編號13執(zhí)行人按照該用例執(zhí)行測試的人員編寫用例原則系統(tǒng)性：對系統(tǒng)業(yè)務(wù)流程要完整說明整個(gè)系統(tǒng)的業(yè)務(wù)需求、系統(tǒng)由幾個(gè)子系統(tǒng)組成以及它們之間的關(guān)系；對模塊業(yè)務(wù)流程要說明子系統(tǒng)內(nèi)部功能、重點(diǎn)功能以及它們之間的關(guān)系連貫性：對系統(tǒng)業(yè)務(wù)流程要說明各個(gè)子系統(tǒng)之間是如何連接在一起,若需要接口，各子系統(tǒng)之間是否有正確的接口，若是依靠頁面鏈接，則頁面的鏈接是否正確;對模塊業(yè)務(wù)流程要說明同級模塊以及上下級模塊是如何構(gòu)成一個(gè)子系統(tǒng),其內(nèi)部功能接口是否連貫全面性：應(yīng)盡可能覆蓋各種路徑、盡可能覆蓋各個(gè)業(yè)

5、務(wù)點(diǎn)，并要考慮跨年、跨月的數(shù)據(jù)以及大數(shù)據(jù)量并發(fā)測試的準(zhǔn)備正確性：輸入界面后的數(shù)據(jù)應(yīng)與測試文檔所記錄的數(shù)據(jù)一致,而預(yù)期結(jié)果也應(yīng)與測試數(shù)據(jù)發(fā)生的業(yè)務(wù)吻合同時(shí)也要兼符合正常業(yè)務(wù)規(guī)則：測試數(shù)據(jù)要符合用戶實(shí)際工作中的業(yè)務(wù)流程,地名、電話號碼等應(yīng)顧各種業(yè)務(wù)的變化以及當(dāng)前該業(yè)務(wù)行業(yè)的法律、法規(guī)、人名、 具有模擬功能，符合一般的命名慣例；不允許出現(xiàn)與知名人士、 小說中人物名等雷 同情況?？刹僮餍裕簻y試用例中要寫清楚測試的操作步驟，以及不同的操作步驟相對應(yīng)的測試結(jié)果編寫用例標(biāo)準(zhǔn)測試案例編寫應(yīng)該制訂統(tǒng)一的模板進(jìn)行，并約定模板的使用方法;測試案例編寫應(yīng)當(dāng)根據(jù)項(xiàng)目實(shí)際情況編寫測試案例編寫手冊，包括案例編號規(guī)則、 案例

6、編寫方法、案例編寫內(nèi)容、案例維護(hù)等內(nèi)容;案例編寫應(yīng)根據(jù)手冊中約定的編寫方法、內(nèi)容等進(jìn)行編寫;案例編寫要步驟明確，輸入輸出要素清晰，并且與需求和缺陷相對應(yīng);要求覆蓋全部需減少測試設(shè)案例編寫應(yīng)嚴(yán)格根據(jù)需求規(guī)格說明書及測試需求功能分析點(diǎn)進(jìn)行, 求功能點(diǎn);注重案例的可復(fù)用性，即在以后相似系統(tǒng)的測試過程中可以重復(fù)使用, 計(jì)工作量。用例設(shè)計(jì)步驟測試需求分析：從軟件需求分析文檔中，找出待測軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，要清楚被測對象具體包含哪些功能點(diǎn)。業(yè)務(wù)流程分析：對所在行業(yè)的業(yè)務(wù)知識(shí)要熟悉，然后對被測軟件/模塊的業(yè)務(wù)流程要進(jìn)行全盤的整理出來（可畫簡單的流程圖作為參考），主要包含

7、該業(yè)務(wù)流程的主流程、備選流程、數(shù)據(jù)流向、關(guān)鍵判斷條件以及完成該操作的非必要條件。測試用例設(shè)計(jì)：測試用例設(shè)計(jì)的類型主要包括功能測試、邊界測試、異常測試、性能測試、壓力測試等，在設(shè)計(jì)用例時(shí)要盡量考慮邊界、異常等情況。測試用例評審：他相關(guān)的測試人員。測試用例完善：測試用例必測試用例編寫完成之后需不斷完善，軟件產(chǎn)品新增功能或更新需求后,須配套修改更新;在測試過程中發(fā)現(xiàn)設(shè)計(jì)測試用例時(shí)考慮不周，需要對測試用例進(jìn)行修改完善;在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成,需要對測試用例進(jìn)行完善;用例級別劃分P0:確保系統(tǒng)基本功能及主要功能的測試用例P1:確保系統(tǒng)功能的完善方面的測試用例

8、P2 :關(guān)于用戶體驗(yàn)，輸入輸出的驗(yàn)證；較少使用或輔助功能的測試用例。P0 （優(yōu)先執(zhí)行）：即關(guān)鍵路徑的測試用例，包括最常執(zhí)行的功能、基本流程的輸入以及界面數(shù)據(jù)有效性校驗(yàn)作為高級別的測試用例;若該級別的測試用例完全執(zhí)行通過,表示該軟件功能漸趨穩(wěn)定;P1 （次級執(zhí)行）：即可接收級測試的用例，包括不常執(zhí)行的功能、異常流程的輸入、 邊界值以及異常數(shù)據(jù)的輸入作為中等級別的測試用例；若該級別的測試用例完全執(zhí)行通 過，則表示該軟件可以進(jìn)行發(fā)布了;P2 （最后執(zhí)行）：即建議執(zhí)行的測試用例，也就是說該級別的測試用例不是不重要,GUI、界面顯示、錯(cuò)而是該級別的用例在整個(gè)項(xiàng)目的生命周期內(nèi)不是常常被運(yùn)行，包括: 誤信息

9、提示不統(tǒng)一、可用性、壓力和性能測試等。備注：對已有的用例級別說明，包括A-正常流程測試、B-異常流程測試、C-頁面元 素正常輸入測試、D-頁面元素異常輸入測試、E-頁面元素顯示測試，可具體歸類如下（僅 供參考）：P0 : A-正常流程測試、C-頁面元素正常輸入測試P1 : B-異常流程測試、D-頁面元素異常輸入測試P2 : E-頁面兀素顯示測試用例的維護(hù)刪除過時(shí)的測試用例那么這些因?yàn)樾枨蟮母淖兊仍蚩赡軙?huì)使一個(gè)基線測試用例不再適合被測系統(tǒng),測試用例就會(huì)過時(shí)， 需要對這些測試用例進(jìn)行及時(shí)的刪除，在刪除過程中，不能夠?qū)⒄械臏y試用例刪除， 應(yīng)該將要?jiǎng)h除的測試用例整行置灰，并將該行的用例計(jì)數(shù)器清 為

10、空;當(dāng)整個(gè)功能模塊需要?jiǎng)h除時(shí)，則將整個(gè)SHEET狀態(tài)置灰，并將用例計(jì)數(shù)器清空修改的測試用例隨著軟件項(xiàng)目的進(jìn)展， 測試需求可能會(huì)有部分變更,甚至大范圍的變更，這個(gè)時(shí)修改已經(jīng)不符合目前需求的候我們就會(huì)根據(jù)需求的變化相應(yīng)的對測試用例進(jìn)行維護(hù), 內(nèi)容，并在備注欄中加以說明刪除冗余的測試用例則需要對其進(jìn)如果存在兩個(gè)或更多測試用例對一組相同的輸入和輸入進(jìn)行測試,行刪除，只需留下其中的一個(gè)BUG增添新的測試用例對新增的功能、在評審過程及測試過程中發(fā)現(xiàn)缺少測試用例或者系統(tǒng)出現(xiàn)但是沒有與之對應(yīng)的測試用例，需要按照測試用例的設(shè)計(jì)標(biāo)準(zhǔn)進(jìn)行增添，增加測試用例時(shí)，需要在相應(yīng)功能模塊的最下方插入新增的測試用例，并在備注欄

11、中加以說明用例設(shè)計(jì)方法測試用例要包括欲測試的功能、應(yīng)輸入的數(shù)據(jù)和預(yù)期的輸出結(jié)果。測試數(shù)據(jù)應(yīng)該選用少量、高效的測試數(shù)據(jù)進(jìn)行盡可能完備的測試；基本目標(biāo)是：設(shè)計(jì)一組發(fā)現(xiàn)某個(gè)錯(cuò)誤或某類錯(cuò)誤的測試數(shù)據(jù)，測試用例應(yīng)覆蓋方面:等價(jià)劃分：將所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個(gè)等價(jià)類。邊界值分析法：確定邊界情況（剛好等于、稍小于和稍大于和剛剛大于等價(jià)類邊界值）針對我們的系統(tǒng)在測試過程中主要輸入一些合法數(shù)據(jù)/非法數(shù)據(jù),主要在邊界值附近選取。場景法：通過運(yùn)用場景來對系統(tǒng)的功能點(diǎn)或業(yè)務(wù)流程的描述,從而提高測試效果的一種方法。用例場景來測試需求是指模擬特定場景邊界發(fā)生的事情,通過事件來觸發(fā)某個(gè)動(dòng)作的發(fā)生，觀

12、察事件的最終結(jié)果，從而用來發(fā)現(xiàn)需求中存在的問題?；玖鳎菏墙?jīng)過用例的最簡單的路徑 （無任何差錯(cuò)，程序從開始直接執(zhí)行到結(jié)束）備選流：一個(gè)備選流可能從基本流開始，在某個(gè)特定條件下執(zhí)行，然后重新加入基本流中，也可以起源于另一個(gè)備選流，或終止用例，不在加入到基本流中;（各種錯(cuò)誤情況）因果圖：利用圖解法分析輸入的各種組合情況，設(shè)計(jì)測試用例，檢查程序輸入條件的各種組合情況。正交表：在界面中有多個(gè)控件， 控件之間有多種組合關(guān)系，如果組合的數(shù)量巨大（一般超過20種），沒有必要將所有組合都測試，可以通過正交排列法將組合中最優(yōu)，最少的組合進(jìn)行測試。正確性測試：輸入用戶實(shí)際數(shù)據(jù)以驗(yàn)證系統(tǒng)是滿足需求規(guī)格說明書的要求;

13、測試用例中的測試點(diǎn)應(yīng)首先保證要至少覆蓋需求規(guī)格說明書中的各項(xiàng)功能，并且正常。容錯(cuò)性（健壯性）測試：程序能夠接收正確數(shù)據(jù)輸入并且產(chǎn)生正確（預(yù)期）的輸出;輸入非法數(shù)據(jù)（非法類型、不符合要求的數(shù)據(jù)、溢出數(shù)據(jù)等），程序應(yīng)能給出提示并進(jìn)行相應(yīng)處理。把自己想象成一名對產(chǎn)品操作一點(diǎn)也不懂的客戶，在進(jìn)行任意操作。完整（安全）性測試：對未經(jīng)授權(quán)的人使用軟件系統(tǒng)或數(shù)據(jù)的企圖,系統(tǒng)能夠控制的程度，程序的數(shù)據(jù)處理能夠保持外部信息（數(shù)據(jù)庫或文件）的完整。接口間測試：測試各個(gè)模塊相互間的協(xié)調(diào)和通信情況，數(shù)據(jù)輸入輸出的一致性和正確性。數(shù)據(jù)庫測試：依據(jù)數(shù)據(jù)庫設(shè)計(jì)規(guī)范對軟件系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)、數(shù)據(jù)表及其之間的數(shù)據(jù)調(diào)用關(guān)系進(jìn)行測試

14、。壓力測試：輸入10條記錄運(yùn)行各個(gè)功能， 輸入30條記錄運(yùn)行，輸入50條記錄運(yùn)行,進(jìn)行測試。錯(cuò)誤推測：主要是根據(jù)測試經(jīng)驗(yàn)和直覺，參照以往的軟件系統(tǒng)出現(xiàn)錯(cuò)誤之處。效率：完成預(yù)定的功能，系統(tǒng)的運(yùn)行時(shí)間（主要是針對數(shù)據(jù)庫而言）?？衫斫猓ú僮鳎┬裕豪斫夂褪褂迷撓到y(tǒng)的難易程度（界面友好性）。可移植性：在不同操作系統(tǒng)及硬件配置情況下的運(yùn)行性。回歸測試：按照測試用例將所有的測試點(diǎn)測試完畢，測試中發(fā)現(xiàn)的問題開發(fā)人員。或與比較測試：將已經(jīng)發(fā)版的類似產(chǎn)品或原有的老產(chǎn)品與測試的產(chǎn)品同時(shí)運(yùn)行比較, 已往的測試結(jié)果比較。還需對關(guān)鍵流程和功兼容性測試：操作系統(tǒng)的兼容性測試內(nèi)容不僅包括軟件的安裝,能點(diǎn)進(jìn)行檢查。而需要測試哪

15、些操作系統(tǒng)的兼容性，首先取決于軟件用戶文檔上對用戶的 承諾，其次就需要對一些常用操作系統(tǒng)兼容的檢查歷史版本兼容性測試：某些功能存在新版本和歷史版本數(shù)據(jù)顯示、頁面展示不一致的 問題。需要不同版本進(jìn)行測試。評審原因用例評審測試用例是軟件測試的原則， 但由于軟件人員對在需求理解、設(shè)計(jì)等理解程度不同等因素的影響，首次產(chǎn)生的測試用例質(zhì)量難以避免會(huì)有不同程度的差異,故對編寫的測試用例進(jìn)行評審是很有必要的，其作用是測試用例的評審過程能夠起到用例結(jié)構(gòu)清晰化、場景覆蓋全面化以及優(yōu)先用例的合理化安排等。評審內(nèi)容用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰合理，是否高效的需求進(jìn)行覆蓋用例的優(yōu)先級別是否安排合理是否覆蓋了測試需求的所有

16、功能點(diǎn)，包括需求中的業(yè)務(wù)規(guī)則、 所有用戶可能使用的流程或場景等用例是否有很好的可執(zhí)行性。例如用例的前提條件、 執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確是否已經(jīng)刪除了冗余的測試用例是否包含充分的負(fù)面測試用例是否簡潔、復(fù)用性強(qiáng)、是否易于管理評審過程基于項(xiàng)目需求的測試計(jì)劃完成之后,進(jìn)行初審，主要是對測試范圍和測試要點(diǎn)進(jìn)行審查在測試用例的設(shè)計(jì)完成之后進(jìn)行復(fù)審,主要是對測試用例的結(jié)構(gòu)和覆蓋率進(jìn)行評審所有是否有冗余用例測試用例結(jié)束后，主要是對測試用例的具體描述是否有很好的可執(zhí)行性,的存在進(jìn)行評審評審人員部門評審:測試部全體成員參與的評審項(xiàng)目評審:項(xiàng)目組全體測試人員與部分開發(fā)人員、產(chǎn)品人員等組成的小組內(nèi)部評審:全部參與測試的人員評審方式會(huì)議評審（包括內(nèi)部評審及客戶評審）。由設(shè)計(jì)該用例的人員進(jìn)行講解，參與會(huì)議評審的相關(guān)人員給出意見或建議，并記錄評審的意見和建議郵件評審郵件形式發(fā)給參與評審的相關(guān)人員，然后以郵件的形式把評審意見反饋給評審發(fā)起人。結(jié)束標(biāo)準(zhǔn)更新用例，再次發(fā)起評經(jīng)評審的用例由用例設(shè)計(jì)者