本期导航:测试工作流程 软件缺陷 缺陷报告样例
关键词:缺陷状态 缺陷等级 缺陷报告规范 缺陷查找
目录
一、软件的生命周期
软件生命周期包括可行性分析、需求分析、概要设计、详细设计、编码、测试、维护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标题
- 复现步骤
- 截止时间
本期内容完整介绍如上,本篇也是测试理论最后一篇,关于软件测试模型、测试用例、测试用例模板的介绍在该系列中理论篇第一篇,需要了解的可以关注一下。