重读《从菜鸟到测试架构师》-- 模拟客户的访问行为（上）

上一章，咱们跟着刚刚进入性能测试组的小艾一块儿初识了什么是性能测试，也知道了客户在性能上都关注了些什么，在组长的教导下，小艾明白了，想要让用户获得最好的性能体验，最简单有效的方法就是模拟客户使用产品时遇到的访问行为，这一章节就来聊聊如何来模拟客户的访问行为呢？

更真实更高效的模拟——自动化的性能测试

若是说功能测试还有手动测试和自动测试的选择，那么，性能测试则不可避免地要用到自动化测试，即经过程序来模拟实际用户对于网站的访问行为。这里你们能够思考下为何性能测试必须使用自动化来测试~

既然说到须要使用自动化，那么如何作呢？通常咱们会经过一些本身开发的或者现有的测试工具来实现多用户混合场景的并发访问。

通常而言，对于功能繁多的大型软件的测试来说，一般会设计一个比较完备的测试框架，而非简单录制脚本加压进行测试。

测试框架的要求

1. 测试程序的模块化和可重用性：实际测试中，不一样的测试分支可能会有相同的步骤，在定义每一个模块的时候将输入/输出定义清楚是关键。 

2. 功能分支的可选择性：为了模拟实际客户的访问，每每将多个测试分支混合在一块儿进行并发访问，所以，测试脚本必须是能够选择混合哪些分支的。

3. 可定义的输入数据：脚本必须能够定制输入的数据

4. 高可靠性：对同一套脚本，一样的输入，一样的测试环境，屡次运行出的结果应该相同或很是接近，不然测出的结果没有可信性

5. 可扩展性：如并发用户数量、测试时间等的扩展

春节大促——压力测试

如上一篇文章提到的双十一大促等，是一种短期内将系统负载压到极限的例子，在测试中，通常经过压力测试来模拟。

压力测试

主要考察让系统运行在比较大的负载条件下的性能表现。通常会采用多个并发用户进行一段时间高压力的访问，压力测试能够发现系统工做在多任务并发状况下可能出现的性能问题。因为压力测试下系统工做在很是高的负载情况下，因此衡量的性能运行指标通常为吞吐率和错误率，而不包括响应时间。

压力测试的目的

发现并解决在并发、长时间运行或大量数据状况下才出现的系统缺陷。

在指定并发用户数下可否达到吞吐率目标。

什么是吞吐率？

吞吐率一般是指应用系统在单位时间内实际处理的交易数量或页面点击数量。与系统负载指标相似，吞吐率也随时间而变化，存在最大值和平均值。

一些重要的组件的吞吐率每每被做为一个版本的关键质量标准，决定软件版本是否能顺利发布。

新版本的吞吐率每每用来与旧版本的吞吐率进行比较来确保新功能的加入不会引发总体的性能降低。

 

压力测试根据目的分类

一类压力测试是找出应用系统的饱和点，即系统的性能瓶颈。一般但愿该瓶颈是系统的CPU处理能力，这类压力测试主要经过标准是系统在CPU运算能力饱和状态下的吞吐率和错误率。

一类压力测试则是找出应用系统的崩溃点。这类测试一般不关心具体的吞吐率和错误率指标，而是考察吞吐率、错误率指标与负载的关系曲线。

压力测试经过的标准

在承受指定负载的前提下，系统的吞吐率是否达标，并发用户数是否达标，出错率是否达标。

在并发量很大的状况下，有的事务可能由于等候资源超时而形成回滚，少许的访问失败在所不免，但若是大并发下出错率很高，就说明系统处理并发的能力不足，有多是并发处理逻辑有问题。

通常来讲，吞吐率越高表示系统的性能越好，但值得注意的是，各类交易的复杂程度不一样，每一个交易页面的点击数也可能相差很大，脱离具体交易的内容，片面经过两个系统的吞吐率来衡量两个系统的性能好坏是没有意义的。

而对于同一个交易系统来说，但愿吞吐率与并发数能成正比，这是理想的状况。现实则会在某个点达到CPU使用率饱和，若饱和后继续增大并发量，则可能致使系统崩溃。

平常的访问量——正常的响应时间

响应时间是另外一个常见的衡量系统快慢的运行指标。通常来讲，响应时间越短越好。

与将系统负载压到极限的压力测试相比，响应时间测试测的是再正常负载状态下，被测系统的服务器端和客户端响应时间（不考虑外部网络传输影响）。即，响应时间的测试结果更接近一般状态下的系统真实性能表现。

响应时间测试的目的

在正常负载前提下，保证服务器或者客户端的操做响应时间不超过规定的标准。

网页响应时间的构成

用户的页面请求从发出到彻底获得响应有一个过程：在网络上传输数据、在服务器端处理，服务器将响应数据传回到客户端，在浏览器中显示，这几部分是相互独立的。

在网络上数据传输的时间取决于页面数据量的大小、网络速度和网络上的拥挤程度。

在浏览器中显示的时间取决于客户端程序的复杂程度，以及运行浏览器的客户计算机的处理速度。

服务器端处理的时间和服务器系统的性能相关，这段时间称为页面处理时间，又可细分为队列等待和实际处理两部分。

 

实际处理

实际处理时间与吞吐率关系较小，主要取决于处理程序的执行效率（算法好坏）和硬件处理速度。

 

队列等待

队列等待时间除了与硬件处理速度相关，还跟各类共享资源的参数设置有关。

在设计响应时间这方面的测试用例的时候，会针对服务器端和客户端分别设计用例，而且分别定义经过标准。

保证长时间的稳定运营——可靠性测试

通常来讲，可靠性测试对待测系统施加的负载要小于压力测试的负载。通常能够选取系统平常处理的平均负载。

可靠性测试评估的性能指标一般是响应时间、错误率和系统资源占用率。

 

可靠性测试的目的

评估长时间的性能指标是否知足要求，每每考察平均值。

考察性能指标的变化趋势，以发现系统可能存在的内存泄漏、性能降低等与执行时间有关的性能问题。

考察某些维护性操做是否会对前台用户访问的性能形成大的影响。

可靠性测试是一个版本性能的终极测试，可靠性测试的设计每每须要考虑把药测试版本最关键功能和最基本功能都涉及到。

客户的成长不比产品慢：想象不到的数据量——可扩展性测试

可扩展性测试是验证被测系统随着计算能力的扩展可否承受更大的负载，负载的增大包括数据规模、业务种类、数据复杂度等。

 

可扩展性测试的目的

可扩展性测试每每针对的是系统在某一个负载方向上的可扩展性。

可扩展性测试通常在不一样的负载下衡量系统响应时间或者吞吐率的变化趋势。

尾声

不论是吞吐率、并发用户数、响应时间仍是可靠性，任何性能指标的好坏，除了与软件自己的并发性能好坏有关，还在很大程度上取决于硬件系统的处理能力。

在明白了上述的知识以后，下一章，小艾将亲身经历性能测试的工做了，让咱们一块儿期待吧~

 

这一系列文章在微信公众号中已经所有更新完成，你们能够经过查看历史消息回顾全部文章，更多精彩内容能够扫描下面二维码关注微信公众号: 倚楼听风雨的如月