设计理念：
- 充分复用优秀的开源项目，不追求重复造轮子，而是将强大的轮子组装成战车
- 遵循 “约定大于配置” 的准则，在框架功能中融入自动化测试最佳工程实践
- 追求投入产出比，一份投入即可实现多种测试需求
在 HttpRunner 中，测试用例组织主要基于三个概念：
- 测试用例集（testsuite）：对应一个文件夹，包含单个或多个测试用例（YAML/JSON）文件
- 测试用例（testcase）：对应一个 YAML/JSON 文件，包含单个或多个测试步骤
- 测试步骤（teststep）：对应 YAML/JSON 文件中的一个 test，描述单次接口测试的全部内容，包括发起 接口请求、解析响应结果、校验结果等
Quick Start
- a. 创建项目：$ hrun --startproject projectName
- b. 项目分层：api、data、testcases、testsuites、debugtalk.py、.env、requirements.txt
api: 定义单个请求信息
data: 测试过程中使用的参数，如参数化 parameters 数据驱动
testcases: 多个api组成的测试用例，也可以是单个
testsuites：单个或多个测试无序用例集
debugtalk.py：公共函数、hook函数定义
.env: 环境配置信息
requirements.txt： 环境依赖相关 pip install -r requirements.txt
一、API文件概述
api文件：描述请求相关内容
关键字：name、variables、request、base_url、validate、extract
name: api 名称描述
base_url: \${ENV(LOGIN_URL)} 固定写法
variables：定义api变量用于下面的 request 调用
request: 请求对象
url: 接口地址
method: 请求方法
headers: 请求头
params: 请求头参数，一般用于get请求
data: Content-type: application/x-www-form-urlencoded
json: Content-Type: application/json;charset=UTF-8
files: Content-Type: multipart/form-data
upload: 一般用于简单图片上传同files类似更为简单
validate: 验证断言结果
extract: 提取参数, $token的形式进行引用
`注意点：其中，name 和 request 部分是必须的，request 中的描述形式与 requests.request 完全相同,另外API 描述需要尽量保持完整，做到可以单独运行.`
在开始测试之前，我们需要先了解 接口的请求和响应细节 ，而最佳的方式就是采用 Charles Proxy 或者 Fiddler 这类网络抓包工具进行抓包分析。导出HAR格式文件，在CMD中运行 har2case 自动解析生成用例：
har2case docs/data/demo-quickstart.har 不带参数默认json格式
har2case docs/data/demo-quickstart.har -2y 加上 -2y/--to-yml 参数
转换为 YAML 格式测试用例
详细可以参考一下：录制生成用例
api 编写规范：
1. name 描述接口的具体功能，增强接口可读性.
2. 在 api 内尽量提供参数实例说明便于协作 ，默认传参跟实际业务保持一致.
3. requests 中传参尽可能的进行变量引用，避免参数写死，便于后续参数分离多环境执行.
4. 尽量不要在API文件里提取返回参数 // token 之类的除外
5. 遵循restful规范的API，尽量写成1个API文件，如果传参比较复杂则可以根据请求方式(GET/POST/PUT/DELETE)写成多个
6. API 文件中的断言校验，仅校验常规字段,实际业务断言放在测试用例中体现.
7. 注释必须要有!!! // 所有业务字段必须在api中说明
二、testcases/testsuites概述
关键字：config、teststeps
config：
name: 测试用例描述
variables_ 变量定义
setup_hooks: 全局用例测试之前执行，局部执行直接在teststeps定义即可
teardown_hooks: 全局用例测试之后执行，局部执行直接在teststeps定义即可_默认False, 主要针对https请求
output: 变量输出，字符串引用，在日志debug模式显示，作用于export类似
teststeps:
name: 步骤api描述1
api: 需要调用对应的api路径+文件名.yml/.json
validate: 断言验证
#其他api中关键字也可以使用
测试套件（集合testsuites）
关键字：config testcases
config:
name: testsuite description
testcases: 用例集
testcase1_name: 用例1
testcase: /path/to/testcase1 #测试用例path
testcase2_name: 用例2
testcase: /path/to/testcase2 #测试用例path
注意点：关键字段的缩进和yml文件的语法.`
三、validate校验器方法源码：
def get_uniform_comparator(comparator):
""" convert comparator alias to uniform name
"""
if comparator in ["eq", "equals", "==", "is"]:
return "equals"
elif comparator in ["lt", "less_than"]:
return "less_than"
elif comparator in ["le", "less_than_or_equals"]:
return "less_than_or_equals"
elif comparator in ["gt", "greater_than"]:
return "greater_than"
elif comparator in ["ge", "greater_than_or_equals"]:
return "greater_than_or_equals"
elif comparator in ["ne", "not_equals"]:
return "not_equals"
elif comparator in ["str_eq", "string_equals"]:
return "string_equals"
elif comparator in ["len_eq", "length_equals", "count_eq"]:
return "length_equals"
elif comparator in ["len_gt", "count_gt", "length_greater_than", "count_greater_than"]:
return "length_greater_than"
elif comparator in ["len_ge", "count_ge", "length_greater_than_or_equals",
"count_greater_than_or_equals"]:
return "length_greater_than_or_equals"
elif comparator in ["len_lt", "count_lt", "length_less_than", "count_less_than"]:
return "length_less_than"
elif comparator in ["len_le", "count_le", "length_less_than_or_equals",
"count_less_than_or_equals"]:
return "length_less_than_or_equals"
else:
return comparator
总结下相关的校验方法：
eq equals: 判断实际结果和期望结果是否相等,可以用”eq”, “equals”, “==”, “is”
lt less_than: 判断实际结果小于期望结果 ，可以用 “lt”, “less_than”
le less_than_or_equals: 判断实际结果小于等于期望结果 ，可以用 “le”, “less_than_or_equals”
gt greater_than: 判断实际结果大于期望结果，可以用”gt”, “greater_than”
ge greater_than_or_equals: 判断实际结果大于等于期望结果，可以用”ge”, “greater_than_or_equals”
ne not_equals: 判断实际结果和期望结果不相等，可以用”ne”, “not_equals”
str_eq string_equals: 判断转字符串后对比 实际结果和期望结果是否相等，可以用”str_eq”, “string_equals”
len_eq length_equals: 判断字符串或list长度,可以用”len_eq”, “length_equals”, “count_eq”
en_gt length_greater_than: 判断实际结果的长度大于和期望结果，可以用”len_gt”, “count_gt”, “length_greater_than”, “count_greater_than”
len_ge length_greater_than_or_equals: 实际结果的长度大于等于期望结果，可以用”len_ge”, “count_ge”, “length_greater_than_or_equals”, “count_greater_than_or_equals”
len_lt length_less_than: 实际结果的长度小于期望结果，可以用”len_lt”, “count_lt”, “length_less_than”, “count_less_than”
len_le length_less_than_or_equals : 实际结果的长度小于等于期望结果，可以用”len_le”, “count_le”, “length_less_than_or_equals”, “count_less_than_or_equals”
实际demo案例：
pipline
