想让性能测试更高效？“性能等式”了解一下

在测试性能时，我们可以尝试编写一个“性能等式”，以便检查影响性能的每个因素。但是，就算逐一检查方程式里的每一项也并不总是能看清整体情况，有些影响性能的因素很容易被忽略，测试更多的是发现系统的行为，而不是对一些期望行为的样本进行验证。

许多团队为了查看系统是否能够满足业务需求，会搭建一套基于服务器和网络基础设施的“测试平台”，开发一些模拟用户请求的脚本，并运行这些脚本来测试应用程序。为了确保系统有额外的容量，他们会将事务数增加一倍。

但这种方法似乎只是有时起作用，这意味着它在其他时候失败了。而解释它为什么成功或失败也同样是件困难的事。

让我们先仔细看看构成“性能等式”的部分：

这里：

• Env 表示测试环境(网络、交换机、负载均衡器、服务器、数据库和平台软件)。
• WL 表示模拟用户行为的负载脚本。
• Code 表示应用程序代码，包括程序内部组件和第三方库。
• X 是一组性能特征，比如响应时间、吞吐量等。

环境

测试环境中的硬件和软件对应用程序的性能有多方面的影响。如果复制生产环境在在经济上不允许的话，那么最好的选择是使用最接近生产环境的、可用的环境进行性能测试。

通常，这可能是用户验收测试环境或生产前环境。典型的“挑战叉”式，使用比实际生产环境弱的测试环境可能会导致许多不真实的错误，而使用比生产环境强大的测试环境可能会掩盖真正的性能问题。

尽管在明显不同的硬件上进行测试的风险是显而易见的，但有些差异可能就不那么明显了。像服务器设置、内存分配和进程优先级，这些都是需要优先考虑的。

应用程序的设置也可能会导致性能变化，比如，调试模式或日志记录的级别都有可能会显著改变文件操作的频率和数量。

数据库结构和内容的复杂性也可能会对搜索和报告等功能产生显著的性能影响。要避免此风险，我们可以使用生产数据库的屏蔽副本。

而且可能需要几轮测试我们才能发现和纠正那些隐藏在环境部分的、影响性能的因素。

负载

负载模型通常基于服务级协议和业务需求。一些常见的示例包括事务数、并发用户数和响应时间。典型的需求可能如下所示：

• 允许并发数占2500个总用户基数的10%。
• 支持每小时执行2500次的交易量。
• 页面加载时间不应超过5 -10秒。
• 该系统应保持8小时内无操作。

这样的需求看起来非常简单，因此它们可能被用作工作负载模型。例如，根据上面给出的需求，您可能需要模拟250个并发用户每小时执行10个事务，每次8个小时。

同时，还要测试页面加载时间。是的，为了测试额外的容量，我们可以每小时做20个事务，或者每三分钟做一次。

对这个简单直白的模型，我们有没有漏掉什么东西？

为了获得另一个视角，让我们将应用程序流量比作道路流量。

一段100码长的路可以同时被10辆车占用。但是，当只有几辆车时，或者当他们一辆接一辆地行驶时，我们注意到行驶速度是不一样的。还要注意的是，在任何给定的路段上，同时并行的可能只有车道数那么多的车辆。

如果车道数变了，车道数最少那一段，即能同时并行车辆数最少的路段，将极大地影响车辆行驶速度。

你可能知道这是怎么回事。在一段时间内平均分配事务的数量时，考虑到了用户的并发性，但没有考虑事务的并发性。

虽然人们可能会争辩说，250个用户不太可能同时按下“提交”按钮，但是有10个用户这么做的可能性有多大呢？甚至是3个？这是我们最有可能遇到瓶颈的地方。

那么并发用户的总数呢？大多数负载测试工具和服务都有一个基于虚拟用户数量的定价模型，而且许多公司没有为250个虚拟用户颁发许可证。

一个典型的解决方法是将脚本的速度提高一倍或三倍，以弥补事务的数量。

虽然它在数学上是正确的，但是这种方法没有考虑到用户会话的数量对软件系统有非线性的影响。每个用户会话都需要分配资源(分配到应用程序的内存、服务器和数据库)，并且资源管理本身也有性能压力。

因此，以三倍的速度运行脚本并不能真正弥补同等数量的用户行为。

代码

在我们的性能方程中，如果我们假设代码部分是唯一的变量，那么任何性能变化都应该意味着是由于最近的代码更改引起的。

一些代码更改可能确实会对性能产生巨大影响。但是，通常情况下，在性能问题变得明显之前，这里和那里的隐藏的小变化会累积一段时间。除非您有关于每个构建的性能基准的趋势图，否则很难注意到任何缓慢的下降。

尽管测试可能会显示性能下降，但解决问题的困难之处在于缺乏单一的根本原因。

