上一章：

Django实现接口自动化平台（四）解决跨域问题【持续更新中】_做测试的喵酱的博客-CSDN博客

下一章：

一、httpruner介绍

1.1 背景：

之所以学习httpruner的用法，是要把httpruner嵌入我们的自动化平台，来实现接口自动化。

官方文档：

📚 用户指南 | HttpRunner

整体概览 | HttpRunner

HttpRunner V3.x Docs

1.x 2.x 使用的是unittest

3.x使用的是unitest

1.2  v4版本 介绍

开发语言：Golang + Python

脚本转换工具：HAR/Postman/Swagger/Curl

脚本格式类型：YAML/JSON/pytest/gotest

脚本执行引擎：Go 自研 + Python pytest

接口测试报告：html 自研（Go template） + pytest-html/allure

性能测试引擎：Go Boomer

运行环境依赖：Go 引擎无需依赖、pytest 引擎依赖 Python 3.7+

安装部署方式： curl/wget

1.3 v4 版本的 Go & Python 功能对比

HttpRunner v4.0 同时采用了 Golang/Python 两种编程语言，底层会有两套相对独立的执行引擎，目标是兼具 Golang 的高性能和 pytest 的丰富生态。

关键差异点对比如下：

引擎	Go	Python
脚本类型	YAML/JSON/gotest	YAML/JSON/pytest
网络协议	多协议 HTTP(S)/HTTP2/WebSocket/TCP/RPC	HTTP(S)
脚手架工具	hrp startproject	/
用例生成工具	hrp har2case	/
脚本转换工具	hrp convert	/
插件化语言	多语言（Go/Python/Java/etc.）	Python
运行环境依赖	与插件语言相关，详见依赖环境说明	Python 3.7+
脚本编写语法提示	gotest 链式调用	pytest 链式调用
运行接口测试	hrp run	hrp pytest
运行性能测试	hrp boom	/
网络性能采集	hrp run –http-stat	/
接口测试报告	html 自研（Go template）	pytest-html/allure

其他：

我自己写了一个接口自动化框架，实现思路与httpruner 差不多，敢兴趣的小伙伴可以瞅瞅。

