10.测试执行

概念:根据编写的测试用例,按照用例步骤进行执行,查看预期结果和实际结果是否一致,如果不一致则为bug (缺陷)

参考依据:测试用例

执行人:软件测试工程师

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

时间周期:占整个项目周期40%左右的时间

测试执行过程中的时间安排,假设总的项目为66天,测试执行的时间为:66*40%=26天

测试执行分为3轮,时间安排如下:13:8:5---->按照5:3:2的比例进行安排

若测试分为4轮,时间安排如下:10:8:5:3---->按照4:3:2:1的比例进行安排

10.1 测试用例的执行结果状态

new:用例编写完成,未开始执行的状态

pass:执行用例预期结果和实际结果一致

fail:执行用例预期结果和实际结果不一致

block:当因为软件有缺陷妨碍了用例的执行,并且该缺陷不是该用例的关注点

investigate:当用例在执行过程中需要消耗较多的时间来观察期间的结果

10.2 测试过程中的注意事项

搭建软件测试环境

测试用例需要全部执行

不要忽视任何偶现bug

加强测试过程中的记录

提交缺陷和开发关系处理恰当

提交一份优秀的问题报告单

及时更新测试用例

10.3 提交的缺陷开发不认可,怎么处理?

1.首先进行自我检查,依据需求确定该缺陷是否有问题

2.确认是问题,拿出依据与开发人员有理有据地沟通

3.沟通无效,告知测试经理,将问题升级提交项目变更控制委员会CCB进行裁决是否为问题

10.4 缺陷的分布特性

1.群集现象(二八原则)

2.测试进行的越多,新缺陷就越难发现,此时需要拓展测试思路,寻找新的突破点

3.并非所有的缺陷都需要修复

​ 1.修复风险太大,不值得修复

​ 2.没有足够的时间进行修复,并且遗留的bug不会影响版本发布新功能

10.5 测试执行过程中发现bug太多,你会怎么处理?

1.冒烟测试进行的不充分,不彻底

2.发现bug越多的模块,残留的缺陷也越多,同时说明开发编码质量太差,会影响到测试的质量和效率

3.我们需要将版本打回,要求开发人员自测,自测通过后再提交代码

10.6 幽灵(偶现)bug的处理方式?

1.截图,保留证据,必要时录制视频,抓包,查看日志文件

2.在本机进行多次尝试该问题,若能够重现该问题,则记录

3.若本机不能重现,在其他电脑上尝试是否能够重现

4.在其他电脑上无法重现,但是问题比较严重,找到开发人员进行协助定位

5.对于难以重现的问题,需要将问题单挂起,看后续版本是否存在,后续版本如果不存在,则关闭。

10.7 缺陷的组成

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

1.缺陷ID:缺陷编号,bug管理系统自动生成的编号

2.缺陷标题:对发现的bug通过简洁的文字进行描述

3.缺陷的状态:

​ 1.测试发现问题,使用bug管理工具提单至开发人员,bug状态为new

​ 2.开发打开bug单,确认问题是否存在,bug状态为open

​ 3.开发确认是bug,将bug修改完成后,bug的状态为fixed

​ 4.开发给出依据确认不是bug,bug状态为rejected

​ 5.测试回归bug,验证通过,bug状态为closed

​ 6.测试同意开发给出不是bug的依据,关闭问题单,bug状态为closed

​ 7.开发确认测试提的问题是问题,但延迟解决,bug状态为pending(挂起)

​ 8.测试回归bug,验证不通过,bug状态为reopen

bug的状态流程:

4.缺陷级别

致命:程序的主要功能丧失,闪退,崩溃,报5xx,如:无法登陆,无法注册等

严重:次要功能没实现,引发部分功能无法使用,如:无法删除商品,新增商品失败,编辑商品失败

一般:基本功能实现,但是边界值错误,或者某些重要功能的异常情况错误

轻微:界面排版错误,系统操作不方便,但是可以使用

5.bug的优先级:1(致命)2(严重)3(一般)4(轻微)

6.测试版本:即本次发布新功能的版本号

7.测试阶段:

BVT(build verification testing):冒烟测试

SIT(system integration testing):集成测试

UAT(user acceptance testing):用户验收测试

8.缺陷类型:

文档缺陷:文档不容易理解,文档缺失,文档描述有误

设计缺陷:主要是指需求设计不合理

配置缺陷:软件在安装时出现的错误

界面缺陷:系统界面排版错误,界面文字错误

功能缺陷:需求规格说明书中要求的功能没有实现

性能缺陷:业务处理性能低,查询性能低,统计报表性能低

9.缺陷描述:又称重现步骤,指导开发人员怎么样重现问题

10.实际结果:执行用例后得到的结果

11.预期结果:需求中期望得到的结果

12.bug所属模块:bug在哪个模块下测试发现的

13.提交人:发现问题的测试工程师

14.提交时间:发现问题的时间

15.修改人:缺陷修复对应的开发人员

16.修改时间:开发修复完bug的时间

17.关闭时间:软件测试工程师关闭问题的时间

18.附件:主要是为了方便开发人员快速定位问题,提供分析问题的依据,如:截图,视频,抓包,日志文件等

10.8 提单的5C原则

correct(准确):问题单中每个组成部分描述准确,不会引发误解

clear(清晰):问题单中每个组成部分描述信息易于理解

concise(简洁):只包含必不可少的信息,不包含任何多余的信息

complete(完整):包含重现该缺陷的完整步骤

consistent(一致):按照一致的格式书写全部问题单

10.9 缺陷的生命周期

提交-->确认-->分配-->修改-->验证-->关闭

10.10 常用的bug管理工具

禅道(Zentao),bugfree,QC,mantis,DTS(华为),TAPD(腾讯),jira

Last modification:May 9th, 2021 at 10:58 pm
If you think my article is useful to you, please feel free to appreciate