对于程序来说，我想没有一个测试是敢说我测的程序没有bug，这个是不现实的，只不过是还没发生特定的场景来触发隐藏着的bug。而我们测试在异常测试的时候的确也会设计异常的case去检查程序的处理是否合理，但是这一切都是我们能想到的，或者说你预期出来的，而重要的是程序并不一定会按照你的预期来执行。那么对于此，我们能做些什么。

　　做好对于预期指标的监控

　　我们不希望程序崩溃，但是也不希望程序危险的运行了很久直到崩溃才发现问题。那么其实可以设定一些你预期的目标，比如资源的使用情况，程序的运行时间，数据产出的时间，这些都可以设定一个预期的值，并进行监控，当真实情况已经和预期不符的时候可以发警告到相关的开发和测试，提醒目前可能有一些因素导致程序可能处于危险的状态。提前发现一些危险的苗头扼杀解决掉总是要比等到崩溃再处理好的多吧。

　　举几个典型的例子：

　　1、缺少regionserver的监控，导致问题很晚才发现。

　　数据倾斜的问题：因为应用不重要很少有人关注，这个应用开始肆意的运行，直到有网络监控的人经过排查觉得这个应用可能会占用很多带宽，事实的确如此。但是，如果之前对regionserver的服务状况进行监控，当发现某台机器处理数据的频繁程度超过其他机器，那么不用等到负责系统的人员排查很久才发现，而在之前我们自己完善的监控会提醒负责的人员，此时数据或者程序处于危险状态，需要处理，那么问题会很早的解决掉。

　　2、依赖第三方或者其它组的jar包，依赖的东西有bug，导致问题很晚才发现。

　　云梯jar包升级存在bug：通俗的说是A家给B家送数据，要用B家的工具才行，某天B家的工具升级了，但是升级失败了，而它的bug是明明自己不能用了，但是还拉着你不让你走也不给你返回值退出。那么会出现一种什么状况，程序是判断返回值来感知命令是执行成功了还是失败了，但是B的jar包的bug是拉着你，不给你返回值，怎么办，会导致你不知道他不能用了，死耗在那，虽然我不耗在那我也不能往B送数据了，但是我希望我自己的程序是可以感知到推数据的部分运行时间太长了，可能是在危险的运行着，那么此时是需要一个对于预期指标的监控，需要一个外围的和程序无关的外围监控，当这个程序执行的时间比平常长一个阀值，我应该发个警告提醒相关人员去看看，发生了什么事情导致我程序运行的这么慢。

　　这些问题的出现说白了，还是缺少必要的外围监控，我们不能对于环境，或者某些别人提供给我们的，或者某些很或的开源代码，或者被证明很稳定的软件产生任何的依赖信任心理，一切可能发生的或者不可能发生的监控都是有必要的，使用任何东西都是存在风险的，但是我们要尽量努力风险被触发的时候我们能在尽量早的时间发现。

　　回滚方案：

　　当上面那些东西已经没用，我们没能在程序处于危险的状态的时候发现，而程序已经崩溃了。想想如果之前没有回滚方案，那么任何现想出来的方案都是冒着非常大的风险，或者回滚方案大家并没有验证可行否，那跟前者也没什么区别。我们不能保证不发生任何的突发状况，但是当出现突发状况的时候我们要怎么处理，要怎么把损失降到小，用少的时间解决才是关键。所以回滚方案是非常重要的，测试可能的话好自己模拟一下，验证一下可行行。而且对于回滚方案随着时间的退役可能遇到的问题好也能跟进，比如这周回滚方案是可行的，但是又过了一阵环境啊，资源啊，依赖的东西啊，当这些都变了，原来制定的回滚方案还有效吗。这些问题考虑清楚了，回滚方案才会在关键的时候起作用。

　　对整体的把握来看新老的依赖：

　　这个我想对于新接手什么的挑战是大的，对于从头跟，业务逻辑，依赖关系清楚的人来说可能还好，的那是对于新接手，前面发生了什么事情完全不知的人来说可能是个潜在的灾难。这个需要有一些前人总结的checklist，什么的来提醒之类的，主要的是自己要时刻提醒自己，要记得关注新功能是否对老的会产生影响。如果因为新老依赖没搞清楚，导致新的上线使得部分来的功能失效了，那是非常悲剧不值的，所以嘴一定要勤，要问。

　　暂时想到这些了，当这些问题都纳入考虑的时候，软件测试其实真的只是测试的一部分！