httprunner-validate的使用

1、一般在API接口不做业务逻辑的判断。
2、使用

• test:
  name: "查询是否可以减免"
  api: api/queryIsCaseDerateAble.yaml
  variables:
  Token: bidId
  validate:
  - str_eq: ["content.msg",'该案件可提交减免']
  3、判断场景
  1）实际结果包含期望结果
  • contains: ["content.result",'token']
    2）实际结果和期望结果是否相等
  • eq: ["status_code", 200]
  • str_eq: ["content.msg",'该案件可提交减免']
    3）实际结果小于期望结果
  • lt: ["status_code", 200]
    4）实际结果小于等于期望结果
  • le: ["status_code", 200]
    5）实际结果大于期望结果
  • gt: ["status_code", 200]
    6）实际结果大于等于期望结果
  • ge: ["status_code", 200]
    7）实际结果和期望结果不相等
• ne: ["status_code", 200]
  8）实际结果的长度和期望结果是否相等
• len_eq: ["status_code", 200]
  9）实际结果的长度大于等于期望结果
• len_ge: ["status_code", 200]
  10）实际结果的长度小于期望结果
• len_lt: ["status_code", 200]
  11）实际结果的长度小于等于期望结果
• len_le: ["status_code", 200]
  12）实际结果被期望结果包含
• contained_by: ["content.result",'token']
  13）实际结果的字段类型和期望结果相同：type_match
• type_match: ["content.result",'int/float/str/list等']
  14）检查实际结果和期望结果是否都是basestring的实例，如果都是就用正则匹配两个输入参数：regex_match
• regex_match: ["content.result",'正则表达式']
  15）验证check_value是否已expect_value开始
• startswith: ["content.result",'abc']
  16）验证check_value是否已expect_value结尾
• endswith: ["content.result",'abc']