[开发测试]day_06_上_bug管理

1、测试用例评审

????????按是否正式
?? ??? ??? ?正式：会议评审，项目组人参与会议面对面进行交流评审
?? ??? ??? ?非正式：非会议评审，书面检查测试用例
?? ??? ?按参与角色
?? ??? ??? ?组内评审
?? ??? ??? ?项目组评审
?? ??? ??? ?客户评审

2、测试用例评审流程

????????

????????

测试组内部评审，一般评审彼此的用例，以文档检查的形式居多。若需求业务逻辑复杂，视情况开展会议评审。项目组评审主要是会议评审。
会议评审，一般测试负责人(参与测试的测试团队负责人，可能是测试主管、也可能是临时小组长)为会议主持人，会议评审开始时，一般先会大致介绍用例编写的思路，可以按照核心业务流程展开评审，再到各个不同的模块的用例设计，重点包括测试验证点、测试数据、预期输出。同时针对被指出的用例问题组织讨论并做好用例标记记录。会后，整理问题清单，并明确问题责任人。

?

?3、如何评审测试用例

《需求规格说明书》是否评审并建立了基线？
是否按照测试计划时间完成用例编号？
需求新增和变更是否进行了对应的调整？
用例是否按照公司定义的模板进行编写？
测试用例是否覆盖了《需求规格说明书》？
用例编号是否和需求进行对应？
非功能测试需求或不可测试需求是否在用例中列出并说明？
用例设计是否包含了正面、反面的用例？
每个测试用例是否清楚的填写了测试特性、步骤、预期结果？
步骤/输入数据部分是否清晰，是否具备可操作性？
测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？
测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？是否针对需求不同部分设计使用不同设计方法？
重点需求的用例是否至少使用了三种设计方法？
每个测试用例是否都阐述预期结果和评估该结果的方法？
需求进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？
用例覆盖率是否达到相应质量指标？
用例预期缺陷率是否达到相应质量指标？

4、bug管理

????1、bug分类

	按严重程度划分为5个等级
	系统崩溃，严重，一般，次要，建议

? ? 2、按优先级划分

Immediate 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
Urgent 即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
High 即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
Normal 即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
Low 即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。

??????????????????????????????????????????????????????????????????????????????????????????bug定级示例

?

? ? 3、按照测试种类分

????????逻辑功能类，性能类，界面类，易用性类，兼容性类

? ? 4、按照功能模块分

????????登录注册，订单模块，购物车，个人信息等

? ? 5、按解决方案划分

????????1、无效类bug

By Design 程序设计问题，非编码问题
Duplicate 别人已发现的问题，重复提交bug
Not Repro ?开发无法复现 ?需要测试去帮开发复现bug

? ? ? ? 2、有效类bug???? ? ? ?

Fixed  已修复  需要回归验证
External 外部问题，非编码问题 系统问题
Postponed 发现太晚 前提（小问题）
Won't Fix  是个bug但不修复

?

? ? 6、缺陷管理流程

1、登录到公司的缺陷管理平台
2、新建bug
	1、填入bug详细信息（标题，复现步骤，预期与实际结果，相关截图。优先级）
	2、指定解决者（开发人员）
	3、bug状态标注为 new
	4、提交
	5、开发人员接收bug之后，会进行bug状态的修改
		如果开发已修复  fixed
		那么代表测试人员可以对这个bug进行回归验证了
		确认已修复
		closed 关闭bug
		确认未修复完
		open 重新打开
	6、将所有的bug全部closed

????????????????总结:新建-确认-解决-重新验证-关闭-重新打开

5、缺陷报告（Bug报告，提的Bug）?

?

?

?? ?

?

?

?

?