JMeter学习第一、二、三天

首先，我们来了解一下到底什么是接口测试与性能测试：

接口测试

定义

接口测试主要关注系统组件之间的交互，确保各个接口按预期工作。这包括验证传递的数据、数据格式、调用的频率和其他与接口调用相关的任何限制。

目的

确保系统的各个组件可以正确、高效地进行通信。
检查数据传输、数据完整性和行为是否满足要求。
验证错误情况下的处理和异常管理。

主要特点

通常与系统的功能测试分开。
可使用模拟或存根来模拟外部系统和接口。
通常使用专门的工具，如 Postman、SoapUI 或 JMeter 进行。
涵盖RESTful API、SOAP Web服务、数据库接口和其他第三方服务。

性能测试

定义

性能测试主要关注软件应用的响应时间、稳定性和可靠性，特别是在各种负载和压力条件下。

目的

确定系统在各种负载下的行为。
评估系统的吞吐量、最大负载、响应时间等。
找出可能的性能瓶颈。
验证系统是否满足性能标准和基准。

主要特点

包括多种测试类型，如负载测试、压力测试、耐久测试和容量测试。
通常使用专门的工具，如 JMeter、LoadRunner 或 Gatling 进行。
需要特定的环境和设置以模拟实际用户行为和流量。
结果分析可能涉及硬件和软件的多个层面。

本篇我们学习接口测试！

JMeter介绍

Apache JMeter 是一个开源软件，它最初被设计为用来进行压力测试和性能测试，但后来添加了更多的测试功能，如功能测试和服务测试等。JMeter 可以用于分析和衡量各种服务的性能，包括网络服务、数据库、FTP服务器、HTTP服务等。

通常来说，性能测试的过程是针对于某一个接口进行压力施加。而JMeter本身能够模拟很多人同时访问。所以通常来说使用JMeter做性能测试。但是JMeter有点老，作者因为想打好基础，就跟着学习JMeter了，学完这个应该可以再学一下国产的apipost，也不错。

接口测试

进行接口测试的最为重要的总结：提取有效信息！所有的知识都是有最小知识点的，只要我们抓到核心逻辑，就能够快速学会一样东西。

接口的本质，就是请求，给对应的IP地址访问一次（也就是回车一次），再返回相对应的内容。所以无论是Postman，还是JMeter，本质上都是寻找到这样一个服务器，给它发送请求，再接收到回应的数据，仅此而已。

其中，有一些需要注意的点：

1.服务器返回的内容通常以JSON格式为主。

2.也有可能返回其他格式的东西，比如纯文本内容、xml或表单数据。

接口四要素

URL地址

请求方式（GET/POST）

请求参数（400参数类型报错，比如字符串传成数字了，最常见的错误）

响应结果

一旦发现一个请求的返回值或者应答不对，就立马检查这四要素。这四要素能够检查80%的错误，剩下20%错误：检查请求头的Accept/Token部分、常见的500错误，只要5开头就一定是个bug，一定是服务器错误。

安装使用注意点

1.别tm下载5.6.2的JMeter，文件目录根本不一样，下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！下载5.5的版本！

2.很有可能遇到无法保存的情况：

2.1 首先，关闭JMeter（不能保存就是不能保存了，所以读者使用的时候先随便写几个，看能不能保存），然后以管理员身份运行jmeter可执行文件。

2.2 如果这样还不行，就说明jdk版本很有可能高了，请下载jdk11版本（配 jmeter5.5 完全没有问题），然后配置环境变量稍微改改就行了，作者看到一篇文章居然要求卸载原先的jdk，无法理解……

简单使用

简单来说，就是先在测试计划中添加线程组，然后再在线程组中添加“取样器——HTTP请求”：

然后再在线程组中创建“监听器——查看结果树”，然后点击运行就能看到测试结果。

注意，这里的网站接口信息都是来自于某一商城开源网站（供学习），如果没有完全的把握明白其他网站的HTTP请求，读者就先用这个作为样例。到时候作者使用Springboot+Vue这就很容易测试自己网站的接口，主要就是看有没有接口文档！

其他

1.创建线程组，相当于创建一批用户。

2.JMeter控件很多，但都只是特殊情况需要的时候才使用，不是全都要用的。而且是基础中的基础，通过学习JMeter能够为测试能力打下良好的基础。

3.工作中经常出现协同测试。往往存在具有共用性的接口，会存在潜在的问题。

模块化测试——共用性接口

