测试对case加监控总结

这两天在对一个项目的接口加case监控，中间也有了自己的理解，特来分享给大家：

一、监控的目的

1、检验核心逻辑的正确性

2、能够实时监控接口状态，防止发生异常无法及时发现，从而不能够及时处理，导致线上事故

 

二、哪些case需要加监控

首先，case分为四类：

全case：测试过程中编写的所有case

checklist：覆盖全部需求的case

主路径：覆盖核心功能逻辑的case

冒烟：核心case，一般这条case不通过，基本能确定接口已经崩了

加监控时，一般是加冒烟类别的case，最多加到主路径类别的case

 

三、什么情况下配置什么样的监控报警条件

监控的报警条件有，一次出错即报警，连续三次出错后报警、1h出错5次报警等，大多情况下，是连续三次出错会报警。

一次出错即报警：

1、不允许出任何错误，比如牵扯到利益的红包、优惠券、积分、金币等逻辑

2、一次出错能确定程序已经崩了

连续三次出错报警：

1、一次出错可能会误判，比如执行这条case时，实现报警机制的逻辑出错

2、允许出现偶然性错误

 

四、监控的频率是多长时间一次，由什么决定

监控的频率时长通常有1分钟一次，5分钟一次，10分钟一次、30分钟一次等

1、报警条件是一次还是三次。如果是三次，频率时长相对要设置短一点，因为报警时间=报警条件（3）*频率时长

2、线上QPS。如果线上QPS较高，频率时长要短，减少损失

3、监控的检查点是新功能，还是已上过线的旧版本。新功能的稳定性不好保证，所以监控要密集一点；已经上线的旧版本，基本说明已经能稳定运行了，所以不用加太密集的监控耗费资源

 

五、要与开发确认的事项

1、报警后怎么保证能够及时收到通知

2、收到通知后怎么保证能够及时处理

3、业务是否有容灾能力，即服务端异常无结果时，客户端怎么处理，能让用户发觉不到出现了bug

4、业务是否有回滚能力，即新功能上线后，出现bug，能够及时回滚，再去花时间排查

5、如果出现bug，目标多长时间能够解决