小议计算机软件性能测试与监控

□ 许潇湘　江苏联宏自动化系统工程有限公司

小议计算机软件性能测试与监控

□ 许潇湘江苏联宏自动化系统工程有限公司

通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。软件测试作为保障软件质量最有效的手段之一，现今已成为了研究热点。随着软件规模的不断增大，复杂度越来越大，与其他系统的接口不断增多，应用越来越广泛，集成度越来越高，软件测试这一环节必须得到重视，只有这样，才能尽早的发现并解决错误。本文重点从软件性能测试的方法与监控关键指标的分析着手，集中从资源指标与系统指标两方面进行阐述。

软件；软件测试；指标分析

1.引言

计算机领域，性能测试（performance testing）就是用来测试软件在集成系统中的运行性能。其目的是为了度量系统相对于预定义目标的差距。软件性能测试是在交替进行负荷和强迫测试时常用的术语。软件性能测试一般包括负载测试和软件压力测试。性能测试必须有工具支持，市面上有一些专门用于GUI或是web性能测试的工具，如：Loadrunner，Sil kperformance，Webload；性能测试收集的信息包括：CPU使用率、IO使用情况、内存使用情况、系统反应时间等。

2.软件性能测试的目的

主要有：（1）评价系统当前性能，判断系统是否满足预期的性能需求。（2）寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。（3）判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。

3.常见性能测试的方法

3.1负载测试

负载测试指的是最常见的验证一般性能需求而进行的性能测试，在上面我们提到了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。对负载测试的理解有：（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。

3.2压力测试

压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。

3.3并发测试

是验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。

3.4基准测试

当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。

3.5稳定性测试

“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。

3.6可恢复测试

测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。

4.软件性能测试中监控关键指标的分析

4.1资源指标分析

4.1.1判断CPU是否是瓶颈的方法

一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈，比如Linux总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般判断CPU为瓶颈，主要从两方面：一是CPU空闲持续为0，二是运行队列大于CPU核数（经验值3-4倍），即可判定存在瓶颈，对于CPU高消耗主要由什么引起的，可能是应用程序不合理造成，也可能是硬件资源不足，需要具体问题具体分析，比如问题SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。

4.1.2判断内存是否是瓶颈的方法

一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。

4.1.3判断磁盘I/O是否是瓶颈的方法

磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说，更容易成为瓶颈，一般从以下几个方面对磁盘I/O进行分析判断：

（1）计算每磁盘I/O数

每磁盘I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈，每磁盘I/O计算方法如下表：

（2）监控磁盘读写

如果磁盘长时间进行大数据量读写操作，且cpu等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能。

4.1.4判断网络带宽是否是瓶颈的方法

判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如：减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；或者增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高

在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现 网络严重延迟或丢包，则说明网络不稳定，需要检查网络。

通过对资源指标四个指标的分析，实际上各个方面都是互相依赖的，不能孤立的单从某个方面进行排查。当一个方面出现性能问题时，往往会引发其他方面的性能问题，例如，大量的磁盘读写势必消耗CPU和IO资源，而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作，造成磁盘IO瓶颈，同时，大量的网络流量也会造成CPU过载，所以，在分析性能问题时，需要从各个方面进行考虑。

4.2系统指标分析

4.2.1并发用户数

系统能够支持的用户数是系统容量的重要标志，并发用户数用于度量系统在高并发量访问下，系统的并行处理能力，一般如果系统中存在死锁、资源争用，在并发访问下，由于请求处于队列等待中，系统响应就会随着时间变慢。

一般情况下，选用高吞吐量、高数据库I/O、高商业风险的业务功能进行并发用户访问测试。

判断系统能够承受的最大并发用户数，通常以满足以下条件为准：（1）业务功能操作平均响应时间在合理范围之内；（2）事务成功率在合理范围之内；（3）系统运行无故障（无异常宕机）；（4）系统资源指标使用在合理范围内。

4.2.2平均响应时间

对于客户端用户来说，最直观的体验就是访问该页面快或者慢，即响应时间的长短。比如在持续并发性能测试过程中，客户感知访问应用很慢，监控到的平均响应时间也逐渐变长，这时就需要先借助于监控到的资源指标，首先排除资源方面的限制因素，再从应用本身进行定位，如可以采用页面细分工具（如httpwatch、Loadrunner Anaysis中的页面组件细分）分析响应比较慢的页面。

4.2.3事务成功率、超时出错率

事务成功率越高，则表明系统处理能力越大；而失败事务主要由于系统响应慢，导致访问业务功能超时，或者系统业务功能异常，不能正常访问等，需要根据事务错误提示信息，具体分析。

5.测试要点

主要是：（1）软件性能测试计划、方案一般与测试用例统一在一个文档里。（2）测试环境应尽量与用户环境保持一致。（3）软件性能测试一般使用测试工具和测试人员编制测试脚本来完成，软件性能测试的环境应单独运行尽量避免与其他软件同时使用。（4）软件性能测试的重点在于前期数据的设计与后期数据的分析。（5）软件性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做软件性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于软件性能测试，很少影响到软件性能测试的设计用例。但是如果某个功能有较大的修改，软件性能测试也应该进行重新测试。）

6.结束语

综上所述，软件性能测试是执行、监控—〉分析—〉调优不断进行的过程，即监控是为分析提供更多的参考数据，分析是为了进行调优，调优是解决当前系统存在的性能瓶颈，为用户提供更好、更快的客户体验。由于分析、调优需要根据具体问题进行具体分析，本文未做过多说明，只对通用的关键指标进行监控分析，建议在实际工作中可从资源指标与系统指标两个方面，层层检测、步步排查，性能问题就无处藏身，一旦找到出现问题的原因，性能问题也就迎刃而解！总之，软件测试作为保障软件质量最有效的手段之一，现今已成为了研究热点。随着软件规模的不断增大，复杂度越来越大，与其他系统的接口不断增多，应用越来越广泛，集成度越来越高，软件测试这一环节必须得到重视，只有这样，才能尽早的发现并解决错误，提高效益、品质。