应该用多大规模的数据库的做性能测试

　　在做性能测试时必须记住，数据库的规模会显著影响从表中取出记录所需的时间。如果一张表没有合适的索引，当数据规模较小时可能还看不出问题；然而，一旦有几千行以上的生产数据，性能就会严重降低。

　　应该先与关注性能的客户交流，争取拿到一份生产数据库的副本，这样就可以针对它来进行测试。在这个过程中要注意数据保护，并对拿到的数据库做适当的清理，删除或修改其中的私密信息。

　　你还应该与客户探讨数据规模发生变化的可能性。数据量会大致保持在现有水平上吗？还是很可能会增长？如果会增长，增长的速度会有多快？只有了解这些信息，你才知道是否应该用一个比现在大得多的数据库来做性能。

　　要得到一个更大的数据库，最好的办法就是使用稳定性测试创建新的数据库。在稳定性测试中，你应该会创建新的用户和新的交易数据。如果这组测试整个周末都在顺利运行，那么你就能得到一个适用于未来情形的数据规模了。

　　如果处理第三方接口

　　如果系统用到很多第三方接口，性能测试最好不要直接去使用这些第三方系统。原因有两点：首先，第三方系统可能并不适合成为性能测试的一部分；其次，即使第三方系统提供了测试环境，依赖你无法控制的第三方系统会降低测试的可靠性。

　　最好的办法是用一个单独的测试来获知第三方系统的平均响应时间，然后为它写一个mock或者stub，直接等待那么长的一段时间然后返回一个固定的响应。当然也可以直接返回响应，不过这样就会让测试失去了一些真实性，因为没有了等待第三方系统的时间，应用程序服务器就能够更快地释放数据库连接或者网络连接，这会给最终的测试结果造成差异。

　　需要多少种测试案例

　　这是个重要的问题，因为不恰当（过多或过少）的测试会严歪曲测试结果。如果测试案例太少，所有相关的信息都会被缓存起来，系统就会显得比实际情况更快，如果测试案例太多，缓存就会溢出，系统就会显得比实际情况要慢。

　　多少种测试案例才是合适的呢？你需要和关注性能的客户讨论系统的预期使用情况，并且如果可能的话，请分析现有系统的使用日志从而找到一个答案。比如说，如果要测试的场景是“从应用程序获取顾客信息”，那么要在测试中覆盖到的顾客数显然和正常操作中涉及的顾客数有关。如果正常情况下系统中每天有5%的顾客信息记录会被取出，那么你的测试也就应该覆盖这么多的顾客。

　　为何要多次度量响应时间和吞吐量

　　一般来说，在从空闲状态开始增加负载量时，系统响应时间不会有什么变化。随着负载量不断上升，到达某一个点之后，尽管单位时间内处理的事务量仍然在上升（即吞吐量继续上升），但每个请求的响应时间会受到影响而逐渐上升。当服务器达到能力上限时，起初吞吐量会保持不变，而同时响应时间表显著上升；最终吞吐量会急剧下跌，因为计算机已经无法承担所要求的如此大量的工作。这时响应时间将会上升；最终吞吐量会急剧下跌，因为计算机已经无法承担所要求的如此大量的工作。这时响应时间将会急升，整个系统会濒临死机。

　　在这个过程中，我们对几方面的信息感兴趣。首先，我们希望知道系统最大吞吐量出现在哪个点。除此之外，我们还希望知道最佳响应时间、当响应时间正好符合要求时的负载量以及负载达到事先测量的最大吞吐量的80%和90%时的响应时间等信息。

　　有了这组数据，你就可以限制每台应用程序服务器的连接数，从而确保系统性能始终保持在性能需求所规定的水平以上。可以看到，当负载量逼近极限时，响应时间会急剧上升；而当负载量达到80%甚至90%时，响应时间却没有太多变化。如果你必须确保某个性能水平，这一现象应该始终牢记于心。

　　有必要测试所有功能吗

　　对系统的所有功能进行测试基本上是不现实的。重点在于要覆盖最常用的功能。所以你需要识别出系统的主要使用场景，并针对这些场景创建不同的测试。

　　比如说，在线购物网站最主要的使用模式应该是“浏览”和“购买”。来购物的人不全会浏览很多页面，浏览的时间通常也不都会太长。所以你需要创建一个“浏览”的测试脚本和一个“购买”的测试脚本。为了让测试脚本更贴近真实，你需要知道用户浏览商品的平均数量、每次购买的平均商品数以及正常情况下一时间内被浏览过的商品数点商品总数的百分比。

　　小结

　　关于性能测试，有很多话题可以讨论。需要度量什么？需要多频繁的测试？需要编写多少脚本？需要多少数据？在与关注性能的客户进行日常讨论时，主要应该确保这些重要的问题被提出来，并保证能得到你需要的信息。如果你认为事情的发展方式会严重影响测试的进展，也应该找时间与项目经理和客户沟通。