PS：有朋友问我为什么对 DSL 这么执念，而不是使用 Python / Java 的裸代码来操作。

原因是我认为 Test Case 代码的「强一致性、简洁、表达力强、stateless、无副作用」很重要。

Test Case 代码维护周期长，这几个特点会让整个项目易于维护。

目前未解决的痛点是，测试环境数据管理的问题，这是另外一个话题，也是我本季度工作的一个探索目标。

不考虑接口录制的形式吗？，你们的工具都是自己些测试用例吗

#2 楼 @pacerron 接口录制的形式太原始了，我们成品的一个 Test Case 大致这样：

---
- config:
  - testset: "Login&broadcast"
  - variable_binds: {
  'blog_id': '502874816', 
  'include_fields': 'tags,related_albums,related_albums.covers,root_album,share_links_2,extra_html,top_comments,top_like_users',
  'username': 'mosaic',
  'password': 'mosaic'
}

- test:
  - name: "login"
  - url: "/napi/login/"
  - method: 'POST'
  - headers: {'Content-Type': 'application/x-www-form-urlencoded'}
  - body: {template: 'login_name=$username&pswd=$password'}
  - expected_status: 200
  - validators:
     - compare: {jsonpath_mini: "status",     comparator: "eq",     expected: 1}
  - extract_binds:
    - 'user_id': {'jsonpath_mini': 'data.user.id'}
    - 'sessionid': {'cookie': 'sessionid'}
- test:
  - name: "check profile detail"
  - url: {template: "/napi/people/profile/?user_id=$user_id"}
  - method: GET
  - expected_status: 200
  - validators:
     - compare: {jsonpath_mini: "status",     comparator: "eq",     expected: 1}
- test:
  - name: "visit broadcast feed"
  - url: {template: "/napi/broadcast/list/"}
  - method: GET
  - headers: {template: {'Cookie': '$sessionid'}}
  - expected_status: 200
  - validators:
     - compare: {jsonpath_mini: "status",     comparator: "eq",     expected: 1}
     - json_schema: {schema: {file: 'broadcast_schema.json'}}

这个可以完成登录，并查看自己的关注动态是否正常工作，通过 JSON schema 检测。

#3 楼 @alswl 接口录制，然后 diff 比对 ，更快速。你这样是不是覆盖比如 500 个 url ，比较花时间？

#4 楼 @pacerron

录制的问题：

• 会增加环境噪音和环境导致的不确定性
• 对数据调整不友好
• 对 CI 不友好，自动化的操作，对幂等性要求高，需要对数据、流程进行精细控制，Test Case 需要设计的
• 基于 DSL 设计，已经可以做很少的工作量，不会比录制更复杂

PS：

不会有 500 个 URL 这么多 URL 的疯狂场景的，同一类 pattern 一个写一条好了，多种类型的数据用对应的数据 choice 插件生成；而录制比较难解决这种场景。

#5 楼 @alswl 写 case 也不算快吧，需要一个个写接口，关键还要写期待值。我意思是录制回放的方式，写 case 的时间会比较少。

另外 不用 jmeter 这种 ui 工具吗， 是复用 case 比较麻烦吗？

#7 楼 @pacerron JMeter 对 CI 不够友好，我期望是运行在 CLI 下面的的

这个东西我看了一个星期，如果有业务场景的接口测试，这个貌似不灵活吧

#9 楼 @nsirone 由于是直接操作 YAML 来配置 HTTP Request 和对应的期望，理论上基于 HTTP 的请求都可以处理。

同时可以使用一些插件，插件有几大类（generator / extractor / decode）比如 random_seq_generator / cookie_extractor / json_mini 等。

如果说这个系统的问题，可能是太偏工程化，为了 CI、表达力高效，牺牲了 UI。

PS：今天恰好看到 https://testerhome.com/topics/6247 这个项目，他也是由 Appium Script -> XML DSL -> YAML DSL。
可以看出大家思考方向是一致的。

可否开源

#11 楼 @nsirone https://github.com/svanoort/pyresttest

#12 楼 @alswl 我是说插件之类的，享集成到我们 CI 项目的管理平台当中去，但是没有头绪