五、如何处理不能迅速定位的工程故障

　　对于一些不能迅速定位的工程故障，开发很自然寄望于测试环境能将问题重现，如果能够轻易在测试环境重现，那肯定是一件好事，不过通常如果是一些简单的容易出现的问题，在测试的时候肯定已经发现问题了；正是因为问题的复杂或者是一些测试时没有考虑过的问题，才遗留到工程上导致出现故障。

　　1、查看工程环境程序日志，如果没有查询的权限，请工程实施人员帮忙查找，分析日志查找到问题的原因或相关线索。

　　2、如果日志的提示信息足够，可以根据日志定位原因，则在测试环境中按照日志提示构造条件相同的测试案例测试，尝试在测试环境中将问题重现。

　　3、如果不能从日志中获取足够的信息，而且测试环境中也无法把问题重现，那么先跳出思维定势，想想为什么会出现这样的故障，可能导致的原因有那些，自己还有哪些测试点或异常没有考虑到，测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动与开发负责人、工程实施人员以及有经验的项目经理讨论，分析可能导致的原因。

　　4、请工程实施人员将工程环境的配置文件和执行程序帮忙ftp到本地测试环境，在测试环境中使用实际工程环境的配置文件和执行程序，并尽量模拟实际环境搭建测试环境。

　　5、在模拟实际环境的测试环境中，根据分析的可能原因构造测试案例测试，尝试在测试环境中将问题重现。

　　6、问题重现后协助开发解决问题。

　　7、验证解决后的程序是否仍然会出现类似故障。

　　8、总结出现故障的原因并作记录，如果是配置的问题需要提醒工程人员在实施的时候注意，如果是测试疏忽的测试点要在测试报告中记录并在案例库中增加相应的案例，如果是某些异常开发没有考虑全面要总结类似的问题并提示所有开发注意。

　　下面是一个非常难定位的工程故障的实例，希望这个工程故障的解决方法和态度能够给你一些启示。

　　1、问题描述：在某省某短信业务高峰期，实际处理的短信比接受到的短信少，也是在系统处理某环节丢失了部分短信。

　　2、问题进展：

　　A、实际工程环境的日志没有任何错误提示

　　B、相关模块的负责人进行代码白盒检查，也没办法从代码中看出缺陷

　　C、测试环境没有出现工程所描述的故障