測試流程及規(guī)范

1、文件名稱測試流程及規(guī)范受控標識處1、 電子文件受控以實時查閱“數(shù)據(jù)中心”實現(xiàn)；2、 紙質(zhì)文件受控以主管部門加蓋“受控”印章實現(xiàn)。文件編號文件版本1 目的側(cè)重測試工作流程及規(guī)范的控制，明確產(chǎn)品研發(fā)的各階段測試組應完成的工作。測試技術和策略等問題不在本文檔描述范圍內(nèi)。本規(guī)范作為所有測試組成員工作前必須掌握的工作規(guī)范，也供給其它部門其它組查閱參考，以便于組間的協(xié)調(diào)溝通，更好的合作完成產(chǎn)品的研發(fā)工作。2 概念與術語在整個產(chǎn)品的研發(fā)過程中，測試類型按照先后順序主要分為：單元測試、集成測試、系統(tǒng)測試及產(chǎn)品確認，整個過程如下面的W模型所示：設計規(guī)格模塊設計集成測試系統(tǒng)測試產(chǎn)品確認N概要設計需求規(guī)格單元測試三

2、繪圖/編碼測試需求測試計劃測試計劃測試大綱走查/審核 執(zhí)行單元測試執(zhí)行集成測試 執(zhí)行系統(tǒng)測試 產(chǎn)品試用圖1有關的測試類型的概念如下：1）單元測試：驗證產(chǎn)品中的模塊，測試依據(jù)主要為模塊詳細設計或模塊的需求規(guī)格。能使問題及早暴露，也便于問題的定位解決，單元測試屬于早期測試，因而錯誤發(fā)現(xiàn)后能明確知道是某一單元產(chǎn)生的，單元測試允許多個被測單元的測試工作同時開展。根據(jù)公司研發(fā)流程的實際情況，此測試也可由設計研發(fā)人員執(zhí)行。2）集成測試是驗證模塊間接口及匹配關系，測試依據(jù)主要為概要設計。一般采用自底向上或自頂向下的模塊集成方法，逐步集成。在此環(huán)節(jié)中測試組還負責驗收研發(fā)人員提供的轉(zhuǎn)測試的材料，如果材料不完備，

3、測試組可以拒絕接收。3）系統(tǒng)測試是對系統(tǒng)的一系列的整體、有效性、可靠性的測試，測試依據(jù)主要為設計規(guī)格及產(chǎn)品需求規(guī)格。目的是確認產(chǎn)品與設計規(guī)格、需求、行業(yè)標準及公司標準的符合性，同時還要確認性能和系統(tǒng)的穩(wěn)定性，與之前的集成測試應遵循“相同的被測對象不要做兩遍相同的測試” 的基本原則。4）除單元測試、集成測試和系統(tǒng)測試之外，還應有“產(chǎn)品確認”環(huán)節(jié)，即在客戶環(huán)境中或模擬客戶環(huán)境測試與驗證產(chǎn)品，在有限的試用客戶中或模擬客戶環(huán)境中發(fā)現(xiàn)產(chǎn)品問題并加以妥善處理，保證產(chǎn)品質(zhì)量，提高客戶滿意度。確認與實驗室內(nèi)部測試的區(qū)別在于：實驗室內(nèi)部測試要盡可能多做，多發(fā)現(xiàn)問題；確認要在達到質(zhì)量目標的情況下盡可能少做；兩者要

4、在質(zhì)量和成本之間權衡、綜合考慮。5）TD：全稱Mercury TestDirector，一種測試管理工具。6）黑盒測試：黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結構和內(nèi)部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內(nèi)部邏輯結構，主要針對軟件界面和軟件功能進行測試。黑盒測試是以用戶的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應關系出發(fā)進行測試的。3 職責角色名稱相關主要責任測試主管l 組建測試小組l 協(xié)調(diào)測

