編寫目的（此文非原創，只是忘了當初是誰寫的了~）

主要明確測試團隊在整個項目各階段中的職責，并對測試團隊的組織架構、職能劃分進行說明，對日后各部門間配合及組內工作的正常開展起到規范的指導作用。（注：該文檔在測試流程及規范部分主要針對測試團隊來撰寫，其他團隊的職責僅略微描述。）

各角色職責

? 測試經理

1）負責團隊內部管理工作，各部門間協調工作；協助團隊內部解決測試技術問題；

2）根據每次即將上線的版本內容制定測試范圍、分配測試任務；

3）制定測試方案并推進實施加以改進，改善產品體驗；

4）制定質量管理體系標準，嚴格保證并管控產品質量；

5）打造高效的測試團隊，培養人才梯隊，制訂團隊發展計劃與培訓機制，不斷學習新技術；

6）優秀的執行力，面對挑戰，能快速決策分析，調動資源集中突破；

7）負責測試人員招聘、組織架構劃分、人員的績效考核等。

? 測試接口人

1）根據測試經理指派的任務，根據各組別職能協調小組內成員共同完成測試任務；

2）編寫測試用例、測試計劃、測試方案、測試報告并能指導測試工程師完成工作；

3）與產品、研發、運維團隊進行有效的溝通，并負責組織測試用例評審工作；

4）驗收各階段測試工作，保質、保量、按時完成小組內的測試任務；

5）負責小組內的團隊建設，探索并提升組內所需新技術，提高組內技術實力等。

測試開發工程師

? 根據項目組需要，能夠獨立完成測試框架開發工作及所需工具；

? 熟悉mock測試工具，完成mock測試開發；

? 精通web端及客戶端APP的自動化測試工具，如selenium、monkeyrunner等，能夠熟練使用其做自動化測試；

? 掌握持續交付理念、快速接受持續交付中自動化測試部分；

? 掌握全業務流程，可以分析并提取出業務框架并實施開發；

? 指導其他自動化測試人員，并通過組內培訓分享自動化測試理念及方法，提升組內技術水平等。

性能自動化測試工程師

? 有扎實的功能測試基礎，能夠根據獨立編寫性能測試方案及性能測試報告；

? 熟練掌握LoadRunner、Jmeter等工具的使用及原理；

? 與客戶一起制定并分析性能指標、編寫性能測試方案、定位性能瓶頸并找出解決方案；

? 掌握linux命令、Sqlserver、Qracle、Mysql等數據庫

? 熟悉Apache、windows及linux平臺；

? 編寫性能測試腳本并調試。

功能測試工程師

? 服從上級安排，并通過指導能夠勝任測試任務；

? 參與需求評審，并對產品需求提出各方面建議及意見；

? 按照需求文檔設計測試用例、編寫測試用例并嚴格按照測試計劃及用例執行；

? 參與用例內部評審及外部評審；

? 按規定格式提交有效的軟件bug，并對軟件bug周期進行跟蹤處理。

? 測試流程及規范

? 測試流程

1)計劃與設計階段

2)實施階段

3)測試總結階段

? 計劃與設計階段

? 項目立項

? 項目立項主要是闡述項目背景、內容及意義，確定項目相關負責人、評估項目預算等；

? 測試參與人員：測試經理；

? 其他部門參與人員：研發總監、產品總監、產品經理等與項目相關的領導、高層。

? 需求評審

? 產品部門組織召開需求評審會議，以產品需求文檔、原型設計、UI為輸出條件；

? 會議內容：測試團隊對需求文檔存在異議/需求不完整/不清晰的地方提出問題，相關人員進行解答；

? 會議結束的標準：所有人員達成一致，對需求無異議，需求確定；

? 測試參與人員：測試經理、模塊測試負責人；

? 其他部門參與人員：研發總監、模塊研發負責人、產品總監、產品經理、UI設計等；

注：

? 需求評審會議召開之前，產品需將產品需求文檔、原型及UI設計圖提前發給各個團隊，以便測試團隊預留出熟悉及理解需求的時間；

? 測試團隊參與人員由測試經理指定，包含測試模塊負責人、測試設計人員、質量保證人員等。

? 測試計劃

? 制定依據：需求文檔、原型設計、UI設計、研發計劃、概要設計及詳細設計文檔；

? 內容：包含測試范圍、測試環境、測試方法及策略、資源分配及進度安排、風險預估等；

? 評審：研發、測試人員需對測試計劃初稿進行評審，確認測試的側重點。

? 評審目的：確保測試計劃的正確性、全面性、可行性。評審后完善測試計劃，并形成終稿；

? 測試參與人員：測試全體參加。

? 用例設計

? 設計依據：需求文檔、原型設計、UI設計、研發概要設計及詳細設計文檔；

? 測試用例設計

1）需求測試分析、分解需求功能模塊、提取測試點后，根據以上文檔采用邊界值、等價類劃分等方法設計測試用例 ；

