1、引言
接着上一篇《深聊性能测试，从入门到放弃之：性能测试如何做》，这篇我们看看，到底做到那几点，架构师也对我刮目相看。
我的都知道，普通BS架构的系统，一般都采用测试工具（如LR）直接录制手工操作的方式进行测试。
这种方式简单有效，对测试人员要求不高。但在一些情况下，这种基于录制的方法可能无法完成，比如页面上有特殊控件、系统是CS架构、或者通讯的协议无法捕获等。
这时就需要更复杂的测试方法，如手动编写模拟客户端的JAVA代码，而把测试工具当作一个调度控制台，去调度大量的虚拟用户线程执行编写好的代码。
2、 执行步骤
举例
现在假设有一个简易版的12306网站，JAVA实现，中间件为TOMCAT，数据库为SYBASE，没有集群处理（一切从简，只有查询和订票功能）。如何对它进行性能测试呢？
接着往下看。
2.1 测试确认
数据量并发，数据也应该是海量的，但基本都是简单查询，没有复杂的统计，所以主要困难还是在海量并发事务的处理上。
中间件、数据库上都会承受巨大压力。此类高并发系统还需要对一些功能特别注意，比如一个车次有10张票，5个人同时购票，如何处理？如果是12个人同时点购票，又是如何处理？
2.2 通过标准
无非是系统能够满足多少人同时在线，一分钟内能处理多少订单，用户最大等待时间是几分钟。注意这个标准一定要是经过各方面确认过实际可行的啊，定一个订单响应时间不超过5秒有意义么？确认了以后，就要按照这个目标来设计测试和执行。
另一个需要注意的问题，按照预期的压力测试通过了以后，是不是就高枕无忧了？答案是否定的，因为很可能这个预期或者标准是不合理的。这个是非常可能的，只有长期的数据积累，才会一点点走向精确。
想想奥运订票系统，开通后短短五分钟，网站就瘫痪了，你们以为这种系统没有经过专业的性能测试么？据我所知，奥运订票系统性能测试时制定的标准是每分钟处理四百万访问，出事后的检查发现，每分钟的访问量超过了八百万。这种事故责任在谁呢？
测试机构敢拍胸脯保证，每分钟处理四百万就是没问题的。而奥组委自己设定的每分钟四百万目标，和实际出现偏差也是正常的，毕竟这种系统是第一次上线。最后的处理方法就是，压力达到了预期最大值以后，再后来的访问就被排队了。好好体会这个案例吧，会有收获的。
2.3 测试设计
设计用户模型，设计测试场景，设计测试用例。一个典型的用户是如何使用系统的？登录、查询车次余票、订票、付款，这是理想化的情况。
实际更可能是这样的，登录（一次登不进去，重复多次）、查询A车次（未到放票时间、不断重试，时间到无票）、查询B车次（无票）、查询C车次（有票）、订票、付款、查询订单。两种交互方式对系统产生的压力，差别是很大的。
将多个用户行动整合到一起，也就是用户模型，或者叫系统使用模型，是压力场景设计的依据。假设系统一天的访问量是一万个用户，这一万访问量是在24小时内平均分布的，还是分布在8小时内，还是在某一时间点上集中访问？这些具体到用例中也就是虚拟用户的加载策略，直接决定了压力的大小。
除了这个压力场景，针对此系统还需要进行绝对并发测试，参考第一步的分析。
2.4 数据准备
压力测试最繁琐的最夸张最麻烦的就是数据准备，环境准备，针对大量用户的并发进行一些预调优。
2.5 处理问题
比如1000人的压力下，系统响应就比较慢了，查询车次需要1分钟，下订单需要2分钟，接下来要做什么？能把这些作为一个性能缺陷提起么？显然是不可以的，这只是通过你的压力测试场景产生的一个现象，可能是测试脚本有问题、也可能是测试环境有问题。作为一个性能测试人员，需要尽量深入的定位到问题产生的原因。
就像这个响应慢，只是一个表面现象，慢在哪？是中间件还是数据库？一些简单的测试方法就可以进行判断，如在页面上进行一些数据库无关的操作，如果依然比较慢，说明在中间件上压力就已经比较大了。
还可以部署另一套中间件测试环境，连接之前相同的数据库，在压力测试出现问题的同时，手动访问新部署的应用（只有一个用户），如果同样很慢，那说明慢在了数据库端的处理上。还可以通过日志的方式更准确的进行判断，如应用日志和数据库SQL执行日志。总之方法是多种多样的，但目的只有一个，就是不断的排除无关部分、缩小问题范围，直到解决问题。
3、总结
还是那句话，对于测试来说，技术能力只能排在第二号，测试思想才是最根本的。
因为思想是根本，技术是辅助。
更多性能测试内容，请关注小鱼的博客
《性能测试基础到实战》从理论到实战，小鱼带着你一起飞~ ~
