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

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

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

　　性能测试的需求背景通常来自于如下三种状况：

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

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

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

　　根据背景的不一样咱们每每有不一样的准备方式，可是大体能够从如下几个方面入手准备。

　　一、全面了解该系统概况

　　(1)系统所指望的性能指标：

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

　　(2)组网以及网间各个系统之间的通讯形式：

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

　　图1

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

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

　　(3)系统的各个逻辑分支：

　　了解系统的逻辑分支，主要是有利于设计测试用例。在咱们实际的工做过程当中，时间老是颇有限的，而咱们提升工做效率的一个很重要的方法就是重视用例的设计，了解了系统的各个逻辑分支，能够很精准的准备用例，直击问题的本质，减小摸索的时间。

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

　　(4)系统内部模块的组合：

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

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

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

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

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

　　系统的性能指标，除了最典型指标即吞吐量或者响应时间，另外还有不少咱们须要关注的指标，好比cpu，内存，io，数据库链接数操做等等，因而咱们在测试前还须要进一步深挖的系统，找出如下几个关键点：

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

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

　　(3)耗cpu的操做：好比一些大内存排序

　　(4)数据库的操做：频繁的进行数据库的读写操做，频繁的创建数据库链接等等

　　(5)网络调用：网络时延以及链接的并发

　　(6)临界资源：多进程处理模式中是否有加锁不恰当的行为 (7) 三、设计测试用例 了解了以上的基本状况，其实都是为这一步做准备的。在解决第一个状况的

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

　　(7)……

　　三、设计测试用例

　　了解了以上的基本状况，其实都是为这一步做准备的。在解决第一个状况的性能需求时显得尤为省力，有经验的性能测试人员在了解了以上的状况甚至能够不用设计测试就能够肯定问题出在了哪里!(lisa大胆揣测一下，尽管尚未达到那个水平)

　　性能测试的测试用例不比功能测试，能够考虑不少的异常测试，由于成本很小，而一次性能测试用例的执行经常须要消耗较大的资源和时间，因此精准的性能测试用例显得尤其重要。

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

　　(1)选定最合适的逻辑分支进行测试

　　每每会有不少分支能够知足你的测试要求，选择的时候，能够从如下两点入手：A.受周边影响最小，B，消耗的资源最少。

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

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

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

　　好比说我怀疑致使aqc系统性能降低的缘由是本次迭代新增了大内存的排序。例如aqc系统有一条分支将用户全部的cdkey查询出来而后按照时间排序，并所有返回给用户。那么咱们怎么让这个问题获得验证呢?在设计的时候能够选择两种极端的状况极其组合进行测试，一种是全部用户均没有cdkey，另外一种是全部用户均含有500个cdkey，最后一种则是二者的组合，比较一下则能够验证出是不是由于偶尔的某些用户的cdkey太多，致使总体的性能降低。

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

　　(3)请教有经验的性能测试人员每每会有惊喜

　　在经验有限的状况下，着手处理前和前辈请教下，不只能够提升工做效率，更能够增加见闻。可是这点恐怕也是不少人忽略的。任务来了，不要急着入手，先问问每每能够拓展思路。

　　四、测试环境的准备

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

　　(1)数据：大数据量以及数据的多样性每每是模拟的难点。大数据量须要本身写脚本将数据库填充到必定的程度，若是要求高的话，甚至能够采用从现网导数据的方法。多样性每每比较难以实现，须要了解现网的数据多样性以及比例，达到模拟的效果

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

　　(3)配置：日志级别的配置，线程或进程的个数，若是条件容许，配置能够升级到机器的硬件的配置，若是能够一致天然是最理想的效果。

　　这里有一个误区，我以前一直觉得最好每次测试的环境都尽可能的去和现网靠拢，可是在听了yuetangdeng的一堂课以后，发现IBM并非这么作的，对于之前曾经作过性能测试的系统，每每那套环境仍是存在的(无论这套环境是否以前和现网一致)，而测试咱们更多的是想验证系统是否存在性能问题，想一想与上一次测试周边环境都相同的状况下，新的迭代版本替换后系统性能明显降低了，难道还不能说明问题么?

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

 

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