測試流程及規(guī)范

1、1目的側(cè)重測試工作流程及規(guī)范的控制，明確產(chǎn)品研發(fā)的各階段測試組應(yīng)完成的工 作。測試技術(shù)和策略等問題不在本文檔描述范圍內(nèi)。本規(guī)范作為所有測試組成員工作前必須掌握的工作規(guī)范，也供給其它部門其它組查閱參考，以便于組間的協(xié)調(diào)溝通，更好的合作完成產(chǎn)品的研發(fā)工作。2概念與術(shù)語在整個產(chǎn)品的研發(fā)過程中，測試類型按照先后順序主要分為：單元測試、集 成測試、系統(tǒng)測試及產(chǎn)品確認(rèn)，整個過程如下面的W模型所示：圖1有關(guān)的測試類型的概念如下:1）單元測試：驗證產(chǎn)品中的模塊，測試依據(jù)主要為模塊詳細(xì)設(shè)計或模塊的 需求規(guī)格。能使問題及早暴露，也便于問題的定位解決，單元測試屬于早期測 試，因而錯誤發(fā)現(xiàn)后能明確知道是某一單元產(chǎn)生的

2、，單元測試允許多個被測單 元的測試工作同時開展。根據(jù)公司研發(fā)流程的實際情況，此測試也可由設(shè)計研 發(fā)人員執(zhí)行。2）集成測試是驗證模塊間接口及匹配關(guān)系，測試依據(jù)主要為概要設(shè)計。一 般采用自底向上或自頂向下的模塊集成方法，逐步集成。在此環(huán)節(jié)中測試組還 負(fù)責(zé)驗收研發(fā)人員提供的轉(zhuǎn)測試的材料，如果材料不完備，測試組可以拒絕接 收。3）系統(tǒng)測試是對系統(tǒng)的一系列的整體、有效性、可靠性的測試，測試依據(jù) 主要為設(shè)計規(guī)格及產(chǎn)品需求規(guī)格。目的是確認(rèn)產(chǎn)品與設(shè)計規(guī)格、需求、行業(yè)標(biāo) 準(zhǔn)及公司標(biāo)準(zhǔn)的符合性，同時還要確認(rèn)性能和系統(tǒng)的穩(wěn)定性，與之前的集成測 試應(yīng)遵循“相同的被測對象不要做兩遍相同的測試”的基本原則。4）除單元測試

3、、集成測試和系統(tǒng)測試之外，還應(yīng)有“產(chǎn)品確認(rèn)”環(huán)節(jié)，即 在客戶環(huán)境中或模擬客戶環(huán)境測試與驗證產(chǎn)品，在有限的試用客戶中或模擬客 戶環(huán)境中發(fā)現(xiàn)產(chǎn)品問題并加以妥善處理，保證產(chǎn)品質(zhì)量，提高客戶滿意度。確 認(rèn)與實驗室內(nèi)部測試的區(qū)別在于：實驗室內(nèi)部測試要盡可能多做，多發(fā)現(xiàn)問題; 確認(rèn)要在達到質(zhì)量目標(biāo)的情況下盡可能少做；兩者要在質(zhì)量和成本之間權(quán)衡、 綜合考慮。5）TD:全稱Mercury TestDi rector, 一種測試管理工具。6）黑盒測試：黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否 都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮 程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序

4、接口進行測試，它只檢查程序功能 是否按照需求規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸 出信息。黑盒測試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件 界面和軟件功能進行測試。黑盒測試是以用戶的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù) 的對應(yīng)關(guān)系出發(fā)進行測試的。3職責(zé)角色名稱相關(guān)主要責(zé)任測試主管組建測試小組協(xié)調(diào)測試小組內(nèi)外部的溝通組織編制測試大綱（含測試用例）和計劃組織測試準(zhǔn)入檢查測試過程中的進度控制、風(fēng)險管理測試過程報告編寫測試報告召集測試評審測試人員識別測試需求參與編制測試大綱（含測試用例）和計劃協(xié)助測試準(zhǔn)入檢查執(zhí)行測試用例，測試結(jié)果記錄測試缺陷記錄與跟蹤協(xié)助測試評審支持人員為測試工

