目录
测试执行的要点
测试执行的要点:
- 根据测试用例优先级来执行测试用例(冒烟测试就是测试软件的基本功能或是核心功能是可用的,冒烟测试就是测试优先级最高的用例)
- 比对实际结果与测试用例中的预期结果是否一致
- 一致:用例执行通过。
- 不一致:用例执行失败
- 无法执行:用例阻塞
- 对于用例执行不通过:需要记录并提交缺陷
- 更新维护测试用例:遗漏/冗余/无法操作
软件缺陷
缺陷定义
软件在使用过程中存在的任何问题都叫软件的缺陷,简称bug。
缺陷的判定标准
- 软件未实现需求(规格)说明书中明确要求的功能(少功能)
- 软件出现了需求(规格)说明书中指明不应该出现的错误(功能错误)
- 软件实现的功能超出需求(规格)说明书指明的范围(多功能)
- 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求(隐性少功能)
- 软件难以理解,不易使用,运行缓慢,用户体验不好(不易使用)
缺陷的产生源头
需求阶段:需求描述不易理解,有歧义、错误等。
设计阶段:设计文档存在错误或者缺陷。
编码阶段:代码出现错误。
运行阶段:软硬件系统本身故障导致软件缺陷。
缺陷的生命周期
注意:在故障解决(即修改缺陷阶段)也可能会引入新缺陷,这时候要进行回归测试(回归测试是一个系统的质量控制过程,用于验证最近对软件的更改或更新是否无意中引入了新错误或对以前的功能方面产生了负面影响)。
缺陷跟踪流程
注意:是否重复,是开发人员判断该缺陷是否和缺陷库中的某一条缺陷重复,如果重复,就直接关闭缺陷,测试人员如果不认可该做法,认为确实是新的缺陷,可以重新打开该缺陷。
缺陷提交需要注意的事项
- 提交的缺陷是开发可以复现的(偶发缺陷也要上报,要提供证据(比如截图))
- 注意一个缺陷不要上报多个一样的
- 提交的缺陷要规范(符合公司或项目要求)
缺陷编写规范
- 编写缺陷时,注意描述信息是准确的
- 编写缺陷时,描述简洁易懂
- 编写缺陷时,描述缺陷的细节应是真实具体的
- 编写缺陷时,描述缺陷的复现步骤要次序清晰,有先后
描述缺陷需要的要素
核心要素:
- 缺陷的标题(描述缺陷的核心问题)
- 缺陷的预置条件(缺陷产生的前提条件)
- 缺陷的复现步骤(复现缺陷的过程)
- 缺陷的预期结果(希望得到的结果)
- 缺陷的实际结果(实际得到的结果)
- 缺陷的必要附件(图片,日志等,方便开发人员更直观的分析和解决缺陷)
其他要素:
- 缺陷报告编号(缺陷的唯一性标志)
- 严重程度(公司/项目组可以定制自己的级别,一般越影响用户使用,级别就越高):
- 严重(S1):主功能
- 一般(S2):次要功能
- 微小(S3):易用性、界面
- 建议(S4):建议性问题
- 缺陷优先级(公司/项目组可以定制自己的级别):
- Priority 0:24小时之内解决
- Priority 1:发布前必须修复
- Priority 2:可以在下一个版本中修复
- Bug类型(功能错误、UI错误,兼容性问题、数据错误,易用性问题,建议性问题,架构错误,性能问题)
- 缺陷状态(从发现到解决):
- New:新建(测试人员提交了一个缺陷)
- Submitted:提交,测试人员已提交的缺陷
- Open:打开(缺陷确认并分配给某个开发人员)
- Resolved:开发已修复缺陷
- Closed:关闭(缺陷修复后,再测试发现没有问题,将缺陷关闭)
- Postponed:延期(开发人员将该缺陷放置到后续版本解决)
- Reopen:重新打开(测试人员回归测试不通过后设置)
- Rejected:驳回(研发评测缺陷不需要修改或者缺陷说明不清楚时设置)
注意:严重程度高,缺陷优先级不一定高(比如:修复成本高,涉及到架构的调整,那么给与的修复时间就要多一点)
缺陷报告案例
如:针对下面的测试用例,编写缺陷报告
缺陷报告
缺陷ID | 缺陷标题 | 缺陷状态 | 严重程度 | 优先级 | 所属模块 | 缺陷描述 |
bug_001 | qq号为空,下一步的按钮可点击 | new | S1 | P0 | 转账 | 【前置条件】:打开qq转账界面 【测试步骤】:1.输入qq号 2.点击下一步 【测试数据】:qq号为空 【预期结果】:下一步按钮置灰 【实际结果】:下一步按钮可点击 【附件】:/ |