項目管理流程(適用于服務(wù)器開發(fā))-評審版

項目管理流程(適用于服務(wù)器開發(fā))評審版項目管理流程(適用于服務(wù)器開發(fā))評審版項目管理流程(適用于服務(wù)器開發(fā))評審版xxx公司項目管理流程(適用于服務(wù)器開發(fā))評審版文件編號：文件日期：修訂次數(shù)：第1.0次更改批準(zhǔn)審核制定方案設(shè)計，管理制度項目管理流程（適用于server開發(fā)）版本號：目錄：TOC\o"1-4"\h\z\u1. 概述 32. 適用范圍 43. 術(shù)語和縮略語 4 術(shù)語 4 縮略語 44. 項目管理總流程圖 45. 項目管理規(guī)范和流程 6 產(chǎn)品需求文檔（PRD）生成 6 技術(shù)調(diào)研 6 軟件需求文檔（SRD）編寫 6 軟件需求文檔（SRD）編寫 6 SRD文檔評審 7 項目預(yù)立項 7 項目整體方案設(shè)計 8 技術(shù)方案設(shè)計 8 概要設(shè)計文檔編寫及評審 8 詳細設(shè)計文檔編寫與評審 8 測試方案及用例設(shè)計 8 測試方案設(shè)計及評審 8 測試用例設(shè)計及評審 9 UI/UE設(shè)計（針對有界面展現(xiàn)的產(chǎn)品） 9 配置管理方案及計劃設(shè)計 9 項目正式啟動準(zhǔn)備 10 項目計劃制定 10 項目組成員列表 10 風(fēng)險評估及管理 11 項目質(zhì)量目標(biāo)的設(shè)計和制定 11 配置管理 12 項目啟動會議 12 編碼實現(xiàn)及調(diào)試 12 編碼 12 單元測試 13 聯(lián)調(diào) 13 集成測試 14 提交系統(tǒng)測試申請 14 系統(tǒng)測試版本輸出 15 系統(tǒng)測試 15 系統(tǒng)測試 15 測試報告評審 15 開發(fā)debug 16 性能測試 16 封板及代碼凍結(jié) 17 封板測試及封板 17 代碼凍結(jié) 17 生產(chǎn)環(huán)境部署、驗證測試 18 上線部署申請 18 部署上線 18 驗證測試 196. 文檔模板列表 197. 編制歷史 20概述本文檔旨在通過建立規(guī)范化標(biāo)準(zhǔn)化的項目管理流程并且不斷地改進、優(yōu)化，達到提高工作效率，標(biāo)準(zhǔn)化項目管理，提高軟件質(zhì)量，優(yōu)化資源配置，減小風(fēng)險事件等不良影響，降低溝通成本的目的。進而，為公司拓展業(yè)務(wù)、擴大規(guī)模、持續(xù)發(fā)展，掃除阻礙、鋪平道路。適用范圍本流程適用于北京無限立通基礎(chǔ)平臺服務(wù)器開發(fā)的項目管理使用術(shù)語和縮略語下列術(shù)語和縮略語只適用于本規(guī)范：術(shù)語術(shù)語說明輸入每項任務(wù)開始時的前提條件活動每項任務(wù)的具體工作內(nèi)容分解輸出每項任務(wù)經(jīng)過活動后得出的結(jié)果，原則上要求所有的輸出內(nèi)容需要保存、備份。負責(zé)人指當(dāng)前任務(wù)項的主要負責(zé)人參與方指當(dāng)前任務(wù)項的配合、輔助人員縮略語縮略語英文全稱中文含義MRDMarketRequirementDocument市場需求文檔PRDProductRequirementDocument產(chǎn)品需求文檔SRDSoftwareRequirementDocument軟件需求文檔項目管理總流程圖以下是無限立通項目管理總流程圖（本流程適用于服務(wù)端的開發(fā)）項目管理規(guī)范和流程產(chǎn)品需求文檔（PRD）生成輸入：移動規(guī)范、業(yè)務(wù)部提出需求、開發(fā)自行新需求活動：產(chǎn)品經(jīng)理結(jié)合移動規(guī)范、業(yè)務(wù)部提出的新需求或開發(fā)自行提出的新需求，對產(chǎn)品進行整體規(guī)劃；產(chǎn)品經(jīng)理根據(jù)產(chǎn)品規(guī)劃，編寫和制定《產(chǎn)品需求文檔》；產(chǎn)品需求文檔輸出后，產(chǎn)品經(jīng)理須召集項目經(jīng)理、開發(fā)人員、測試人員對產(chǎn)品的具體需求進行分析、同步及討論；針對產(chǎn)品需求中的實現(xiàn)功能點，如果評估有涉及到技術(shù)難點或風(fēng)險點的，需要做前期的技術(shù)調(diào)研工作。輸出：《產(chǎn)品需求文檔》負責(zé)人：產(chǎn)品經(jīng)理 參與方：項目經(jīng)理、開發(fā)人員、測試人員技術(shù)調(diào)研輸入：產(chǎn)品文檔活動：針對產(chǎn)品設(shè)計討論過程中所提出的技術(shù)性風(fēng)險、難題進行前期技術(shù)調(diào)研，技術(shù)調(diào)研都要有一定的深度，評測結(jié)果要真實可信，其他來源的數(shù)據(jù)僅能作為參考，要以自己的測試結(jié)果為主要依據(jù)；調(diào)研工作結(jié)束后，必須編寫《技術(shù)調(diào)研報告》，報告中要有對被調(diào)研技術(shù)的分析和建議結(jié)論；《技術(shù)調(diào)研報告》完成后，需要與相關(guān)人員共同評估被調(diào)研技術(shù)，評估完成后，針對該技術(shù)的調(diào)研工作完成；如果在調(diào)研過程中有涉及到相關(guān)的代碼和demo，需要在《技術(shù)調(diào)研報告》中體現(xiàn)，并說明具體放置的路徑。輸出：《技術(shù)調(diào)研報告》、代碼、Demo負責(zé)人：開發(fā)人員 參與方：產(chǎn)品經(jīng)理、項目經(jīng)理軟件需求文檔（SRD）編寫軟件需求文檔（SRD）編寫輸入：產(chǎn)品需求文檔活動：項目經(jīng)理根據(jù)產(chǎn)品經(jīng)理提供的PRD文檔，將PRD文檔轉(zhuǎn)化為軟件需求文檔；SRD文檔主要內(nèi)容包含：項目名稱術(shù)語解釋功能需求描述性能需求描述安全及可擴張性需求所參考的協(xié)議和規(guī)范（包含內(nèi)部協(xié)議和外部協(xié)議）接口要求軟硬件需求產(chǎn)品質(zhì)量要求項目大致計劃等具體格式可參見《軟件需求文檔》模板輸出：《軟件需求文檔》負責(zé)人：項目經(jīng)理參與方：產(chǎn)品經(jīng)理、開發(fā)人員、測試人員SRD文檔評審輸入：SRD文檔活動：項目經(jīng)理編寫好SRD文檔后，召集產(chǎn)品經(jīng)理、開發(fā)人員、測試人員進行討論、評審，并輸出評審報告及修正后的SRD文檔。輸出：評審報告，修正后的SRD文檔負責(zé)人：項目經(jīng)理參與方：產(chǎn)品經(jīng)理、開發(fā)人員、測試人員項目預(yù)立項輸入：SRD文檔活動：項目經(jīng)理根據(jù)最終確定的SRD文檔對項目進行預(yù)立項，對后面的工作進行安排和規(guī)劃；預(yù)立項工作主要是針對接下來的“項目整體方案設(shè)計”階段進行規(guī)劃和計劃安排；項目整體方案設(shè)計主要涵蓋以下四大部分：技術(shù)方案的設(shè)計（包含概要設(shè)計及詳細設(shè)計）UI/UE的設(shè)計測試方案及測試用例的設(shè)計配置方案及計劃的設(shè)計輸出：項目計劃負責(zé)人：項目經(jīng)理參與方：產(chǎn)品經(jīng)理、開發(fā)人員、測試人員、配置管理員項目整體方案設(shè)計技術(shù)方案設(shè)計概要設(shè)計文檔編寫及評審輸入：PRD文檔、SRD文檔、項目計劃活動：在SRD完成后，需要開發(fā)人員對SRD、PRD進行系統(tǒng)分析工作；必要時需要進行額外的技術(shù)調(diào)研，技術(shù)調(diào)研的流程仍參照步驟進行；初步系統(tǒng)分析完成后，需要編寫《概要設(shè)計文檔》；概要設(shè)計文檔至少包含內(nèi)容：系統(tǒng)架構(gòu)系統(tǒng)各模塊的分解及功能說明針對《概要設(shè)計文檔》進行評審，評審?fù)ㄟ^后初步系統(tǒng)分析完成具體格式可參見《概要設(shè)計文檔》模板輸出：《概要設(shè)計文檔》、評審報告負責(zé)人：技術(shù)負責(zé)人參與方：開發(fā)人員、項目經(jīng)理、技術(shù)總監(jiān)、測試人員詳細設(shè)計文檔編寫與評審輸入：SRD文檔、《概要設(shè)計文檔》、項目計劃活動：開發(fā)人員根據(jù)SRD和《概要設(shè)計文檔》，進行系統(tǒng)模塊的劃分和分解；分模塊進行系統(tǒng)分析，各個模塊的系統(tǒng)分析完成后，需要編寫《詳細設(shè)計文檔》；各子系統(tǒng)間的交互需要編寫《系統(tǒng)內(nèi)部接口文檔》；如本系統(tǒng)與其他系統(tǒng)有交互，需要編寫《系統(tǒng)接口文檔》；針對《詳細設(shè)計文檔》、《系統(tǒng)內(nèi)部接口文檔》和《系統(tǒng)接口文檔》須召集項目經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)人員、測試人員進行評審；具體格式可參見《詳細設(shè)計文檔》、《系統(tǒng)內(nèi)部接口文檔》和《系統(tǒng)接口文檔》模板。輸出：《詳細設(shè)計文檔》、《系統(tǒng)內(nèi)部接口文檔》、《系統(tǒng)接口文檔》、評審報告負責(zé)人：開發(fā)人員參與方：項目經(jīng)理、技術(shù)總監(jiān)、測試人員測試方案及用例設(shè)計測試方案設(shè)計及評審輸入：PRD文檔、SRD文檔、《概要設(shè)計文檔》、《詳細設(shè)計文檔》、《系統(tǒng)內(nèi)部接口文檔》和《系統(tǒng)接口文檔》活動：測試人員根據(jù)產(chǎn)品文檔、需求文檔及技術(shù)文檔進行測試方案的編寫；測試方案包含：功能測試、性能測試、白盒測試；測試方案編寫完成后，需要組織相關(guān)人員進行評審，并輸出評審報告；測試方案評審后，測試、開發(fā)需雙方達到確認(rèn)。輸出：《測試方案》、測試方案評審報告負責(zé)人：測試人員參與方：開發(fā)人員、項目經(jīng)理、產(chǎn)品經(jīng)理測試用例設(shè)計及評審輸入：測試方案、PRD文檔、SRD文檔活動：測試人員根據(jù)測試方案、產(chǎn)品文檔及SRD文檔進行測試用例的編寫和分解；測試用例包含：功能測試、性能測試、白盒測試；測試用例編寫完成后，需要組織相關(guān)人員進行評審，并輸出評審報告；測試用例評審后，測試、開發(fā)需雙方達到確認(rèn)。輸出：《測試用例》負責(zé)人：測試人員參與方：開發(fā)人員、項目經(jīng)理、產(chǎn)品經(jīng)理UI/UE設(shè)計（針對有界面展現(xiàn)的產(chǎn)品）輸入：PRD文檔、SRD文檔、項目計劃活動：產(chǎn)品經(jīng)理根據(jù)SRD文檔、PRD文檔對產(chǎn)品的UI/UE進行設(shè)計；設(shè)計結(jié)束后，須召集項目經(jīng)理、開發(fā)人員、測試人員進行評審。輸出：UI/UE設(shè)計文檔負責(zé)人：產(chǎn)品經(jīng)理參與方：開發(fā)人員、項目經(jīng)理、測試人員配置管理方案及計劃設(shè)計輸入：SRD文檔、PRD文檔、項目計劃活動：項目經(jīng)理根據(jù)SRD文檔對項目的配置管理方案及計劃進行設(shè)計；配置管理方案主要涵蓋以下內(nèi)容：項目名:（供內(nèi)部使用）發(fā)布版本命名及版本號：（每次版本發(fā)布時的版本命名及版本號控制，包含從輸出給測試部系統(tǒng)測試起一直到正式版本的發(fā)布。）Sharepoint：（項目文件目錄的規(guī)劃和設(shè)計）SVN：（目錄的規(guī)劃和設(shè)計）QC系統(tǒng)：（目錄的規(guī)劃和設(shè)計）資源配置人力資源設(shè)備資源其它無形資源（如開發(fā)環(huán)境軟件、工具類等）配置管理方案和計劃設(shè)計結(jié)束后，須召集開發(fā)人員、測試人員、配置管理員進行討論及信息同步；最后輸出《配置管理方案和計劃》，并同步給配置管理員作為后續(xù)項目配置管理的依據(jù)。輸出：《配置管理方案和計劃》負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、測試人員、配置管理員、運維人員項目正式啟動準(zhǔn)備項目計劃制定輸入：PRD文檔、SRD文檔、整體方案設(shè)計活動：項目經(jīng)理召集技術(shù)負責(zé)人進行計劃預(yù)估及制定；技術(shù)負責(zé)人須配合項目經(jīng)理進行任務(wù)的分解和評估，同時對開發(fā)時間進行評估（技術(shù)負責(zé)人在預(yù)估時間時可找相應(yīng)要參與的直接工程師進行共同預(yù)估時間點，以確保給出的時間盡量準(zhǔn)確）；評估的時間粒度原則上能讓項目經(jīng)理可有效的進行跟蹤任務(wù)進展，具體的粒度由項目經(jīng)理根據(jù)項目實際情況進行把握（按照國內(nèi)的項目管理慣例，一般情況下，最小粒度希望能細到1天。）項目計劃所包含的維度須涵蓋：服務(wù)器端開發(fā)客戶端開發(fā)單元測試聯(lián)調(diào)集成測試系統(tǒng)測試性能測試封板發(fā)布等項目經(jīng)理根據(jù)開發(fā)、測試評估的計劃，整理出整個項目計劃；輸出：項目計劃負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、測試人員、運維人員、配置管理員項目組成員列表輸入：項目計劃活動：項目經(jīng)理根據(jù)項目計劃中的人力資源，對所有項目組人員建立一份成員列表；需明確每位項目組成員的職責(zé)；如果有涉及到客戶或第三方，也需要將其項目的負責(zé)人進行建立，以便保持后續(xù)聯(lián)系；項目成員列表至少包含姓名、職責(zé)、電話、郵件等聯(lián)系方式。輸出：項目成員列表負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、測試人員、運維人員、合作伙伴、配置管理員風(fēng)險評估及管理輸入：項目計劃、PRD文檔、SRD文檔、項目整體方案設(shè)計活動：項目經(jīng)理需組織項目組成員對項目的風(fēng)險進行識別和評估；項目風(fēng)險主要包含技術(shù)風(fēng)險、資源風(fēng)險等；根據(jù)識別出的風(fēng)險，項目組需要對其嚴(yán)重程度及影響面進行評估，以綜合評估風(fēng)險的影響程度；針對識別出來的風(fēng)險，需要項目組共同討論預(yù)防措施及應(yīng)對措施，以防問題發(fā)生，將風(fēng)險降到最低點；項目經(jīng)理根據(jù)識別出的風(fēng)險點及討論后的預(yù)防措施，進行管理，并跟進預(yù)防措施的落實情況，并定期更新和維護風(fēng)險管理表。輸出：風(fēng)險評估和管理表負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、測試人員、運維人員項目質(zhì)量目標(biāo)的設(shè)計和制定輸入：SRD文檔、項目計劃活動：項目經(jīng)理根據(jù)SRD文檔和項目計劃對項目在實施過程中的每個milestone，產(chǎn)品所要完成的功能及達到的質(zhì)量目標(biāo)進行設(shè)計和制定；項目質(zhì)量目標(biāo)需要分解到每個大的里程碑；質(zhì)量目標(biāo)和測試用例需要同開發(fā)人員進行討論、同步；項目質(zhì)量目標(biāo)主要涵蓋內(nèi)容如下：功能完成度性能達到的要求本階段的輸入及輸出本階段質(zhì)量所要達到的最終目的評判標(biāo)準(zhǔn)評判人員輸出：項目質(zhì)量目標(biāo)負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、測試人員、產(chǎn)品經(jīng)理配置管理輸入：配置管理方案及計劃活動：配置管理員收到項目經(jīng)理的配置管理方案和計劃書后。對項目實施過程中所使用到的工具、系統(tǒng)、環(huán)境進行相關(guān)的配置；當(dāng)前涉及到相關(guān)的工具、系統(tǒng)、環(huán)境是:Sharepoint：根據(jù)配置方案進行項目建立、目錄的建立及相關(guān)人員權(quán)限開通、設(shè)置；QC系統(tǒng)：根據(jù)配置方案進行項目建立、目錄的建立及相關(guān)人員權(quán)限開通、設(shè)置；SVN：根據(jù)配置方案進行項目建立、目錄的建立及相關(guān)人員權(quán)限開通、設(shè)置；版本管理：根據(jù)配置方案對版本發(fā)布地址、版本命名、版本號進行建立和管理。配置管理員對以上的配置進行管理和維護，并輸出項目配置表。輸出：項目配置表負責(zé)人：配置管理員參與方：項目經(jīng)理、開發(fā)人員、測試人員、運維人員項目啟動會議輸入：項目計劃、團隊成員列表、風(fēng)險評估和管理表、項目質(zhì)量目標(biāo)、項目配置表活動：在項目啟動準(zhǔn)備工作就緒后，項目經(jīng)理發(fā)起會議并召集項目組所有人員進行kickoff會議；會議主要討論和明確內(nèi)容如下:項目計劃同步和確定項目組成員及職責(zé)的明確和確定對當(dāng)前存在風(fēng)險點進行同步和明確，并明確各風(fēng)險點的負責(zé)人；對項目質(zhì)量目標(biāo)的明確和同步對項目配置方案的明確和同步會議結(jié)束后，項目經(jīng)理將以上5項討論后的結(jié)論做最終整理，并將其相關(guān)文檔提交到sharepoint上相應(yīng)的文件目錄下進行管理，以便項目組查詢。輸出：項目計劃、團隊成員列表、風(fēng)險評估和管理表、項目質(zhì)量目標(biāo)、項目配置表負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、測試人員、運維人員編碼實現(xiàn)及調(diào)試編碼輸入：項目計劃、PRD文檔、SRD文檔、技術(shù)方案設(shè)計文檔活動：在項目啟動會議結(jié)束后，開發(fā)在開始編碼前，須建立并確定代碼目錄結(jié)構(gòu)、文件命名規(guī)則；代碼格式須遵照《Java代碼編寫規(guī)范》書寫；每隔2-3天，應(yīng)將代碼入庫一次；代碼入庫前必須完成CodeReview準(zhǔn)備進行CodeReview前，應(yīng)當(dāng)更新本地代碼到最新版本；檢查更新后的代碼是否會導(dǎo)致BuildBreak；如沒有問題，生成patch，將patch發(fā)送給Reviewer；Reviewer檢查完代碼，確認(rèn)沒有問題后，方可入庫；入庫代碼如果造成BuildBreak，須在當(dāng)天解決，并且入庫更新的代碼開發(fā)過程中的各種討論（技術(shù)討論、需求討論、測試討論等）原則上都需要有文檔記錄，可以通過SharePoint或者郵件來記錄對于BuildBreak、較嚴(yán)重或有代表性的Bug、重大設(shè)計錯誤等問題，需要進行CaseStudy，每一次CaseStudy都需要有獨立的文檔，并且保存在SharePoint中開發(fā)過程中如有并行開發(fā)的情形（例如同時修改多個Bug，或者Bug修改和代碼開發(fā)同步進行，或者多個分支同時開發(fā)等），應(yīng)該在自己的開發(fā)機器上建立多個開發(fā)鏡像，不應(yīng)將代碼混雜在一個工程中管理在代碼編寫階段，需要嚴(yán)格按照項目計劃執(zhí)行，并確保代碼質(zhì)量。輸出：代碼負責(zé)人：開發(fā)人員參與方：項目經(jīng)理單元測試輸入：項目計劃、PRD文檔、SRD文檔、系統(tǒng)設(shè)計文檔、產(chǎn)品代碼活動：在代碼實現(xiàn)過程中，須保證在在一個迭代周期內(nèi)完成單元測試（迭代周期視項目具體情況而定）；在一個迭代周期結(jié)束前，入庫的代碼須包含相應(yīng)的單元測試代碼；單元測試代碼入庫前原則上也必須進行CodeReviewer；單元測試的最終結(jié)果是保證迭代周期內(nèi)的代碼測試通過，以確保入庫代碼的質(zhì)量；單元測試結(jié)束后，須輸出相應(yīng)的測試報告，測試報告原則上要求每項都是pass。輸出：單元測試代碼、單元測試報告負責(zé)人：開發(fā)人員參與方：項目經(jīng)理聯(lián)調(diào)輸入：編碼完成、單元測試完成活動：在編碼及單元測試完成后，軟件系統(tǒng)進入聯(lián)調(diào)工作；聯(lián)調(diào)工作主要包含：★子系統(tǒng)間接口、功能聯(lián)調(diào)★本系統(tǒng)與其它系統(tǒng)間的接口、功能聯(lián)調(diào)聯(lián)調(diào)須確保各子系統(tǒng)間或相互調(diào)用的系統(tǒng)之間接口調(diào)通，正常流程的功能實現(xiàn)正常，以作為進入下階段集成測試奠定良好的基礎(chǔ)；聯(lián)調(diào)結(jié)束后，須輸出聯(lián)調(diào)報告（報告模板和格式可根據(jù)項目實際情況進行設(shè)計）。輸出：聯(lián)調(diào)報告負責(zé)人：開發(fā)人員參與方：項目經(jīng)理集成測試輸入：聯(lián)調(diào)結(jié)束活動：聯(lián)調(diào)結(jié)束后，開發(fā)需進行集成測試；集成測試的測試方案和測試標(biāo)準(zhǔn)由測試部門提供；通過集成測試，須保證各系統(tǒng)及系統(tǒng)間相互調(diào)用的功能、正常流程是正常的；集成測試后，須輸出集成測試報告（報告模板和格式可根據(jù)項目實際情況進行設(shè)計，重點是確保功能已實現(xiàn)且正常流程跑通）；集成測試的結(jié)論將作為是否準(zhǔn)入系統(tǒng)測試的判定標(biāo)準(zhǔn)之一，如果集成測試不通過，測試團隊有權(quán)拒收提交的系統(tǒng)測試版本；集成測試結(jié)束后，開發(fā)需將最新代碼進行提交、入庫。輸出：集成測試報告負責(zé)人：開發(fā)人員參與方：項目經(jīng)理、測試人員、配置管理員提交系統(tǒng)測試申請輸入：集成測試報告活動：集成測試通過后，開發(fā)人員將程序打包并提交到指定的服務(wù)器地址；開發(fā)人員需填寫《系統(tǒng)測試申請單》，申請單需經(jīng)過相關(guān)人員簽字后提交給測試部和配置管理員；系統(tǒng)測試申請單須包含以下內(nèi)容：集成測試的結(jié)果安裝包的存放位置和地址代碼的具體地址（包含SVN地址及SVN版本號）輸出：《系統(tǒng)測試申請單》負責(zé)人：開發(fā)人員參與方：項目經(jīng)理、測試人員、配置管理員系統(tǒng)測試版本輸出輸入：系統(tǒng)測試申請單活動：配置管理人員從開發(fā)手上拿到系統(tǒng)測試申請單后，按照開發(fā)申請單上所描述的版本存放位置下載安裝包，將版本備份到指定的服務(wù)器，并對版本進行統(tǒng)一管理；同時配置管理員需要審核開發(fā)所提交的安裝包的版本命名和版本號是否正確；確保沒問題后，將通知測試人員到指定的位置取安裝包；輸出：系統(tǒng)測試版本負責(zé)人：配置管理人員參與方：開發(fā)人員、項目經(jīng)理、測試人員系統(tǒng)測試系統(tǒng)測試輸入：系統(tǒng)測試版本、測試用例、測試方案活動：測試負責(zé)人按照測試計劃對測試用例對任務(wù)進行分解到每位測試人員，并確保每條用例到具體負責(zé)人；測試人員收到測試版本及測試任務(wù)后，進行測試工作；測試人員的工作須按照測試計劃進行，如出現(xiàn)與測試計劃不符的，需及時提出，并跟項目經(jīng)理進行溝通；測試過程中發(fā)現(xiàn)的bug提交及具體操作，請參照QC文檔執(zhí)行；測試過程中，如果碰到嚴(yán)重問題而造成正常測試無法進行的，須第一時間highlight出來給開發(fā)和項目經(jīng)理，開發(fā)接到問題后需第一時間安排分析解決。問題得到修正后，開發(fā)需要重新走到版本提交申請、輸出的流程；測試負責(zé)人需要每天反饋測試進展，并輸出《每日測試報告》；一輪系統(tǒng)測試結(jié)束后，測試負責(zé)人需要發(fā)布一輪《系統(tǒng)測試總結(jié)報告》；輸出：《每日測試報告》、《系統(tǒng)測試總結(jié)報告》負責(zé)人：測試負責(zé)人參與方：開發(fā)人員、項目經(jīng)理、測試人員測試報告評審輸入：測試報告、buglist活動：項目經(jīng)理收到測試部發(fā)出的系統(tǒng)測試總結(jié)報告后，結(jié)合實際情況，發(fā)起測試報告評審的會議；會議評審內(nèi)容主要包含測試報告的內(nèi)容及QC中的buglist；測試報告評審的原則：測試報告中是否已完成該涵蓋的用例；針對N/A的部分需要說明具體原因，并確認(rèn)當(dāng)前是否確實無法測試；Fail項是否都已提交到QC系統(tǒng)中進行管理BugList評審原則：需要對每個bug的最新狀態(tài)作確認(rèn)；逐一討論bug，對每個bug需要分析其嚴(yán)重程度、解決的優(yōu)先級；每個bug需要明確具體的負責(zé)人和解決時間點；對一些bug暫時不需要解決的（如需求不明確或嚴(yán)重程度低的），可做“掛起”處理。但事后需要特別對“掛起”問題，重新進行分析、討論，作為后期完善、優(yōu)化的一部分內(nèi)容；針對“爭議”類的bug需要項目組做特別討論，并給出處理的結(jié)論；其它關(guān)于bug的處理原則，具體詳見QC文檔執(zhí)行。根據(jù)評審?fù)甑膱蟾婧蚥uglist，需要進一步明確下階段版本更新、系統(tǒng)測試的時間點以及測試范圍；根據(jù)評審的結(jié)果，項目組確定版本是否可達到封板目的。輸出：評審結(jié)論、會議記錄負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、項目經(jīng)理、測試人員開發(fā)debug輸入：buglist活動：開發(fā)人員需要主動查看分配給自己的Bug，并及時更新Bug狀態(tài)；當(dāng)Bug修改完成提交修改代碼時，需要說明以下事項：在提交到SVN時，必須附帶comment，并且在comment中說明相關(guān)Bug號；同時修改Bug狀態(tài)，在Bug中增加comment說明相關(guān)代碼提交時的Revision。針對Bug修改的代碼提交時，原則上不允許以下情況：一次提交代碼中包含多個Bug修改；一次提交代碼中即包含Bug修改，又包含其他功能的開發(fā)代碼關(guān)于bug的處理原則，具體詳見QC文檔執(zhí)行。輸出：評審結(jié)論、會議記錄負責(zé)人：項目經(jīng)理參與方：開發(fā)人員、項目經(jīng)理、測試人員性能測試輸入：測試版本、測試環(huán)境活動：測試負責(zé)人按照測試計劃對性能測試進行安排；性能測試主要包含以下幾方面：客戶端方面：對功耗、流量、內(nèi)存占有率進行測試（具體測試內(nèi)容視具體項目和測試方案而定）；服務(wù)器方面：根據(jù)設(shè)定的相應(yīng)使用指標(biāo)進行測試（具體指標(biāo)視不同項目實際情況和測試方案而定）；測試結(jié)束后，須輸出性能測試報告，并把報告發(fā)給項目經(jīng)理、開發(fā)人員及相關(guān)負責(zé)人；測試報告中，測試人員需要給出每項測試的結(jié)論；輸出：性能測試報告負責(zé)人：性能測試負責(zé)人參與方：開發(fā)人員、項目經(jīng)理、測試人員封板及代碼凍結(jié)封板測試及封板輸入：系統(tǒng)測試完成、性能測試完成活動：測試負責(zé)人按照測試計劃，完成系統(tǒng)測試及性能測試的結(jié)果對產(chǎn)品進行最后一輪封板測試；封板測試結(jié)束后，須輸出封板測試報告；根據(jù)封板測試報告，召集項目組進行討論、評估，以確定版本是否可達到封板條件；如果達到，測試負責(zé)人啟動版本封板流程，并填寫《版本封板申請單》，并提交申請單給開發(fā)人員、項目經(jīng)理、配置管理員進行簽字確認(rèn)；版本封板申請單所包含內(nèi)容項，至少涵蓋：各相關(guān)負責(zé)人確認(rèn)結(jié)果封板測試的版本及版本號對應(yīng)代碼的SVN地址和版本號封板的結(jié)論和具體時間最終將封板申請單提交給配置管理員，由配置管理員進行版本封存，對代碼、版本進行凍結(jié)、封存管理。輸出：封板測試報告負責(zé)人：測試負責(zé)人參與方：開發(fā)人員、項目經(jīng)理、配置管理員代碼凍結(jié)輸入：版本封板申請單活動：配置管理員收到版本封板申請單后，根據(jù)申請單上對應(yīng)的SVN地址和版本號對代碼、版本進行凍結(jié)和封存，并對SVN上的代碼打Tag，同時對Tag進行特別注釋；凍結(jié)完成后，配置人員需在《版本封板申請單》上填寫代碼凍結(jié)、版本封存的結(jié)論、時間、地址及相應(yīng)的SVN版本號，并通知給項目的相關(guān)人員；在代碼凍結(jié)之后，原則上禁止任何代碼的提交，如果確實需要提交，需要部門經(jīng)理及配置管理員確認(rèn)，以確定是否在原有基礎(chǔ)上拉分支，方案確定后方可入庫。輸出：版本封板申請單負責(zé)人：配置管理員參與方：開發(fā)人員、項目經(jīng)理、測試人員、開發(fā)經(jīng)理生產(chǎn)環(huán)境部署、驗證測試上線部署申請輸入：版本封板及代碼凍結(jié)活動：上線前開發(fā)人員需要編寫和準(zhǔn)備《系統(tǒng)部署文檔》和《上線手冊》兩份文檔；此兩份文檔需要提交給測試人員進行驗證測試，驗證通過后將文檔提交給運維部門；開發(fā)人員收到配置管理員最后的版本封板和代碼凍結(jié)成功后，根