JMeter学习第一、二、三天
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值也不是办法，所以咱可以从测试数据入手：
将每种情况下正确的code值作为测试数据的一部分，然后将其设置为第三个变量code：
然后，将断言中的期望值从0变成${code}，也就是我们在测试数据中添加的第三列code：
最后，获得测试结果（右图），发现测试的所有情况下的code都成功对应了应该返回的值。
下一篇文章讲解一下JMeter与性能测试！ 也是作者目前最需要学习的部分！