我觉得没毛病啊， 你要从查询 API 结果来对比也可以啊。 2 者不冲突啊。

“痛点 3：当开发的接口发生变化时，测试人员如何第一时间获知呢？”
请问你这个契约需要开发帮忙吧。 而文中提到的 前后两次结果的 字段 diff ,那 入参变动怎么感知，结果的 diff 字段也是可能存在不一样的吧，这个怎么过滤。

https://developers.google.com/speed/pagespeed/insights/?hl=zh-CN
数据了超大， 导致前端卡死， 后端是否可以做分页？

"社区引入 appium 之后，有几个月都是 appium 安装问题的咨询，尤其是 iOS 相关的，毕竟那个时候 mac 电脑和 iOS 手机不是一般人能消费的起的。"
14 年初回二线城市，会点 selenium ，发现连个自动化测试岗位都木有，更别提 IOS 自动化测试相关。 当时就买了羋峮大佬的书，还要了签名，再花了将近 1.8W 搞了苹果三件套，自学了 Appium、Calabash 然后薪资成功破 W。

到还不至于 衰弱。

大佬 ，请教下， 这东西 测试环境搞，怎么避免放到线上去。 例如我们是开发代码里面 搞了 Filter ，但是毕竟会影响速度等， 在避免这个功能跑到线上去，大佬有什么建议么？

个人看法：
何必把自己定位在啥啥啥呢？
要学的一切的一切从工作中来，问题驱动。

遇到问题、难点、痛点，想方法解决，要培养解决问题的能力，解决问题的过程就是不断的学习进步的过程。
需要善于挖掘问题，敢于挑战现有规则，用更好的方式取代现有规则。
需要不断的总结，不断的分享，不断的尝试，不断的进步。

工作需要啥，就精通啥。 工作不需要啥，我了解那是啥，待到工作用到啥，我就精学啥。

我们正在做。

这。。。能落地么？

java 我们上 jsonunit

每个节点单独存储，目的是便于扩展字段。 用例评审和测试计划都是用例的子集，我们也可以根据所选的节点来拼接处当前的整条链路等，获取规划用例时，根据选择的父节点就能把该父节点下所有子节点选中等等。 我们也会测试报告中去展示，哪条链路测试失败等的记录。 这种显示局部或者某条链路就很方便。

我们一开始弄自动保存，也出现过用例丢失、切换过快时互相覆盖等，我们后面改了非常简单的一种思路，保留最新历史 20 份的保存数据，丢失时，直接从历史恢复。

我们也居于 百度脑图做了大量二开。做了 1 年多了。我们跟滴滴脑图存储上不同，滴滴直接全 json 保存，我们是每个节点都存储 1 条数据，并存储节点的关系，父节点 ID 等。 同样的我们也想做增量保存，但一直没找到好的方式。但我们的规则 json diff 等其实都无法满足我们的真实需求。原因，我们增量 1 来不想每次给到后端的 json 都是整个脑图 2 来我们想通过增量做一些统计如某个 QA 今天新建多少用例，修改多少用例等。 最后我们用了一个不算增量的增量，就是每个节点编辑新建等时加上更新的时间和用户，然后还是全 Json 给后端，后端一个一个节点保存。

跟开发走

没遇到过这个问题，百度了下， 就说重启终端就好了。

哥 sorry 。 就是参考你的，我这就改。

我看都好好滴呀 懒得折腾了，我贴个原文地址吧：https://www.yuque.com/miyang.meyoung/other/wux7a6

哈哈哈哈哈哈哈。。。

话说天下大势，合久必分，分久必合。

咳。。。 见多这类平台了，实际业务没法落地，特别是复杂场景，又有上游，又得多环境支持。
5、6 年前玩这套把自己玩死了，而后别人再问我 API\RPC 自动化测试最佳实践，都甩 3 个字：写代码。

上个 team ，测试接近 20 人。 就 2 个男的。

如果为了提供自己能力，可以做，提升自己。

如果是为了落地到项目，团队，那帮助非常有限，非常多复杂的场景完全覆盖不了。

手动滑稽.jpg
做自动化测试还是写代码爽，一时写一时爽，一直写一直爽。 自由，自在。

保留票， 等明年北京站。

工作 9 年，新技术全靠自学，然后还是把自己单小白，虚心各种学习，坚持写笔记，写博客。主动揽一些未触及的任务。