性能测试实战--计划测试（一）-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_22003641/article/details/83479514

一、性能测试流程

计划测试->创建脚本->创建场景->运行场景->分析性能数据->生成x性能测试报告，如下图所示：

1.1 计划测试

在任何类型的测试中，编写测试计划都是必要的步骤。有条不紊、计划周密的计划，可以确保在执行中能够有章可循。在计划测试阶段需要输出性能测试计划，而计划阶段需要经历如下几个环节，如下图所示：

1.1.1 分析系统阶段

要进行性能测试，了解被测对象是需要做的第一步。首先需要确认系统的架构和所使用的协议，对工具的可行性进行分析，然后对整个业务进行熟悉，确认相关的数据和业务操作可以被工具录制回放。

✔ 通过分析系统阶段需要知道该系统能不能进行性能测试。

1. 确定协议

如何确定系统所使用的协议，这是大家经常讨论的问题，其实询问一下需求分析人员或开发人员就知道，绝大多数时候系统都使用标准的开发架构，而所使用的协议也是系统事先封装好的，不过万一开发人员也不知道系统到底使用了哪些协议呢？这时不能随意悬着录制协议，否则会由于漏录软件交互协议导致回放失败，或录制了大量无用交互协议导致脚本无法维护，这时就需要引入网络数据包拦截分析，来确认系统协议。

网络数据包拦截软件其实有很多，比如常见的Wireshark、Omnipeek等。通过这类工具，可以拦截整个被测系统所使用的协议类型，甚至明确数据包的封装格式。它们和HttpWach略有不同，HTTPWatch是一个基于浏览器的插件，可以帮助我们拦截HTTP的数据包；而这里使用的网络拦截工具是基于网卡的底层扫描的。

这里以Omnipeek为例具体说明一下。Omnipeek是由Wildpackets公司研发的网络扫描维护工具，其提供了高效的故障诊断和定位能力，这一特性能够明显缩减日常花费大量寻障和排障的时间，使我们有精力去完善日常其他的工作以及学习更多的业务知识。在很长一段时间内，Sniffer都是网络扫描和数据包拦截方面的指导性软件，作为后起之秀的Omnipeek，在最近几年中其锋芒已经压过Sniffer成为各大杂志推荐的最佳产品。

Omnipeek提供以下几种功能，可帮助测试人员快速对网络问题进行故障诊断/定位。

主机排名。发现网络中通信量最大的主机，对比故障现象与影响范围，如下图所示：
协议排名。可以对监控的所有协议进行排名，找到使用最多的协议，如下图所示：
具体哪些主机在使用某种通信协议，如下图所示：
通过PeerMap网络分布图了解主机会话的实时情况，如下图所示：
深入解码分析。发现异常后，可以进行深入的解码分析，如下图所示：

通过以上步骤可以很容易的发现流量异常的主机、主机不正常的协议通信以及网络中实际传输的数据内容。从某些角度来说，使用Omnipeek来做协议分析，真是杀鸡用牛刀。读者可以在各大网络下载到免费版本的Omnipeek安装包。下面我们使用Omnipeek来尝试捕捉和分析系统，了解其使用的网络协议。

打开Omnipeek，在主界面的左上侧单机New Capture按钮，如下图所示：
新建一个数据捕捉，弹出Capture Options协议捕捉设置窗口，如下图所示：
在这里需要设置以下内容。

General中的捕捉名称。
Adapter需要捕捉的设备。
Filters对于协议包的过滤规则。

在多网卡的情况下，这里选择的设备不能有错，否则会导致没有数据包被捕捉的情况。确认后进入监控页面，如下图所示：

单击Start Capture按钮就可以开始进行协议捕获了。

如果现在想知道自己的有线网卡在做些什么，那么只要确保前面设置的捕获设备是本地网卡即可，不需要设置任何Filters过滤规则，单击Start Capture按钮开始捕获，稍等片刻，可以看到有大量的数据包被捕获下来，如下图所示：

在列表中可以看到通过网络数据包捕获得到了每个请求的发送源、接收请求的地址、数据包的大小、传送时间及协议类型。

通过这种方式可以轻松地确认需要进行性能测试的系统所使用的协议类型。另一方面还能对每个请求进行更加深入的分析，双击打开请求，即可得到该请求的详细分析，包括发送的数据包格式、所使用的协议及该协议下的数据内容，如下图所示：

一般从性能测试工具的协议选择角度来说，应尽可能使用高级的协议，作为底层的Windows Sockets 协议只有在万不得已的情况下才使用。通过工具分析扫描以后可以确定系统所使用的协议类型、协议格式和封包规则，而Omnipeek几乎能够识别所有的协议标准，下图所示：

