炼金术(9):简约而不简单，永不停歇的测试always_run

最强战力&＃xff0c;永不停歇的测试&＃xff1a;always_run

许多工程师写完程序后&＃xff0c;都不愿意对自己的程序做仔细测试。

很多测试说会做自动化测试&＃xff0c;可能工作好几年都没真做过多少自动化测试。

我们的解决方案是&＃xff0c;在系统的测试环境里&＃xff0c;常驻跑一个always_run程序来做质量保证以及有效发现问题。

always_run 程序的简约设计如下&＃xff1a;

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

--end--