本期导航：测试工作流程 软件缺陷 缺陷报告样例
关键词：缺陷状态 缺陷等级 缺陷报告规范 缺陷查找
目录
一、软件的生命周期
软件生命周期包括可行性分析、需求分析、概要设计、详细设计、编码、测试、维护7大阶段。
不同阶段对应的岗位及职责如下：
二、测试工作的流程
测试工作包括以下步骤：需求分析、设计测试计划、设计测试用例、执行测试、测试评估。
各个阶段任务如下：
需求分析阶段：依据需求文档，设计、开发、测试三方举行会议，明确需求，消除歧义。
设计测试计划阶段：依据需求文档，由测试组长（测试经理/测试负责人）设计测试文档并召开评审。测试计划主要涉及功能模块的划分、人员安排、测试方法、测试工具、进度安排、资源分配、风险分析等。
设计测试用例阶段：依据需求文档、设计文档、用户手册，测试人员按分工设计测试用例，完成后进行评审，保证用例正确、覆盖全面、对需求无遗漏。
执行测试阶段：搭建环境、执行用例。
测试评估阶段：出具测试报告，上线或者打回。
三、软件缺陷
bug一次来源：1945年，一只小飞蛾钻进了计算机电路里，导致系统无法工作，一位名叫格蕾丝·赫柏的人把飞蛾拍死在工作日志上，写道：就是这个 bug (虫子)，害我们今天的工作无法完成。
后来，bug一词成了电脑系统程序的专业术语，形容那些系统中的缺陷或问题。
IEEE 1983 of IEEE Stardard 729中软件缺陷做了一个标准的定义：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
因此，软件缺陷定义为：
软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
缺陷产生根源：
交流不充分、软件的复杂性、开发任务的错误、需求的变化、进度压力。
具体包含：
未达到需求规格说明书中的功能；出现了需求规格说明数中指名不会出现的错误；功能超出了需求规格说明书的范围；未达到需求规格说明书中虽然没有指明，但应该达到的目标；测试人员或者用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好。
缺陷的状态：
new 新建, 缺陷的初始状态
assigned 已指派，分配给具体的开发人员
open 打开, 开发人员开始修改缺陷
fixed 修复,开发人员修改缺陷完毕
closed 回归测试通过,关闭缺陷
reopen 回归测试失败,再次打开
postpone 推迟修改
duplicate 与已提交的Defect重复
reject 拒绝修复，可能为测试人员与开发人员对于需求理解不同
缺陷的优先级：
P1 立即解决
P2 高级优先
P3 正常级别
P4 低优先级
缺陷的严重程度
Fatal 致命的缺陷
Critical 严重错误的软件缺陷
Major 一般的软件缺陷
Minor 较小的软件缺陷
Enhancemental 建议问题
缺陷的流转图示：
四、缺陷报告
缺陷报告原则：
一个缺陷一个报告
5C准则：准确、简洁、清晰、完整、一致
准确：每个组成部分的描述准确不会引起误解。
简洁：只包含必不可少的信息，不包括任何多余的内容。
清晰：每个组成部分的描述清晰，易于理解。
完整：包含复现该缺陷的完整步骤和其他本质信息。
一致：按照一致的格式书写全部缺陷报告一个缺陷一个报告
缺陷报告书写规范：
标题要求
简短
尽量能够体现 原因和结果
准确：避免使用模糊不清的词语
便于他人理解，不要使用俚语、方言词汇
内容要求：
测试环境描述
测试步骤
加上编号
一个步骤不要包含太多步骤
可以将多个步骤合为一个
可以包含 该步骤后的一个中间结果
可使用短语或者短句，不需要复杂句式
实际结果 清楚，不笼统
期望结果 根据需求文档，应该出现的结果
附件 截图、录屏、测试中需要的数据
常见缺陷的查找方法：
UI：字体、图片、布局
大小：时间网络、传输数据未压缩、解析困难
文字内容：描述不清、描述不正确、有语病或错别字、太复杂、乱码
性能缺陷：花费时间长、资源占用多、卡顿、并发差、延迟高
容错处理
五、缺陷报告样例
常用的缺陷管理平台如禅道，提交bug的页面如下：
主要包括以下要素
- 所属产品/项目/模块
- 影响版本
- 指派人员
- 反馈者
- 测试环境（操作系统、浏览器）
- bug类型
- bug优先级
- bug严重程度
- bug标题
- 复现步骤
- 截止时间
本期内容完整介绍如上，本篇也是测试理论最后一篇，关于软件测试模型、测试用例、测试用例模板的介绍在该系列中理论篇第一篇，需要了解的可以关注一下。
2680
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