5、作提供技術(shù)支持，比如環(huán)境安裝、版本布署、測試工 具支持等備注：該角色可選，可根據(jù)項目實際情況設(shè)置，一般情況下由研發(fā)人員擔(dān)任?！咀ⅰ浚寒?dāng)某個項目僅有一個測試人員時，該測試人員同時也為該項目內(nèi)的測試 主管，需要擔(dān)負(fù)起測試主管的職責(zé)。4測試類型和測試方法4.1測試類型測試工作通常分為4個類型，功能測試、聯(lián)合測試、性能測試及穩(wěn)定性測試。測試類型測試意義功能測試確保功能符合需求定義確保所有功能可以正常完成工作聯(lián)合測試一個新產(chǎn)品或一個產(chǎn)品的新版本發(fā)布時，要確保與之相配合的 產(chǎn)品可以正常配合使用性能測試在產(chǎn)品有性能要求的部分，進行性能測試和調(diào)優(yōu)，確保產(chǎn)品性 能符合需求穩(wěn)定性測試模擬用戶真正的使用情況，設(shè)計相

6、應(yīng)的測試用例，確保產(chǎn)品可 以穩(wěn)定可靠的長時間運行4.2測試方法測試類型測試方法功能測試/以手工黑盒測試為主，手工執(zhí)行功能測試用例。聯(lián)合測試正規(guī)測試和隨機測試相結(jié)合：根據(jù)需求文檔撰寫測試方案及測試用例來進行常規(guī)測試，考慮 到測試用例有可能寫的不全面，所以在進行常規(guī)測試過程中， 可以加入隨機測試。同時，對預(yù)測試出來的缺陷，將其執(zhí)行過 程寫成一個測試用例，添加到測試用例集合中，以完善測試用 例；采用測試工具TD進行測試用例的管理和缺陷記錄、跟蹤。性能測試性能測試要求滿足兩種情況：1）產(chǎn)品在特定工況下可以達到的最高性能（例如：測試時 將日志等影響性能的選項關(guān)閉）；2）模擬用戶真正的使用環(huán)境（如：日志功

7、能打開，在一定的 用戶數(shù)量的情況下），產(chǎn)品真實可以達到的性能；穩(wěn)定性測穩(wěn)定性測試要求模擬用戶真正的使用情況，設(shè)計相應(yīng)的測試用試?yán)?，確保產(chǎn)品可以穩(wěn)定可靠的長時間運行【注】：黑盒測試過程的參考準(zhǔn)則：（1）必須采用邊界值分析法;（2）必要時采用等價類劃分法補充測試用例；(3) 采用錯誤判斷法，追加測試用例;(4) 對照程序邏輯，檢查已設(shè)計出的測試用例的邏輯覆蓋程度。如果 沒有達到要求的覆蓋標(biāo)準(zhǔn)，應(yīng)當(dāng)補充更多的測試用例；(5) 測試數(shù)據(jù)應(yīng)準(zhǔn)備充分，應(yīng)采用有效數(shù)據(jù)、無效數(shù)據(jù)、邊界數(shù)據(jù)分別測試驗證；5工作流程、模式及規(guī)范5.1工作流程測試工作可劃分為三個階段，每個階段由不同的活動組成。5.2測試提交文件及

8、裁剪說明階段提交文件必須 提 交模板定義裁剪條件說明測試需求測試需求分析報告否項目組自定義無特殊需求，可省略測試計劃測試大綱是項目組自定義各項目組根據(jù)測試任務(wù)的規(guī)模可自定義模板測試計劃否項目組自定義如果測試大綱或設(shè)計開發(fā)計劃中已包括了測試計劃的內(nèi)容，則本文檔可省略測試大綱計劃評審記錄否公司模板各項目酌情選用測試用例是公司模板采用公司統(tǒng)一測試用例模板測試用例評審記錄否公司模板各項目酌情選用測試實測試準(zhǔn)入檢查表否公司模板各項目酌情選用施測試記錄是項目組自定義各項目組根據(jù)測試任務(wù)的規(guī)模可自定義模板測試收測試報告是公司模板采用公司統(tǒng)一測試報告模板尾測試報告評審記錄否公司模板各項目酌情選用測試工作改進報

