炼技术(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被写出来了，不需要依赖什么自动化测试框架，只需对新加入的测试做入口和出口的约定即可。
- 不要996， 而要 always_run !
–end–
