性能测试往往在投产上线前开展，无法对整个系统变更进行全面的覆盖测试，因此性能测试需求提出十分关键。

性能测试需求交付过程中，需要对开发团队提出的测试需求进行审查，重点分析交付的测试需求是否充分覆盖了影响系统性能的因素，避免遗漏重要测试项，引发生产性能事件。

在很多企业中，性能测试需求交付都设置有需求评审环节，需求审查的动作也会包含系统变更影响性分析，其中最关键的分析内容就是梳理影响系统性能的因素，进而权衡性能测试需求交付的全面性。

分析影响性能的因素，不仅要从系统本身的程序改造来看，更要关注本次投产上线整个系统资源、配置、参数、程序、业务等多方面的变化情况，很可能程序调整不大，但因基础软件的版本变化或关键应用配置的参数发生调整，会引发重大的性能异常。

因此从性能测试的角度而言，测试的需求不仅来源于被测系统程序的改变，还涉及到架构调整、参数变化、容量配置、基础软件等各方面，下面我结合自身工作经验简要介绍五个方面可能影响系统性能的因素，供分析性能测试需求充分性做参考。

程序变更

程序变更引发的性能影响，是常规分析性能影响的首要因素。

一方面涉及业务逻辑的处理调整，如新增业务逻辑或原始业务处理环节增加处理逻辑，导致程序性能消耗相比变大；

另一方面涉及技术影响，如使用线程池、系统同步对接、事务处理调整等，会导致系统在技术应用方面带来额外的性能损耗。

通常程序变更引发的性能影响是研发团队最主要和最容易识别出来的因素。

架构调整

架构调整通常涉及技术架构调整包括基础软件的升级或更换，如Oracle更换为Mysql，WAS更换为TOMCAT、JDK版本变化等，此外还有升级开发框架、应用拆分、中间件引入、增加限流熔断等框架服务组件等。

架构调整对性能的影响较大，因为涉及到技术架构与应用的适配，往往涉及应用较大规模改造，通常性能测试会开展全面测试以验证性能影响。

容量调整

性能容量调整包括横向资源规模的增扩减少以及单台资源的硬件配置，通常容量扩容较为常见。

但一些情况下因性能容量降低导致的系统性能隐患仍然存在，比如系统资源调整机房，可能存在硬件服役时间和配置上的差异。另一种情况是业务发生调整后，重新编排了生产资源规模，减少了资源数量，此时存在性能容量可能不足的隐患，需要在保持日均业务量的前提下，开展有效的性能容量测试，验证系统性能。

配置调整

配置调整是分析性能影响可能遗漏的一项因素，系统中存在大量的配置项，具体包括JVM配置参数、系统功能启停开关、WEB服务器最大连接数、数据库连接池大小、日志级别等，这些参数的变化对系统性能有十分直接的影响，比如JVM配置的最大堆内存直接与GC频率挂钩，再比如配置文件中调整日志级别从ERROR改为INFO，将导致大量的日志读写进而影响资源IO能力。

业务调整

还有一些情况虽然系统未发生程序变更或架构调整，但业务层面使用系统的规则发生了变化，导致访问系统的流量骤增，造成性能压力。

比如系统从试点转为推广、承接更多上游系统、突发热点活动等。主要表现在系统的程序、架构、配置、资源尚未发生调整的情况下，需要应用突发的业务流量。

总结

以上粗略的从五个方面分析可能影响性能的因素，在实际操作中，无论是需求分析或者需求评审会议，性能测试需求都直接或间接通过此类方法进行评判，全面分析性能影响，对准确提出性能测试需求，避免测试工作存在遗漏起到非常关键的作用。

粉丝专享

为你们整理了价值2000+ 的100G资源

内容包含：

• 从0-1规划软件测试学习路径

• 职场上常用的测试模板、攻略

• 软件测试提升电子书

• 经典面试题

有需要的小伙伴可以点击下方卡片进群免费领取：