共计 1344 个字符，预计需要花费 4 分钟才能阅读完成。
download：体系课 - 全能软件测试工程师无密完结
1. 缺点的定义
产品不满足用户的需要或者测试执行时理论后果和预期后果不统一都属于缺点。
2. 缺点的断定规范及产生起因
软件不满足下述任何一种都算作是软件的缺点，缺点的概念是包含 bug 概念的。
未达到需要说明书指明的性能
呈现了需要说明书指明不应该呈现的谬误
实现了需要说明书之外的性能
未达到需要说明书虽未明确提及然而应该实现的指标（如：性能要求等）
用户角度发现的各种问题与谬误
缺点产生的起因是多方面的，能够总结为以下几种：
需要文档存在谬误
程序代码存在谬误
同一个项目组的成员信息不同步，比方需要产生变更，然而没有同步到项目组所有成员
- 缺点报告
测试人员发现缺点之后，须要将缺点同步给项目组的其余成员，为了让其余成员可能清晰的晓得软件目前存在的缺点，就须要对软件缺陷的形容进行规范化，通常来讲测试人员须要将发现的缺点整顿成缺点报告而后通过一些平台比方禅道或者 jira 指定给项目组的指定成员，而后由他们进行解决。
缺点报告首先必须有以下几个外围的内容：
题目：形容缺点的根本信息，如（输出明码长度为 5 时，注册胜利。）
前置条件：形容缺点呈现依赖的相干根底条件，如（未注册手机号）
复现步骤：测试用例外面的执行步骤
理论后果：执行被测试软件过程中，零碎给出的后果
预期后果：参照需要说明书，在测试用例中设计的预期后果
附件：不便开发定位 bug 的要害信息，蕴含图片、日志 log 等
有了上述几个核心内容之后，开发人员基本上能够依据所给信息去定位缺点，而后进行解决，当然缺点报告还有一些其余的基本要素：
ID 编号：缺点的惟一编号
模块：依据产品进行具体的划分，如登录、注册
缺点状态：表明缺点解决进度，通常会应用禅道等工具进行治理，缺点状态有以下几种
new：新建的缺点
open：关上的缺点
fix：已修复的缺点
close：敞开的缺点
reopen：从新关上
reject：被回绝解决的缺点
postpone：延期解决
重大水平：从技术维度来掂量，bug 的破坏力
优先级：从业务的角度，决定 bug 批改的先后顺序
缺点类别：用于分类整理缺点，通常缺点类别能够从以下几个角度进行辨别：
功能性谬误
非功能性谬误
界面谬误
兼容性
易用性
…
缺点报告十分重要，合格的缺点报告能够帮忙解决缺点的开发人员更快的复现和定位缺点，因而缺点报告必须保障可能让开发人员复现缺点。通常在编写缺点报告时能够遵循以下书写标准：
题目：应放弃简短、精确，提供缺点的实质信息
复现步骤：应蕴含如何使他人可能很容易的复现该缺点的残缺步骤
理论后果：是执行复现步骤后软件的景象和产生的行为
预期后果：通常须要列出冀望的后果是什么
附件：对缺点形容的补充阐明
- 缺点跟踪流程
应用禅道或者 jira 进行缺点跟踪时，依据不同的场景会产生不同的缺点状态。下图是缺点跟踪流程图，每一条流程示意一种场景。
场景 1：确认 BUG 解决
测试【new】》开发【open】》开发【fix】==》测试【close】
场景 2：验证未通过，缺点仍存在
测试【new】》开发【open】》开发【fix】==》测试【reopen】
场景 3：开发延期解决
测试【new】》开发【open】》开发【postpone】
场景 4：回绝解决
测试【new】》开发【open】》开发【reject】作者：程序媛小庄链接：