5、試小組內(nèi)外部的溝通l 組織編制測試大綱（含測試用例）和計劃l 組織測試準入檢查l 測試過程中的進度控制、風險管理l 測試過程報告l 編寫測試報告l 召集測試評審測試人員l 識別測試需求l 參與編制測試大綱（含測試用例）和計劃l 協(xié)助測試準入檢查l 執(zhí)行測試用例，測試結果記錄l 測試缺陷記錄與跟蹤l 協(xié)助測試評審支持人員l 為測試工作提供技術支持，比如環(huán)境安裝、版本布署、測試工具支持等備注：該角色可選，可根據(jù)項目實際情況設置，一般情況下由研發(fā)人員擔任。【注】：當某個項目僅有一個測試人員時，該測試人員同時也為該項目內(nèi)的測試主管，需要擔負起測試主管的職責。4 測試類型和測試方法4.1 測試類型測試工

6、作通常分為4個類型，功能測試、聯(lián)合測試、性能測試及穩(wěn)定性測試。測試類型測試意義功能測試l 確保功能符合需求定義l 確保所有功能可以正常完成工作聯(lián)合測試l 一個新產(chǎn)品或一個產(chǎn)品的新版本發(fā)布時，要確保與之相配合的產(chǎn)品可以正常配合使用性能測試l 在產(chǎn)品有性能要求的部分，進行性能測試和調(diào)優(yōu)，確保產(chǎn)品性能符合需求穩(wěn)定性測試l 模擬用戶真正的使用情況，設計相應的測試用例，確保產(chǎn)品可以穩(wěn)定可靠的長時間運行4.2 測試方法測試類型測試方法功能測試/聯(lián)合測試l 以手工黑盒測試為主，手工執(zhí)行功能測試用例。l 正規(guī)測試和隨機測試相結合：根據(jù)需求文檔撰寫測試方案及測試用例來進行常規(guī)測試，考慮到測試用例有可能寫的不全面

7、，所以在進行常規(guī)測試過程中，可以加入隨機測試。同時，對預測試出來的缺陷，將其執(zhí)行過程寫成一個測試用例，添加到測試用例集合中，以完善測試用例；l 采用測試工具TD進行測試用例的管理和缺陷記錄、跟蹤。性能測試l 性能測試要求滿足兩種情況：1）產(chǎn)品在特定工況下可以達到的最高性能（例如：測試時將日志等影響性能的選項關閉）；2）模擬用戶真正的使用環(huán)境（如：日志功能打開，在一定的用戶數(shù)量的情況下），產(chǎn)品真實可以達到的性能；穩(wěn)定性測試l 穩(wěn)定性測試要求模擬用戶真正的使用情況，設計相應的測試用例，確保產(chǎn)品可以穩(wěn)定可靠的長時間運行【注】：黑盒測試過程的參考準則：（1）必須采用邊界值分析法；（2）必要時采用等價類

8、劃分法補充測試用例；（3）采用錯誤判斷法，追加測試用例；（4）對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當補充更多的測試用例；（5）測試數(shù)據(jù)應準備充分，應采用有效數(shù)據(jù)、無效數(shù)據(jù)、邊界數(shù)據(jù)分別測試驗證；5 工作流程、模式及規(guī)范5.1 測試提交文件及裁剪說明階段提交文件必須提交模板定義裁剪條件說明測試需求測試需求分析報告否項目組自定義無特殊需求，可省略測試計劃測試大綱是項目組自定義各項目組根據(jù)測試任務的規(guī)?？勺远x模板測試計劃否項目組自定義如果測試大綱或設計開發(fā)計劃中已包括了測試計劃的內(nèi)容，則本文檔可省略測試大綱計劃評審記錄否公司模板各項目酌情選用測試用例是

