好奇于数据库压力测试方案，这两天一直在思考如何对数据库做压力测试。
在数据应用系统上线前，测试数据库能接收多少并发量，能够给自己信心，对上线不影响用户体验有充分的把握。清楚哪一块是薄弱的地方，知道怎么去弥补。
偶尔在 google 里面搜出来一个产品的测试方案基本用法，得以窥见成熟的商业方案。
英文链接如下：
https://support.smartbear.com/loadcomplete/docs/tutorials/getting-started/intro/basic-concepts.html
以下是对其做的翻译和理解，整理出来做个记录，算是一种思路。
对应用系统的压力测试方案：
1 recording a scenario.
录入场景：
场景就是用户在某一个应用的操作，比如注册一个新用户，或者网购下单。
当对注册新用户这一操作做了录像，那么就可以模拟多个新注册用户的操作了。
当对一个用户下单这一操作，做了录像，那么10万人同时下单的自动化测试，只要生成10万个线程，模拟下单过程就可以测试下单这一过程的压力。
重点是，如何针对应用的操作，做好数据的录入，有些数据是自增的，有些是随机的，有些可以更改，有些删除了就不能再次执行删除，这些都是数据应用的场景，包含的逻辑怎么可以被识别，并正确的录入下来，方便以后线性扩展开来？如果是微服务架构的应用，会设计到各种 http, https, websocket 的交互，给录入标准化增加了难度。
如果是自研的系统还能利用白盒测试，自主扩展；如果是第三方系统，那么就有难度了。所以暂且不论第三方系统，就以自研系统为标的，做压力测试。
2 Modifying the recorded traffic(optional)
修改录入场景的流量（可选）。有些原本录入的请求是不需要在测试环境中再次模拟发送的，可以去掉；有些请求可以做线性扩展的，来测试抗压能力。上述场景都可以在这一步编辑。
3 Verifying the recorded scenario
校验录入场景的有效性。
在第一步中，提出了很多针对数据应用逻辑识别的难点，在这一步我们就可以详细的解答这些难点了。
比如数据的自增难题，我们可以模拟自增数字，日期，名称等，来与数据应用交互，判断场景的有效性；比如新用户注册并发问题，在一个虚拟用户操作逻辑成立的基础上，模拟成千上万个虚拟用户注册的操作，来测试并发能力。
在这一步中，我们要考虑的是如何给录入的场景做模型存储。既然录入场景已经生效了，就可以抽象成模型，用来做扩展基础。
4 Creating load tests that will simulate recorded traffic.
模拟录入的场景，以此为基础，测试用户多个连贯的操作。
这一步就是真正实现测试程序了。在已经校验过的录入场景上，模拟多个连贯场景来完成应用操作，
5 Assigning recorded scenarios to desired virtual users.
分配多个虚拟用户来模拟录入场景的并发测试。
上面4步中，我们举了两个场景：新用户注册和网购下单。单个用户模拟通过，是完成自动化测试程序的第一步，多用户的模拟，需要灵活的配置，和多线程调度的编程。在此基础上，逐步增加虚拟用户，以观察数据应用的响应时间，数据库的CPU,Memory,IO的增长趋势。
一台计算机的并发毕竟是有限的，借助云客户端，可以模拟更多用户的访问量。
6 Running load tests
7 Analyzing load test results
分析多用户访问量的测试结果。
将第 5 步的监控指标都撰写成报告，观察指标的趋势。