QC使用入门

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


  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.测试用例编写
  测试用例的编写时间(最早启动时间):
   单元测试用例:编码阶段
   集成测试用例:设计阶段
   系统测试用例:设计阶段
   验收测试用例:需求阶段
  QC工具中添加测试案例注意:
   详细填写测试案例每一项信息
   测试案例名称为“测试用例的路径+测试点”(不超过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

我来说两句

日历

« 2022-01-16  
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

我的存档

数据统计

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

RSS订阅

Open Toolbar