迟来的点赞。之前竟然没留意到这个项目。。。

额，我这个文章已经比较老了，没想到还这么多人看。

我当时的文字描述可能有点引起误解了，我当时的误区是：想通过接口自动化测试这个方式，去做非常详细的后端服务测试，甚至包括上传后存储的图片内容对不对这种级别的校验。而实际上，对于这个功能，用接口自动化去测试，相比直接人工做接口测试（上传一个图片后，直接打开返回值里的 url ，人工确认一下两个是否一致），性价比比较低。这个并不代表接口测试，就不用去测试后端服务的功能哈。

所以对于标题里的问题，我的观点是：测试的是后端服务。

然后对于第二个点，，你现在的现状其实对让接口测试产生比较明显的收益是不利的：

1、接口设计频繁变更，意味着很难并行，只能等开发功能都联调完毕，设计不再改后再开始开展。而一般调好后客户端其实都差不多可以提测了，这时候做单独的接口测试不如直接做客户端整体集成测试性价比高。除非测试团队后端和客户端是分开的，后端测试团队专职做接口测试。

2、一般对于新接口的测试，核心的目的应该是在接口设计稳定的前提下，提前测试确认后端服务提供的功能正确，减少联调期间由于服务端接口功能问题引起联调不通，问题排查时两端都得排查的高成本。如果没有接口设计相对稳定这个前提，而是一旦联调接口设计就各种改甚至推倒重来，那接口测试很难发挥威力。

建议先想办法提高团队对接口设计质量把控的能力，让接口设计能尽量稳定下来，而不是一到实现或者联调层面就各种修改吧。

请查看评论区右下角排版说明，优化下排版吧。

现在的排版完全没法看

这个确实运气有点背。塞翁失马，焉知非福，继续加油吧！

1、录制回放要看回放的是读接口还是写接口。读接口相对简单，保障中间件数据一致的情况下，直接回放请求值即可。

2、楼主说的 大多新增数据的场景都有唯一性校验 ，新增数据一般就是写接口。唯一性校验本质上是依赖数据库告知的信息的，所以写接口要做到能回放，一般需要把数据库告知信息这类和外部中间件通讯的返回值也录制下来，回放时直接 mock 告知程序，这样程序收到的一切外部输入就和录制时完全一致，所以执行逻辑也是基本一致的，不会引起唯一性校验不通过这类问题。

可以参考下 双引擎回归测试平台介绍。

不知道标题的 “震惊” 是和什么框架的写法对比得出的结论？建议文中给点对比参考，要不可能每个人接触的框架不一样，有的觉得比自己用的容易，有的可能没感觉。比如我自己就没啥感觉，看起来和日常接触的写法基本差不多，还少了个很常见的基于数据库表结构自动生成 rest 接口代码。

另外，这个 FastAPI 是你们自研后开放出来的么？还是业内已有的那个开源框架？如果是后者，建议说明下并附上框架地址之类的信息，避免引起误解吧。

没写完？

请用 markdown 代码块来排版代码部分吧，现在代码部分没有缩进高亮什么的，读起来不是很舒服。

1、裁员并不一定是淘汰，也可能是业务不行所以整个业务裁掉。

2、如果抛开业务线整个裁掉这种因素看的话，核心就是看你对业务有没有贡献。所以我理解核心要具备能发现并解决业务中遇到痛点的技能。你做的东西业务用得多、效果明显、持续有产出，自然不会先动你，因为后面还需要你。而且最好除了测开本身的技术能力，对业务也需要有一定的熟悉度，有需要时随时可以直接上手做业务测试，毕竟人少之后其实对提效工具的需求也会减少或者弱化，大家更需要的是能保障业务质量的人。

恭喜！作为开源项目，持续保持这么久的维护更新频率，真心点赞！

4.接口测试你是怎么做的？都发现了哪些问题，详细说下定位分析过程。

答：如截图：

遇到问题如截图：

截图都没有看到？

额，有些原因造成的崩溃本身就没有稳定复现步骤的，比如内存占用过大导致被系统强制 kill 掉这类。

你们没有接入 bugly 之类的崩溃自动采集上报平台么？一般崩溃的处理主要通过分析错误堆栈信息来处理，而不是要你绞尽脑汁去想办法稳定复现。。。有不少崩溃是多种综合因素引起的（比如涉及此时内存数据的状态、服务端返回的值内容、多线程下的锁管理等），不是你固定做一样的 app 操作步骤就可以复现的。

另外，除了 monkey ，像 fastbot 这类智能遍历工具也可以拿来用，这样页面覆盖率更有保证。

个人观点：需要，但要求不会很高，能做就行，核心是要满足自己能设计自己开发的功能的测试用例这个场景的需要。

但又不一定每个测开都是从传统业务测试成长上来，不少一开始就直接是做工具的了。

这类测开一般也需要学习测试知识，甚至有需要的话到业务组轮岗做一下测试。只是技能点偏向于做工具开发，并不代表不需要具备测试用例设计能力。不真实了解和做过测试的测开，体会不到测试的痛，很容易跑偏。

