（2）新增配置项：在ptop模块的配置文件ptop.ini中增加以下配置：

　　[SERVER]

　　CacheStatus = 0 //是否需要启用短信状态报告缓存处理功能，0表示不启用，1表示启用，默认配置为0。

　　CacheStatusDir = SMS01 //缓存状态报告的目录，每个smsPtop必须

　　FetchInterval= 10 //状态报告缓存进行处理的时间间隔，单位：豪秒

　　（3）业务流程：

　　A、若启用了状态报告缓存功能，接收到短信状态报告后做简单判断并给对方回响应；

　　B、将状态报告缓存到CacheStatus目录；

　　C、新起一条线程处理状态报告，FetchInterval时间间隔扫描一次状态报告目录，并处理状态报告；

　　D、若不启用状态报告缓存处理功能，则处理流程与原流程相同。

　　（4）异常的处理：

　　A、接收到状态报告后如果存放失败，则马上处理状态报告；

　　B、若出现线程池满，则先sleep一秒，然后再处理状态报告；

　　C、 模块重新启动后，若有状态报告积压，优先将积压数据取出来处理。

　　Bug报告的确是需要花费一定的时间，但是也给予效果显著的回报，使产品获得更好的质量。一方面，一个的Bug report可以轻易地打开开发人员和测试人员之间的积极关系，在时间上前期花费在编写Bug report上的时间和后期由于返工差的Bug report花费的时间相抵消；另一方面，也可以有效改进测试小组和高层、平行管理层之间的沟通，增强测试小组的信任度。

　　六、如何进行Bug回复描述

　　开发人员修改问题之后，将Bug回复给对应的测试负责人。很多开发人员在回复的时候只是简单地用“已解决”或“fixed”这样的语句，对于简单浅显的问题来说，这样已经足够。而对于复杂或重要的问题，在回复的时候应该详细说明测试的解决方法，一般来说，Bug回复应该包括：

　　（1）问题原因：导致Bug产生的根源

　　（2）问题结果：问题是否已经被解决说明，如“问题解决”、“下一版本解决”、“无法解决”等

　　（3）配置说明：在fixed Bug的时候是否需要增加或修改配置项，如果需要则详细说明配置。

　　（4）数据库结构：解决此问题是否需要改动数据库表，如果需要则需要详细说明。

　　（5）目标文件：解决此Bug的代码文件以及涉及到的相关代码文件文件

　　（6）解决方法：解决此Bug的方法

　　（7）改动代码：解决此Bug的时候有哪些代码被改动或增加，并将新的核心代码在回复中粘贴出来。

　　（8）业务流程：解决此Bug或新增功能的业务流程是否变更，如果有则详细说明新的业务流程，对于特殊的异常的处理也应该进行详细的说明。

　　开发人员回复Bug之后，测试人员会进行验证，如果问题还没解决或修改后引进了新的问题，则将这个Bug重新回复给开发人员，并且在回复中进行详细的问题描述。

　　七、如何进行Bug 关闭描述

　　开发回复Bug之后，测试负责人验证该Bug，如果问题得到解决则关闭（否则回复给开发负责人，让其继续追踪）。关闭一个Bug时，大多数的测试人员都是采用“问题解决”或“OK”这样的语句回复，作为一个简单的问题这样回复已经足够。但是对于一些比较复杂的问题或需求，可能经过了多次的修改，修改的终结果已经跟Bug描述有相当部分的出入了，因此在关闭Bug的时候，应该对Bug描述的内容进行一个总结：

　　（1）问题结果：问题是否已经被解决说明，如“问题解决”、“下一版本解决”、“无法解决”等；

　　（2）配置说明：软件问题解决之后终需要新增或修改的配置文件和配置项目；

　　（3）数据库结构：软件问题解决之后，软件升级涉及到修改的数据库表结构有哪些以及需要执行哪些脚本；

　　业务流程：Bug fixed之后的业务流程，如果是新需求，还要进行新功能点说明。