編寫目的（此文非原創(chuàng)通惫，只是忘了當初是誰寫的了~）

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

各角色職責

? 測試經(jīng)理

1）負責團隊內部管理工作纪铺，各部門間協(xié)調工作相速；協(xié)助團隊內部解決測試技術問題；

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

3）制定測試方案并推進實施加以改進苫拍，改善產(chǎn)品體驗芜繁；

4）制定質量管理體系標準，嚴格保證并管控產(chǎn)品質量绒极；

5）打造高效的測試團隊骏令，培養(yǎng)人才梯隊，制訂團隊發(fā)展計劃與培訓機制垄提，不斷學習新技術榔袋；

6）優(yōu)秀的執(zhí)行力，面對挑戰(zhàn)铡俐，能快速決策分析凰兑，調動資源集中突破；

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

? 測試接口人

1）根據(jù)測試經(jīng)理指派的任務滩报，根據(jù)各組別職能協(xié)調小組內成員共同完成測試任務锅知；

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

3）與產(chǎn)品可训、研發(fā)昌妹、運維團隊進行有效的溝通捶枢，并負責組織測試用例評審工作；

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

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

測試開發(fā)工程師

? 根據(jù)項目組需要术瓮，能夠獨立完成測試框架開發(fā)工作及所需工具；

? 熟悉mock測試工具贰健，完成mock測試開發(fā)胞四；

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

? 掌握持續(xù)交付理念脊另、快速接受持續(xù)交付中自動化測試部分导狡；

? 掌握全業(yè)務流程，可以分析并提取出業(yè)務框架并實施開發(fā)偎痛；

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

性能自動化測試工程師

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

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

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

? 掌握linux命令、Sqlserver星压、Qracle践剂、Mysql等數(shù)據(jù)庫

? 熟悉Apache、windows及l(fā)inux平臺娜膘；

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

功能測試工程師

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

? 參與需求評審军洼，并對產(chǎn)品需求提出各方面建議及意見巩螃；

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

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

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

? 測試流程及規(guī)范

? 測試流程

1)計劃與設計階段

2)實施階段

3)測試總結階段

? 計劃與設計階段

? 項目立項

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

? 測試參與人員：測試經(jīng)理；

? 其他部門參與人員：研發(fā)總監(jiān)德谅、產(chǎn)品總監(jiān)爹橱、產(chǎn)品經(jīng)理等與項目相關的領導、高層窄做。

? 需求評審

? 產(chǎn)品部門組織召開需求評審會議愧驱，以產(chǎn)品需求文檔、原型設計椭盏、UI為輸出條件冯键；

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

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

? 測試參與人員：測試經(jīng)理、模塊測試負責人掩蛤；

? 其他部門參與人員：研發(fā)總監(jiān)枉昏、模塊研發(fā)負責人、產(chǎn)品總監(jiān)揍鸟、產(chǎn)品經(jīng)理兄裂、UI設計等；

注：

? 需求評審會議召開之前阳藻，產(chǎn)品需將產(chǎn)品需求文檔晰奖、原型及UI設計圖提前發(fā)給各個團隊，以便測試團隊預留出熟悉及理解需求的時間腥泥；

? 測試團隊參與人員由測試經(jīng)理指定匾南，包含測試模塊負責人、測試設計人員蛔外、質量保證人員等蛆楞。

? 測試計劃

? 制定依據(jù)：需求文檔溯乒、原型設計、UI設計豹爹、研發(fā)計劃裆悄、概要設計及詳細設計文檔；

? 內容：包含測試范圍臂聋、測試環(huán)境光稼、測試方法及策略、資源分配及進度安排逻住、風險預估等钟哥；

? 評審：研發(fā)、測試人員需對測試計劃初稿進行評審瞎访，確認測試的側重點腻贰。

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

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

? 用例設計

? 設計依據(jù)：需求文檔、原型設計拾徙、UI設計洲炊、研發(fā)概要設計及詳細設計文檔；

? 測試用例設計

1）需求測試分析尼啡、分解需求功能模塊暂衡、提取測試點后，根據(jù)以上文檔采用邊界值崖瞭、等價類劃分等方法設計測試用例 狂巢；

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

首頁簽：測試用例目錄及鏈接、用例修訂日期及修正模塊等信息說明书聚；上半部分：項目名稱唧领、版本號、編寫人雌续、編寫時間斩个、功能模塊要點、聯(lián)調測試要點（涉及哪些客戶端的交互聯(lián)調測試）西雀；下半部分：用例ID萨驶、優(yōu)先級、功能模塊艇肴、用例名稱腔呜、前置條件叁温、輸入數(shù)據(jù)、操作步驟核畴、預期結果膝但、實際結果、備注（關注點谤草、bug號等信息）跟束；