9、告否項目組自定義各項目酌情選用測試成果提交否項目組自定義各項目酌情選用5.3評審點評審點定義參照設(shè)計開發(fā)控制程序。5.4敏捷測試模式5. 4.1 敏捷測試概念敏捷測試即是不斷修正質(zhì)量指標(biāo)，正確建立測試罠略，確認(rèn)客戶的有效需 求得以圓滿實現(xiàn)和確保整個生產(chǎn)的過程安全的、及時的發(fā)布最終產(chǎn)品。5. 4. 2敏捷增量測試方法測試是敏捷開發(fā)過程重要的環(huán)節(jié)，自始自終測試貫穿于每個迭代。整個產(chǎn) 品的敏捷開發(fā)生命周期可以分為4個階段，即初始階段，項目的建設(shè)階段，產(chǎn) 品發(fā)布階段和產(chǎn)品的維護階段，在關(guān)鍵的項目建設(shè)階段中，測試被分成兩個部 分，驗證測試和系統(tǒng)測試。驗證測試：靜態(tài)測試和關(guān)鍵的功能測試。系統(tǒng)測試：功能測試

10、、聯(lián)合測試、性能測試、穩(wěn)定性測試。5. 4.3 敏捷測試流程敏捷測試流程依據(jù)業(yè)務(wù)場景制定測試策略。在每次敏捷測試的過程中包括 驗證測試和聯(lián)合測試。并且不斷的進行迭代測試。在系統(tǒng)的所有業(yè)務(wù)場景都經(jīng) 過敏捷測試過后，進入系統(tǒng)測試階段。進行所有業(yè)務(wù)場景的功能測試、聯(lián)合測 試、性能測試、穩(wěn)定性測試。根據(jù)業(yè)務(wù)場景制定測試策略流程圖敏捷測試流程圖根據(jù)缺陷性質(zhì)來判斷更新提交測試的依據(jù)：1）嚴(yán)重級別為Urgent和High的修改后立即更新，要保證更新后不能影響其他功能測試。2）功能級別為Medium以下的可以等待下一次提交敏捷測試的時候更新。5.5傳統(tǒng)瀑布模式5. 5. 1 測試需求分析過程要點詳細(xì)說明啟動條

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

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

13、少應(yīng)包括以下關(guān)鍵內(nèi)容：主要任務(wù)每項任務(wù)的時間計劃、前置條件及資源主要里程碑關(guān)鍵任務(wù)及完成時間點在項目研發(fā)過程中，要適時的對測試計劃進行跟蹤，以評估此計劃 的完整性、可行性，在項目結(jié)束時還要最后評估一下測試計劃的質(zhì) 量結(jié)束標(biāo)準(zhǔn)測試計劃評審?fù)ㄟ^或得到相關(guān)各方的審批輸出文件測試計劃、測試計劃評審記錄例外對于多個系統(tǒng)參與的同一個測試任務(wù)，可由主項目組或牽頭方統(tǒng)一 編制測試大綱和計劃，不用每個系統(tǒng)單獨編制和出具測試計劃可以在測試大綱中直接詳細(xì)列明，而不用單獨編制責(zé)任人測試主管參與人研發(fā)總監(jiān)、項目經(jīng)理、測試人員5. 5.4 編制測試大綱、設(shè)計測試用例在技術(shù)規(guī)格書評審?fù)ㄟ^以后，測試小組需要針對項目的測試范圍

14、編制測試大綱、設(shè)計測試用例。在實際測試過程中，測試用例可根據(jù)實際需要進行更新和調(diào)整。在測試用例的設(shè)計過程中，具體的任務(wù)和責(zé)任人如下：過程要點詳細(xì)說明啟動條本次測試范圍、業(yè)務(wù)需求已經(jīng)明確件需求規(guī)格說明是、詳細(xì)設(shè)計說明書已通過評審工作內(nèi)準(zhǔn)備本次測試的測試用例容測試用例在該產(chǎn)品的測試用例庫中進行選擇，如有需要，可以進行 增加；每個測試用例須包括用例編號、測試槪述、測試數(shù)據(jù)、操作步驟說 明、預(yù)期結(jié)果等要素；測試用例須覆蓋所有的測試需求和功能點；采用統(tǒng)一的模板進行用例設(shè)計。結(jié)束標(biāo)準(zhǔn)測試用例覆蓋所有的待測試需求或功能點，并且評審?fù)ㄟ^輸出文件測試大綱、測試用例、測試大綱評審記錄責(zé)任人測試人員參與人研發(fā)總監(jiān)、

