1、缺陷介绍
缺陷定义:软件在使用过程中出现的任何问题都叫软件的缺陷,简称bug
软件缺陷判定标准:
1、软件未实现需求(规格)说明书中明确要求的功能--也就是少功能
2、软件出现了需求(规格)说明书中指明不应高出现的错误--也就是功能错误
3、软件实现的功能超出需求(规格)说明书指明的范围--也就是多功能
4、软件未实现需求(规格)说明书中虽未指明但应该实现的要求--也就是阴性功能错误
5、软件测试人员认为:软件难以理解、不易使用、运行缓慢、用户体验不好--也就是不易使用
缺陷产生原因:
1、需求阶段:需求描述不易理解、有歧义、错误等。
2、设计阶段:设计文档存在错误或缺陷
3、代码阶段:代码出现错误
4、运行阶段:软硬件系统本身故障导致出现软件缺陷。
软件缺陷的生命周期:
缺陷核心内容(缺陷的描述【告诉别人缺陷是什么、发生在哪里、如何发生的】、缺陷的提交要素):
1、缺陷的标题:描述缺陷的核心问题
2、缺陷的预置条件:缺陷产生的前提
3、缺陷的复现步骤:复现缺陷的过程
4、缺陷的预期结果:希望得到的结果
5、缺陷的实际结果:实际得到的结果
6、缺陷的必要附件:照片、日志等信息(证据)
缺陷提交要素:
缺陷类型:
1、功能错误
2、界面(UI)错误
3、兼容性
4、数据
5、易用性
6、改进建议
7、架构
2、回归测试
定义:添加新功能之后为了避免原有的功能无法使用,需要对之前已经测过的功能进行再次测试
常规测试:一般指测试新增功能所涉及的模块
非常规测试:例如军工、航天等,需要保持高度的严谨性,所以在添加新功能之后前面所有的功能都需要重新测一遍。
3、回归bug
指的是:在上一个版本当中出现过的bug,需要在新的版本当中进行再次验证。
4、缺陷编写
缺陷报告示例:
缺陷跟踪流程:
提交缺陷注意事项:
1、可重现(缺陷可以重新复现)
2、唯一性(一个缺陷只上报一个问题)
3、规范性(符合公司或者项目要求)
缺陷编写规范:
1、准确(描述的缺陷信息是正确的)
2、简洁易懂(缺陷信息描述简单、便于理解)
3、具体(有细节,且是真实特定的)
4、次序清晰(描述缺陷过程有条理,有先后顺序)
5、缺陷标题分析
缺陷标题的作用:让人明白是哪里错了
如何让人明白哪里错了:
描述测试数据+实际结果(预期结果)
描述测试数据+预期结果(实际结果)
描述测试数据+实际结果(需求)
6、使用Excel或工具对缺陷进行管理
Excel:
缺陷编号
缺陷标题
缺陷状态
严重程度(严重级别)
优先级(什么时候修复)
模块
缺陷描述
附件
其他:
指派人
缺陷类型
工具:
禅道(提交与关闭):
介绍:开源免费、轻量级使用简单
特点:
三权分立:
产品部门--构想者
研发部门--执行者
测试部门--保证者
四角协调:
产品经理
项目经理
研发团队
测试团队
缺陷管理流程:
提交、验证、关闭