大型工程中，总是使用模块化测试方案。所以，面对常用的模块化测试，需要合理解决共用性接口所带来的问题，那么，什么是共用性接口呢？

在协同测试或自动化测试中，接口的共用性是一个重要概念，它指的是一些接口（或功能、方法）被多个测试案例或场景共同使用。这些公用的接口通常被设计为可重用的组件或方法，以简化测试过程，并提高测试的效率和一致性。

例子：登录接口

登录接口是一个经常被提及的共用性接口的例子。很多应用的功能都需要用户登录后才能访问，这意味着在执行大部分的测试场景之前，都需要先调用登录接口。

假设你要测试一个在线购物网站。你可能会有以下几个测试场景：

用户登录并浏览商品。
用户登录、选择商品并加入购物车。
用户登录、下单并完成支付。
用户登录并查看订单状态。

在上述所有的测试场景中，登录都是第一个要执行的步骤。因此，登录接口具有很高的共用性。

为什么共用性接口重要？

提高测试效率：对于共用性接口，只需要编写一次，然后在多个测试场景中重复调用，这大大提高了测试的效率。

确保一致性：如果登录接口出现问题，那么所有依赖于登录的测试场景都可能会受到影响。确保共用性接口的正确性非常重要。

简化测试设计：对于共用性接口，可以单独编写并维护，减少了每个测试场景中的重复代码。

处理共用性接口的策略

模块化：将共用性接口封装成可重复使用的模块或函数，确保其稳定性，并在多个测试场景中重复调用。在JMeter中，将其封装为测试片段的模块，然后调用这个模块即可。（测试片段就是对用例的描述，一段测试片段代表一段逻辑，可以共用）

先行测试：由于共用性接口是很多测试场景的基础，建议首先对其进行详细的测试，确保其稳定和可靠。

错误处理：共用性接口应具备健壮的错误处理机制，以确保在调用失败时可以提供清晰的错误信息。

测试片段处理共用性接口

上图为协作测试的时候常用的JMeter结构。具体流程为在线程组中添加逻辑控制器（如include、模块控制器），然后导出测试片段，再将任意导出的测试片段添加到逻辑控制器中，这样线程组就可以直接调用控制器中的公共接口测试了！所有人都可以共用这一个片段。

重复数据的定义

一件非常恶心且没有效率的一件事：配了一堆接口测试，结果环境变了，之前写的所有URL地址、端口、http请求都要修改！这些被称为公共重复数据。太麻烦了，需要提效，而提效就是自动化最为核心的概念！

一变皆变，突然就能和变量联系起来，变量不就是为了解决这样的情况吗？JMeter为此提供“用户定义的变量”这个功能选项。从上到下将我们的重复数据变量化。所有的公共内容，都可以存！

还有一点我们需要注意，使用定义好的变量时，需要使用${ 变量名 }这一格式引用。

多组数据测试

一个接口一般不可能一组数据就测完了。你要测登录接口，还要改一改用户名、密码等，需要多组数据进行测试。那如果一次一次修改数据，就很麻烦啊，一点都不是自动化的测试，效率很低。

我们可以创建.csv测试数据文件，里面每组data都是一行，每个参数用“，”相隔。

然后使用JMeter里的导入CSV文件功能，告诉JMeter我们的csv文件中每一行的数据都对应着哪些变量（csv都是通过“，”分割的）。

然后设置CSV文件格式，重点是第三行的变量名称，一定要与CSV文件对应。

其次，将原本的登录测试数据从固定值变为CSV文件中设置的变量。

为了方便直观获取某一测试用到的测试数据，可以直接在这次HTTP请求名字中添加CSV文件中的变量。

最后利用循环控制器重复读取.csv文件中的数据再赋值给变量，就能实现简单的多组数据测试。注意循环控制器一定是把需要重复的HTTP请求和CSV文件读取包含在一起。（操作是重复的，但是每次读取都是从第一行开始，所以应该放在循环控制器内部）

这种测试有其专业术语定义：DDT数据驱动。

DDT数据驱动测试

DDT（Data-Driven Testing）是一种软件测试模型，它允许测试人员以参数化输入数据的形式创建测试用例。这意味着测试人员可以使用不同的输入数据（通常存储在表格或文件中）来执行相同的测试用例，而无需为每个输入数据手动创建测试用例。核心：测试的逻辑可以复用！比如接口的逻辑

DDT的主要优势

提高效率：

