【转自网络】后台性能测试总结—测试准备篇

lsekfe

在这半年以来，我陆续参加或者独立承担的项目组版本的部分性能测试，慢慢的有了一些认识，暂时做一个积累，和大家做一个交流

性能测试的需求背景一般来自于以下三种情况：

第一种是现网出现性能问题，项目组专门进行了性能改造。比如修改的某个接口，由原来的同步调用修改成了异步，又或者是更换了新的api，由tcp协议修改为udp协议，为了保证新替换的api的可靠性，都需要进行性能测试

第二种是一个新做的系统，运营人员需要全面的把脉，了解该系统的处理能力。

第三种是随着请求量的快速增长，而该系统却从未做过性能测试，项目组担心系统在可预见的短期会扛不住，所以要求测试人员对该进行全面的性能测试，给出一份参考数据

根据背景的不同我们往往有不同的准备方式，但是大致可以从以下几个方面入手准备。

1、全面了解该系统概况

（1）系统所期望的性能指标：

对于第一二两种情况，都会有很明确的现网性能指标，比如以前测试的acs，是一个新作的系统，需求说明书中就明确标注需要达到1wtps.而对于第三种情况，往往我们需要尽量的模拟现网，得出数据供运营做参考。例如最近测试的查询限制引擎，测试这边给出了单台svr的处理能力以及是否支持平行扩展等运维最关心的数据即可。

（2）组网以及网间各个系统之间的通信形式：

有时我们性能改造只是组网中一个小小的系统，这就需要我们去弄清楚这个系统在整个逻辑处理中所处的位置。

图1

了解被测系统在整个交易中的位置，对于测试用例的设计以及测试环境的搭建是至关重要的

其次，还需要了解组网中各个模块之间的通信方式，tcporudp，同步调用还是异步调用，长连接还是短连接。

（3）系统的各个逻辑分支：

了解系统的逻辑分支，主要是有利于设计测试用例。在我们实际的工作过程中，时间总是很有限的，而我们提高工作效率的一个很重要的方法就是重视用例的设计，了解了系统的各个逻辑分支，可以很精准的准备用例，直击问题的本质，减少摸索的时间。

举一个例子，psc系统性能改造版本（如图1），几乎所有的业务逻辑都要走ssp去查询是否受限，但是我们选择其中的一条最简单的受周边系统最小的二级赠送分支进行测试，利用最短的成本验证问题，很好的保证了测试的进度

（4）系统内部模块的组合：

较为复杂的系统，都会有自己的模块组合方式。我们需要了解系统由几个模块组成，各个模块的耦合关系是怎样的，不仅对于功能测试中的异常测试用例的设计有很大帮助，对于性能测试的帮助也同样不可小觑。

举一个比较简单的例子：aqc系统，这个系统是供外部查询的，内部的模块大致分为：网络通信层，请求分发层，功能处理层。网络通信层主要是利用某网络通信组件，处理网络通信，请求分发层dispatch，主要将网络通信层队列的包根据cmdcode的不同分发到后端的功能处理层，功能处理层则有一个个小svr组成，每个svr处理不同的查询请求。

倘若有一个性能需求是发现现网有一个查询分支性能不OK，那么我们就需要很快的锁定关键的模块，瓶颈很可能存在与处理这条分支的svr上。

其次了解了系统的各个模块以及模块之间的耦合关系，在理解性能曲线，调整测试方案时同样很重要。

2、踩准关键点，进一步深挖系统

系统的性能指标，除了最典型指标即吞吐量或者响应时间，另外还有很多我们需要关注的指标，比如cpu，内存，io，数据库连接数操作等等，于是我们在测试前还需要进一步深挖的系统，找出以下几个关键点：

（1）内存分配和使用。消息队列的使用，缓存的使用

（2）文件，网络IO操作：大文件读取到内存，或者将内存写会文件，是否操作频繁

（3）耗cpu的操作：比如一些大内存排序

（4）数据库的操作：频繁的进行数据库的读写操作，频繁的建立数据库连接等等

（5）网络调用：网络时延以及连接的并发