? 測試參與人員：模塊負責人、用例設計人員及用例執(zhí)行人員丑孩。

? 用例評審

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

? 測試參與人員：測試經(jīng)理温学、模塊負責人略贮、用例設計人員及用例執(zhí)行人員。

? 測試實施階段

? 測試準備

? 測試環(huán)境的準備：硬件環(huán)境仗岖、軟件環(huán)境逃延、網(wǎng)絡環(huán)境、歷史數(shù)據(jù)環(huán)境轧拄；可靠且可控的測試環(huán)境有利于bug重現(xiàn)揽祥、減少環(huán)境的變動對測試工作帶來的不利影響；

? 測試文檔準備：產(chǎn)品需求文檔檩电、原型圖拄丰、UI設計圖、測試計劃俐末、測試方案愈案、測試用例；

? 測試數(shù)據(jù)準備：老數(shù)據(jù)與新數(shù)據(jù)的準備（數(shù)據(jù)遷移）鹅搪、帶有歷史數(shù)據(jù)記錄的數(shù)據(jù)（與程序判斷有關）、與測試方法及策略有關的數(shù)據(jù)準備（安全測試遭铺、）丽柿；

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

? 單元測試

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

? 冒煙測試

? 單元測試后交付測試涂召，測試人員進行冒煙測試坠非，確保后續(xù)正式的測試工作可順利進展；

? 冒煙測試通過標準：實現(xiàn)所有主要功能果正，且無一級炎码、二級bug盟迟，三級bug可根據(jù)產(chǎn)品迭代情況適當制定相應標準；

? 冒煙測試用例：確定主要模塊的主要功能潦闲，根據(jù)需求文檔提取測試用例功能點并編寫攒菠；

? 冒煙測試執(zhí)行人員：模塊測試負責人員。

? 功能細則測試

? 業(yè)務功能細則測試：當冒煙測試通過后歉闰，進入正式功能測試辖众；

? 功能測試通過標準：需求覆蓋度達到100%，且測試用例的粒度達到單個細小模塊的校驗和敬，所有用例被嚴格執(zhí)行且fix掉所有bug（或最終上線前產(chǎn)品凹炸、研發(fā)及測試評估優(yōu)先級為三、四級bug是否全部fix）昼弟；

? 功能測試執(zhí)行：模塊測試負責人員啤它。

? 集成測試

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

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

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

? 集成測試執(zhí)行人員：模塊測試負責人員誊爹。

? 系統(tǒng)測試

? 系統(tǒng)測試是在集成測試基礎上進行的測試，依賴于產(chǎn)品需求說明書中已經(jīng)確定好的系統(tǒng)外設瓢捉、硬件频丘、網(wǎng)絡等組成因素；

? 系統(tǒng)測試分類：恢復性測試泡态、安全性測試搂漠、壓力測試等；

? 系統(tǒng)測試通過標準：所有系統(tǒng)測試用例被嚴格執(zhí)行某弦，且滿足產(chǎn)品需求及設計說明書桐汤；

? 系統(tǒng)測試執(zhí)行人員：模塊測試負責人員。

? 驗收測試

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

? 驗收測試分類：正式測試怔毛、非正式測試（Alpha 測試）、Beta 測試腾降；正式測試由測試人員與用戶共同組成小組或完全由用戶來組織驗收測試拣度；非正式測試多數(shù)由最終用戶執(zhí)行；Beta測試

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

? 驗收測試執(zhí)行人員：測試人員、研發(fā)人員宿接、產(chǎn)品赘淮、最終用戶。

? 回歸測試

? 需注意：回歸測試貫穿于整個開發(fā)周期的各個階段睦霎；

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

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

? 在組織回歸測試時需要注意兩點睛竣，首先是各測試階段發(fā)生的修改一定要在本測試階段內完成回歸晰房，以免將錯誤遺留到下一測試階段。其次射沟，回歸測試期間應對該軟件版本凍結嫉你，將回歸測試發(fā)現(xiàn)的問題集中修改，集中回歸躏惋；

? 回歸測試執(zhí)行人員：測試全體

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

? 測試總結階段

? 測試報告

? 把測試的過程和結果寫成文檔，對發(fā)現(xiàn)的問題和缺陷進行分析扁位，為糾正軟件的存在的質量問題提供依據(jù)准潭，同時為軟件驗收和交付打下基礎；