2）包含測試用例的要素：

首頁簽：測試用例目錄及鏈接、用例修訂日期及修正模塊等信息說明；上半部分：項目名稱、版本號、編寫人、編寫時間、功能模塊要點、聯調測試要點（涉及哪些客戶端的交互聯調測試）；下半部分：用例ID、優先級、功能模塊、用例名稱、前置條件、輸入數據、操作步驟、預期結果、實際結果、備注（關注點、bug號等信息）；

? 測試參與人員：模塊負責人、用例設計人員及用例執行人員。

? 用例評審

? 用例評審及標準：確保測試用例的全面性、需求覆蓋率達到100%；

? 測試參與人員：測試經理、模塊負責人、用例設計人員及用例執行人員。

? 測試實施階段

? 測試準備

? 測試環境的準備：硬件環境、軟件環境、網絡環境、歷史數據環境；可靠且可控的測試環境有利于bug重現、減少環境的變動對測試工作帶來的不利影響；

? 測試文檔準備：產品需求文檔、原型圖、UI設計圖、測試計劃、測試方案、測試用例；

? 測試數據準備：老數據與新數據的準備（數據遷移）、帶有歷史數據記錄的數據（與程序判斷有關）、與測試方法及策略有關的數據準備（安全測試、）；

? 測試人員準備：根據測試方法及策略分配測試人員，合理安排進度。

? 單元測試

? 研發在編寫代碼后需進行單元測試且達到一定的覆蓋率標準，才可交付給測試人員。

? 冒煙測試

? 單元測試后交付測試，測試人員進行冒煙測試，確保后續正式的測試工作可順利進展；

? 冒煙測試通過標準：實現所有主要功能，且無一級、二級bug，三級bug可根據產品迭代情況適當制定相應標準；

? 冒煙測試用例：確定主要模塊的主要功能，根據需求文檔提取測試用例功能點并編寫；

? 冒煙測試執行人員：模塊測試負責人員。

? 功能細則測試

? 業務功能細則測試：當冒煙測試通過后，進入正式功能測試；

? 功能測試通過標準：需求覆蓋度達到100%，且測試用例的粒度達到單個細小模塊的校驗，所有用例被嚴格執行且fix掉所有bug（或最終上線前產品、研發及測試評估優先級為三、四級bug是否全部fix）；

? 功能測試執行：模塊測試負責人員。

? 集成測試

? 集成測試是在單元測試基礎上，對多模塊組裝聯合起來的接口進行測試；

? 集成測試細則：考慮各模塊連接起來時，穿越接口的數據是否丟失、一個模塊的功能是否影響另外一個模塊的功能、子模塊組裝后是否滿足父功能等；

? 集成測試通過標準：所有集成測試用例被嚴格執行，且滿足集成測試接口上的需求；

? 集成測試執行人員：模塊測試負責人員。

? 系統測試

? 系統測試是在集成測試基礎上進行的測試，依賴于產品需求說明書中已經確定好的系統外設、硬件、網絡等組成因素；

? 系統測試分類：恢復性測試、安全性測試、壓力測試等；

? 系統測試通過標準：所有系統測試用例被嚴格執行，且滿足產品需求及設計說明書；

? 系統測試執行人員：模塊測試負責人員。

? 驗收測試

? 驗收測試是軟件正式上線前的最后一步測試；

? 驗收測試分類：正式測試、非正式測試（Alpha 測試）、Beta 測試；正式測試由測試人員與用戶共同組成小組或完全由用戶來組織驗收測試；非正式測試多數由最終用戶執行；Beta測試

? 驗收測試通過標準：產品最終需滿足需求設計說明書的內容及對硬件、軟件相關的規定；最終的體驗以及功能、性能等方面用戶可接受；無一級、二級bug（三級bug接受程度由用戶或產品方與我們共同評估）；

? 驗收測試執行人員：測試人員、研發人員、產品、最終用戶。

? 回歸測試

? 需注意：回歸測試貫穿于整個開發周期的各個階段；

? 修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。自動回歸測試將大幅降低系統測試、維護升級等階段的成本。回歸測試作為軟件生命周期的一個組成部分，在整個軟件測試過程中占有很大的工作量比重，軟件開發的各個階段都會進行多次回歸測試。在漸進和快速迭代開發中，新版本的連續發布使回歸測試進行的更加頻繁，而在極端編程方法中，更是要求每天都進行若干次回歸測試。因此，通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是非常有意義的；

? 回歸策略：用例庫維護、自動化腳本回歸、手工測試輔助回歸；

? 在組織回歸測試時需要注意兩點，首先是各測試階段發生的修改一定要在本測試階段內完成回歸，以免將錯誤遺留到下一測試階段。其次，回歸測試期間應對該軟件版本凍結，將回歸測試發現的問題集中修改，集中回歸；

? 回歸測試執行人員：測試全體

