炼金术(9): 简约而不简单,永不停歇的测试 -- always_run
最强战力,永不停歇的测试:always_run
许多工程师写完程序后,都不愿意对自己的程序做仔细测试。
很多测试说会做自动化测试,可能工作好几年都没真做过多少自动化测试。
我们的解决方案是,在系统的测试环境里,常驻跑一个always_run程序来做质量保证以及有效发现问题。
always_run 程序的简约设计如下:
- 设计一个插件模式,约定了各模块提供的测试程序的入口和出口。
- 这个程序里包含对各模块的场景使用流程代码。在项目中严格要求各模块必须提供对应的测试程序。
- always_run 在系统里会24*7运行,通过设计不同分组的定时器,定时跑不同分组的测试程序,尽量做到足够的覆盖率。
- 测试环境的机器覆盖了实际系统所需的所有角色。
- 为always_run提供一个机器人,在测试api里提供机器人上报接口,在测试失败的分支里,调用机器人把错误简要信息和日志路径信息发送到测试报警IM里。进一步可以自动AT相关的模块负责人。
- 项目组需要把报警的优先级调高,出现的错误报警如果不解决,会一直上报,只到被修复重新上线。
- 为了保证always_run持续起作用,需要持续为always_run添加测试用例程序,持续活跃的测试加入,保证了always_run的不过时和真正为项目质量作出贡献。
- always_run 在测试体系里,属于模块级别的集成测试,不算单元测试。但是它能快速的发现大部分问题,特别是程序里跟时序有关的BUG。
- 工程师可能只能为模块跑有限次数的测试,或者不够复杂的测试。测试如果不能写接口测试,手工操作也只能做有限次数的测试。
- 为 always_run 写的场景测试,实际上是系统的最小使用原型,尽快地跑起来always_run 就是尽快地验证系统的最小子集,此后有新的组件进来,就可以持续地为场景增加常驻执行的代码。
- always_run 和通常说的自动化测试并不完全相同,always _run 本身是被当作一个完整的独立Program被写出来了,不需要依赖什么自动化测试框架,只需对新加入的测试做入口和出口的约定即可。
--end--