測試用例編寫規(guī)范80895.doc

_測試用例編寫規(guī)范技術(shù)部賴文舉編寫人賴文舉編寫日期2019年3月1日審核人審核日期批準人批準日期變更歷史序號變更內(nèi)容變更頁變更類別變更者1.0新建/引言1. 背景為保證測試用例對需求的覆蓋率，即對一個系統(tǒng)從整體功能到單個功能，都盡可能的高的覆蓋。而單個功能點主要強調(diào)的是不同的輸入及其組合所帶來的各種輸入動作，系統(tǒng)是否都做了處理；測試用例設(shè)計首先要明確該系統(tǒng)存在多少功能點，要通過各種常用的測試方法來保證用例的完整性，然后再對各功能點的邊界范圍進行考慮。所以要保證測試用例的設(shè)計按照一種合理的結(jié)構(gòu)組織進行，這樣才能夠更有效的保證系統(tǒng)所有功能點的覆蓋率。2. 目的為測試用例的質(zhì)量負責(zé)，使測試工作能有序、合理化的進行，從而提高實施測試時對所測產(chǎn)品、系統(tǒng)或者模塊的測試質(zhì)量，也是作為各測試人員在設(shè)計用例時的一種規(guī)范，使之設(shè)計的用例能有效的被管理。3. 概念是指為了實施測試而編寫的一組有規(guī)范性、有據(jù)可依的輸入數(shù)據(jù)與輸出數(shù)據(jù)的組合，也指為了實施測試而向被測對象提供的一組輸入、輸出數(shù)據(jù)以及由各種執(zhí)行條件和期望結(jié)果相組合的一個特定集合，以便測試某個程序路徑或者來核實是否滿足某個特定的需求。4. 適用范圍l 本文檔適用于測試人員l 本文檔適用于系統(tǒng)進行測試時的測試案例設(shè)計l 本文檔適用于案例補充時的測試案例用例規(guī)范用途l 指導(dǎo)測試工作有序進行，使實施測試的數(shù)據(jù)有據(jù)可依l 確保所實現(xiàn)的功能與客戶預(yù)期的需求相符合l 完善軟件不同版本之間的重復(fù)性測試l 跟蹤測試進度，確定測試重點l 評估測試結(jié)果的度量標準l 增強軟件的可信任度l 分析缺陷的標準。設(shè)計依據(jù)l 需求說明書l 項目測試需求功能點l 所屬行業(yè)的業(yè)務(wù)知識掌握程度l 測試工程師本人的理解程度（個人經(jīng)驗）用例內(nèi)容1用例實際內(nèi)容用例編號唯一標識。規(guī)則“模塊名-功能點-編寫人-001，單詞或中文首字母。2模塊名稱模塊名稱3功能點測試的功能點4用例標題對測試項簡短的描述5用例級別確定用例執(zhí)行的級別P0,P1,P2,P36前提條件執(zhí)行用例時需要的預(yù)置條件7操作步驟執(zhí)行該動作需要完成的操作，需要明確輸入數(shù)據(jù)。8預(yù)期結(jié)果執(zhí)行完該動作后程序的表現(xiàn)結(jié)果9執(zhí)行結(jié)果執(zhí)行狀態(tài)用例的執(zhí)行結(jié)果通過，失敗，延后10實際結(jié)果實際輸出的結(jié)果11問題描述執(zhí)行該用例出現(xiàn)后系統(tǒng)顯示的錯誤12BUG編號填寫bug庫中對應(yīng)此用例的BUG編號13執(zhí)行人按照該用例執(zhí)行測試的人員編寫用例原則l 系統(tǒng)性：對系統(tǒng)業(yè)務(wù)流程要完整說明整個系統(tǒng)的業(yè)務(wù)需求、系統(tǒng)由幾個子系統(tǒng)組成以及它們之間的關(guān)系；對模塊業(yè)務(wù)流程要說明子系統(tǒng)內(nèi)部功能、重點功能以及它們之間的關(guān)系l 連貫性：對系統(tǒng)業(yè)務(wù)流程要說明各個子系統(tǒng)之間是如何連接在一起，若需要接口，各子系統(tǒng)之間是否有正確的接口，若是依靠頁面鏈接，則頁面的鏈接是否正確；對模塊業(yè)務(wù)流程要說明同級模塊以及上下級模塊是如何構(gòu)成一個子系統(tǒng)，其內(nèi)部功能接口是否連貫l 全面性：應(yīng)盡可能覆蓋各種路徑、盡可能覆蓋各個業(yè)務(wù)點，并要考慮跨年、跨月的數(shù)據(jù)以及大數(shù)據(jù)量并發(fā)測試的準備l 正確性：輸入界面后的數(shù)據(jù)應(yīng)與測試文檔所記錄的數(shù)據(jù)一致，而預(yù)期結(jié)果也應(yīng)與測試數(shù)據(jù)發(fā)生的業(yè)務(wù)吻合l 符合正常業(yè)務(wù)規(guī)則：測試數(shù)據(jù)要符合用戶實際工作中的業(yè)務(wù)流程，同時也要兼顧各種業(yè)務(wù)的變化以及當(dāng)前該業(yè)務(wù)行業(yè)的法律、法規(guī)、人名、地名、電話號碼等應(yīng)具有模擬功能，符合一般的命名慣例；不允許出現(xiàn)與知名人士、小說中人物名等雷同情況。l 可操作性：測試用例中要寫清楚測試的操作步驟，以及不同的操作步驟相對應(yīng)的測試結(jié)果編寫用例標準 l 測試案例編寫應(yīng)該制訂統(tǒng)一的模板進行，并約定模板的使用方法；l 測試案例編寫應(yīng)當(dāng)根據(jù)項目實際情況編寫測試案例編寫手冊，包括案例編號規(guī)則、案例編寫方法、案例編寫內(nèi)容、案例維護等內(nèi)容；l 案例編寫應(yīng)根據(jù)手冊中約定的編寫方法、內(nèi)容等進行編寫；l 案例編寫要步驟明確，輸入輸出要素清晰，并且與需求和缺陷相對應(yīng)；l 案例編寫應(yīng)嚴格根據(jù)需求規(guī)格說明書及測試需求功能分析點進行，要求覆蓋全部需求功能點；l 注重案例的可復(fù)用性，即在以后相似系統(tǒng)的測試過程中可以重復(fù)使用，減少測試設(shè)計工作量。用例設(shè)計步驟測試需求分析：從軟件需求分析文檔中，找出待測軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，要清楚被測對象具體包含哪些功能點。業(yè)務(wù)流程分析：對所在行業(yè)的業(yè)務(wù)知識要熟悉，然后對被測軟件/模塊的業(yè)務(wù)流程要進行全盤的整理出來（可畫簡單的流程圖作為參考），主要包含該業(yè)務(wù)流程的主流程、備選流程、數(shù)據(jù)流向、關(guān)鍵判斷條件以及完成該操作的非必要條件。測試用例設(shè)計：測試用例設(shè)計的類型主要包括功能測試、邊界測試、異常測試、性能測試、壓力測試等，在設(shè)計用例時要盡量考慮邊界、異常等情況。測試用例評審：由測試用例設(shè)計者發(fā)起，參加的人員需包括測試負責(zé)人、項目經(jīng)理、開發(fā)人員及其他相關(guān)的測試人員。測試用例完善：測試用例編寫完成之后需不斷完善，軟件產(chǎn)品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發(fā)現(xiàn)設(shè)計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善； 用例級別劃分P0：確保系統(tǒng)基本功能及主要功能的測試用例P1：確保系統(tǒng)功能的完善方面的測試用例P2：關(guān)于用戶體驗，輸入輸出的驗證；較少使用或輔助功能的測試用例。P0（優(yōu)先執(zhí)行）：即關(guān)鍵路徑的測試用例，包括最常執(zhí)行的功能、基本流程的輸入以及界面數(shù)據(jù)有效性校驗作為高級別的測試用例；若該級別的測試用例完全執(zhí)行通過，則表示該軟件功能漸趨穩(wěn)定；P1（次級執(zhí)行）：即可接收級測試的用例，包括不常執(zhí)行的功能、異常流程的輸入、邊界值以及異常數(shù)據(jù)的輸入作為中等級別的測試用例；若該級別的測試用例完全執(zhí)行通過，則表示該軟件可以進行發(fā)布了；P2（最后執(zhí)行）：即建議執(zhí)行的測試用例，也就是說該級別的測試用例不是不重要，而是該級別的用例在整個項目的生命周期內(nèi)不是常常被運行，包括：GUI、界面顯示、錯誤信息提示不統(tǒng)一、可用性、壓力和性能測試等。備注：對已有的用例級別說明，包括A-正常流程測試、B-異常流程測試、C-頁面元素正常輸入測試、D-頁面元素異常輸入測試、E-頁面元素顯示測試，可具體歸類如下（僅供參考）：P0：A-正常流程測試、C-頁面元素正常輸入測試P1：B-異常流程測試、D-頁面元素異常輸入測試P2：E-頁面元素顯示測試用例的維護刪除過時的測試用例因為需求的改變等原因可能會使一個基線測試用例不再適合被測系統(tǒng)，那么這些測試用例就會過時，需要對這些測試用例進行及時的刪除，在刪除過程中，不能夠?qū)⒄械臏y試用例刪除，應(yīng)該將要刪除的測試用例整行置灰，并將該行的用例計數(shù)器清為空；當(dāng)整個功能模塊需要刪除時，則將整個SHEET狀態(tài)置灰，并將用例計數(shù)器清空修改的測試用例隨著軟件項目的進展，測試需求可能會有部分變更，甚至大范圍的變更，這個時候我們就會根據(jù)需求的變化相應(yīng)的對測試用例進行維護，修改已經(jīng)不符合目前需求的內(nèi)容，并在備注欄中加以說明刪除冗余的測試用例 如果存在兩個或更多測試用例對一組相同的輸入和輸入進行測試，則需要對其進行刪除，只需留下其中的一個增添新的測試用例對新增的功能、在評審過程及測試過程中發(fā)現(xiàn)缺少測試用例或者系統(tǒng)出現(xiàn)BUG但是沒有與之對應(yīng)的測試用例，需要按照測試用例的設(shè)計標準進行增添，增加測試用例時，需要在相應(yīng)功能模塊的最下方插入新增的測試用例，并在備注欄中加以說明用例設(shè)計方法測試用例要包括欲測試的功能、應(yīng)輸入的數(shù)據(jù)和預(yù)期的輸出結(jié)果。測試數(shù)據(jù)應(yīng)該選用少量、高效的測試數(shù)據(jù)進行盡可能完備的測試；基本目標是：設(shè)計一組發(fā)現(xiàn)某個錯誤或某類錯誤的測試數(shù)據(jù)，測試用例應(yīng)覆蓋方面：等價劃分：將所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個等價類。邊界值分析法：確定邊界情況（剛好等于、稍小于和稍大于和剛剛大于等價類邊界值），針對我們的系統(tǒng)在測試過程中主要輸入一些合法數(shù)據(jù)/非法數(shù)據(jù)，主要在邊界值附近選取。場景法：通過運用場景來對系統(tǒng)的功能點或業(yè)務(wù)流程的描述，從而提高測試效果的一種方法。用例場景來測試需求是指模擬特定場景邊界發(fā)生的事情，通過事件來觸發(fā)某個動作的發(fā)生，觀察事件的最終結(jié)果，從而用來發(fā)現(xiàn)需求中存在的問題?；玖鳎菏墙?jīng)過用例的最簡單的路徑（無任何差錯，程序從開始直接執(zhí)行到結(jié)束）備選流：一個備選流可能從基本流開始，在某個特定條件下執(zhí)行，然后重新加入基本流中，也可以起源于另一個備選流，或終止用例，不在加入到基本流中；（各種錯誤情況）因果圖：利用圖解法分析輸入的各種組合情況，設(shè)計測試用例，檢查程序輸入條件的各種組合情況。正交表：在界面中有多個控件，控件之間有多種組合關(guān)系，如果組合的數(shù)量巨大（一般超過20種），沒有必要將所有組合都測試，可以通過正交排列法將組合中最優(yōu)，最少的組合進行測試。正確性測試：輸入用戶實際數(shù)據(jù)以驗證系統(tǒng)是滿足需求規(guī)格說明書的要求；測試用例中的測試點應(yīng)首先保證要至少覆蓋需求規(guī)格說明書中的各項功能，并且正常。容錯性（健壯性）測試：程序能夠接收正確數(shù)據(jù)輸入并且產(chǎn)生正確（預(yù)期）的輸出；輸入非法數(shù)據(jù)（非法類型、不符合要求的數(shù)據(jù)、溢出數(shù)據(jù)等），程序應(yīng)能給出提示并進行相應(yīng)處理。把自己想象成一名對產(chǎn)品操作一點也不懂的客戶，在進行任意操作。完整（安全）性測試：對未經(jīng)授權(quán)的人使用軟件系統(tǒng)或數(shù)據(jù)的企圖，系統(tǒng)能夠控制的程度，程序的數(shù)據(jù)處理能夠保持外部信息（數(shù)據(jù)庫或文件）的完整。接口間測試：測試各個模塊相互間的協(xié)調(diào)和通信情況，數(shù)據(jù)輸入輸出的一致性和正確性。數(shù)據(jù)庫測試：依據(jù)數(shù)據(jù)庫設(shè)計規(guī)范對軟件系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)、數(shù)據(jù)表及其之間的數(shù)據(jù)調(diào)用關(guān)系進行測試。壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄運行，進行測試。錯誤推測：主要是根據(jù)測試經(jīng)驗和直覺，參照以往的軟件系統(tǒng)出現(xiàn)錯誤之處。效率：完成預(yù)定的功能，系統(tǒng)的運行時間（主要是針對數(shù)據(jù)庫而言）?？衫斫猓ú僮鳎┬裕豪斫夂褪褂迷撓到y(tǒng)的難易程度（界面友好性）?？梢浦残裕涸诓煌僮飨到y(tǒng)及硬件配置情況下的運行性?；貧w測試：按照測試用例將所有的測試點測試完畢，測試中發(fā)現(xiàn)的問題開發(fā)人員。比較測試：將已經(jīng)發(fā)版的類似產(chǎn)品或原有的老產(chǎn)品與測試的產(chǎn)品同時運行比較，或與已往的測試結(jié)果比較。兼容性測試：操作系統(tǒng)的兼容性測試內(nèi)容不僅包括軟件的安裝，還需對關(guān)鍵流程和功能點進行檢查。而需要測試哪些操作系統(tǒng)的兼容性，首先取決于軟件用戶文檔上對用戶的承諾，其次就需要對一些常用操作系統(tǒng)兼容的檢查歷史版本兼容性測試：某些功能存在新版本和歷史版本數(shù)據(jù)顯示、頁面展示不一致的問題。需要不同版本進行測試。用例評審評審原因 測試用例是軟件測試的原則，但由于軟件人員對在需求理解、設(shè)計等理解程度不同等因素的影響，首次產(chǎn)生的測試用例質(zhì)量難以避免會有不同程度的差異，故對編寫的測試用例進行評審是很有必要的，其作用是測試用例的評審過程能夠起到用例結(jié)構(gòu)清晰化、場景覆蓋全面化以及優(yōu)先用例的合理化安排等。評審內(nèi)容 用例設(shè)計的結(jié)構(gòu)安排是否清晰合理，是否高效的需求進行覆蓋 用例的優(yōu)先級別是否安排合理 是否覆蓋了測試需求的所有功能點，包括需求中的業(yè)務(wù)規(guī)則、所有用戶可能使用的流程或場景等用例是否有很好的可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確 是否已經(jīng)刪除了冗余的測試用例 是否包含充分的負面測試用例是否簡潔、復(fù)用性強、是否易于管理評審過程 基于項目需求的測試計劃完成之后，進行初審，主要是對測試范圍和測試要點進行審查在測試用例的設(shè)計完成之后進行復(fù)審，主要是對測試用例的結(jié)構(gòu)和覆蓋率進行評審所有測試用例結(jié)束后，主要是對測試用例的具體描述是否有很好的可執(zhí)行性，是否有冗余用例的存在進行評審 評審人員部門評審：測試部全體成員參與的評審 項目評審：項目組全體測試人員與部分開發(fā)人員、產(chǎn)品人員等組成的小組 內(nèi)部評審：全部參與測試的人員評審方式 會議評審（包括內(nèi)部評審及客戶評審）。由設(shè)計該用例的人員進行講解，參與會議評審的相關(guān)人員給出意見或建議，并記錄評審的意見和建議郵件評審 郵件形式發(fā)給參與評審的相關(guān)人員，然后以郵件的形式把評審意見反饋給評審發(fā)起人。結(jié)束標準 經(jīng)評審的用例由用例設(shè)計者根據(jù)評審的建議或意見進行修改，更新用例，再次發(fā)起評審、修改、更新用例，反復(fù)評審后，直至用例達到要求。（反復(fù)評審時存在時