9、公司模板采用公司統(tǒng)一測試用例模板測試用例評審記錄否公司模板各項目酌情選用測試實施測試準入檢查表否公司模板各項目酌情選用測試記錄是項目組自定義各項目組根據(jù)測試任務的規(guī)模可自定義模板測試收尾測試報告是公司模板采用公司統(tǒng)一測試報告模板測試報告評審記錄否公司模板各項目酌情選用測試工作改進報告否項目組自定義各項目酌情選用測試成果提交否項目組自定義各項目酌情選用5.2 評審點評審點定義參照設計開發(fā)控制程序。5.3 敏捷測試模式5.3.1 敏捷測試概念敏捷測試即是不斷修正質(zhì)量指標，正確建立測試策略，確認客戶的有效需求得以圓滿實現(xiàn)和確保整個生產(chǎn)的過程安全的、及時的發(fā)布最終產(chǎn)品。5.3.2 敏捷增量測試方法測試

10、是敏捷開發(fā)過程重要的環(huán)節(jié)，自始自終測試貫穿于每個迭代。整個產(chǎn)品的敏捷開發(fā)生命周期可以分為 4 個階段，即初始階段，項目的建設階段，產(chǎn)品發(fā)布階段和產(chǎn)品的維護階段，在關鍵的項目建設階段中，測試被分成兩個部分，驗證測試和系統(tǒng)測試。驗證測試：靜態(tài)測試和關鍵的功能測試。系統(tǒng)測試：功能測試、聯(lián)合測試、性能測試、穩(wěn)定性測試。5.3.3 敏捷測試流程敏捷測試流程依據(jù)業(yè)務場景制定測試策略。在每次敏捷測試的過程中包括驗證測試和聯(lián)合測試。并且不斷的進行迭代測試。在系統(tǒng)的所有業(yè)務場景都經(jīng)過敏捷測試過后，進入系統(tǒng)測試階段。進行所有業(yè)務場景的功能測試、聯(lián)合測試、性能測試、穩(wěn)定性測試。根據(jù)業(yè)務場景制定測試策略流程圖產(chǎn)品業(yè)務

11、場景一業(yè)務場景二。業(yè)務場景N模塊一模塊二模塊三三。模塊N模塊四三業(yè)務場景一缺陷管理缺陷管理業(yè)務場景三TR5業(yè)務場景二TR5業(yè)務場景NTR5業(yè)務場景四TR5敏捷測試流程圖測試傳遞項報告敏捷測試測試總結測試通過進入下一次敏捷迭代測試計劃提交測試N Y Y N 滿足準入條件系統(tǒng)測試條件Y 軟件測試總結軟件評估滿足發(fā)布條件產(chǎn)品發(fā)布測試案例維護系統(tǒng)測試和回歸測試測試是否通過Y Y 根據(jù)缺陷性質(zhì)來判斷更新提交測試的依據(jù)：1） 嚴重級別為Urgent和High的修改后立即更新，要保證更新后不能影響其他功能測試。2） 功能級別為Medium以下的可以等待下一次提交敏捷測試的時候更新。5.4 傳統(tǒng)瀑布模式5.4

12、.1 測試需求分析過程要點詳細說明啟動條件需求階段的工作啟動工作內(nèi)容由測試主管根據(jù)項目任務復雜程度組織或指定測試人員進行測試需求分析，從客戶角度考慮軟件測試需要達到的驗證狀態(tài)，并確定是否要形成測試需求分析報告結束條件需求分析完成例外對于簡單設計更改、衍生產(chǎn)品等只需例行測試的，可不進行測試需求分析責任人項目經(jīng)理參與人測試主管5.4.2 成立測試小組或確認測試人員過程要點詳細說明啟動條件測試任務明確，前期工作啟動工作內(nèi)容l 確認項目的測試人員，若整個項目的測試需要若干個測試人員，則需要成立一個測試小組；l 為測試小組任命一名測試主管，若只有一個測試人員，則該測試人員同時也為該測試組的測試主管，同時