15、研發(fā)人員、項目經(jīng)理、測試主管5.6測試實施階段5. 6.1 測試準(zhǔn)入檢查過程要點詳細(xì)描述啟動條件測試實施準(zhǔn)備工作完成工作內(nèi)容測試主管根據(jù)本項目的特點，事先確定測試準(zhǔn)入標(biāo)準(zhǔn)中哪些條目可 以進行裁剪，并與項目經(jīng)理及研發(fā)人員商討確認(rèn)準(zhǔn)入標(biāo)準(zhǔn)中“計劃準(zhǔn)入標(biāo)準(zhǔn)”是指編制測試計劃、測試大綱、測試 用例設(shè)計時就需要具備的前提條件，應(yīng)提前進行檢查；“執(zhí)行準(zhǔn)入 標(biāo)準(zhǔn)”是指在執(zhí)行測試之前需要進行的檢查。以上兩類檢查應(yīng)分兩 次進行測試主管和測試人員根據(jù)測試準(zhǔn)入標(biāo)準(zhǔn)，逐項進行檢查，并填寫測 試準(zhǔn)入檢查表對于不滿足條件的檢查項，要求相關(guān)方面進行解決，解決后重新進行檢查必須要通過的檢查項，而沒檢查通過的，視為準(zhǔn)入檢查不通

16、過，不 能進入下一階段工作結(jié)束條件測試準(zhǔn)入檢查通過輸出文件測試準(zhǔn)入檢查表責(zé)任人測試主管參與人測試人員、項目經(jīng)理、研發(fā)人員5. 6.2執(zhí)行測試用例過程要點詳細(xì)描述啟動條件測試執(zhí)行階段準(zhǔn)入檢查通過工作內(nèi)容測試人員根據(jù)計劃，執(zhí)行相應(yīng)的測試用例，并做好測試記錄 測試人員進行缺陷登記，并跟蹤解決情況，及時復(fù)測，關(guān)閉缺陷 測試主管跟蹤測試用例執(zhí)行情況，了解影響測試用例執(zhí)行的因素，及時跟進有關(guān)的協(xié)調(diào)、報告測試狀態(tài)測試主管根據(jù)項目的情況，選擇有關(guān)的報告形式，將測試進展情況及時通報給有關(guān)各方結(jié)束條件測試用例執(zhí)行完成責(zé)任人測試人員、測試主管參與人研發(fā)人員、項目經(jīng)理5. 6.3 回歸測試在每輪測試結(jié)束之后，當(dāng)研發(fā)人

17、員解決完相關(guān)問題，重新提交，進行回歸測試。過程要點詳細(xì)描述啟動條件在每輪測試中，按現(xiàn)有的測試用例沒有新的缺陷被發(fā)現(xiàn)，測試報告中 全部的活動缺陷都被解決工作內(nèi)容測試組將按照測試計劃中對于回歸測試的策略對產(chǎn)品進行回歸測試， 回歸測試的用例屬于測試用例的一部分或者是全部測試用例，但不能 超出原先預(yù)定的測試用例的范圍結(jié)束條件回歸測試所運行的用例全部通過責(zé)任人測試人員參與人研發(fā)人員、項目經(jīng)理5. 6.4缺陷管理過程要點詳細(xì)描述啟動條件測試用例開始執(zhí)行工作內(nèi)容測試人員在測試過程中，記錄被測產(chǎn)品缺陷，跟蹤缺陷的分析、解 決過程研發(fā)人員及時分析處理缺陷，并按要求記錄缺陷的分析處理信息， 更新缺陷狀態(tài)，填制缺陷

18、起源；對需要其它人員參與分析處理的時 候，需及時將缺陷分配給下一環(huán)節(jié)人員測試人員對待驗證的缺陷需及時進行復(fù)測，測試通過后關(guān)閉缺陷結(jié)束條件測試用例執(zhí)行完成，并且缺陷跟蹤完成責(zé)任人測試人員、研發(fā)人員、測試主管參與人項目經(jīng)理5.7測試收尾階段測試實施階段結(jié)束或即將結(jié)束時，測試小組可以開始著手準(zhǔn)備進行總結(jié)報告及收尾工作。5. 7. 1 編制測試報告在測試實施完成之后，測試主管或測試人員需根據(jù)實施測試情況，編制測試 報告。過程要點詳細(xì)描述啟動條件測試小組完成了所有的測試實施工作或測試時間已結(jié)束工作內(nèi)容測試主管或測試人員根據(jù)測試的結(jié)果，按照測試報告的文檔模板編寫 測試報告，測試報告必須包含以下重要內(nèi)容：測

