测试人员在做什么
传统的软件测试,开发人员完成编码后,交付给测试人员,这种模式下,测试人员不能及早发现需求阶段的缺陷,同时测试工作的开展也滞后了,产品质量得不到有效的过程控制和分析,总体进度可能会由于返工问题造成拖延。
如今的软件测试,测试在做什么?
首先是需求阶段测试在做什么:
参与stroy分析、评审,需求澄清,记住一点测试永远要比开发更了解业务。开发需要stroy评估,测试也需要stroy评估,排除技术上的问题把业务放在第一位。
再就是编码阶段测试在做什么:
功能要点确认的过程也就是需求澄清的过程,只有开发与测试对需求功能点没有异议,后续的工作才能顺利的进行。
测试用例的设计前提是明确了需求,以功能实现、业务逻辑、数据流程为原则设计测试用例。测试用例按项目要求分清等级,一级用例为主流程用例,也是开发人员自测用例。二级用例为功能分支用例,在不影响主流程的前提下功能堵塞、功能未实现用例。三级用例是异常行为用例,包括性能、安全、用户适应度等问题。分清用例等级可以更有效的管理统计测试结果。
用例评审是必不可少的环节,可以帮助测试人员补充遗漏问题和解决分歧问题。
测试探索是进行了功能要点确认和用例评审后,为了保证测试场景的覆盖率,需要再进行测试探索。在开发人员完成雏形之后,使用探索式测试的策略,对功能基本流程进行有目的的快速走查,挖掘功能不确定的地方和补充测试场景,避免不确定的因素拖延到开发阶段后期,造成返工。
功能测试、Bug Tracking、回归测试、系统测试、验收测试都是日常测试工作所需环节,不再一一说明了。
测试完毕,测试还需要做些什么?
一:测试报告:
完成验收测试,提供测试报告,给出测试数据度量,例如:
1) 测试发现缺陷总数:测试过程中产生的去除状态为“无效”、“不用改”的缺陷数目。
2) 测试发现严重缺陷数:测试过程中产生的并去除状态为“无效”、“不用改”的、且严重性为“Major”和“Critical”的缺陷总数目。
3) 测试发现缺陷修复数:测试过程中产生的状态为“已关闭”的缺陷数量;
4) 未解决缺陷数:去除状态为“无效”、“不用改”、“关闭”的缺陷总数。
5) 缺陷修复率:(测试发现缺陷的修复数)÷(测试发现缺陷总数)×100%
6) 严重缺陷率:(测试发现严重缺陷数)÷(测试发现缺陷总数)×100%
7) 严重缺陷修复率:(已修复的严重缺陷数)÷(测试发现严重缺陷数)×100%
8) 测试需求覆盖率:已测试需求个数÷需求总数×100%
二:缺陷统计分析报告
另外,测试人员还有一项重要工作,对当前版本的缺陷进行统计分析:
按缺陷级别统计:
测试进度和问题分析:
1、从BUG的严重级别分布来看,Major级别以上的BUG占12%,占的比重不高,说明大部分的主要功能已经实现了;
2、其中在sonar定义级别的缺陷,主要集中在代码规范和单元测试覆盖率,说明代码质量有待提高;
3、版本测试的前期时间较充足,后期随着开发提交完成的功能点增多,BUG数量增多,剩余测试时间变得紧张;
4、在版本测试期间,发现测试环境存在一次代码被覆盖、两次因开发人员操作失误影响测试执行的情况;
小结:
测试人员应当持续反馈、改进、总结每个版本发生的问题(不管是缺陷,还是过程中出现的),并对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。
敏捷测试团队,不再仅仅是在coding之后。而是和研发人员贯穿在需求分析、规格说明、自动化单元测试、自动化验收测试、静态代码分析、技术债等环节中。所以敏捷项目必定在将来效率的趋势下成为主流。
加微信:wonter 发送:技术Q
医疗微信群:
加微信:wonter 发送:医疗Q
更多文章关注公众号:
![](https://images.cnblogs.com/cnblogs_com/Javame/604499/o_cto.png)