异步轮询与卫兵进程
引言：与fitnesse有关的自动化设计
¶背景：
1.业务链涉及多个进程，业务进程之间有一定的衔接。当这个用例执行失败时，想让程序自己去定位出错点，这个工作显然是很麻烦的。
2.fixture代码最后返回fitnesse结果时，需要获取当前用例业务结果表数据。这样预期是希望在被测业务进程在处理完成第一时间或者尽可能短的时间就获取到业务处理的结果数据，这显然也是很难办到的。
¶难点分析：
1.对于自动定位错误：
模拟生产，默认后台被测程序都是启动的，插入数据后应该就会自动触发被测进程做业务处理。链式处理中，可能会遇到被测业务上的bug，那么自动化发现bug或者业务处理错误后，一般会先查看涉及业务的表，然后再去查看日志等步骤。不通case涉及到表不同，日志不同，所以这样让程序自己识别错误和异常等是比较困难。
2.数据比对：
每个case测试的进程执行时间即业务处理场景时间是有差异的，无法设置一个固定值去sleep，当然设置最长时间是不合理的。
¶解决方案：
1.对于问题定位，可以总结和梳理信控业务链，总结出涉及的表，将共性的抽象为一种策略。这个策略就是定义了若干表名，case在执行时会匹配策略。再设置一个常驻进程去执行具体策略，实际上是轮询这个策略中配置的若干表，发现错误或者异常立即上报，类似于一个卫兵。【实现时为了避免卫兵发现处理中间状态不是终态，当卫兵发现错误和异常后将不会立即上报，而是做确认后再上报。】
2.数据比对，采用异步轮询机制，设置最长、最短轮询时间与最多、最少轮询次数两个维度，尽量做到第一时间反馈业务结果数据。