19、試用例執(zhí)行情況分析一一測試階段用例執(zhí)行的數(shù)量、輪次、通 過率等測試過程中已發(fā)現(xiàn)缺陷分析一一分析缺陷的數(shù)量、分布、起源等 未執(zhí)行用例的風(fēng)臉分析一一分析未執(zhí)行的用例對系統(tǒng)形成的風(fēng)臉 未關(guān)閉缺陷的風(fēng)臉分析一一分析未關(guān)閉的缺陷對系統(tǒng)形成的風(fēng)臉 測試結(jié)論評價測試大綱中定義的測試完成標(biāo)準(zhǔn)是否達到，被測系統(tǒng)的質(zhì)量評價，存在的風(fēng)臉，以及有關(guān)建議結(jié)束條測試報告評審?fù)ㄟ^，發(fā)送給相關(guān)人員件輸出文測試報告、測試報告評審記錄件責(zé)任人測試主管、測試人員參與人研發(fā)總監(jiān)、研發(fā)人員、項目經(jīng)理5. 7.2 測試工作過程改進測試過程改進在測試實施階段工作全部結(jié)束以后進行。它的目的是評估本次 測試工作，總結(jié)經(jīng)驗，使下一次的工作做得更

20、好。本項工作不是一個必須的過 程，各項目可根據(jù)情況采用。過程要點詳細(xì)描述啟動條件測試實施階段結(jié)束工作內(nèi)容測試主管召集測試參與人員，討論本次測試過程得與失，總結(jié)經(jīng)驗，提出改進方法和意見編寫測試工作過程改進報告結(jié)束條件測試工作過程改進報告編制完成輸出文件測試工作改進報告責(zé)任人測試主管參與人測試人員5. 7.3 測試成果提交測試資產(chǎn)提交在測試實施階段工作結(jié)束以后進行，對測試過程中涉及到各種標(biāo)準(zhǔn)文檔進行歸類，存檔。過程要詳細(xì)描述點啟動條測試實施階段結(jié)束件工作內(nèi)提交本次測試過程產(chǎn)生的，能為其它項目或本項目后續(xù)測試提供借鑒容的，測試用例等結(jié)束條全部成果歸檔完畢件輸出文測試成果清單件例外如果成果內(nèi)容不多，結(jié)

21、構(gòu)清楚，則可以省略測試成果清單責(zé)任人測試主管參與人測試人員5.8軟件測試執(zhí)行模式目前采用3+1模式。即三輪系統(tǒng)測試加一輪回歸測試。6缺陷管理機制缺陷通過測試管理工具TD進行管理測試團隊研發(fā)團隊測試人員提交缺研發(fā)部門對測測試人員在新51人:工匕-T山 J缺陷的嚴(yán)重級別以及如何分類嚴(yán)重級別描述5-Urgent阻礙流程、系統(tǒng)崩潰導(dǎo)致重大任務(wù)不能正常進行的缺陷，例如：1、由于程序所引起的死機，非法退出。2、死循環(huán)4-High1、數(shù)據(jù)庫發(fā)生死鎖2、錯誤操作導(dǎo)致的程序中斷3、嚴(yán)重的計算錯誤4、與數(shù)據(jù)庫連接錯誤5、數(shù)據(jù)通訊錯誤等3-Med i urn缺陷導(dǎo)致失去系統(tǒng)主要功能，基本功能不能完整使用。例如：1、

22、功能不符2、程序接口錯誤3、數(shù)據(jù)流錯誤4、輕微數(shù)據(jù)計算錯誤等2Low操作性錯誤、錯誤結(jié)果、遺漏功能等影響系統(tǒng)要求或基本功能的實現(xiàn)。例如：1、界面錯誤2、打印內(nèi)容、格式錯誤3、簡單的輸入限制未放在前臺進行控制4、刪除操作未給出提示5、數(shù)據(jù)輸入沒有邊界值限定或不合理6、錯別字等1一suggest建議，不影響使用的瑕疵或更好的實現(xiàn)等。7新產(chǎn)品測試流程7.1新產(chǎn)品測試輸入輸出測試步驟輸入輸出J需求分析階段產(chǎn)品需求分析文檔評審結(jié)果軟件開發(fā)設(shè)計階概要設(shè)計階段評審結(jié)果段詳細(xì)設(shè)計階段測試方案和測試計劃軟件測試設(shè)計階段概要設(shè)計詳細(xì)設(shè)計測試方案和測試計劃測試案例測試環(huán)境準(zhǔn)備概要設(shè)計詳細(xì)設(shè)計測試方案和測試計劃測試環(huán)境清單測