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
提出方式－例如：由客户发现提出工单形式、由内部测试人员测试发现等。