18测试讲解如何正确填写bug.pptx

如何正确填写缺陷 ;必要性 缺陷数据项的正确、合理是所有度量分析的基础，是分析报告准确的保障 有了正确的缺陷信息，我们才能更好地有效利用缺陷数据，实现多纬度管理分析，并据此采取有效措施，切实提高测试效率，压缩测试时间。 清楚、明了的缺陷描述可以减少沟通成本，提高开发效率。;对缺陷填写的管理规则 定期抽验：测试经理会针对bug填写的规范性进行定期地抽验，抽验结果会在部门范围内公告并报告上级经理，对连续2次有抽验不合格的人员，将在研发范围内公告批评。 程序员对测试人员的每个缺陷，针对填写规范性进行打分，发版后会对本项得分进行综合评价。 ;“缺陷标题”如何填写 缺陷标题为必填项，一定要把此缺陷的关键词写上。例如：采购核销数据错；总账凭证选项控制错；应付业务明细账不能输出。。。。。。。 按关键字查询时，系统搜索缺陷标题的内容，恰当地填写标题将有助于以后的缺陷查找，尤其是缺陷量很大时 ;“缺陷描述” 如何填写 缺陷描述为必填项，总体要求是：要详细、全面地描述缺陷出现时的环境信息、条件、现象、前后操作步骤、错误表现、正确的应该是什么等，目标是编码人员、测试经理看到描述后能够明白并重现这个缺陷。 其他与缺陷描述相关的信息项，包括：版本、部门、产品、模块、测试类型、测试项目、问题类型、操作系统、数据库、服务器、测试语言及账套信息，一定要根据每个缺陷的实际情况填写或选择 。 ;比较规范的缺陷描述举例 （各部门可以结合自己的产品特点和新的测试系统，举更有针对性的例子） 将860XX地产的数据升级以后，登陆OA的车辆管理，进行用车统计时点击申请部门的参照，正确情况下该部门下面有36个人员，目前人员不能显示出来。 http://oatest/u8portal 帐套：003 郑州XX房地产 用户名：demo 密码：空 登录日期：2005-9-30 应用服务器bpmtest1,zt003,2003,预算项目设置了控制规则，在总帐中作凭证，控制科目如不在第一条分录，凭证超预算，凭证审核后传递超预算单据到预算系统中，此时可以取消启动控制规则；控制规则只能在没有中间单据的状态下才可以取消启??。 培训开发管理中，培训需求结点打不开。 新加的单据类型自定义项档案缺少英文、繁体资源。 缺陷描述一定要明确、清楚，让程序员明白，不一定多详细、复杂;不标准的缺陷描述举例 部分资源翻译不正确，采用了“ mark”替换，请修改。 数据权限设置中的分组无用?。 总账工具中右键菜单未按需求修改? 现金流量信息导入出错 开户银行子表和主表关联后，还要按公司过滤，请加上 到底说了什么？不明白！;“问题类型” 的明细规则 运行异常：运行某功能出现运行时错误或直接退出系统或出现灰屏等程序中断的错误。 功能不完善：需求、设计要求的基本功能没有完成或与要求不符、无法使用等错误。如：点“增加”就报错、单据不能保存等。 数据错误：由于各种原因引起的数据错误。 控制错误：正常业务逻辑中应该有的控制，或需求中明确写明的控制，在实际产品中没有控制或控制有误。 ;“问题类型” 的明细规则 2 易用性： 不符合用户日常使用习惯、操作非常不方便、与人机工程部要求不一致等错误。 文档类错误：帮助、关于、安装向导、说明信息、错别字等错误。 显示错误：界面显示乱码、错位、显示不下等。 提示错误：提示信息描述不清或是英文乱码等现象。 规范性：与统一要求不符、与人机工程部要求不一致等错误。 需求设计：需求、设计的错误。 ;“紧急程度 ”的填写规则 高: 死机、影响到其他组的工作进度无法进行；数据丢失，主要功能组完全丧失；系统死机导致的严重问题，或者致命的错误声明等。 中: 次要功能丧失；一致性错误；性能低下；界面显示错误；易用性缺陷；目前可以延缓解决的严重错误等。 低: 微小的问题，对功能几乎没有影响；用户使用不方便等。;其他信息项填写 “反复”：以前修改过的问题又出现了，或以前此功能正确由于修改其他错误而影响到此功能。 “重大”：严重的数据、流程错误，或会给用户带来不可恢复的灾难性错误。 “应避免”：如果程序实现人员或设计人员细心一些，或做过简单的单元测试就很容易发现的问题，对于这类问题认为是“应避免”的，否则认为是否。 ;“错误引入阶段”的定义 ---本项不是测试人员的必填项，但测试人员能够明显判断出引入阶段的，也应该填上 “1.编码阶段”： 本缺陷是由于编码阶段的工作引起的 “2.设计阶段”：本缺陷是由于设计阶段的工作引起 “3.需求阶段”：本缺陷是由于需求阶段的工作引起 “4.难以确定”：无法判断是那个阶段的原因引起的 ;“修改人填写规范性 ”的定义 ---本项由测试人员在验证缺陷时填写，主要评价修