测试执行

定义：根据编写的测试用例，按照用例步骤进行执行，查看预期结果和实际结果是否一致，如果不一致则为BUG

参考依据：测试用例

执行人：软件测试工程师

开始时间：测试用例编写完成并且通过评审，且达到测试执行的启动条件

时间周期：占整个测试流程的40%的时间

测试用例执行结果状态：

• new：用例编写完成，未开始执行状态
• pass：用例执行结果与预期结果一致
• fail：执行用例结果和实际结果不一致
• block：因为软件缺陷导致后续用例执行无法进行，导致结果未知的状态
• investigate：测试用例正在执行中需要更多时间观察结果

测试执行中的注意事项：

1. 搭建软件测试环境
2. 测试用例需要全部执行
3. 不忽视任何偶现BUG
4. 加强测试过程中的记录
5. 提交缺陷和开发关系处理恰当
6. 提交一份优秀的问题 告单
7. 及时更新测试用例

缺陷分布的特征：

1. 缺陷的群集现象
2. 随着测试的进行，缺陷也越来越难被发现，此时需要调整测试思路，寻找新的突破点
3. 不是所有的BUG都需要解决
   （1）修改代价太大，不值得修复
   （2）修改时间不够，并且遗留的BUG不会影响版本发布新功能

出现幽灵BUG的处理方法：

1. 对出现的BUG进行记录，保留证据（视频，截图，抓包，日志文件）
2. 尝试重现BUG，如果重现就提交BUG单
3. 如果失败就在其他设备上尝试重现
4. 如果还是失败，就请开发进行定位
5. 开发也无法重现BUG就挂起BUG单，观察程序后续版本是否存在

缺陷的组成

缺陷ID、缺陷标题、缺陷状态、缺陷级别、缺陷优先级、测试版本、测试阶段，缺陷类型、重现步骤、实际结果、预期结果、缺陷所属模块、提交人、提交时间、修改人、修改时间、关闭时间、附件

缺陷状态：
new：测试发现问题，使用BUG管理工具提交BUG单至开发人员
open：开发打开BUG单，确认缺陷是否存在
fixed：开发确认为BUG，将BUG修改完成后
rejected：开发给出依据确认这不是BUG
closed：测试回归BUG，验证通过
pending：开发确认为BUG，延迟解决
reopen：回归测试BUG，验证不通过

• 致命：主流程出现缺陷，主要功能无法实现（闪退，崩溃，无法登陆等）
• 严重：次要功能没有实现，导致部分功能无法使用（无法删除，无法新增）
• 一般：基本功能实现，但是边界值错误
• 轻微：界面排版错误，系统操作不方便，但是可以使用

缺陷优先级：

分为四级：1,2,3,4级，优先级逐渐升高，4级为最高级，划分标准是看缺陷对软件的影响，一般与严重级别对应。

测试阶段：
BVT：冒烟测试
SIT：系统集成测试
UAT：用户验收测试

提单的5C原则：

1、准确：问题单中每个组成部分描述正确，不会引发误解
2、清晰：每个问题每个组成部分描述信息，易与理解
3、简洁：只包含必不可少的信息，不包含任何多余的信息
4、完整：包含重现该缺陷的完整步骤
5、一致：提交的所有BUG单采用相同的格式

缺陷的生命周期：
提交、确认、分配、修改、验证、关闭