测试人员共同的焦虑,在于花了大量的时间去测试这个小场景,测试那个小场景,最后发现除了提交几个EC之外,没有对自己有一个体系的提升。
本文从管理的角度,去分析一下,测试人员的工作现状,产生这些现状的原因,以及如何去有效的做好测试。
- 现状
按照一个release(30天)来计算:
类型 | 内容 | 时间 |
---|---|---|
需求确认 | 和开发、业务人员开会讨论需求,确认理解一致 | 5天 |
测试用例设计 | 结合用户业务故事,从用户的角度去考虑 | 10天 |
测试脚本执行 | 利用工具,针对可自动化的用例进行集成,针对不可自动化的用例,保留步骤、参数和结果 | 15天 |
需求
- 更多的是继承以往经验。比如一些成熟的模块,再次测试时往往可以借助已有的测试脚本来覆盖即可。
- 新的功能依据行业的标准和规范、用户的实际需求。比如某些特定的运营商用户要求,考虑组播预加入时,网元上行的应答包太多了,希望有开关可以将其关闭,以减小干扰。查阅相应的技术标准和规范文件后,认为该新增的功能是合理的,并且是可以实现的。
- 考虑引进新的需求分析方法。比如实例化需求、MFQ。
用例
- 采用一些测试通用的方法。比如边界值、等价类、状态机、
- 依据以往测试经验,在之前用例的基础上,去增加新的用例。比如在测试vlan模块时,只需要对操作命令行进行简单的修改,就可以完全借用。
- 引进新的用例设计方法。比如GIVEN - WHEN - THEN三段式的设计方法,既保证了每个用例的单一性,也保证了对需求的覆盖率。
脚本
- 采用工具,完成脚本编写和调试。例如,采用底层库为python,实现层用RobotFramework做脚本执行,展示层用Jenkins做任务的调度和测试结果的分析和发布。
- 针对可自动化的脚本,将其加入冒烟计划。定期执行这些脚本,并产生可以信赖的测试结果。如果脚本执行失败,那么肯定是网元出现了问题。
- 针对不可或难以自动化的脚本,不将其加入冒烟计划。测试人员此时需要做好操作步骤、配置参数和测试结果的记录。有两个目的:一是为将来再次作此测试时,提供直接的指导;二是保证了该测试结果是可靠的,可以拿出来作为依据和参考。