重读《从菜鸟到测试架构师》-- 模拟客户的访问行为（上）
上一章，我们跟着刚刚进入性能测试组的小艾一起初识了什么是性能测试，也知道了客户在性能上都关注了些什么，在组长的教导下，小艾明白了，想要让用户得到最好的性能体验，最简单有效的方法就是模拟客户使用产品时遇到的访问行为，这一章节就来聊聊如何来模拟客户的访问行为呢？
更真实更高效的模拟——自动化的性能测试
如果说功能测试还有手动测试和自动测试的选择，那么，性能测试则不可避免地要用到自动化测试，即通过程序来模拟实际用户对于网站的访问行为。这里大家可以思考下为什么性能测试必须使用自动化来测试~
既然说到需要使用自动化，那么如何做呢？一般我们会通过一些自己开发的或者现有的测试工具来实现多用户混合场景的并发访问。
一般而言，对于功能繁多的大型软件的测试来讲，通常会设计一个比较完备的测试框架，而非简单录制脚本加压进行测试。
测试框架的要求
1. 测试程序的模块化和可重用性：实际测试中，不同的测试分支可能会有相同的步骤，在定义每个模块的时候将输入/输出定义清楚是关键。
2. 功能分支的可选择性：为了模拟实际客户的访问，往往将多个测试分支混合在一起进行并发访问，因此，测试脚本必须是可以选择混合哪些分支的。
3. 可定义的输入数据：脚本必须可以定制输入的数据
4. 高可靠性：对同一套脚本，同样的输入，同样的测试环境，多次运行出的结果应该相同或非常接近，否则测出的结果没有可信性
5. 可扩展性：如并发用户数量、测试时间等的扩展
春节大促——压力测试
如上一篇文章提到的双十一大促等，是一种短时间内将系统负载压到极限的例子，在测试中，一般通过压力测试来模拟。
压力测试
主要考察让系统运行在比较大的负载条件下的性能表现。一般会采用多个并发用户进行一段时间高压力的访问，压力测试可以发现系统工作在多任务并发情况下可能出现的性能问题。由于压力测试下系统工作在非常高的负载状况下，所以衡量的性能运行指标一般为吞吐率和错误率，而不包括响应时间。
压力测试的目的
发现并解决在并发、长时间运行或大量数据情况下才出现的系统缺陷。
在指定并发用户数下能否达到吞吐率目标。
什么是吞吐率？
吞吐率通常是指应用系统在单位时间内实际处理的交易数量或页面点击数量。与系统负载指标类似，吞吐率也随时间而变化，存在最大值和平均值。
一些重要的组件的吞吐率往往被作为一个版本的关键质量标准，决定软件版本是否能顺利发布。
新版本的吞吐率往往用来与旧版本的吞吐率进行比较来确保新功能的加入不会引起整体的性能下降。
压力测试根据目的分类
一类压力测试是找出应用系统的饱和点，即系统的性能瓶颈。通常希望该瓶颈是系统的CPU处理能力，这类压力测试主要通过标准是系统在CPU运算能力饱和状态下的吞吐率和错误率。
一类压力测试则是找出应用系统的崩溃点。这类测试通常不关心具体的吞吐率和错误率指标，而是考察吞吐率、错误率指标与负载的关系曲线。
压力测试通过的标准
在承受指定负载的前提下，系统的吞吐率是否达标，并发用户数是否达标，出错率是否达标。
在并发量很大的情况下，有的事务可能因为等候资源超时而造成回滚，少量的访问失败在所难免，但如果大并发下出错率很高，就说明系统处理并发的能力不足，有可能是并发处理逻辑有问题。
一般来说，吞吐率越高表示系统的性能越好，但值得注意的是，各种交易的复杂程度不同，每个交易页面的点击数也可能相差很大，脱离具体交易的内容，片面通过两个系统的吞吐率来衡量两个系统的性能好坏是没有意义的。
而对于同一个交易系统来讲，希望吞吐率与并发数能成正比，这是理想的情况。现实则会在某个点达到CPU使用率饱和，若饱和后继续增大并发量，则可能导致系统崩溃。
日常的访问量——正常的响应时间
响应时间是另一个常见的衡量系统快慢的运行指标。一般来说，响应时间越短越好。
与将系统负载压到极限的压力测试相比，响应时间测试测的是再正常负载状态下，被测系统的服务器端和客户端响应时间（不考虑外部网络传输影响）。即，响应时间的测试结果更接近通常状态下的系统真实性能表现。
响应时间测试的目的
在正常负载前提下，保证服务器或者客户端的操作响应时间不超过规定的标准。
网页响应时间的构成
用户的页面请求从发出到完全得到响应有一个过程：在网络上传输数据、在服务器端处理，服务器将响应数据传回到客户端，在浏览器中显示，这几部分是相互独立的。
在网络上数据传输的时间取决于页面数据量的大小、网络速度和网络上的拥挤程度。
在浏览器中显示的时间取决于客户端程序的复杂程度，以及运行浏览器的客户计算机的处理速度。
服务器端处理的时间和服务器系统的性能相关，这段时间称为页面处理时间，又可细分为队列等待和实际处理两部分。
实际处理
实际处理时间与吞吐率关系较小，主要取决于处理程序的执行效率（算法好坏）和硬件处理速度。
队列等待
队列等待时间除了与硬件处理速度相关，还跟各种共享资源的参数设置有关。
在设计响应时间这方面的测试用例的时候，会针对服务器端和客户端分别设计用例，并且分别定义通过标准。
保证长时间的稳定运营——可靠性测试
一般来说，可靠性测试对待测系统施加的负载要小于压力测试的负载。一般可以选取系统日常处理的平均负载。
可靠性测试评估的性能指标通常是响应时间、错误率和系统资源占用率。
可靠性测试的目的
评估长时间的性能指标是否满足要求，往往考察平均值。
考察性能指标的变化趋势，以发现系统可能存在的内存泄漏、性能下降等与执行时间有关的性能问题。
考察某些维护性操作是否会对前台用户访问的性能造成大的影响。
可靠性测试是一个版本性能的终极测试，可靠性测试的设计往往需要考虑把药测试版本最关键功能和最基本功能都涉及到。
客户的成长不比产品慢：想象不到的数据量——可扩展性测试
可扩展性测试是验证被测系统随着计算能力的扩展能否承受更大的负载，负载的增大包括数据规模、业务种类、数据复杂度等。
可扩展性测试的目的
可扩展性测试往往针对的是系统在某一个负载方向上的可扩展性。
可扩展性测试一般在不同的负载下衡量系统响应时间或者吞吐率的变化趋势。
尾声
不管是吞吐率、并发用户数、响应时间还是可靠性，任何性能指标的好坏，除了与软件本身的并发性能好坏有关，还在很大程度上取决于硬件系统的处理能力。
在明白了上述的知识之后，下一章，小艾将亲身经历性能测试的工作了，让我们一起期待吧~
这一系列文章在微信公众号中已经全部更新完成，大家可以通过查看历史消息回顾所有文章，更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月
