关于性能诊断的方法，我们可以按照“问题现象—直接原因—问题根源”这样一个思路去归纳。我们先从问题的现象去入手，包括时间的分析、资源的分析和异常信息的分析。接下来再去分析产生问题现象的直接原因是什么，这里我们归纳了自上而下的资源分析法和发散的异常信息分析法。找到直接原因之后，再去从问题的根源上去分析，包括软件架构的分析、部署架构的分析和业务架构的分析。这篇文章我们就一起探讨一下构架和业务的诊断分析。

·软件架构分析方法

软件架构的诊断分析对测试工程师的技术要求是比较高的，可能要达到软件架构师这个层级，才能对这个层级的问题进行一个比较深入的分析。

在这个层级进行分析的时候，需要分析的有通信协议选择、基础软件产品选择、缓存架构和同步异步。

对通信协议选择需要分析比如在传输层是用http好？还是用UDP好？在应用层用哪种通信加密的算法会更好？等等。在基础软件产品的选择这部分，对于每种类型的中间件、数据库都需要一个选型，哪种中间件或数据库最适合我们？甚至MySQL里面都有不同的存储引擎，哪种存储引擎更适合我们软件系统这个场景。

再就是缓存的架构，其实我们大部分性能的提升都是拿空间换时间，我们为了提高响应速度，我们需要大量的缓存，这个缓存涉及到方方面面，甚至我们的cpu里面，它也有不同的缓存，更何况是在数据库层、应用层等等。在整个软件架构的设计里面，也会有缓存的架构，我们应该在哪些方面去做缓存，怎么去设计缓存架构，这都是需要我们去考虑的。

再就是同步异步，这就牵扯到业务的分析了，哪些业务我们需要去做同步操作，哪些业务需要做异步操作。我们大量的处理都是通过异步，我们需要去尽量减少不需要的请求的响应。

软件架构分析方法的目标主要是为软件架构的升级提供参考。适用于问题直接原因已确定，问题优化无法满足需求的情况。

·部署运维分析方法

部署运维分析方法主要是针对基础软件部署运维配置、数据库分库分表、关系数据库统计信息进行分析，这些都有可能带来系统的性能问题。

部署运维诊断分析方法的目标主要是为部署配置调整提供参考、为运维配置调整提供参考，适用于生产环境运行出现问题的情况。

·业务架构分析方法

业务架构的分析可以总结为两大部分：业务功能分和前端界面分析。业务架构诊断的目标是为软件功能性、易用性、性能等方面的平衡性提供参考。适用于问题直接原因已确定，问题优化无法满足需求的情况。

除此之外，还有一些其他的测试诊断方法像比对测试、沟通讨论等。

以上就是性能测试诊断方法系列的全部内容。