13、確定測試小組的其它構成人選；l 小組內(nèi)進行必要的培訓。結束條件測試小組成立例外l 若以前的測試任務已成立過測試小組，則可以復用以前的組織人員和形式責任人項目經(jīng)理參與人測試主管5.4.3 編制測試計劃過程要點詳細說明啟動條件項目階段性計劃確定需求規(guī)格說明書、詳細設計說明書等已評審工作內(nèi)容測試大綱至少包括以下關鍵內(nèi)容：l 測試目標對本次測試的要求和要達到的目標l 測試范圍需要測試小組測試的范圍，和各個測試需求的測試優(yōu)先級l 工作分工明確測試小組內(nèi)部及外部配合方的相關責任和工作關系l 測試策略整體測試的總體測試策略、環(huán)境、方法和工具等l 完成標準達到何種條件可以認為測試完成l 交付文件測試完成時應提

14、交的文件，比如測試大綱（含測試用例）、測試報告等等測試計劃至少應包括以下關鍵內(nèi)容：l 主要任務每項任務的時間計劃、前置條件及資源l 主要里程碑關鍵任務及完成時間點l 在項目研發(fā)過程中，要適時的對測試計劃進行跟蹤，以評估此計劃的完整性、可行性，在項目結束時還要最后評估一下測試計劃的質(zhì)量結束標準測試計劃評審通過或得到相關各方的審批輸出文件測試計劃、測試計劃評審記錄例外l 對于多個系統(tǒng)參與的同一個測試任務，可由主項目組或牽頭方統(tǒng)一編制測試大綱和計劃，不用每個系統(tǒng)單獨編制和出具l 測試計劃可以在測試大綱中直接詳細列明，而不用單獨編制責任人測試主管參與人研發(fā)總監(jiān)、項目經(jīng)理、測試人員5.4.4 編制測試大

15、綱、設計測試用例在技術規(guī)格書評審通過以后，測試小組需要針對項目的測試范圍編制測試大綱、設計測試用例。在實際測試過程中，測試用例可根據(jù)實際需要進行更新和調(diào)整。在測試用例的設計過程中，具體的任務和責任人如下：過程要點詳細說明啟動條件本次測試范圍、業(yè)務需求已經(jīng)明確需求規(guī)格說明是、詳細設計說明書已通過評審工作內(nèi)容l 準備本次測試的測試用例l 測試用例在該產(chǎn)品的測試用例庫中進行選擇，如有需要，可以進行增加；l 每個測試用例須包括用例編號、測試概述、測試數(shù)據(jù)、操作步驟說明、預期結果等要素；l 測試用例須覆蓋所有的測試需求和功能點；l 采用統(tǒng)一的模板進行用例設計。結束標準測試用例覆蓋所有的待測試需求或功能點

16、，并且評審通過輸出文件測試大綱、測試用例、測試大綱評審記錄責任人測試人員參與人研發(fā)總監(jiān)、研發(fā)人員、項目經(jīng)理、測試主管5.5 測試實施階段5.5.1 測試準入檢查過程要點詳細描述啟動條件測試實施準備工作完成工作內(nèi)容l 測試主管根據(jù)本項目的特點，事先確定測試準入標準中哪些條目可以進行裁剪，并與項目經(jīng)理及研發(fā)人員商討確認l 準入標準中“計劃準入標準”是指編制測試計劃、測試大綱、測試用例設計時就需要具備的前提條件，應提前進行檢查；“執(zhí)行準入標準”是指在執(zhí)行測試之前需要進行的檢查。以上兩類檢查應分兩次進行l(wèi) 測試主管和測試人員根據(jù)測試準入標準，逐項進行檢查，并填寫測試準入檢查表l 對于不滿足條件的檢查項

17、，要求相關方面進行解決，解決后重新進行檢查l 必須要通過的檢查項，而沒檢查通過的，視為準入檢查不通過，不能進入下一階段工作結束條件測試準入檢查通過輸出文件測試準入檢查表責任人測試主管參與人測試人員、項目經(jīng)理、研發(fā)人員5.5.2 執(zhí)行測試用例過程要點詳細描述啟動條件測試執(zhí)行階段準入檢查通過工作內(nèi)容l 測試人員根據(jù)計劃，執(zhí)行相應的測試用例，并做好測試記錄l 測試人員進行缺陷登記，并跟蹤解決情況，及時復測，關閉缺陷l 測試主管跟蹤測試用例執(zhí)行情況，了解影響測試用例執(zhí)行的因素，及時跟進有關的協(xié)調(diào)、報告測試狀態(tài)l 測試主管根據(jù)項目的情況，選擇有關的報告形式，將測試進展情況及時通報給有關各方結束條件測試用

