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

　　(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并不是这么做的，对于以前曾经做过性能测试的系统，往往那套环境还是存在的(不管这套环境是否之前和现网一致)，而测试我们更多的是想验证系统是否存在性能问题，想想与上一次测试周边环境都相同的情况下，新的迭代版本替换后系统性能明显下降了，难道还不能说明问题么?

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

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