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

向 @debugtalk 请教一下：

这是目前看到基于 Appium 做 DSL 封装做的最好的一个项目。
从纯过程式操作来看，已经极为精简了并具有表达力了。

正在犹豫是沿着这类过程式操作展开 Appium，还是基于 Page Object Model 展开。

#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。
可以看出大家思考方向是一致的。

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

#4 楼 @pacerron

录制的问题：

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

PS：

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

#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 检测。

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

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

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

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