Common BS architecture system, generally by way of test tools (such as LR) is directly manually operated test recording. This simple and effective way, do not ask for testers. However, in some cases, this method is based on recording may not be completed, such as a special control on the page, the system is CS architecture, communications protocol or can not be captured and so on. Then you need a more sophisticated test methods, such as JAVA code manually write impersonate the client, and the test tool as a dispatcher console, scheduled to perform a large number of virtual user threads to write good code .
Now suppose there is a simple version of the 12306, JAVA implementation, middleware TOMCAT, database SYBASE, no clustering (keep things simple, only the query and booking functions). How its performance test?
Follow a few steps above to think about it, here simply write a few points.
The first step, test to confirm. Massive concurrency, data should also be massive, but basically simple queries, no complicated statistics, so the main difficulty is in dealing with the mass of concurrent transactions. Middleware, the database will be under enormous pressure. Such highly concurrent systems also need to pay special attention to some of the features, such as a train has 10 votes, while five people tickets, how to deal with? If 12 people at the same point of purchase, but also how to deal with?
The second step, by the standard. Nothing more than the system can meet the number of people online at the same time, the number of orders can be processed within a minute, the user maximum wait time is a few minutes. Note that this standard it must be confirmed through various aspects of practical ah, given an order response time of less than 5 seconds it make sense? After confirmation, we must follow the objective to design and test execution.
Another issue to note, as expected by the stress tests later, it is not to sit back and relax? The answer is no, because it is likely that the expected or standard is unreasonable. This is very likely the only long-term data accumulation, it will go a little accurate.
想想奥运订票系统，开通后短短五分钟，网站就瘫痪了，你们以为这种系统没有经过专业的性能测试么？据我所知，奥运订票系统性能测试时制定的标准是每分钟处理四百万访问（具体数据记不住了，就假设是这个数吧），出事后的检查发现，每分钟的访问量超过了八百万。这种事故责任在谁呢？
测试机构敢拍胸脯保证，每分钟处理四百万就是没问题的。而奥组委自己设定的每分钟四百万目标，和实际出现偏差也是正常的，毕竟这种系统是第一次上线。最后的处理方法就是，压力达到了预期最大值以后，再后来的访问就被排队了。好好体会这个案例吧，会有收获的。
第三步，测试设计。设计用户模型，设计测试场景，设计测试用例。一个典型的用户是如何使用系统的？登录、查询车次余票、订票、付款，这是理想化的情况。实际更可能是这样的，登录（一次登不进去，重复多次）、查询A车次（未到放票时间、不断重试，时间到无票）、查询B车次（无票）、查询C车次（有票）、订票、付款、查询订单。两种交互方式对系统产生的压力，差别是很大的。
将多个用户行动整合到一起，也就是用户模型，或者叫系统使用模型，是压力场景设计的依据。假设系统一天的访问量是一万个用户，这一万访问量是在24小时内平均分布的，还是分布在8小时内，还是在某一时间点上集中访问？这些具体到用例中也就是虚拟用户的加载策略，直接决定了压力的大小。
除了这个压力场景，针对此系统还需要进行绝对并发测试，参考第一步的分析。
第四、五步就不细说了，准备环境、数据，针对大量用户的并发进行一些预调优。按照第三步设计好的各个测试用例准备脚本、执行测试。
第六步，发现问题了怎么办？比如1000人的压力下，系统响应就比较慢了，查询车次需要1分钟，下订单需要2分钟，接下来要做什么？能把这些作为一个性能缺陷提起么？显然是不可以的，这只是通过你的压力测试场景产生的一个现象，可能是测试脚本有问题、也可能是测试环境有问题。作为一个性能测试人员，需要尽量深入的定位到问题产生的原因。
就像这个响应慢，只是一个表面现象，慢在哪？是中间件还是数据库？一些简单的测试方法就可以进行判断，如在页面上进行一些数据库无关的操作，如果依然比较慢，说明在中间件上压力就已经比较大了。
还可以部署另一套中间件测试环境，连接之前相同的数据库，在压力测试出现问题的同时，手动访问新部署的应用（只有一个用户），如果同样很慢，那说明慢在了数据库端的处理上。还可以通过日志的方式更准确的进行判断，如应用日志和数据库SQL执行日志。总之方法是多种多样的，但目的只有一个，就是不断的排除无关部分、缩小问题范围。
定位到了中间件和数据库之一，然后又该怎么办？此时恐怕就需要一些相关方面的专业知识了，但其实最常见的还是那些。中间件相关的一般是线程池、JVM、数据库连接池等，数据库相关的有锁、缓存、IO（一般就是SQL语句的问题）等。要进行全面的监控和分析，再做一些合理的调优并重复测试。
问题定位到什么程度才行？我认为是要让人看了知道改哪就可以了。比如提一个“这个SQL语句进行了大量的物理IO，性能不好”，这就不是个好问题，物理IO是什么？怎么改？如果这么说就好多了“这个SQL语句没有使用索引，导致了全表扫描，进行了大量的物理IO，性能不好。如果要避免全表扫描，需要调整SQL语句或者添加XX索引”，这才是定位问题。
当然了，上面只是一个非常简陋的举例，真实的性能测试要比这复杂的多。
总的来说，我认为，性能测试的难度主要不在技术手段上，互联网时代技术都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于，你要想出来如何去测是有效的、有保障的，这才是测试工程师最重要的能力。
还是那个观点，思想才是根本。