额，个人觉得，你这个分类层级太高，场景太多，会导致测的成本很高。有好几种其实背后都是一个原因（比如带宽限制、网络变化、用户过多，本质上都是网络库处理相关的逻辑处理不够完善，导致极端情况下会出现未被捕获的异常引起 crash ）

一般比较少专门测 crash ，真的测更多是针对第一点，用云真机平台的 monkey 或遍历这方面的能力去跑。其他的更多通过日常功能测试中的异常路径测试 + 部分特定场景专项测试（如弱网）+ 线上崩溃监控预警 来发现。

你这种属于指定 job 之间不允许并行，目前 jenkins 好像没见到有类似这样的功能可供配置。

可以考虑下面几个方向：

1、状态合并。三个 job 合一，用参数区分。这样借助 Job 本身的不允许并行构建可以做到。缺点是相关的定时任务什么的也都被合并了，会增加维护成本。

2、状态共享。建立一个临时文件，用于记录这个手机上是否已经有别的 job 在用（比如 job 开始跑时创建这个文件，跑完后删掉这个文件）。每次 job 运行时先查这个文件内容，如果有，那 job 就直接结束不跑或者轮询等待直到可以跑。基本上云真机平台共享设备资源也是类似这样的做法，只是为了避免意外退出设备持续被占用，一般会额外加个使用时必须保活 + 没有保活则超时自动释放的机制。

3、执行器限制。三个 job 的执行器都分配到一个最多只能同时跑一个任务的执行器上，这样执行器自动会保障 3 个 job 同一时间只有一个在跑，剩余的排队。缺点是为了这个需求额外弄一个执行器，有点不值当。

@ 那颗炽热的心啊 @A. @ 枫叶

日志信息不足，无法定位。

你用类似下面的命令来跑，获取更多信息吧。

tidevice -u <替换成你的设备uuid> xctest --bundle_id "*WebDriverAgent*" --debug

写书不易，飞哥加油！

所以也导致我还是会焦虑，我总是想去挣更多的钱。 老婆大人总会劝我，钱是永远挣不完的，够用就行了，穷也有穷的活法，一家人健健康康的才最重要。所以我也在开始慢慢的调整自己的状态。

我老婆也总是这么说我的。。。

PS：如果发现找不到团队痛点，问业务、问领导都问不到（很常见，习惯了就会成为盲点），你自己直接跑去业务，和业务一起当一个月业务测试，一起测需求，哪些地方低效且容易提升效率，就立马可以发现了。

你的关注点有点不对，关注点不是写脚本还是写平台，这个只是实现形式。关注点应该是做什么能帮助团队的质量保障做得更好。包括效率上的提升，以及一些深度上的扩展。

你领导认为不只是做自动化，我个人其实也认同，毕竟自动化用例这个大多是强耦合业务的，测开人力比业务测试少很多，测开干这个，投入产出比不匹配，而且写出来的自动化业务测试同学不一定信任，还是手动再测一遍才心安，那就是白写。

举几个以前带的团队做过提效的例子：

1、测试环境数据库 ddl 的维护提效。为了便于有需要时并行测试需求，一共有维护 4 套测试环境（此处先不追究是否合理，这个是当时现状）。经常遇到由于 DDL 维护不及时导致需求部署上去后，由于 DDL 过时导致部分核心流程不可用。前期是做了一个 Python 脚本能一键应用上线时的 DDL 到 4 个环境的数据库中，保障和线上 DDL 一致。后期是引入了 flyway ，能让服务自维护 DDL 的框架。

2、定时任务触发提效。开发的定时任务用的是 spring boot 自带的 @Schedule ，缺少手动触发机制，每次测都得等到时间才能触发。后续基于做了扩展方法，测试可以通过调用接口传入定时任务相关参数，就立即启动定时任务，不用干等。

这些都不涉及平台开发，也不是写自动化脚本，但都是能有效解决当时团队痛点的手段。视野拓宽点，不要只看到自动化。当然楼主说的开源有好工具直接用这个是认可的，只是开源工具平台很容易在接入业务的最后一公里不方便（最常见的是和公司账号体系的打通，开源工具不大可能适配每个公司自己的账号体系），所以一般还是要做点二次开发才更适合使用。

长期也要考虑后面怎么 show 的问题，从这个角度，搞个前端界面包一下， show 起来容易很多，所以领导一般也喜欢做成平台形式，ppt 展示起来，总归比配一个报告或者代码的图看起来好很多。

。。。你这个不叫 10 条用例，只是 10 个函数而已。大家被你的术语误导了，默认你应该用了框架并用上了 @Test 这类注解将函数注明为用例。

后续建议在提问题的同时，把你的代码、日志也贴上来吧，这样更全面，也能尽量避免理解偏差。

好奇你用例是怎么写的，可以把具体写法贴一下么？还有具体的报错信息。

用例 fail 后继续执行后续用例，直到全部用例执行完毕，我理解应该是一个测试执行管理框架的标配，unittest 就有这样的设定。

这个是个新思路，可以开个帖子详细说下？

发你要解绑那个账号的邮箱地址，没有邮箱地址没法解绑。

你们的标准化是标准化用例的哪个部分，格式、分类还是啥？