pytest+yml+allure实现接口自动化框架(终版）_pytest+allure接口自动化_做测试的喵酱的博客-CSDN博客

httpruner最大的特点，不是创新，而是整合。将各个框架的优点，整合到了一起。

1.4 设计理念

相比于其它 API 测试工具，HttpRunner 最大的不同在于设计理念。

• 约定大于配置：测试用例是标准结构化的，格式统一，方便协作和维护
• 标准开放：基于开放的标准，支持与 HAR/Postman/Swagger/Curl/JMeter 等工具对接，轻松实现用例生成和转换
• 一次投入多维复用：一套脚本可同时支持接口自动化测试、性能测试、数字体验监测等多种 API 测试需求
• 融入最佳工程实践：不仅仅是一款测试工具，在功能中融入最佳工程实践，实现面向网络协议的一站式测试解决方案

1.5 核心特性

• 网络协议：完整支持 HTTP(S)/1.1 和 HTTP/2，可扩展支持 WebSocket/TCP/RPC 等更多协议
• 多格式可选：测试用例支持 YAML/JSON/go test/pytest 格式，并且支持格式互相转换
• 双执行引擎：同时支持 golang/python 两个执行引擎，兼具 go 的高性能和 pytest 的丰富生态
• 录制 & 生成：可使用 HAR/Postman/Swagger/curl 等生成测试用例；基于链式调用的方法提示也可快速编写测试用例
• 复杂场景：基于 variables/extract/validate/hooks 机制可以方便地创建任意复杂的测试场景
• 插件化机制：内置丰富的函数库，同时可以基于主流编程语言（go/python/java）编写自定义函数轻松实现更多能力
• 性能测试：无需额外工作即可实现压力测试；单机可轻松支撑 1w+ VUM，结合分布式负载能力可实现海量发压
• 网络性能采集：在场景化接口测试的基础上，可额外采集网络链路性能指标（DNS 解析、TCP 连接、SSL 握手、网络传输等）
• 一键部署：采用二进制命令行工具分发，无需环境依赖，一条命令即可在 macOS/Linux/Windows 快速完成安装部署

二、httpruner 安装

HttpRunner v4 采用 Golang 开发，相比于之前的 Python 版本，最大的一个优势是可以编译生成二进制文件。在目标系统只需要下载到对应系统环境的二进制文件即可运行，无需安装任何运行时环境依赖（例如 Python、Java JDK、NodeJS 等）。

当前 HttpRunner v4 支持如下几种安装方式。

2.1 一键部署（推荐）

为了加速二进制包的下载速度，我们已经将编译产物上传到了阿里云 OSS，并且提供了一键安装部署的脚本。只需执行一条 shell 命令，即可完成 hrp 的下载和安装操作。

$ bash -c "$(curl -ksSL https://httprunner.com/script/install.sh)"

注意：install.sh 脚本内部依赖 curl/tar/mktemp/ls/rm/uname/chmod/command 命令行工具，大多数 Linux/macOS 系统都会预置，如果你的系统中存在缺失，需自行解决。

针对 Windows 系统，上述脚本较大概率无法正常运行，建议自行下载编译产物后进行配置。

 

2.1.1 报错处理： 

1、因为没有权限，导致安装失败，使用sudo 命令安装

sudo bash -c "$(curl -ksSL https://httprunner.com/script/install.sh)"

2.2 下载编译产物

同时，你也可以在 GitHub Releases 页面中，自行选择版本进行下载。

当前 HttpRunner v4 在每次发布版本时，会自动编译生成 5 个版本，覆盖的环境包括：

• macOS(darwin) + amd64(x86)
• macOS(darwin) + arm64(M1)
• linux + amd64(x86)
• linux + arm64
• windows + amd64(x86)

获取到编译产物（.tar.gz 格式）后，对压缩包进行解压：

$ tar -xzf hrp-xxx.tar.gz

解压后可以获得一个 hrp 二进制文件，你只需给 hrp 添加可运行权限即可。

$ chmod +x hrp

同时为了让 hrp 在系统中可以全局调用，推荐将 hrp 添加到系统环境变量的 PATH 路径中，

针对 Linux/macOS 系统，推荐将 hrp 移动到系统 /usr/local/bin 目录。

$ mv hrp /usr/local/bin/

针对 Windows 系统：

• 在 C 盘根目录下创建 HttpRunner 目录（自定义目录），将 hrp.exe 文件放在该目录下
• 在「我的电脑=>属性=>高级系统设置=>环境变量」配置中，在 PATH 下新增系统变量，将 C:\\HttpRunner 写入 PATH

如果你的环境为 MinGW64，根据用户反馈，下载 windows-amd64 版本也是可以使用的。

2.3 自行本地编译

如果在上述已有的编译产物中没有包含你的系统类型，那么你可以自行拉取源码进行编译。

# 拉取 hrp 源码
$ git clone https://github.com/httprunner/httprunner.git
$ cd httprunner
# 通过 make 进行一键编译，生成的产物在 output 文件夹中
$ make build
[info] build hrp cli tool
++ mkdir -p output
++ bin_path=output/hrp
++ go build -ldflags '-s -w' -o output/hrp hrp/cmd/cli/main.go
++ ls -lh output/hrp
-rwxr-xr-x  1 debugtalk  staff    20M Apr 10 18:18 output/hrp
++ chmod +x output/hrp
++ ./output/hrp -v
hrp version v4.0.0-alpha

2.4 go install 安装

如果你的系统有 Golang 环境，那么也可以通过 go install 命令从 GitHub 仓库中拉取代码进行安装。

指定版本号（v4.x.y）进行安装：

$ go install github.com/httprunner/httprunner/v4/hrp/cmd/cli@v4.x.y

如果你期望使用最新的代码进行安装，可以指定 master 分支进行安装：

$ go install github.com/httprunner/httprunner/v4/hrp/cmd/cli@master

2.5 检查安装结果

完成安装操作后，你将获得一个 hrp 命令行工具。hrp 包含多个子命令，具体的使用方式可查看命令行帮助。

在你的命令行终端中执行 hrp -h 命令，如果能正常打印帮助信息，则说明 hrp 已安装成功。

zhaohui@zhaohuideMacBook-Pro ~ % hrp -h

██╗  ██╗████████╗████████╗██████╗ ██████╗ ██╗   ██╗███╗   ██╗███╗   ██╗███████╗██████╗
██║  ██║╚══██╔══╝╚══██╔══╝██╔══██╗██╔══██╗██║   ██║████╗  ██║████╗  ██║██╔════╝██╔══██╗
███████║   ██║      ██║   ██████╔╝██████╔╝██║   ██║██╔██╗ ██║██╔██╗ ██║█████╗  ██████╔╝
██╔══██║   ██║      ██║   ██╔═══╝ ██╔══██╗██║   ██║██║╚██╗██║██║╚██╗██║██╔══╝  ██╔══██╗
██║  ██║   ██║      ██║   ██║     ██║  ██║╚██████╔╝██║ ╚████║██║ ╚████║███████╗██║  ██║
╚═╝  ╚═╝   ╚═╝      ╚═╝   ╚═╝     ╚═╝  ╚═╝ ╚═════╝ ╚═╝  ╚═══╝╚═╝  ╚═══╝╚══════╝╚═╝  ╚═╝

HttpRunner is an open source API testing tool that supports HTTP(S)/HTTP2/WebSocket/RPC
network protocols, covering API testing, performance testing and digital experience
monitoring (DEM) test types. Enjoy! ✨ 🚀 ✨

License: Apache-2.0
Website: https://httprunner.com
Github: https://github.com/httprunner/httprunner
Copyright 2017 debugtalk

Usage:
  hrp [command]

Available Commands:
  adb          simple utils for android device management
  boom         run load test with boomer
  build        build plugin for testing
  completion   Generate the autocompletion script for the specified shell
  convert      convert multiple source format to HttpRunner JSON/YAML/gotest/pytest cases
  dns          DNS resolution for different source and record types
  help         Help about any command
  ios          simple utils for ios device management
  ping         run integrated ping command
  pytest       run API test with pytest
  run          run API test with go engine
  startproject create a scaffold project
  wiki         visit https://httprunner.com

Flags:
  -h, --help               help for hrp
      --log-json           set log to json format
  -l, --log-level string   set log level (default "INFO")
      --venv string        specify python3 venv path
  -v, --version            version for hrp

Use "hrp [command] --help" for more information about a command.

三、脚手架创建项目

3.1选择 go 插件

$ hrp startproject demo --go

3.2 选择 python 插件

在终端中，执行以下命令

$ hrp startproject demo --py

3.2.1 问题处理

1、执行创建命令，在终端中长时间卡着进度没有增加。因为在下载依赖

2、安装报错，提示权限不够

$ hrp startproject demo --py

 报错信息：

11:37AM INF exec command cmd="/Users/zhaohui/.hrp/venv/bin/python3 -m pip install --upgrade funppy==v0.5.0 --index-url https://pypi.org/simple --quiet --disable-pip-version-check"
ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/Users/zhaohui/.hrp/venv/lib/python3.7/site-packages/grpc/__init__.py'
Consider using the `--user` option or check the permissions.

解决办法：使用sudo创建

$ sudo hrp startproject demo --py

3、sudo 安装报错

 报错信息：

11:41AM INF exec command cmd="/Users/zhaohui/.hrp/venv/bin/python3 -m pip install --upgrade httprunner==v4.3.0 --index-url https://pypi.org/simple --quiet --disable-pip-version-check"
WARNING: The directory '/Users/zhaohui/Library/Caches/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
WARNING: The directory '/Users/zhaohui/Library/Caches/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.

解决办法：使用sudo -H 安装

sudo -H hrp startproject study_hrp --py

3.2.2 创建项目成功提示

创建项目成功提示

3.3忽略插件

$ hrp startproject demo --ignore-plugin

举例：

 hrp startproject miao_hrp --py

四、编写测试用例

4.1录制生成 HAR 文件

基于 HAR 生成测试用例

4.1.1 什么是 HAR 格式

以下内容来自维基百科关于 HAR 格式的介绍

HTTP 存档格式（HTTP Archive format，简称 HAR）是一种 JSON 格式的存档文件格式，多用于记录网页浏览器与网站的交互过程。文件扩展名通常为 .har。

HAR 格式的规范定义了一个 HTTP 事务的存档格式，可用于网页浏览器导出加载网页时的详细性能数据。此格式的规范由万维网联盟（W3C）的 Web 性能工作组制作，截至2016年3月是一份规范草案。

4.1.2 录制 HAR 文件

采用 Charles 等抓包工具，以及 Chrome 等浏览器均可以导出 HAR 格式的文件，具体方式可以参考如下流程：

4.1.3 Charles 录制 HAR 文件

Charles 录制 HAR 分为如下两步：

• 步骤一：在抓取到的会话（Session）上右击选择 Export Session...

• 步骤二：导出格式选择 HTTP Archive (.har) 来导出为 HAR 文件

4.1.4 Chrome 录制 HAR 文件

Chrome 录制 HAR 文件可以通过如下两种方法：

• 方法一：点击按钮导出 HAR 文件
• 方法二：在请求列表空白处右击，选择以 HAR 格式保存所有内容

4.2 转换生成测试用例

使用主流 API 工具转换生成测试用例。

在 v4.0 版本中，HttpRunner 将实现一套更为灵活的测试用例转换机制，并且将所有的转换功能都集中在 hrp convert 一个指令中。用户可以通过指定选项将将输入转换为各种类型的测试用例。

HttpRunner 的转换功能将不仅仅局限于支持 Postman、Swagger 等工具导出的工程文件到 HttpRunner 测试用例的转换，

还会支持 curl、Apache ab 等指令到测试用例的转换，甚至是会支持测试用例的不同形态之间的相互转换。

本文将介绍 HttpRunner v4.0 用例转换功能的基本使用方式以及注意事项，从而可以方便用户快速上手。此外，为了帮助大家更好地理解用例转换的原理，本文还会介绍 hrp convert 指令转换过程的具体流程，最后会介绍 hrp convert 指令当前的开发进度。

4.2.1 查看帮助文档

通过执行 hrp convert -h 可以查询该指令的功能简介、用法和各个选项的介绍：

$ hrp convert -h
convert to JSON/YAML/gotest/pytest testcases

Usage:
  hrp convert $path... [flags]

Flags:
  -h, --help                help for convert
  -d, --output-dir string   specify output directory, default to the same dir with har file
  -p, --profile string      specify profile path to override headers (except for auto-generated headers) and cookies
      --to-gotest           convert to gotest scripts (TODO)
      --to-json             convert to JSON scripts (default true)
      --to-pytest           convert to pytest scripts
      --to-yaml             convert to YAML scripts

Global Flags:
      --log-json           set log to json format
  -l, --log-level string   set log level (default "INFO")

hrp convert 各个选项的详细说明和使用示例如下：

4.2.2 指定输出类型

--to-json/--to-yaml/--to-gotest/--to-pytest 用于将输入转化为对应目标形态的测试用例，四个选项中最多只能指定一个。

例如，将输入的 HAR 文件转换为 pytest 测试用例：

# 将输入的 demo.har 转换为 pytest 测试用例 demo_test.py
$ hrp convert demo.har --to-pytest

如果不指定该选项，则默认会将输入转换为 JSON 形态的测试用例，例如：

# 默认会将输入的 demo.har 转换为 JSON 测试用例 demo_test.json
$ hrp convert demo.har

其他：

我转换报错了，但是没找到原因。

4.2.3 指定输出目录

--output-dir 后接测试用例的期望输出目录的路径，用于将转换生成的测试用例输出到对应的文件夹，需要注意该路径必须是存在且合法的，例如：

# 创建输出目录
$ mkdir -p testcase/from/postman

# 将输入的 postman_collection.json 转换为 YAML 测试用例 postman_collection_test.yaml，并导出到 testcase/from/postman 目录下
$ hrp convert postman_collection.json --to-yaml --output-dir testcase/from/postman

指定全局修改配置文件

--profile 后接 profile 配置文件的路径，该文件的后缀可以为 .json/.yaml/.yml，其作用是在转换过程中对测试用例的各个步骤进行全局修改，目前支持修改输入中的 Headers 和 Cookies 信息，并且支持替换（不存在则会创建）以及覆盖两种修改模式，下面给出这两种修改模式的 profile 配置文件示例：

• profile.yaml：根据 profile 替换指定的 Headers 和 Cookies 信息

headers:
    Header1: "this header will be created or updated"
cookies:
    Cookie1: "this cookie will be created or updated"

• profile_override.yaml：根据 profile 覆盖原有的 Headers 和 Cookies 信息

override: true
headers:
    Header1: "all original headers will be overridden"
cookies:
    Cookie1: "all original cookies will be overridden"

创建了以上的两个 profile 配置文件后，我们可以使用 --profile 选项指定配置文件来进行全局修改，例如：

# 将输入的 demo.har 转化为 json 测试用例 demo_test.json，并进行全局替换
$ hrp convert demo.har --profile profile.yaml

# 将输入的 demo.har 转化为 pytest 测试用例 demo_test.py，并进行全局覆盖
$ hrp convert demo.har --to-pytest --profile profile_override.yaml

注意事项

1. 输出的测试用例文件名格式为 输入文件名称（不带后缀） + _test + .json/.yaml/.go/.py 后缀，如果该文件已经存在则会进行覆盖
2. hrp convert 可以自动识别输入类型，因此不需要通过选项来手动指定输入类型，如遇到输入类型不支持、加载失败或转换失败的情况，则会输出错误日志并跳过，不会影响其他转换过程的正常进行
3. 在 profile 文件中，指定 override 字段为 false/true 可以选择全局修改模式为替换/覆盖。需要注意的是，如果不指定该字段则默认的全局修改模式为替换模式
4. 输入为 JSON/YAML 测试用例时，向前兼容 HttpRunner v2.0/v3.0 版本的测试用例，输出则统一采用 HttpRunner v4.0 版本的风格
5. 在进行测试用例的不同形态之间的相互转换时，如果输入测试用例的类型与输出的类型相同，所指定的 --output-dir 和 --profile 选项仍然生效

五、手工编写测试用例（重点）

手工编写 YAML/JSON/pytest/gotest 测试用例

5.1 通用概念介绍

在介绍如何手工编写测试用例之前，首先介绍 HttpRunner 中的一些通用概念，理解这些概念对于手工编写测试用例至关重要，因为无论是哪种形态的测试用例，都是按照一定的规则来设计的。这些通用概念具体包含以下的内容：

5.2 测试步骤（teststep）

测试步骤是测试用例的最小执行单元，测试用例是测试步骤的有序集合，对于接口测试来说，每一个测试步骤应该就对应一个具体的用户操作。HttpRunner 支持的测试步骤如下：

测试步骤类型	含义
request	用于发起 HTTP 请求的步骤类型
api	用于引用 API 的步骤类型
testcase	用于引用其他测试用例的步骤类型
transaction	用于定义一个事务
rendezvous	集合点
think_time	思考时间
websocket	用于发起 WebSocket 请求的步骤类型

除了基本的测试步骤之外，部分测试步骤还可以进行增强，从而拓展更多功能，这一部分内容将在增强测试用例章节中进行详细介绍。

增强操作类型	含义	适用的测试步骤
variables	局部变量	通用
setup_hooks	前置函数	request/api/websocket
teardown_hooks	后置函数	request/api/websocket
extract	参数提取	request/api/websocket
validate	结果校验	request/api/websocket
export	导出变量	testcase

5.3 测试用例（testcase）

从 2.0 版本开始，HttpRunner 开始对测试用例的概念进行进一步的明确，参考 wiki 上对于 test case 的定义：

A test case is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular software testing objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

概括下来，一条测试用例（testcase）应该是为了测试某个特定的功能逻辑而精心设计的，并且至少包含如下几点：

• 明确的测试目的（achieve a particular software testing objective）
• 明确的输入数据（inputs）
• 明确的运行环境（execution conditions）
• 明确的测试步骤描述（testing procedure）
• 明确的预期结果（expected results）

按照上述的测试用例定义，HttpRunner 的测试用例应该保证是完整并且可以独立运行的。

从测试用例的组成结构来看，一个测试用例可以分为「测试脚本」和「测试数据」两部分：

• 测试脚本：重点是描述测试的业务功能逻辑，包括预置条件、测试步骤、预期结果等，并且可以结合辅助函数（debugtalk.go/debugtalk.py）实现复杂的运算逻辑
• 测试数据：重点是对应测试的业务数据逻辑，例如数据驱动文件中的定义的 UUID、用户名等等，以及环境配置文件中定义的 base_url 环境变量等等

测试脚本与测试数据分离后，就可以比较方便地实现数据驱动测试，通过对测试脚本传入一组测试数据，实现同一业务功能在输入不同业务数据情况下的测试验证。那么测试数据是如何传入测试脚本中的呢？这就需要用到测试数据与测试脚本之间的桥梁——用例配置（config），测试脚本除了包含多个有序的测试步骤之外，还包含针对当前测试用例的用例配置项，HttpRunner 支持的用例配置项如下：

用例配置项名称	含义
verify	客户端是否进行 SSL 校验（todo）
base_url	当前请求的基础 URL（deprecated in v4.1, moved to .env）
headers	定义测试用例级别的请求头
environs	配置环境变量（如果未指定则会从 .env 文件导入）
variables	定义测试用例级别的变量
parameters	配置参数驱动的数据源
parameters_setting	配置参数驱动的具体策略
think_time	配置思考时间的具体策略、超时时间限制等
websocket	配置 WebSocket 断开重连的最大次数和间隔等（todo）
export	导出当前测试用例中的变量
weight	性能测试过程中，分配给当前测试用例的虚拟用户权重
path	当前测试用例所在路径（通常不需要手工填写）

5.4 测试用例集（testsuite）

对于测试用例集的概念，同样参考 wiki 上对于 test suite 的定义：

a test suite, less commonly known as a validation suite, is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests.

从上面定义中可以看出，测试用例集是测试用例的无序集合，通俗来将，测试用例集就是「一堆」测试用例。对应地，HttpRunner 除了支持指定单个文件来运行某一测试用例，也支持指定多个文件或指定文件夹来运行一整个测试用例集。

项目根目录：

项目根目录是整个测试用例集的目录，测试用例中的相对路径（例如在测试步骤中引用 API 或测试用例的路径，或者在使用参数驱动功能时引用 CSV 文件的路径）都是基于项目根目录来进行引用的。在 HttpRunner v4.0 中，项目根目录以 proj.json 为锚，并且按照使用习惯，环境配置文件 .env，以及辅助函数的定义文件 debugtalk.py/debugtalk.go 通常也是放在项目根目录下的。

手工编写 YAML/JSON 测试用例

YAML 和 JSON 是两种常用的定义结构化数据的格式，关于这两种格式的优劣是非常有争议的问题，下面首先从编写风格、功能多样性和解析效率几个方面进行一下对比：

• 编写风格：YAML 必须使用空格来表示缩进，并且对空格具体数量没有要求，只需要相同层级左侧对齐即可，这种缩进风格简洁且易于阅读，针对同一测试用例，YAML 文件的篇幅通常要比带缩进的 JSON 文件简短很多，用户可以较快地把握整体结构，但是对于手动编写 YAML 测试用例的场景而言，则需要重点注意相同层级左侧对齐，否则很容易导致测试用例的加载错误。JSON 的编写风格则是频繁地使用 {} [] 和 “"，对缩进并没有严格要求（习惯上还是采用良好的缩进风格来便于阅读），正是由于额外的符号过多，容易降低阅读和手工编写上的体验
• 功能多样性：在功能方面，YAML 是 JSON 的超集，YAML 有许多 JSON 缺乏的附加功能，包括注释、可扩展数据类型、关系锚、不带引号的字符串等等，尤其是添加注释的功能在编写测试用例供他人阅读时尤为实用，而 JSON 只支持数值、字符串、布尔值、数组、对象和空值六种数据类型。
• 解析效率：与 YAML 相比，JSON 对机器来说更容易解析，序列化/反序列化的速度更快

从上面的对比中可以看出 YAML 与 JSON 各有优劣，用户在编写测试用例的时可以根据自己的喜好和使用场景来进行选择，不过二者具有较强的相似性，下面以 YAML 为例来对手工编写测试用例进行介绍，JSON 测试用例的编写方式同理，只需要适配 JSON 的语法规则即可。

编写用例配置

下面展示一个 YAML 用例配置部分的示例，读者只需要了解 YAML 的基本语法规则以及各个字段的类型即可在项目中自定义用例配置部分。

config:
  name: "demo with complex mechanisms"
  verify: False
  base_url: "https://postman-echo.com"
  headers:
    X-Request-Timestamp: "165460624942"
  parameters:
    user_agent: [ "iOS/10.1", "iOS/10.2" ]
    username-password: ${parameterize($file)}
  parameters_setting:
    strategies:
      user_agent:
        name: "user-identity"
        pick_order: "sequential"
      username-password:
        name: "user-info"
        pick_order: "random"
    limit: 6
  think_time:
    strategy: random_percentage
    setting:
      max_percentage: 1.5
      min_percentage: 1
    limit: 4
  variables:
    app_version: v1
    user_agent: iOS/10.3
    file: examples/hrp/account.csv
  websocket:
    reconnection_times: 5
    reconnection_interval: 2000
  export: ["app_version"]
  weight: 10

编写测试步骤

request

teststeps:
  -
    name: get with params
    variables:
      foo1: ${ENV(USERNAME)}
      foo2: bar21
      sum_v: "${sum_two_int(1, 2)}"
    request:
      method: GET
      url: $base_url/get
      params:
        foo1: $foo1
        foo2: $foo2
        sum_v: $sum_v
    extract:
      foo3: "body.args.foo2"
    validate:
      - eq: ["status_code", 200]
      - eq: ["body.args.foo1", "debugtalk"]
      - eq: ["body.args.sum_v", "3"]
      - eq: ["body.args.foo2", "bar21"]
  -
    name: post raw text
    variables:
      foo1: "bar12"
      foo3: "bar32"
    request:
      method: POST
      url: $base_url/post
      headers:
        Content-Type: "text/plain"
      body: "This is expected to be sent back as part of response body: $foo1-$foo2-$foo3."
    validate:
      - eq: ["status_code", 200]
      - eq: ["body.data", "This is expected to be sent back as part of response body: bar12-$expect_foo2-bar32."]
  -
    name: post form data
    variables:
      foo2: bar23
    request:
      method: POST
      url: $base_url/post
      headers:
        Content-Type: "application/x-www-form-urlencoded"
      body: "foo1=$foo1&foo2=$foo2&foo3=$foo3"
    validate:
      - eq: ["status_code", 200]
      - eq: ["body.form.foo1", "$expect_foo1"]
      - eq: ["body.form.foo2", "bar23"]
      - eq: ["body.form.foo3", "bar21"]

HTTP/2 请求请参考 HTTP/2 章节

api

teststeps:
    - name: test api /get
      api: api/get.json
      variables:
        app_version: 2.8.7
        device_sn: $device_sn
        os_platform: ios
        user_agent: iOS/10.4
      extract:
        session_token: body.headers."postman-token"
      validate:
        - check: status_code
          assert: equal
          expect: 200
          msg: check status_code
        - check: body.headers."postman-token"
          assert: equal
          expect: ea19464c-ddd4-4724-abe9-5e2b254c2723
          msg: check body.headers.postman-token

testcase

teststeps:
-
    name: request with functions
    variables:
        foo1: testcase_ref_bar1
        expect_foo1: testcase_ref_bar1
    testcase: testcases/requests.yml
    export:
        - foo3

transaction

请参考事务（transaction）章节

rendezvous

请参考集合点（rendezvous）章节

think_time

请参考思考时间（think_time）章节

websocket

请参考 WebSocket 章节

注意事项

与下面即将介绍的代码形态编写测试用例的方式不同，手工编写 YAML/JSON 测试用例具有较大的灵活性并且容易出错，因此在手工编写测试用例的过程中需要格外注意。最后，步骤类型的判断是会有一定优先级的，如果用户在一个测试步骤中指定了多个步骤类型，则会按照 api > testcase > think_time > request > transaction > rendezvous > websocket 的顺序进行类型识别，并最终判断为其中的一类，虽然这种情况极少会出现，但也在此说明一下，以防止发生一些意料之外的错误

六、YAML配置文件的格式

用例编写，是用yaml文件来实现的，yaml文件的格式非常重要。

相关学习文档：

yaml语法_yaml文件中list怎么区分字符串和数字_做测试的喵酱的博客-CSDN博客

 1、yaml是数据格式，不是数据类型（结构）
 2、yaml配置文件的后缀为.yml或者.yaml
 3、yaml中使用#作为注释，注释只能在某一行的前后，不能与key\value在同一行
 4、yaml中有两种结构，一种是key: value，value与冒号之间必须有空格
   另一种是 - key: value，“-”为列表结构
 5、yaml文件中嵌套的同一级条目前缩进必须一致（一般缩进2个空格）
 6、yaml中如果value使用引号（单引号或者双引号），那么该value为字符串类型
 7、如果value中只要有字母，哪怕没有添加引号，一般也会识别为字符串类型（false、true、on、off、null除外）
 8、value为false、true、on、off，是布尔类型，null为空
 9、value中为纯数字或者小数，会被识别为int或float类型

miao_httprunner/api/demo_api.yml

name: demo api
variables:
    var1: value1
    var2: value2
request:
    url: /api/path/$var1
    method: POST
    headers:
        Content-Type: "application/json"
    json:
        key: $var2
validate:
    - eq: ["status_code", 200]