理解你的角度，我快人快语，这可不是我随便喷的，社区是好的，可惜了

一直感觉你和他是一类人，今天这条回复算是原形毕露了，我不会为了一个工具特意去建个群搞影响力什么的，谁是真心，天地自知，物以类聚，人以群分。社区水准下降是事实，忠言逆耳都听不进，何来进步

你以为我用小号，那是伪君子的行径，只有做过类似事情的人会这么想吧

目前看来确实很浮躁，缺少基础，缺少思想，缺少创新，缺少干货，吹泡泡的很多，盲目崇拜的小白更是何其多。难怪最近值得收藏的文章几乎绝迹了。。。

赞，界面做的不错

并不是所有的架构支持这种方式，无状态的服务可能不支持

#11 楼 @junewang 我用的就是第三种

#2 楼 @junewang 写个接口，不同的实现方式就能实现通用了

描述生动又不夸张，蛮好

#151 楼 @junewang 这个还真没调研过

房价和收入比真是诱人啊，如果不是土著真想过来发展

接口入参如何设计，直接影响到接口测试的有效性和覆盖性，重要性不言而喻，需重点研究和探索的部分。可惜的是，关注这篇文章的人不多。

好文，谢谢分享

报告简洁明了，确实不错，我更想了解的是工具的实用性和内涵：

1.UI 频繁变动，如何解决维护成本问题；

2.性能图的 cpu 和 memory 能给前端性能分析带来哪些有用的价值；

3.日志能否记录下有助于开发定位问题的上下文（logcat 的错误关键字过滤，只用 exception 吗）；

感谢分享朴实无华的好文

#7 楼 @azdbaaaaaa 两者都挺重要，侧重点不同而已

#5 楼 @azdbaaaaaa 我之前也有你现在的困惑，我理解的接口测试分为 2 个阶段，其侧重点不同：

1.接口单测阶段：该阶段的侧重点是单个接口的正确性，主要包括以下几点：

a）接口对正常入参和异常入参的正确处理；

b）接口入参结构和响应报文结构是否符合设计；

c）接口返回的错误码是否符合预期；

d）接口返回数据的正确性；

2.接口场景化测试阶段：该阶段想做固化的数据验证，以我的经验很多情况下是不可能的，原因如下：

a）系统越来越复杂，关联方多，无法固化数据环境

b）关联方多，数据权限受限，数据环境重置或无法初始化；

c）无限接近实战业务场景；

Mock Better 的接口测试属于接口场景化测试，设计的愿景如下：

a）寄生于实际使用中的真实业务场景；

b）保留场景化操作过程中前端程序发起的请求参数和后端接口返回的响应报文，可作为证据链；

c）系统规则捕获接口环境问题、错误码对应问题，用户自定义规则抽查数据正确性问题。

结论：接口场景化测试做深层次数据 assert 的代价过于高昂，在接口单测阶段实施深层次数据 assert 更原子化、成本更低，且具有抗干扰和隔离性。当然，接口场景化阶段的数据校验也是需要的，可以运用结构校验、自动化抽查，正则匹配等模糊校验技术。

以上是个人观点，希望对你有所帮助。

前期阶段，重点在于接口单测，后期阶段，侧重点在于接口的场景化测试，各阶段的着重点不同

#3 楼 @azdbaaaaaa 初版支持系统规则，系统规则满足通用性，例如：httpcode、errorcode 等。
后续版本会支持用户自定义规则，例如：结构校验、内容校验，内容校验包括包含匹配、正则匹配等等。

#1 楼 @jaychang1989 条件允许后会的

#3 楼 @cloudhuan 很高兴能看到这么有质量的回帖，现在能看清这一点的很少了，很多人马步还没站稳就出来布道了

mock client 方式的接口测试，建议用测试引擎解析指定格式用例文件的模式执行

精华帖的评判标准是什么，如何避免一些误导性的文章？

#20 楼 @xjjava 这种情况没遇到过，你发帖在社区里咨询下试试

#18 楼 @xjjava 和 chromeDriver 相应的，杀 AndroidDriver 的进程试试