前言
1、性能测试中业务量、吞吐量和存量数据的设计关系
1）业务量
是不带时间单位。我们提到业务量的时候，一定会加一个时间单位。比如说，每天的业务量是 100 万笔，每年的业务量是 1 亿笔，等等。
2）吞吐量
是自带时间单位的。吞吐量是单位时间内处理的业务数量。
业务量和吞吐量的关系
那么问题来了，我们做性能测试的时候，用哪个词呢？业务量 or 吞吐量？
事实上，这两个词我们都用。因为他们的内涵不同。
业务部门的目标里，往往是一年业务量多少，一天业务量多少。而这些目标并不能勾勒出性能测试目标。因为性能测试要的是每秒的业务量有多少。
举个例子：
一天 24 万笔业务，并不代表一小时处理 1 万笔，也许这 24 万笔是一个小时里处理完的。
用户往往等个一两秒钟还是可以忍的，如果等 10 秒钟，恐怕是觉得系统已经挂了。因此，系统要及时处理业务请求 / 报文，不能产生严重堆积，我们最关注的是一秒钟处理多少业务。而不是一小时多少，或者一天多少。
这里有存在一个换算的过程。
业务的要求是 1 天处理 2000 万笔业务，那么吞吐量目标是多少呢？
这就要看系统的性能模型，一天当中哪个时段业务量大，这个时段的业务量占一天业务量的百分比是多少？然后一步一步的计算出峰值时期一秒钟的业务量，它，就是我们的吞吐量目标。
3）存量数据
有了吞吐量目标，但还不能立刻就动手做测试，这是因为，还有第三个概念，存量数据。
如果数据库是一个空库，或者数据库是个存有 2 亿条记录的库，那么 SQL 的增删改查的响应时间是完全不一样的。对应的业务响应时间也完全不一样。那么，我们数据库里面的存量数据应该设多少呢？
存量数据和业务量的关系
预计的存量数据，就要用到业务量这个概念。
毕竟，存量数据是以年、月、天为单位的，而不是以秒为单位的。
比如说，这个系统的存量数据是 3 年，或者 3 天，而不是 3 秒。
并且，计算一年的存量数据，肯定不是用峰值每秒的业务量 360024*365 来计算的。而是用到业务部门提到的业务量。
比如，今年业务量预计 100 亿笔，预计年增长率是 50% 。那么，如果要测试系统能否满足 3 年以后的需求，就要这么计算：假设系统存量数据保存 3 年，那么 3 年后的存量数据是（ 100+1001.5+1001.5*1.5 ）亿笔。
三年后的吞吐量这么来计算：
假设一天业务最大的那个小时，占全天业务量的 20% ，业务量最大的一秒占这个小时的 1/2000 。假设一天业务量是 A 笔。
今年的每秒吞吐量目标 B=A20%(1/2000) 。假设性能模型不变，三年后的每秒吞吐量目标 C=B1.51.5。
2、压力测试的几种常见的解决方案
并发性（压力测试）指的是多个用户试图同时访问相同数据的处理，问题的关键在于如何设计应用程序对并发性问题的处理方式，特别是当前很多系统都存在多用户对共享资源的访问，常见的解决方案如下：
1）保守方法
这种并发性模型在数据上加了锁，如一个用户在操作数据库的一条记录时，在允许编辑的环境中，系统就会拒绝来自其它用户读取数据的请求。
对于很可能出现一个以上用户同时编辑相同数据的情况时，最适合采用这种方式，虽然这种方式在实现上有一定的复杂度。
在此模式下测试并发性主要关心的是验证能否正确地取得、释放加在记录上的锁，并且正确处理应用程序中所有可能更新这条记录的部分。
锁的获得：
因为同一时刻只有一个用户能够进入一条数据记录或数据项的更新状态，所以关键是系统必须把锁正确地分配给第一个请求的用户。获得锁的操作应该是可操作的。
具体的做法是：
让两个用户试图同时进入编辑状态或者也可以使用大量的请求，对于后者我们可以使用一个脚本来产生多个同时的编辑数据请求，以此来验证只有一个请求获得成功。
锁的效用：
验证锁的有效性必须确保其它任何用户不能用任何方式修改这个数据(如修改和删除)。
具体的验证方法是：
让一个用户打开一条记录(进入编辑模式并且保持这个状态)，同时其它用户在应用程序的所有地方试图编辑、删除等一切方法更新数据，系统应该拒绝所有其它用户更新数据的企图。
锁的释放：
必须验证：当编辑数据的用户释放了该条记录后，系统能够让其它用户编辑该条记录，另一个注意的方面是错误处理，也就是持有锁的用户用到错误的情况下(如客户端崩溃)，系统应该完成什么样的操作，系统从释放锁的故障中重新恢复的能力要重点考虑。
2）开放方式
在此模式中，总是允许用户读取数据，甚至还可能允许更新数据，但当用户试图保存数据时，系统会自动检查自从这个用户检索数据以后是否有其它人更新过数据，如果数据发生了变化，那么更新就失败。
这种方法比保守模型允许更多的用户查看数据，所以它适用于不太可能出现多人同时修改同一数据的情况。
在此模式下，更新是唯一需要关注的要点，最佳的测试方法是综合手动和自动测试技术，在手动测试时，两个测试人员编辑数据，然后试图同时保存数据，一个用户更新的操作成功后，另一个用户得到的消息是内容是其它用户已经更新了数据，此时他只有重新装载数据并且重新完成修改操作。
在使用自动海量的测试方法时，同理，只有一个用户能更新记录，而其它用户都收到提示，因为其它用户已经更新了数据，所以他的操作无效。
3）无并发保护
是所有模式中最简单的一种，通俗的说即胜利属于最后一个用户，但当两个用户同时修改一条记录时，可能导致数据损坏。
在此模式下，无论更新请求的顺序如何，所有用户都该成功完成更新操作，特别需要关注的是数据的完整性和更新错误，如：当一个用户更新某记录的同时，它确被删除了。
处理并发测试时还要注意，当相同的数据可以通过不同的界面或者功能更新时，应该测试所有可能访问这条记录的功能。
总结：
感谢每一个认真阅读我文章的人！！！
作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