可以快速生成多个测试用例。
减少代码重复和减少维护工作量。

更易于管理：测试数据可以独立于测试脚本进行管理和修改。

提升测试覆盖率：使用多种数据集测试相同的功能可以更全面地覆盖测试场景。

便于非技术人员理解和使用：测试数据和测试逻辑分离，更易于阅读和编辑。

如何实现DDT

选择工具和库：

选择支持数据驱动测试的测试框架和工具。
例如，在Python中可以使用pytest库进行数据驱动测试。

准备测试数据：

创建包含不同测试数据的文件（例如，CSV，Excel，或XML文件）。

编写测试脚本：

编写测试用例，并将测试数据参数化。
使用框架或工具读取测试数据文件，并将数据应用到测试用例中。

执行测试：

使用选定的测试框架执行测试脚本。
测试框架将自动使用不同的测试数据重复执行测试用例。

无人值守测试

数据驱动测试、无人值守测试、自动化测试

数据驱动测试 (Data-Driven Testing, DDT):
- 是一种测试方法，通过将测试脚本和数据分离，允许测试脚本从外部数据源（如Excel、CSV文件等）获取数据。通过使用不同的数据集执行相同的测试脚本，可以方便地进行大规模和复杂的测试。
- 在JMeter中使用: 可以使用CSV Data Set Config配置元素或使用自定义脚本来从外部数据源读取数据。
无人值守测试 (Unattended Testing):
- 指的是测试脚本可以在没有人工干预的情况下自动执行。这通常用于回归测试，确保软件在开发周期中的更改没有引入新的错误。
- 在JMeter中使用: 可以使用命令行模式来运行JMeter，这样可以轻松地集成到持续集成/持续部署(CI/CD)管道中，实现无人值守测试。
自动化测试 (Automated Testing):
- 是一种测试方法，它使用自动化工具来编写和执行测试用例，无需人工干预。自动化测试可以快速、可靠地执行大量复杂的测试任务。
- 在JMeter中使用: 使用JMeter的图形用户界面或命令行工具来创建和执行自动化测试脚本。

虽然这三个概念有所重叠（例如，数据驱动测试、无人值守测试通常也是自动化的），但它们不完全是相同的东西：

数据驱动测试主要关注使用不同的测试数据来执行相同的测试脚本。
无人值守测试主要关注在没有人工干预的情况下执行测试。通常用于执行时间较长、资源消耗较大的测试任务，例如性能测试、负载测试和稳定性测试等。
自动化测试是一个更广泛的术语，涵盖了所有使用自动化工具执行的测试。可以包括功能测试、性能测试、加载测试、单元测试、集成测试、系统测试和验收测试等。

在JMeter中，您可以轻松实现这三种类型的测试。例如，使用CSV Data Set Config或数据库连接来进行数据驱动测试；使用命令行模式来进行无人值守和自动化测试。

断言

在JMeter中可以设置断言（Assertions）来自动验证请求的响应是否符合预期。断言是自动化和无人值守测试的重要组成部分，它们可以在没有人工干预的情况下自动检查和验证响应数据。

添加断言

在JMeter中，选择你想要添加断言的Sampler，本例为用户登录Sampler。
右键点击它，然后选择“添加” -> “断言”。这里你可以选择不同类型的断言。

配置断言

选中添加的断言，并在右侧的面板中进行配置。本文以JSONPath返回中的code部分为例，实现自动验证，首先看一下检查的code的位置：

以code的JSONPATH格式作为断言的判断对象：

我们发现，登陆成功时的code=0，所以先如下设置：

运行测试并查看结果

运行你的测试。
如果响应不符合断言的条件，JMeter将标记该请求为失败，显示为红色，非常刺眼：

但是，其实测试这个东西，并不应该是只给它登陆成功的code值（0）作为验证，并把没有登录成功的情况判断为错误。读者可能会想，没登录不就是错误了吗？其实，没有登陆时会有很多情况，每个情况都会返回不同的code值，而这些code值也应该被断言检测其正确性。对于原来的测试，我们是否成功分辨并测试到所有情况了呢？没有！

真正的思路应该是：一组测试数据下的返回值code，就应该把这个返回值作为本次测试的断言的判断标准，即使是没有登录上。如果code正确返回了“-1”等应该返回的code值，那么也应该认为正确。所以这个应该怎么改进呢？

诶个实现，这个对于JMeter来讲，一直在断言部分修改对应的code值也不是办法，所以咱可以从测试数据入手：