18、例執(zhí)行完成責任人測試人員、測試主管參與人研發(fā)人員、項目經(jīng)理5.5.3 回歸測試在每輪測試結束之后，當研發(fā)人員解決完相關問題，重新提交，進行回歸測試。過程要點詳細描述啟動條件在每輪測試中，按現(xiàn)有的測試用例沒有新的缺陷被發(fā)現(xiàn)，測試報告中全部的活動缺陷都被解決工作內(nèi)容測試組將按照測試計劃中對于回歸測試的策略對產(chǎn)品進行回歸測試，回歸測試的用例屬于測試用例的一部分或者是全部測試用例，但不能超出原先預定的測試用例的范圍結束條件回歸測試所運行的用例全部通過責任人測試人員參與人研發(fā)人員、項目經(jīng)理5.5.4 缺陷管理過程要點詳細描述啟動條件測試用例開始執(zhí)行工作內(nèi)容l 測試人員在測試過程中，記錄被測產(chǎn)品缺陷，跟蹤

19、缺陷的分析、解決過程l 研發(fā)人員及時分析處理缺陷，并按要求記錄缺陷的分析處理信息，更新缺陷狀態(tài)，填制缺陷起源；對需要其它人員參與分析處理的時候，需及時將缺陷分配給下一環(huán)節(jié)人員l 測試人員對待驗證的缺陷需及時進行復測，測試通過后關閉缺陷結束條件測試用例執(zhí)行完成，并且缺陷跟蹤完成責任人測試人員、研發(fā)人員、測試主管參與人項目經(jīng)理5.6 測試收尾階段測試實施階段結束或即將結束時，測試小組可以開始著手準備進行總結報告及收尾工作。5.6.1 編制測試報告在測試實施完成之后，測試主管或測試人員需根據(jù)實施測試情況，編制測試報告。過程要點詳細描述啟動條件測試小組完成了所有的測試實施工作或測試時間已結束工作內(nèi)容測

20、試主管或測試人員根據(jù)測試的結果，按照測試報告的文檔模板編寫測試報告，測試報告必須包含以下重要內(nèi)容：l 測試用例執(zhí)行情況分析 測試階段用例執(zhí)行的數(shù)量、輪次、通過率等l 測試過程中已發(fā)現(xiàn)缺陷分析分析缺陷的數(shù)量、分布、起源等l 未執(zhí)行用例的風險分析分析未執(zhí)行的用例對系統(tǒng)形成的風險l 未關閉缺陷的風險分析分析未關閉的缺陷對系統(tǒng)形成的風險l 測試結論評價測試大綱中定義的測試完成標準是否達到，被測系統(tǒng)的質(zhì)量評價，存在的風險，以及有關建議結束條件測試報告評審通過，發(fā)送給相關人員輸出文件測試報告、測試報告評審記錄責任人測試主管、測試人員參與人研發(fā)總監(jiān)、研發(fā)人員、項目經(jīng)理5.6.2 測試工作過程改進測試過程改進

21、在測試實施階段工作全部結束以后進行。它的目的是評估本次測試工作，總結經(jīng)驗，使下一次的工作做得更好。本項工作不是一個必須的過程，各項目可根據(jù)情況采用。 過程要點詳細描述啟動條件測試實施階段結束工作內(nèi)容l 測試主管召集測試參與人員，討論本次測試過程得與失，總結經(jīng)驗，提出改進方法和意見l 編寫測試工作過程改進報告結束條件測試工作過程改進報告編制完成輸出文件測試工作改進報告責任人測試主管參與人測試人員5.6.3 測試成果提交 測試資產(chǎn)提交在測試實施階段工作結束以后進行，對測試過程中涉及到各種標準文檔進行歸類，存檔。過程要點詳細描述啟動條件測試實施階段結束工作內(nèi)容提交本次測試過程產(chǎn)生的，能為其它項目或本

