功能測試用例編寫指南

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

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

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

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

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

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

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

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

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

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

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

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

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

14、，則可把子功能放到父功能的同級。（具體情況具體分析）3. 文件夾及用例的命名方式要求：所有文件夾用01打頭的數(shù)字標識其順序。如：同級的文件夾以 01、02、03等打頭標識。 如上圖所示，子業(yè)務(wù)模塊計劃錄入文件夾記為父功能（或根節(jié)點）舉例：計劃錄入這個父功能體現(xiàn)在“保存”這個動作上，所以把計劃錄入作為父功能文件夾。文件夾/用例命名規(guī)則舉例備注父功能文件夾編號+父功能01計劃錄入，02計劃查詢父功能用例命名0仆VT_功能 _S01_xx0仆VTJ+劃錄入_S01_xx方式0仆VT_功能 _R01_xx子功能文件夾父功能_子功能_BP01計劃錄入加入任務(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,是指該用例是驗證什么的一個描述。舉例：0仆VT/位新增_S01_驗證給單位添加崗位，02FVT.崗位新增_R03驗證必填用例框架舉例：上圖解釋：父功能記為L,子功能記為 M子功能的子功能記為 N父功能文件夾命名：編號+L/編號從01、02 o。開始子功能文件夾命名：L_M_RP01注意：是下劃線子功能的子功能文件夾命名：M_N_RP01功能用例粒度劃分4.131用例顆粒度劃分的規(guī)范何謂“測試目標”

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

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

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

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

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

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

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

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

24、則，如唯 一性，權(quán)限，數(shù)據(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（極少使用的復執(zhí)行1次雜業(yè)務(wù)邏輯）03 接口 D定義與使用。D1:定義處新增， 使用處獲取更新【崗位管理】新增 后，【用戶管理】 中可選擇使用執(zhí)行2次如定義處對使用處的影響D2定義處修改， 使用處獲取更新【崗位管理】修改，【用戶管理】中同步更新執(zhí)行2次D3:定義處刪除，【崗位管

25、理】刪除，執(zhí)行2次使用處已獲取更新【用戶管理】中不再顯示04邊界B數(shù)據(jù)臨界、事務(wù)操作臨 界，即一般人很少用到 的情況以刪除為例：1）無數(shù)據(jù)時，點擊 刪除2）同時刪除“未被 引用”和“已被引 用”的記錄執(zhí)行1次05并發(fā)C實時并發(fā)執(zhí)行1次異步并發(fā)06合法檢測E數(shù)據(jù)項的完整性約束， 包括異常的情況，事務(wù) 中斷等執(zhí)行1次FIVT_cycle_C01周期性，如與時間相關(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ā)處理（實時、異步）執(zhí)行1次驗收用例執(zhí)行1次2. 優(yōu)先級原則需求優(yōu)先級高，涉及的各類用例優(yōu)先級也高使用頻度高、業(yè)務(wù)失敗對客戶產(chǎ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)于用戶體驗，輸入輸岀的驗證及其他較少該級用例，只要執(zhí)行一次通過即 可B，E, C, R3（較少使用的規(guī)則）測試用例使用或輔助功能的用 例。D?S3P4建議執(zhí)行用例極少被使用如果有時間，最好執(zhí)行該級用 例，但不作為發(fā)布的必要條件。R4 （極少使用的復雜業(yè)務(wù)邏輯）6 測試用例維護與共享6.1測試用例維護當前版本的用例維護需求用例庫目錄用例需求增加按顆粒度劃分規(guī)則，來決策是否需要建立文件夾增加新用例需求修改在本模塊一級目錄下增加【無效用例】子文件夾1）在【無

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

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

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

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

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

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

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