可测试性问题分析报告

可测试性问题分析报告，供大家提可测试性需求时参考。

 

日志可测试性评估：

评估结论：各模块日志打印不符合规范，INFO级别日志信息太少，达不到测试观察要求；缺少run日志和性能统计日志，无法观察各模块处理性能；

改进建议：严格按照日志规范进行日志整改，增加打点密度，正确使用日志级别和区分日志类型。

 

数据库可测试性评估：

评估结论：数据库的关键操作如读取或刷新配置，断连或重连等没有打印运行日志或INFO级别的debug日志，不便于问题发现和定位；缺少SQL性能数据，对SQL执行上的异常情况或数据库性能瓶颈导致的问题难以发现；缺少连接池信息，无法针对具体某些连接进行故障注入；

改进建议：增加日志打印，输出主要步骤及处理结果的信息，输出连接池信息；增加对SQL性能统计数据，发现异常情况及时输出警告信息。

 

文件可测试性评估：

评估结论：文件在配置、读取、刷新等方面都具备了比较完善的可测试性；不过在定期修改密码的测试场景中缺少加密工具支撑；对文件句柄使用情况缺少监控；话单SDK没有提供性能观察点，无法了解SDK本身的处理速度和写文件的速度。

改进建议：提供密码加密工具；结合网管实现对文件句柄使用情况的监控；补充话单SDK的性能统计日志信息。

 

对象池可测试性评估：

评估结论：对象池操作日志信息不完整，队列缺少性能统计信息观察消息积压情况和处理速度，缺少消息超时时长和队列满的控制，申请新的队列没有检测系统内存。

改进建议：为队列增加性能统计日志，至少包括队列消息数，处理速度等；提供队列满的控制方法；提供超时时长的设置方法；实现可用内存阈值检测，以此来判定是否创建新的队列。

 

接口协议可测试性评估：

评估结论：没有记录接口消息的处理时延和调用次数，外部接口处理对性能的影响不可知，也无法发现一些不合理的接口消息调用所引发的问题。

改进建议：为系统接口消息处理增加性能观察点。

 

系统资源可测试性评估：

评估结论：

1、          对于线程，无法获取线程列表信息，无法验证配置是否生效；同时，线程运行状态、运行时长不可知，无法确立线程是否存在处理上的问题；也没有方法对线程进行操作控制，无法验证监控线程的处理能力；有些模块的线程数不可配置。

2、          对于消息队列的并发访问，缺少观察点；

3、          没有提供内存数据的访问工具，无法验证内存信息与配置的一致性；对内存块里的对象进行数据查询和设置操作，共享内存上的问题很难被暴露，即使发现了也难定位。

4、          Socket缺少自测试服务；

改进建议：

1、          为线程提供属性观察点，线程状态可知，线程吊死问题能及时发现；

2、          为线程提供控制方法，能够启动、暂停、退出线程；

3、          线程数可配置

4、          为消息队列的并发访问增加日志，提供观察点实时查询占用、等待线程；

5、          提供内存的访问工具，能够对内存中的数据提供结构化的操作（增加、删除、设置、查询）能力；

6、          为socket提供自测试服务；