扫描后可以根据扫描的结果去检查VuGen是否支持这种协议，如果遇到VuGen不支持的协议，那么使用LoadRunner来进行性能测试可能就不是最佳选择，虽然可以通过Windows Sockets来模拟这个过程，但是使用过程相对烦琐。

对于这次需要测试的Phpwind和Discuz论坛来说，从其官方网站可以了解这是基于PHP技术的B/S架构论坛系统，在客户端上通过HTTP完成对整个论坛的访问，所以确认该系统可以使用LoadRunner的HTTP协议完成操作的录制，该工具是适合进行该系统的性能测试的。

2. 熟悉业务流程

每一个系统都有自己的业务流程，通过查看相关文档，可以了解系统的执行步骤和业务流程，从而了解用户如何使用整个系统。我们需要先将各种业务操作的流程进行整理，并且通过VuGen进行录制回放，检查该系统是否能够被性能测试工具模拟用户行为。

对于一个要测试的论坛来说，常见的操作包括发帖、查看帖子、用户间收发短消息等操作。这里简单分析一下用户进行常见操作所需要的一些业务流程。

1）浏览帖子

一个论坛所能提供给用户主要的功能就是帖子的浏览功能，绝大多数情况下论坛都会被设置为无需登录即可浏览大部分板块的帖子。用户在访问到论坛首页后会点击自己感兴趣的板块，并且进行前后翻页，查找自己关心的话题，然后进入该话题，进行浏览操作。

2）查询帖子

使用搜索引擎是大家最常做的事情，而论坛也提供了强大的查询功能。当登录系统后，就可以使用查询功能在论坛中查找各种话题，查询后列出符合查询条件的相关记录，查询速度一般受到论坛数据量的影响较大。

3）回帖/发帖

相对于浏览来说，回帖或发帖的操作并不会如此频繁，用户发帖或回帖需要先登录论坛，进入在线用户状态后，即可在不同的模块中进行发帖或对某些帖子进行回帖操作。

4）注册新用户

当用户想要进行回帖、发帖或查询等操作时，都需要成为注册用户而不是游客，注册新用户也是论坛比较常用的功能，但是大多数情况下对于任何一个真实用户来说，注册用户也只是只做一次的事情，只需要单击注册后输入相关用户名和密码即可完成用户的操作，而不会每次使用系统新注册用户。

通过VuGen录制上述操作后，检查对应的脚本，回放这些脚本均可以成功并且没有出现漏录协议交互的情况，那么就可以认为该系统的性能测试是能够使用LoadRunner工具进行的。如果出现脚本回放失败，并不能说明无法使用LoadRunner进行性能测试，需要再参考下面的系统相关信息来进一步确认。对于基于HTTP的应用来说，LoadRunner已经非常成熟了，所以很少会发生在基于HTTP的应用中无法进行性能测试的情况。

3. 获得系统相关信息

当脚本回放出错时，某些情况是由于无法录制到某些操作导致回放失败，而大多数情况是由于系统中存在某些动态数据，导致操作无法达到预期的效果，这时需要通过关联来解决动态数据的问题。

那么什么数据需要关联，什么数据需要关联呢？这要求我们熟悉系统业务流程。常见系统的动态数据无非就是session和一些页面参数，通过询问开发或系统设计人员来了解动态数据的产生规则和使用方式。

在需要测试的Discuz论坛中，可以在操作中发现一些常见的动态数据。例如论坛的帖子编号、用户编号、板块编号等，而并没有session这种复杂的检查手段出现（可以通过对相同对象的多次操作，对比请求和返回的区别来识别动态数据）。

而在Phpwind中我们知道需要对verify和_hexie这两个数据进行关联，这两个属性会辅助验证发帖。

当完成了协议的确定、业务的熟悉和相关信息的收集后，接着可以对脚本进行简单的开发了，那么是不是需要把用户所有的行为都进行模拟呢？非也，性能测试并不是要求德智体美劳全面发展，而是强调核心竞争力，接着要做的是对性能测试的目标进行定义，避免性能测试的眉毛胡子一把抓。

1.1.2 定义测试目录

作为任意一个测试来说，了解了被测对象后，接着就需要了解用户的测试目标或者叫做需求。不是在开发前已经和用户确认生成SRS（需求规格说明书）了吗？其实问题就出在我们总认为有了SRS软件就能够做出来了，但是实际情况是一方面SRS并无法包含所有的用户需求，另一方面在设计SRS的时候总会忽视在性能方面的需求，即在设计阶段性能隐患就被植入了软件。

