QC使用入门

上一篇 / 下一篇  2018-11-06 16:11:02 / 个人分类：测试管理工具

查看( 1775 ) / 评论( 0 ) / 评分( 0 / 0 )

　　QC是Mercury的一个基于WEB浏览器环境下的测试管理工具，当前工作中用到的主要功能：测试需求管理、测试计划管理、缺陷管理。
　　一、QC使用简述
　　使用流程：登录系统---需求管理---测试计划管理---缺陷管理
　　1.系统登录：网页地址栏输入QC服务器地址，进入登录页面，输入用户名密码登录，根据客户需求定制相应部分。
　　2.需求管理：验证测试涵盖所有的产品需求，根据产品需求，生成测试计划草案，把测试项目同产品需求一一对应起来
　　需求管理流程：建立项目需求、建立子需求
　　3.测试计划管理：结构化组织测试活动（测试计划树）、测试案例、详细描述测试活动（分步骤）、相关文件可以作为附件、部分测试由手工测试过渡到自动测试
　　测试计划管理流程：需求转换成测试计划、生成测试用例。（测试执行结果有四种状态，分别是：FAILED：该计划执行失败、NORUN：该计划未执行、NOTCOMPLETED：该计划未完成或未完全通过、PASSED：该计划通过测试）
　　4.缺陷管理：从发现问题开始，包括问题定位、问题解决、对解决的确认、状态跟踪、邮件系统支持、统计处理
　　缺陷管理流程：新建缺陷、缺陷与测试计划关联、管理缺陷。
　　二、QC使用规范（限当前所参与项目）
　　1.bug生命周期：提出--修改--验证--关闭--生产机发布
　　2.bug优先级共分为五级：
　　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
　　提出方式－例如：由客户发现提出工单形式、由内部测试人员测试发现等。

收藏 举报

TAG: QC 测试工具 册数管理

 

评分：0

我来说两句

日历

« 2024-04-18  
日 一 二 三 四 五 六
 123456
78910111213
14151617181920
21222324252627
282930    

我的存档

数据统计

  • 访问量: 38487
  • 日志数: 42
  • 建立时间: 2018-11-01
  • 更新时间: 2018-11-06

RSS订阅

Open Toolbar