（6）临界资源：多进程处理模式中是否有加锁不恰当的行为

（7）……

3、设计测试用例

了解了以上的基本情况，其实都是为这一步作准备的。在解决第一个情况的性能需求时显得尤其省力，有经验的性能测试人员在了解了以上的情况甚至可以不用设计测试就可以确定问题出在了哪里！（lisa大胆揣测一下，尽管还没有达到那个水平）

性能测试的测试用例不比功能测试，可以考虑很多的异常测试，因为成本很小，而一次性能测试用例的执行常常需要消耗较大的资源和时间，所以精准的性能测试用例显得尤为重要。

性能测试用例的设计，根据Lisa这段时间的积累与总结，感觉可以从以下几个方面着手。

（1）选定最合适的逻辑分支进行测试

往往会有很多分支可以满足你的测试要求，选择的时候，可以从以下两点入手：A.受周边影响最小，B，消耗的资源最少。

A点可以帮助我们很快的定位出问题，也许整条逻辑分支设计的系统会有很多，我们可以选择涉及周边系统最小但是却可以包含被测系统在内的分支进行，当然最简单的做法就是可以直接压测被测系统，但这样做有些问题是暴露不出来的。

B点可以帮助我们节省资源，比如已经有现成的环境了，总之我所需要准备的东西减少了，自然就速度快效率高了，而对于新系统或者从未进行过性能测试的老系统，在时间有限的情况下，我们还需要结合实际情况，选择用户请求量最多的最重要的分支进行测试。

（2）根据前面的分析，设计最有针对性，最有效的测试用例

比如说我怀疑导致aqc系统性能下降的原因是本次迭代新增了大内存的排序。例如aqc系统有一条分支将用户所有的cdkey查询出来然后按照时间排序，并全部返回给用户。那么我们怎么让这个问题得到验证呢？在设计的时候可以选择两种极端的情况极其组合进行测试，一种是所有用户均没有cdkey，另一种是所有用户均含有500个cdkey，最后一种则是两者的组合，比较一下则可以验证出是否是因为偶尔的某些用户的cdkey太多，导致整体的性能下降。

当然在测试的过程中，我们还需要根据现有的数据调整测试用例，帮助我们验证猜想，更清晰的定位问题

（3）请教有经验的性能测试人员往往会有惊喜

在经验有限的情况下，着手处理前和前辈请教下，不仅可以提高工作效率，更可以增长见闻。但是这点恐怕也是很多人忽略的。任务来了，不要急着入手，先问问往往可以拓展思路。

4、测试环境的准备

测试环境的搭建往往要根据测试用例的设计而确定。对于初次进行性能测试的系统，我们的目标是尽可能的和现网一致。可以主要从以下几个方面入手。

（1）数据：大数据量以及数据的多样性往往是模拟的难点。大数据量需要自己写脚本将数据库填充到一定的程度，如果要求高的话，甚至可以采用从现网导数据的方法。多样性往往比较难以实现，需要了解现网的数据多样性以及比例，达到模拟的效果

（2）网络时延：这个和公司的IDC机器管理很相关.我之前一直以为所有的测试机器都在一个IDC，后来发现其实不然，我们的测试机器也和运营机器一样，分布在不同的IDC，而我们在挑选机器部署时，需要先了解一下现网运营机器之间的网络时延。这在测试整个一条逻辑分支的性能时尤为重要。

（3）配置：日志级别的配置，线程或进程的个数，如果条件允许，配置可以升级到机器的硬件的配置，如果可以一致自然是最理想的效果。

这里有一个误区，我之前一直以为最好每次测试的环境都尽量的去和现网靠拢，但是在听了yuetangdeng的一堂课之后，发现IBM并不是这么做的，对于以前曾经做过性能测试的系统，往往那套环境还是存在的（不管这套环境是否之前和现网一致），而测试我们更多的是想验证系统是否存在性能问题，想想与上一次测试周边环境都相同的情况下，新的迭代版本替换后系统性能明显下降了，难道还不能说明问题么？

在一切都准备好了，接下来我们就可以开始准备测试工具来执行我们的测试用例啦~~~~