? 測試報告內容要素：測試范圍域仇、測試方法刑然、測試工具、測試環(huán)境暇务、測試結果與缺陷統(tǒng)計與分析泼掠、測試結論與建議等；

? 每個測試階段或上線前用例及各環(huán)節(jié)執(zhí)行完畢后都需要提供測試報告垦细；

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

? 上線前review

? 上線前產(chǎn)品择镇、研發(fā)、測試共同review上線前需求完成度括改、用例覆蓋度是否滿足本次上線的要求腻豌，以及存在哪些風險點；

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

? 上線前review執(zhí)行人員：測試經(jīng)理攜測試全體

? 測試歸檔

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

? 涉及的文檔：測試計劃析苫、測試用例兜叨、測試階段性報告、測試總結報告衩侥；產(chǎn)品迭代需求說明国旷、設計文檔等，最好歸類為一次版本上線的文件夾茫死，日后有可追溯性跪但；

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

? 上線后總結

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

? 總結內容：對整個研發(fā)過程改進的建議屡久、提高測試效率的方法、若出現(xiàn)問題需追溯出根本原因爱榔、測試過程出現(xiàn)問題的改進方法被环、對測試過程中好的一面予以肯定并繼續(xù)推行等；

? 上線后總結執(zhí)行人員：測試組長攜全體測試人員详幽。

? 缺陷跟蹤

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

? Bug處理流程圖

? Bug嚴重等級定義

? 一級: 系統(tǒng)“掛起”或“崩潰”的錯誤筛欢，使得整個測試工作無法繼續(xù)進行浸锨，如：程序死機、死循環(huán)版姑、非法退出柱搜、數(shù)據(jù)庫死鎖、程序無法登錄等剥险；

? 二級: 軟件功能未按產(chǎn)品需求文檔規(guī)定的實現(xiàn)聪蘸，導致功能報錯，其他模塊測試工作無法進行表制，如：功能不符健爬、接口錯誤等；

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

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

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

? Bug優(yōu)先級定義

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

? Priority 2—比較嚴重的bug桶现，根據(jù)模塊關聯(lián)性依次修復躲雅；

? Priority 3—一般性bug，可在優(yōu)先級為1和2之后修復骡和；

? Priority 4—輕微性bug相赁，經(jīng)討論后可決定是否在下一版修復；

? Priority 5—針對軟件改進建議可以修復或不修復慰于，由產(chǎn)品最終決定钮科；

注：Bug嚴重等級與Bug優(yōu)先級一一對應，特殊情況可調整映射關系婆赠。

? Bug提交規(guī)范

Bug提交所含內容如下：

? Bug標題：環(huán)境-端名稱-模塊名稱-簡要概述Bug绵脯；

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

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

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

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

? 優(yōu)先級：Bug優(yōu)先級定義可免；

? Bug類型：根據(jù)Bug定位原因筒繁，并選擇適當?shù)念愋停斠奲ugfree類型巴元；

? 如何發(fā)現(xiàn)：詳細闡述bug發(fā)現(xiàn)的階段；

? 操作系統(tǒng)：詳細描述操作系統(tǒng)驮宴；

? 終端設備：指定某個終端逮刨，方便問題重現(xiàn)，準確定位堵泽；

? 發(fā)現(xiàn)版本號：填寫詳細版本號修己；

? 運行環(huán)境：闡述bug發(fā)現(xiàn)的運行環(huán)境；

? 處理狀態(tài)：bug當前狀態(tài)迎罗；

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

? 關鍵詞：方便搜索；

? Bug相關：相關聯(lián)的bug與case纹安；

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

? 復現(xiàn)步驟：分為前置條件、復現(xiàn)步驟厢岂、預期結果光督、實際結果、備注（賬號密碼等相關信息）塔粒。

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

? Bug處理流程圖

詳見售后流程圖

? 軟件發(fā)布標準

軟件發(fā)布需滿足以下標準

? 完成發(fā)布計劃中所有的工作结借；

? 實現(xiàn)需求定義中所有功能特性；

? 完成所有的測試工作（按測試計劃嚴格執(zhí)行）卒茬；

? 嚴重缺陷都已修復船老；

? Bug趨勢圖接近于零，新發(fā)現(xiàn)的缺陷圃酵；

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

? 已達到驗收標準

軟件產(chǎn)品未經(jīng)測試合格柳畔，有嚴重bug時，不允許發(fā)布辜昵。

? 爭議處理

若針對同一問題研發(fā)荸镊、測試團隊對結論有爭議，需項目組成員及產(chǎn)品共同討論堪置，項目經(jīng)理給出最終結果躬存，并衡定是否上線。