恒定工作负荷模型的目的是建立跟踪基准，它们以相同的加载方式执行相同的脚本，但这也意味着以同样的方式行使相同的应用程序功能，实际用户在使用中会执行各种操作。

除了事务预订功能之外，它们还可以搜索、编辑、删除数据和运行报表。所有这些功能可能不会使负载增加，但是如果用户并行操作的话会对性能有实质的影响。

在相同的功能中也有新部署的特性，例如账户查找、编辑购物车等等。如果脚本以相同的方式提交事务，它们不会处理新增的那部分功能。

解X

所有的测试都是一种混合的活动：学习、建模、实验和调查。测试更多的是发现系统的行为，而不是对一些期望行为的样本进行验证，负载和性能测试也不例外，只有经过反复的尝试和错误，我们才能了解系统并开发有用的工作负载模型。

在你的性能方程中寻找隐藏的那部分吧——特别是当它看起来很容易解决的时候。

福利

福利大放送，从入门到实战，从电子书到面试真题，你需要的软件测试资料，我这里都免费赠送，需要的可以私信 888 免费领取哟

利用Jmeter做功能测试的优缺点

2022-01-05 16:36·北漂编程

利用Jmeter做功能测试有以下优点：

  ● 不依赖于界面，如果服务正常启动，传递参数明确就可以添加测试用例，执行测试

  ● 测试脚本不需要编程，熟悉http请求，熟悉业务流程，就可以根据页面中input对象来编写测试用例。

  ● 测试脚本维护方便，可以将测试脚本复制，并且可以将某一部分单独保存。

  ● 可以跳过页面限制，向后台程序添加非法数据，这样可以测试后台程序的健壮性。

  ● 利用badboy录制测试脚本，可以快速的形成测试脚本

  ● Jmeter断言可以验证代码中是否有需要得到的值

  ● 使用参数化以及Jmeter提供的函数功能，可以快速完成测试数据的添加修改等

  利用Jmeter做功能测试有以下缺点：

  ● 使用Jmeter无法验证JS程序，也无法验证页面，所以需要手工去验证。

  ● Jmeter的断言功能不是很强大

  ● 就算是jmeter脚本顺利执行，依旧无法确定程序是否正确执行，有时候需要进入程序查看，或者查看Jmeter的响应数据。

  ● Jmeter脚本的维护需要保存为本地文件，而每个脚本文件只能保存一个测试用例，不利于脚本的维护。

  Jmeter和其他功能测试工具在使用中的比较：

  ● Jmeter比较适用于数据添加，数据修改，数据查询的测试，使用其他测试工具虽然也可以完成该类测试，但是利用Jmeter添加数据更快，更方便，而且不依赖于界面，只要添加数据的参数不改变，无论界面是否有变动，都不影响针对数据的操作。

  ● Jmeter不需要要关注对象是否被识别的问题，而其他测试工具在录制过程中，很容易出现页面对象不能被录制工具识别的问题，因此适用Jmeter，省略了很多关于对象操作的麻烦，更易于使用。

  ● Jmeter的适用更主要的是依赖于对被测项目的认知和熟悉，而对于Jmeter自身的适用技巧要求并不是很高，而其他测试工具，关于工具本身需要较长时间的学习。

  ● Jmeter能够对复杂的业务逻辑进行处理，而对这些复杂业务逻辑的处理，主要是运用Jmeter自身所带的配置元件来达到，对录制的脚本的修改不大，而使用其他测试工具，要实现复杂业务逻辑的测试，则需要对录制的脚本进行修改，需要工具使用人员有一点的编程能了，因此，使用Jmeter进行测试对测试人员编程能力的要求不高，同时节省大量的修改脚本的时间。

  ● 其他测试工具的测试脚本可以通过CVS等版本控制工具进行管理，而Jmeter的测试脚本的管理不知道是否可以纳入版本控制，因此，其他测试工具比较适用于大型的，系统的功能测试中，而Jmeter比较适用于随机的，扩展开发不多的项目，也就是说Jmeter使用起来更灵活。

  ● 其他测试工具有大量的验证点可用，并且能够对界面上的内容进行验证，可以验证更多的内容，测试能够更完全，对于界面变动不大的项目，可以通过修改脚本实现更加全面的自动化测试，而Jmeter提供的断言功能有限，并且不依赖于界面，无法完界面相关内容的验证，用Jmeter测试更需要人工测试，人工确认。

  ● Jmeter用作一个辅助测试工具，可以很大的提高测试人员的效率，而其他测试工具当作辅助测试工具并不能达到和jmeter同样的功能。

  ● Jmeter做功能测试的脚本可以同样用来做性能测试，这是其他大多数功能测试工具所不能具备的。