22、項目后續(xù)測試提供借鑒的，測試用例等結束條件全部成果歸檔完畢輸出文件測試成果清單例外如果成果內(nèi)容不多，結構清楚，則可以省略測試成果清單責任人測試主管參與人測試人員5.7 軟件測試執(zhí)行模式目前采用3+1模式。即三輪系統(tǒng)測試加一輪回歸測試。6 缺陷管理機制缺陷通過測試管理工具TD進行管理測試團隊 研發(fā)團隊提交缺陷缺陷分析缺陷修復復測缺陷是否修復關閉缺陷測試人員提交缺陷到TD，提交缺陷狀態(tài)為open，并制定嚴重級別研發(fā)部門對測試人員提出的缺陷進行分析，確定是否對缺陷進行修改修改后將缺陷置為fixed，不進行修復或不是缺陷的問題應當修改缺陷狀態(tài)。測試人員在新一輪測試時復測研發(fā)修復的缺陷測試過程中發(fā)現(xiàn)修復

23、的缺陷仍然存在問題，缺陷狀態(tài)置為reopen，重新提交至研發(fā)部門。測試驗證后不出現(xiàn)問題的缺陷，即可關閉。缺陷的嚴重級別以及如何分類嚴重級別描述5-Urgent阻礙流程、系統(tǒng)崩潰導致重大任務不能正常進行的缺陷，例如：1、由于程序所引起的死機，非法退出。2、死循環(huán)4-High1、數(shù)據(jù)庫發(fā)生死鎖2、錯誤操作導致的程序中斷3、嚴重的計算錯誤4、與數(shù)據(jù)庫連接錯誤5、數(shù)據(jù)通訊錯誤等3-Medium缺陷導致失去系統(tǒng)主要功能，基本功能不能完整使用。例如：1、功能不符2、程序接口錯誤3、數(shù)據(jù)流錯誤4、輕微數(shù)據(jù)計算錯誤等2-Low操作性錯誤、錯誤結果、遺漏功能等影響系統(tǒng)要求或基本功能的實現(xiàn)。例如：1、界面錯誤2、

24、打印內(nèi)容、格式錯誤3、簡單的輸入限制未放在前臺進行控制4、刪除操作未給出提示5、數(shù)據(jù)輸入沒有邊界值限定或不合理6、錯別字等1-suggest建議，不影響使用的瑕疵或更好的實現(xiàn)等。7 新產(chǎn)品測試流程7.1 新產(chǎn)品測試輸入輸出測試步驟輸入輸出測試準備需求分析階段產(chǎn)品需求分析文檔評審結果軟件開發(fā)設計階段概要設計階段詳細設計階段評審結果測試方案和測試計劃軟件測試設計階段概要設計詳細設計測試方案和測試計劃測試案例測試環(huán)境準備概要設計詳細設計測試方案和測試計劃測試環(huán)境清單測試環(huán)境準備完畢測試執(zhí)行冒煙測試測試項傳遞報告冒煙測試結果系統(tǒng)測試和回歸階段測試方案和測試計劃測試案例測試項傳遞報告測試日志輪次總結測試報告測試分析和維護軟件測試總結系統(tǒng)測試總結報告軟件評估系統(tǒng)測試總結報告評估結果軟件測試維護測試案例的修改7.2 新產(chǎn)品測試流程圖需求調(diào)研階段需求規(guī)格說明書概要設計詳細設計測試方案和測試計劃測試案例編寫評審結果評審結果單元測試和集成測試測試結果提交測試通過冒煙測試和送測清單系統(tǒng)測試和回歸測試測試是否通過軟件測試總結軟件評估滿足需求產(chǎn)品發(fā)布測試案例維護走新增或修改需求流