QC是Mercury的一個基於WEB瀏覽器環境下的測試管理工具，當前工作中用到的主要功能：測試需求管理、測試計划管理、缺陷管理。
一、QC使用簡述
使用流程：登錄系統---需求管理---測試計划管理---缺陷管理
1.系統登錄：網頁地址欄輸入QC服務器地址，進入登錄頁面，輸入用戶名密碼登錄，根據客戶需求定制相應部分。
2. 需求管理：驗證測試涵蓋所有的產品需求，根據產品需求，生成測試計划草案，把測試項目同產品需求一一 對應起來
需求管理流程：建立項目需求、建立子需求
3.測試計划管理：結構化組織測試活動（測試計划樹）、測試案例、詳細描述測試活動（分步驟）、相關文件可以作為附件、部分測試由手工測試過渡到自動測試
測試計划管理流程：需求轉換成測試計划、生成測試用例。（測試執行結果有四種狀態，分別是：FAILED：該計划執行失敗、NO RUN：該計划未執行、NOT COMPLETED：該計划未完成或未完全通過、PASSED：該計划通過測試）
4.缺陷管理：從發現問題開始，包括問題定位、問題解決、對解決的確認、狀態跟蹤、郵件系統支持、統計處理
缺陷管理流程：新建缺陷、缺陷與測試計划關聯、管理缺陷。
二、QC使用規范（限當前所參與項目）
1.bug生命周期：提出--修改--驗證--關閉--生產機發布
2.bug優先級共分為五級：
| 級別 | 要求 | 功能模塊bug級別認定標准 | 報表bug級別認定標准 |
| 低 | 需3天到一周解決 | 報錯提示信息不准確 |
表樣上文字錯誤或格式不美觀 |
| 中 | 需1到兩天解決 | jsp程序錯誤導致運行過程中報錯 | 報表定義、變量定義、表樣定義錯誤，導致報表上數字不正確 |
| 高 | 需盡快響應，一天內解決 | java程序錯誤導致運行過程中報錯退出 | 手工模板定義錯誤，導致報表數據不正確 |
| 非常高 | 需馬上響應，一天內解決 | 頁面錯誤導致程序界面無法操作 | 合計項、分攤規則定義錯誤，導致需要重新生成報表賬 |
| 緊急 | 需馬上響應，一天內解決 | 不能進入程序界面 | 配置文件定義錯誤，導致程序運行過程中報錯退出 |
3.測試案例添加
測試人員測試某一模塊或報表時，請在如下兩部分添加相關測試案例,並添加鏈接：
a) 在測試計划樹中，相對應部分添加測試案例，並在測試需求樹中鏈接這個案例；
b) 在測試集合中添加一個相關集合的測試案例，並在測試需求樹中鏈接這個案例。
注意：無論我們執行的測試案例成功與否，都要相應得修改測試案例狀態，執行成功時狀態為‘pass’， 失敗時為’faild’.
4.測試案例書寫說明：
a.測試案例的名稱錄入“表名或功能模塊的名稱/測試點”即可；
b.測試案例添加后，將測試案例的狀態修改為“Ready”;
c.鏈接需求覆蓋；
d.如果有缺陷，鏈接缺陷覆蓋。
5.增加“不是bug”的bug狀態。
6.bug書寫注意事項：
a.測試人員創建bug時，要把bug詳細信息處的信息填全，尤其bug的創建時間，“分配給”選項，“優先級”選項。
項目：直接選擇測試計划樹中的一個根節點即可，例如：報表相關測試，就選擇 ‘中期決算報表相關’；
主題：就選擇，根節點下面的三級即可，例如：分攤報表的問題，就選擇“中期決 算報表相關—中期決算_報表類—分攤關系調整 ”即可。
b.測試人員提出bug時
摘要：描寫發現問題的表名稱、或功能模塊名稱、或測試計划樹中的大類名稱例如bkj01、帳務管理_**、或bkj**vts校驗，不超過十個字。
c.開發人員回復bug時
在bug摘要處，名稱之前補寫“bug產生的原因類型/”。bug產生原因有四種類型：A、需求階段，B、設計階段，C、編碼階段，D、版本管理階段。開發人員只需直接填寫ABCD即可。例如：一個bug的名稱為“bkj***vts校驗有誤”，回復時開發人員修改名稱為“D/ bkj***vts校驗有誤”，代表bug是在版本管理階段產生的。
三、QC使用經驗舉例
A.測試用例編寫
| 角色 | 職責 |
| 測試經理 | － 組織撰寫《測試用例》 |
| 項目經理/技術負責人 | － 評審以及審批《測試用例》 |
| 甲方項目負責人 | － 評審以及審批《測試用例》 |
| 需求提出部門 | － 評審《測試用例》 |
| 測試成員 | － 編寫《測試用例》 |
- 測試用例的編寫時間（最早啟動時間）：
單元測試用例：編碼階段
集成測試用例：設計階段
系統測試用例：設計階段
驗收測試用例：需求階段
- ＱＣ工具中添加測試案例注意：
詳細填寫測試案例每一項信息
測試案例名稱為“測試用例的路徑+測試點” （不超過10個字）
添加后測試案例的狀態修改為“Ready”
測試案例要鏈接需求與缺陷
測試案例要有預期結果的設定，以便於與實際結果的對比
測試用例與最終的測試報告要建立一一對應關系
B.測試報告以及bug分析
| 角色 |
職責 |
| 測試經理 |
－ 匯總測試結果，撰寫測試報告 |
| 項目經理 |
－ 審核相關測試報告 |
| 甲方項目負責人 |
－ 審核相關測試報告 |
過程說明：
- 測試報告按照統一的格式、統一的分析對象、統一的維度對測試結果進行分析。主要內容如下：
總述：項目、測試人員、開發人員、概要、bug分析
(一)測試需求報告
a.測試需求報告
維 度：帶有覆蓋范圍的測試需求
b.測試需求進度分析。
維 度：需求狀態、時間
分析對象：從時間角度分析需求樹建立情況，從需求狀態分析需求樹被覆蓋進度，從需求狀態分析需求被測試進度
c.測試被需求覆蓋度分析
維 度：需求狀態餅形圖
分析對象：從餅形圖的覆蓋程度更直觀看到需求被測試覆蓋程度
(二)測試計划報告
測試計划樹說明
維 度：分類方式，測試計划樹大類描述、共有多少個功能模塊和報表、多少個測試點、多少個測試案例等
(三)缺陷分析
1.缺陷分布圖
維 度：缺陷功能-狀態分布圖、缺陷分配人員（bug修改人員）-狀態分布圖、缺陷檢測人員-狀態分布圖
分 析：
a) 缺陷功能-狀態分布圖
分析角度：從bug分布情況、結合測試計划樹結構，分析哪些主題bug分布較密集是否是程序較復雜部分、是否符合2－8定律
從bug分布情況分析測試人員測試情況，若不符合2－8定律，則測試有待於進一步的展開整體分析bug分布情況，每個主題各占百分之幾
從bug狀態分析bug修改、驗證情況
從bug狀態、數量、結合測試進行的階段、分析系統穩定性
b) 缺陷分配人員-狀態分布圖
分析角度：從bug分配人員分布大概分析開發人員開發情況
根據bug數量按分配人員排序
從bug數量和狀態分析開發人員bug修改速度，並按bug修改數量按分配人員排序，描述無待修改bug的分配人員
從bug狀態分析開發人員bug修改的質量
c) 缺陷檢測人員-狀態分布圖
分析角度：從bug檢測人員分布分析測試人員的測試情況根據bug數量按檢測人員排序
從bug數量、結合測試階段分析測試人員的測試情況，及分析系統的穩定性
從bug狀態分析測試人員bug新建的情況，測試人員bug驗證情況
從bug狀態分析測試人員發現bug的質量
2.缺陷修改進度分析
維 度：缺陷狀態曲線圖、缺陷狀態餅形圖
缺陷狀態曲線圖
分析角度：從bug“新建”狀態曲線、結合測試階段分析系統測試情況、開發人員修改情況、及系統穩定性
從bug“已修改”狀態曲線分析開發人員bug修改的速度
從bug“已關閉”狀態曲線分析測試人員bug驗證情況
從bug“不是bug” 狀態曲線分析測試人員在整個測試階段，和某個測試階段發現bug質量
從bug“bug重現”狀態曲線分析開發人員修改bug的質量
3.生產機缺陷狀態曲線圖
維 度：缺陷狀態曲線圖
缺陷狀態曲線圖
圖形描述：X軸—bug主題 Y軸—bug狀態
分析角度：從bug在生產線上的分布情況，結合測試計划樹結構，分析哪些bug是在下發包主動沒有驗收測試通過的bug，或是在生產線上新產生的bug。(分析生產線上bug類型，是新建bug，還是生產線上bug重現)
從bug在生產線上的分布情況分析，如果bug是沒有驗收測試通過的bug，分析沒有通過的原因（測試環境，測試數據，測試版本，測試要點等因素）。
4.缺陷報告：標准缺陷報告
(四)缺陷實體分析
1.bug嚴重程度分析
維 度：bug嚴重程度
分析角度：從餅形圖中可以很直觀的了解，目前系統發現的bug中百分之幾是嚴重程度為“中”；百分之幾嚴重程度為“高”；百分之幾嚴重程度為“緊急”；百分之幾嚴重程度為“非常高”。從而了解整個系統的缺陷情況，對開發工作起到一個指導性的作用。
2.bug產生原因分析
維 度：bug產生原因
分析角度：目前在QC中增加實體”bug產生原因”,共分為四種
類型:需求階段、設計階段、版本管理階段、編碼階段.
從餅形圖中可以很直觀的了解，目前系統發現bug的產生原因分布情況,長期就會總結出系統經常出現問題的部分和原因,從而對系統開發過程和管理過程有一個更深刻的了解,對開發、測試、管理起到一個原因分析的指導性作用。
(五)生產機缺陷分析
1.bug注入原因分析
維 度：bug注入原因
分析角度：從餅形圖，分析由於新需求變更產生bug所占比例，系統原有bug所占比例。
從餅形圖中可以很直觀了解，生產機bug得產生原因分布，分析系統質量、穩定性，結合bug產生原因分析系統修改質量。
2.bug嚴重程度分析
維 度：bug嚴重程度分析
分析角度：從bug在生產線上的分布情況，分析哪些bug是由於新需求變更產生得，哪些是系統原有bug。
從bug在生產線上得注入原因分布情況，分析系統質量、穩定性，結合bug產生原因分 析系統修改修改質量及修改穩定性。
3.bug主題分析
維 度：bug主題分析
分析角度：從bug主題分布情況，分析生產機bug程序分布。分析生產機bug多發部分，進行原因分析，為后期的測試和開發提供指導。
4.bug產生時間分析
維 度：bug產生時間分析
分析角度：按月度統計生產機bug出現數量，完成《bug階段行分析統計表》。
5.bug發布區間分析
維 度：bug發布區間分析
分析角度：分析bug的“生產機發布區間”“UAT環境發布區間”。從bug生產機發布區間分布圖分析生產機bug修復后發布到生產機的時間，進而分析bug發布周期，如果時間較短證明問題嚴重級別較高，必須及時解決，如果發布周期過長說明修改質量和速度要進行改進。
從bugUAT環境發布區間圖分析生產機bug發布到驗收環境的時間，進而分析bug修改和驗證速度，對內部測試和bug修改進行評估。
6.bug提出方式分析
維 度：bug提出方式分析
分析角度：從bug提出方式分析生產機bug中，以工單形式提出所占比率.
C.生產機bug管理
針對生產機bug，在QC中錄入時，必須錄入如下信息：
*項目－生產機bug所屬QC中項目
*主題－所屬子項目
*嚴重程度（Bug級別）－bug嚴重程度級別？（統一級別）
*檢測日期（生產機bug發生月度）－生產機bug發生時間
*檢測版本－生產機bug發生得版本
*產生原因－bug產生是因為編碼、需求、分析、設計等
*產生階段－生產機bug產生階段就是“驗收測試”。是否需要
*分配給（責任人）－bug負責人
*生產機發布區間－bug從發現到修復后發布到生產機得時間，例如3天
*UAT環境發布區間－bug從發現到修復后發布到驗收測試環境時間
*注入原因－生產機bug發生原因，例如：因為新需求產生或系統原有bug
提出方式－例如：由客戶發現提出工單形式、由內部測試人員測試發現等。