注意：以上事實流程僅限于有足夠的測試時間方可全方位實施，根據敏捷迭代的特性，在實施的各階段需因環境變化而制定臨時測試實施策略。具體詳見敏捷迭代過程中各階段的測試策略及計劃報告。

? 測試總結階段

? 測試報告

? 把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正軟件的存在的質量問題提供依據，同時為軟件驗收和交付打下基礎；

? 測試報告內容要素：測試范圍、測試方法、測試工具、測試環境、測試結果與缺陷統計與分析、測試結論與建議等；

? 每個測試階段或上線前用例及各環節執行完畢后都需要提供測試報告；

? 測試報告撰寫人：負責各階段的測試人

? 上線前review

? 上線前產品、研發、測試共同review上線前需求完成度、用例覆蓋度是否滿足本次上線的要求，以及存在哪些風險點；

? 上線前的標準是所有覆蓋需求的用例執行達到100%，且無嚴重等級的bug掛起；

? 上線前review執行人員：測試經理攜測試全體

? 測試歸檔

? 測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸類，存檔；

? 涉及的文檔：測試計劃、測試用例、測試階段性報告、測試總結報告；產品迭代需求說明、設計文檔等，最好歸類為一次版本上線的文件夾，日后有可追溯性；

? 測試歸檔執行人員：測試組長/負責人。

? 上線后總結

? 上線后測試組內需對上線成功或經過一段時間線上反饋的問題做出總結；

? 總結內容：對整個研發過程改進的建議、提高測試效率的方法、若出現問題需追溯出根本原因、測試過程出現問題的改進方法、對測試過程中好的一面予以肯定并繼續推行等；

? 上線后總結執行人員：測試組長攜全體測試人員。

? 缺陷跟蹤

? 測試過程中的缺陷跟蹤及處理

? Bug處理流程圖

? Bug嚴重等級定義

? 一級: 系統“掛起”或“崩潰”的錯誤，使得整個測試工作無法繼續進行，如：程序死機、死循環、非法退出、數據庫死鎖、程序無法登錄等；

? 二級: 軟件功能未按產品需求文檔規定的實現，導致功能報錯，其他模塊測試工作無法進行，如：功能不符、接口錯誤等；

? 三級: 一般性錯誤：如界面UI不符/錯誤、錯誤未給出彈出框提示等；

? 四級: 輕微bug，如：格式排版、個別文字錯誤等問題；

? 五級：對軟件的改進建議，如：需求說明中未明確但影響用戶體驗等；

? Bug優先級定義

? Priority 1—嚴重bug，需立即修復；

? Priority 2—比較嚴重的bug，根據模塊關聯性依次修復；

? Priority 3—一般性bug，可在優先級為1和2之后修復；

? Priority 4—輕微性bug，經討論后可決定是否在下一版修復；

? Priority 5—針對軟件改進建議可以修復或不修復，由產品最終決定；

注：Bug嚴重等級與Bug優先級一一對應，特殊情況可調整映射關系。

? Bug提交規范

Bug提交所含內容如下：

? Bug標題：環境-端名稱-模塊名稱-簡要概述Bug；

? 模塊路徑：首先選擇項目端名，其次選擇版本號，如圖：

? 指派給：輸入研發人員名字全拼或名字首字母，下拉框中會顯示出研發人員的名字；

? 抄送給：輸入抄送人員名字全拼或名字首字母，下拉框中會顯示出研發人員的名字，可按需要抄送給相關人；

? 嚴重程度：Bug嚴重等級定義；

? 優先級：Bug優先級定義；

? Bug類型：根據Bug定位原因，并選擇適當的類型，詳見bugfree類型；

? 如何發現：詳細闡述bug發現的階段；

? 操作系統：詳細描述操作系統；

? 終端設備：指定某個終端，方便問題重現，準確定位；

? 發現版本號：填寫詳細版本號；

? 運行環境：闡述bug發現的運行環境；

? 處理狀態：bug當前狀態；

? 機器配置：描述機器配置；

? 關鍵詞：方便搜索；

? Bug相關：相關聯的bug與case；

? 附件：可上傳bug截圖附件；

? 復現步驟：分為前置條件、復現步驟、預期結果、實際結果、備注（賬號密碼等相關信息）。

? 市場反饋的Bug跟蹤及處理

? Bug處理流程圖

詳見售后流程圖

? 軟件發布標準

軟件發布需滿足以下標準

? 完成發布計劃中所有的工作；

? 實現需求定義中所有功能特性；

? 完成所有的測試工作（按測試計劃嚴格執行）；

? 嚴重缺陷都已修復；

? Bug趨勢圖接近于零，新發現的缺陷；

? 出具完整且權威的測試報告

? 已達到驗收標準

軟件產品未經測試合格，有嚴重bug時，不允許發布。

? 爭議處理

若針對同一問題研發、測試團隊對結論有爭議，需項目組成員及產品共同討論，項目經理給出最終結果，并衡定是否上線。