1、質量保證組（簡稱：質保組）一、 目標協助研發對項目周期中產生的相關文檔進行評審，展開內測工作，保證部門整體管理及產品質量品質的提升。二、 主要職責1、 作為研發與需求、UE、測試的統一接口人，起到溝通協作、承上啟下的作用；2、 負責對需求部提交的需求規格說明書進行評審；3、 負責對UE部提交的高保真/低保真、通用規則進行評審；4、 負責對測試部提交的測試用例進行評審；5、 負責對測試部提交的Bug進行確認；6、 參與需求變更的評審工作，負責將變更內容及時、有效地反饋給研發，并負責跟蹤需求變更在研發的對應情況；7、 負責在提交測試部測試前根據項目情況進行功能走查或功能測試。三、 職責流程圖任務說

2、明：1、 各類文檔的評審 目前暫定采用問題跟蹤表的形式（后期考慮轉移至Jira中，以實現問題的統一管理、確認及跟蹤，具體的流程定義待定） 以所有問題全部確認關閉為原則。2、 需求變更控制 需求變更的發起：由需求自發產生，由UE在設計高/低保真時產生，由研發在設計或編碼時產生，由測試在編寫用例時產生 需求變更的反饋：a) 發起人直接與需求人員進行問題的溝通及確認；b) 若需求發生變更，需求人員發送變更通知的mail必須抄送給質保組；c) 質保組將需求變更的mail轉發給相應的研發人員，若是由研發人員發起可省略該步；d) 質保組需要跟蹤需求變更的對應情況。 需求變更的跟蹤：考慮使用Jira進行管理

3、，具體的流程定義待定3、 外測Bug的處理流程 測試部提交Bug； Bug會自動先分配給質保組（各服務單元對應質保組成員名單在測試前會發送給測試經理，配置在bugzilla中，不需要手動進行該步驟。）； 質保組接收到分配給自己的Bug后，首先確認Bug的有效性；a) 判斷為無效的、無法重現、需求變更的Bug需要跟Bug的提交者進行溝通確認，確認后，直接將Bug置為已解決，解決途徑選擇相應選項，并在備注中說明已經與何人進行了確認，確認結果及原因；b) 判斷為重復的Bug，需要跟Bug的提交者進行溝通確認，確認后，直接將Bug置為已解決，解決途徑選擇已修復，在備注中說明已經與何人進行了確認，確認與

4、哪一個Bug重復； 判斷為需要修改的Bug，質保組將Bug分配給技術經理，有必要時可以補充相應的備注說明，在標題處以“*”開頭標識Bug的缺陷類型； 技術經理接收到分配給自己的Bug后，進行Bug修改的判定，a) 判定為需要修改，則根據Bug的優先級、嚴重度，綜合評估目前研發人員已分配Bug的對應情況，將Bug進行二次分配給具體的研發人員；b) 判定為決定不改、稍后再改的Bug，直接將Bug置為已解決，解決途徑選擇相應選項，并在備注中說明原因； 研發人員對分配給自己的Bug進行調查對應a) 對應修正完畢，自測沒有問題后，將Bug置為已解決，解決途徑選擇已修復，在備注中說明修改內容，若缺陷類型定

5、義有誤需要修改；b) 調查后對Bug有疑義的，可以再與質保組溝通，根據實際情況判定解決途徑。 測試人員會根據計劃對已解決狀態的Bug進行回歸確認a) 確認沒有問題，測試人員會將Bug直接置為已關閉；b) 確認存在問題，測試人員會將Bug重新打開，并在備注中說明返回的原因，研發人員接收到返回給自己的Bug后，重復執行步驟附：缺陷類型缺陷類型說明Bugzilla中如何對應的補充說明【需求】未明確定義需求中沒有明確的定義，導致實施結果與測試用例不符此類Bug，置為需求變更，請跟蹤需求進行補充或修改，需要在備注中補充說明【需求】描述不清需求中有相關定義，但是理解會產生歧義，導致實施結果與需求不符【功能

6、】正常系邏輯錯誤基本功能按照正常業務流程進行使用，出現錯誤此類Bug需要修改【功能】異常系邏輯錯誤進行異常系測試，發現的功能性錯誤【功能】功能點遺漏需求中有明確定義，但是沒有實現【功能】關聯模塊錯誤在測試A模塊時發現了關聯模塊B的問題此類Bug需要重新分配給關聯模塊的負責人進行修改【功能】JavaScript錯誤進行操作時，頁面拋出JavaScript錯誤此類Bug需要修改【界面】格式校驗錯誤【界面】提示信息錯誤【界面】界面不一致【界面】低/高保真錯誤高保真或低保真本身存在錯誤，即不符合需求或通用規則此類Bug，置為需求變更，請跟蹤低/高保真進行了修改或補充，需要在備注中補充說明【界面】與低/

7、高保真不符實現的結果與低/高保真的設計不相符此類Bug需要修改【界面】框架、組件錯誤此類Bug需要重新分配給框架或組件的負責人進行修改【界面】瀏覽器錯誤相同的功能在A瀏覽器下可用，但B瀏覽器下不可用時使用。【建議】易用性錯誤建議級的Bug不一定要當時進行修改，此類問題需要與組長討論后再做決定，涉及到需求、UE的地方，由組長溝通后反饋給研發和測試人員。【建議】功能錯誤需求中定義的交互或功能存在微不足道的問題，不修改也不會對整體功能產生影響，只是建議進行修改【建議】功能點遺漏需求中沒有定義，提出的問題微不足道，不修改也不會對整體功能產生影響，只是建議進行追加【標準】不符合通用規則需求中沒有明確定義，但是通用規則中有定義，而實現的結果與之不符此類Bug需要修改【其他】接口問題【其他】環境問題【其他】DB問題【其他】性能問題【其他】其他所有類型均不能準確定義該Bug類型，需要在備注中補充說明，以便后續缺陷類型的補充4、 內測的形式根據項目的實際情況安排測試計劃對比測試方式功能走查功能內測測試依據需求跟蹤矩陣需求規格說明書側重點大體基本功能是否實現功能操作是否拋出異常或錯誤基本業務流程能否走通需求中要求的業務規則實現完整且正確；進行異常系的測試；從需求、功能、界面等各方面進行測試，提出問題；耗時相對較短相