用户自身是无法提供准确有效的需求的，所以作为需求中的性能测试，需要性能需求分析工程师对其进行显式和隐式的分析，得到准确清晰的性能需求，当需求被确认后我们就能知道性能测试该测什么了。

✔ 通过定义测试目标需要知道的是用户想要什么。

那么如何获得性能需求呢？在此之前请先考虑一个问题：上海铁路人民广场1号线站台和换乘大厅应该修建多宽？

乍看一眼，你可能觉得这是一个功能需求，怎么可能和性能相关呢？但这个确实是性能问题，如果换乘的楼梯修建过窄，会导致大量乘客无法疏散出月台引起事故，而如果修建过宽又会带来不必要的浪费，合适的疏散能力就是性能的吞吐量指标。

可能有些朋友会说，我没去过上海，也没有坐过地铁，如何知道这个性能是多少呢？确实，很多时候我们对用户所需要的系统闻所未闻，现在需要我们来做性能需求定义性能测试的目标不是无稽之谈么？那么按照这个道理来说，做性能需求分析的人都应该是业务专家，从某些角度来说需求分析本来就是需要对业务或技术的专家才能担当，但并不是说没有简便入手的方法，对于这种情况，可以通过一下几个方法来获取系统的性能需求。

1. 通过用户提供的数据进行分析

用户永远是需求的最后确认人，通过用户介绍和提供相关数据是分析系统性能需求最直接也是最简便的方式。例如用户想要新建一个系统，来将公司的业务无纸化，那么他会提出相关的要求，例如容量、响应时间、并发量、服务器资源等。而作为实现方，当性能需求分析工程师将用户的需求进行整理后，需要参考以前的项目或相关信息去确定该需求是否合理可实施，进一步和用户协调制定合理有效的性能需求，已达到双赢的结果。

例如，这里有一个OA系统的客户数据，整个公司有500个用户会使用这个系统，主要是在上面完成各种订单的内部处理，每笔业务的提交大概平均要15分钟，每个用户每天大概要提交20笔订单，高峰期时会有33个订单的提交量。整个公司大概有400人事负责订单提交的，还有50个用户负责订单的审查，每个订单都会被2个审查人员复审，复审的时间平均为5分钟。

通过整个客户信息我们能给出什么样的建议和性能需求呢？用户并不了解具体的性能指标，而只能提供业务数据，但是我们在这个业务数据中可以和用户确认一些事情来帮助我们了解性能需求。

在这里我么知道有400个用户在线提交订单，每个订单的提交平均速度是15分钟，而全天每个用户的订单量是20~33笔。通过这个数据我们大概可以计算出订单处理这个模块所需要的系统吞吐量。按照最悲观的考虑方式，以500个用户全部都做订单提交操作，每个用户的提交时间按照10分钟~12分钟较快的模式来计算，那么可以得到系统的处理能力需要达到500*60/10=3000笔业务/小时。进一步计算也就是50笔业务/分钟，每秒不到1笔业务，但是在这里我们并不能按照平均值来计算，这里需要适当地放松，避免多用户并发操作时系统出现问题。

所以需求应该定义为：系统支持500用户并发操作订单提交操作，提供每小时3000笔业务以上的操作能力，单位时间的处理能力大于10笔业务/秒（这个数据可以自己先进行性容量测试后再做确定，参考系统日志中得峰值数据，一般来说峰值数据是按照平均业务的10倍来计算的），标准处理能力下响应时间在2s以内，普通负载下10用户并发响应时间在3s以内，50用户以内的大业务并发响应时间在5s以内。按照每笔业务50个数据字段来计算，一笔业务需要使用500KB（带附件）的数据量，系统对于100Mb/s带宽的设计能够支持20个用户并发提交订单（不包含其他业务的带宽需要），在数据库中每存放一笔订单大概需要开销1MB的磁盘空间，按照每小时3000笔业务的基础加上8~10小时的标准工作时间，所以每天的业务应该有30000笔，需要开销3GB的磁盘空间。

当拥有这样一个性能需求时，如何进行性能测试，如何设计场景，如何评估服务器处理能力，如何确定服务器配置及容量是不是已经清晰了很多。

2. 通过系统日志

当进行旧系统升级的时候，历史数据即系统日志的方式是获得真实用户需求最有效的参考数据（对于峰值并发量的计算通过日志才是最可靠的）。作为常用的Web服务器IIS、Apache或者Nginx，当用户通过客户端发送请求到Web服务器的时候，都会访问日志中记录下来。

IIS日志设置的方法说明如下。在IIS中找到需要的网站，打开日志功能，如下图所示：