后台性能测试总结—测试准备篇

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

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

　　第一种是现网出现性能问题，项目组专门进行了性能改造。比如修改的某个接口，由原来的同步调用修改成了异步，又或者是更换了新的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)网络调用：网络时延以及连接的并发

原文转自：http://www.uml.org.cn/Test/201308025.asp