共计 1001 个字符，预计需要花费 3 分钟才能阅读完成。
一、缺点介绍
1.1 缺点的定义
软件在应用过程中存在的各种问题叫做缺点 (bug)1.2 缺点的断定规范
- 软件未实现需求说明书明确要求的性能 —- 少性能
- 软件呈现了需要说明书中指明不应该呈现的谬误 —- 性能谬误
- 软件实现的性能超出需要说明书没有要求的性能 —- 多功能
-
软件未实现需求说明书中未明确但应该实现的性能 —- 隐形性能缺失
页面有跳转，应用到该数据的中央同步更新 - 用户体验差，运行迟缓，不易应用、软件难以了解 —- 不易应用
1.3 缺点的产生起因
目标：通过缺点起因分类，可能验证公司职能部门素质，提交 bug 时能够对 bug 分类，不便后续总结
- 需要阶段：需要形容不易了解，有歧义，谬误等
- 设计阶段：设计文档存在谬误或者缺点
- 编码阶段：代码呈现谬误
- 运行零碎：软硬件零碎自身故障导致软件缺陷
1.4 缺点的生命周期
1.5 缺点的核心内容
如何编写测试报告
1.6 缺点提交因素
- 缺点的编号：示意缺点唯一性
- 缺点的重大级：示意缺点的重大水平（S1 S2…..）
- 缺点的优先级：示意缺点修复的紧急水平（P0 P1 …）
- 缺点的类型：性能、性能、界面（UI）、兼容、平安 ….
- 缺点的状态：new closed (reopen)
1.7 用例执行
-
执行用例模板
- 减少一列理论后果（示意曾经执行的用例）
-
执行的后果
- 通过（pass）
- 失败（failed）
- 阻塞（block）：示意用例某个步骤执行不上来了，找开发解决该问题
- 不实用（N/A）：示意曾经编写的用例作废了
-
执行的前提
- 开发的零碎曾经实现
- 冒烟测试通过
二、编写缺点报告
2.1 缺点的跟踪流程
目标：搞清楚工作中如何和开发协同解决 Bug, 直到 bug 革除 (敞开)
本人叙述：测试进行提交缺点，领导调配 Bug，开发来验证该 bug 是否反复，如果反复，则敞开缺点；如果不反复，则验证该缺点是否是真正的 bug，如果不是，则敞开缺点；如果是，则依据该 bug 的优先级来评测该缺点是否推延解决，若优先级较低，则能够在后续版本中进行修复；若优先级较高，须要尽快解决该缺点，开发缺点修复实现后，测试要再次依据测试用例来进行回归测试，若验证通过，则敞开缺点，若不通过，则从新关上缺点。注：语言组织可能不好，仅供参考，多多指教
2.2 缺点报告注意事项
- 可重现 —- 缺点要可重现
- 唯一性 —- 一个缺点上报一个问题
- 规范性 —- 合乎公司或者我的项目要求
2.3 缺点编写标准
- 精确、具体
-
简洁易懂、秩序清晰
2.4 缺点报告模板
注：依据本人公司的模板来，能够不必这个
正文完
