建议详细说下你这个 “点击测试” 按钮点击背后，到底平台做了啥事？

信息太少，只有个截图，也没有齐全的日志（浏览器的、平台服务端的）、大致功能实现逻辑，大伙也不好给你出主意，只能靠猜。实现逻辑猜错了，给的意见也很难有参考意义。

这个坑确实挺深的。想请教下，应该怎么做能避免踩中这个坑？

设置成不可见只是一个选项，便于作者做一些个人私藏的记录。专栏的核心点是提供更好的个人社区影响力。

至于发的帖子很少人回复，可以换个角度想下，会不会是帖子内容对大家吸引度有限，无法引起大家回帖的兴趣？一般大家回帖，要不是有同感，要不是发表自己不同观点，但这类帖子大多都是有作者的观点或者感想。一些不包含作者观点或感想的（如消息公告），容易无感导致没找到能回帖交流的点。

建立专栏本身，也期望大家更多去分享自己的独特经验或观点，便于社区的其它同学更好地认识你。

挺不错的，敢于突破。如文中领导所说，已经超越 95% 的人了。

功能做得挺全的，基本上大部分核心功能都有了。但个人比较好奇，这个平台的相比其它已有平台，独特的点是什么？或者说哪个点其它平台没满足，而这个平台可以满足？

后续周边功能方面的建议（仅供参考，具体还得看公司实际需要）：
1、和持续集成的对接（如支持通过调用指定接口触发测试任务执行、支持自动发送测试结果到邮件/钉钉）
2、对流程类用例更友好的支持。从介绍上看，一次接口调用为一个用例，那对于流程类用例（调用多个接口的），是怎么处理？如果用用例集管理，那 3 个核心流程的用例要变成一个用例集一次性执行，是否可以配置？
3、对于多项目的支持（每个项目有自己的独立的环境配置、用例集、定时任务等）
4、数据报表（如趋势图、饼图）。这个领导会比较关注

另外，通过平台降低技术要求是一个挺好的切入点，但如果要把自动化坚持下来，逐步让测试关注技术、推动规范统一还是需要的，要不维护用例会累死，自动化发现不了什么问题也会导致大家不认可。

我指的不是线上回滚，是测试环境切换版本到可以验证的旧版本

1、先把问题归类。bugly 之类的平台已经会自动按出现次数排序了。
2、寻根问底是什么原因导致的问题。可以参考 5 why 原则，了解到根本原因，再从根本上解决。

假设占比最大的问题，从崩溃平台上看到原因是空指针，可以按照类似下面的套路询问：

• 这个空指针具体是哪个值为空导致的？——xx 属性
• 为啥这个值会为 null ? ——坑爹的服务端没返回这个值
• 为啥服务端没返回这个值？——因为服务端本身存储的数据里就没这个值
• 为啥服务端存储的数据里没有这个值？——因为前面的流程这个值不是必填的，刚好用户没填，所以没有
• 为何对于这个本身服务端就可以不返回的值，客户端没有进行兼容？——当时不知道这个字段是非必填的
• 为何当时不知道？——接口文档没写
• 为何接口文档没写？——以前就是这样的，一直都不会写
• 如果要加上，会有什么困难吗？——接口老是调整，改完代码又得该文档，维护接口文档成本太高了

那问题的原因就比较清晰了：接口文档的维护成本太高，导致客户端没考虑到这个场景，最终导致这个空指针。那解决的方法，可以考虑用 swagger 之类的自动生成接口文档工具生成接口文档，免除接口文档的额外维护成本。当然，也可以更进一步，了解为何接口总是要调整，是否团队人员经验太缺乏导致设计没做好，还是需求改动太频繁导致系统必须配合调整。

同时，也补充一个，使用前判空是一个很关键的编程习惯，可以团队内分享下各种遗漏判空导致的损失，以及形成什么样的习惯来避免空指针异常（调用这个对象的子方法/子属性前，都先判空）。

执行 cd complete mvn install && java -jar target/*.jar 之后，你是新开窗口执行 ps aux | grep target/gs-rest-service-0.1.0.jar 的吗？

从你的描述上看，这个 jar 包在 attach 的时候是没有在运行的。

个人理解，javaSubInvokeBehaviors 对应子调用，回放时会被 mock 掉（前提是回放时给到的入参和录制时一致），javaEntranceBehaviors 是入口调用，回放时会被作为输入。

举个例子，a 接口对应的 controller 方法是 A，而 A 的实现里面有调用另一个系统的接口，方法是 B 。录制回放主要测试的是 A 方法的逻辑，不想依赖另一个系统。
此时，应该配置 javaEntranceBehaviors 为 A ，javaSubInvokeBehaviors 为 B 。

这样回放时，A 这个入口调用会被原封不动地发给应用进行回放，而 B 这个调用会被 mock 掉，应用实际不会发请求给另一个系统。

深有同感，从用户角度思考很重要。

建议可以看看产品经理相关的文章，对如何培养用户嗅觉，有很多相关的资料

赞！期待后续解决阻碍后的更新。

这类问题去脉脉匿名区问比较好吧，也为陆金所的同学着想下？

PS：这类问题可以直接问 HR ，或者问你要入职部门的同学。陆金所还是挺大的，很有可能回答你的同学加班情况和你即将入职部门的不一样。

感觉楼主的解决方案，不好保障是否做到位？比如要求大家都检查配置文件的 ip 是否正确，如果刚好这次是一个新入职的同学，不知道或者不记得要这么做，问题是不是还会存在？有什么手段检查大家是否都有做到位，甚至达到做不到位就无法进行线上/预发布环境的接口测试的地步，杜绝问题的再次发生？

个人建议，可以从这几个方面做：

1. 对于生产、预发布这类直接对接线上数据的环境，相关配置数据都通过环境变量配置，不允许写在 git 仓库里。同时配置读取时，若有同名环境变量配置，优先读取环境变量值。可以参考下 spring boot config 的设定。杜绝由于没检查配置导致跑到生产/预发布环境的问题（用的配置就不是 git 仓库别人提交的配置）
2. 单独设定另外的 jenkins job ，job 中设定好第一点提到的环境变量。大部分测试人员不需要，也不应该知道生产/预发布的配置。job 配置权限只有组长级别有，固定写死只跑生产/预发布不测试环境，且测试集名称固定。禁止在用户本地执行此类测试（手工操作是最不可控的），可以通过 ip 限制等手段封禁，只允许 jenkins 服务器访问生产/预发布环境。杜绝用户本地随意修改执行，影响到生产/预发布。也杜绝 jenkins job 被任意修改为执行不能在线上执行的测试集的问题
3. 线上/预发布环境的测试集，和平时的测试集区分，且每次修改必须通过组长审核通过。如果脚本是 git 仓库管理的，可以使用 gitlab 的 protect 分支特性，jenkins job 只执行 master 中的用例，而 master 分支是 protect 分支，若要变更，只有组长级别有权限。可以通过 MR 让组长只审核，不用自己改代码。杜绝线上/预发布环境的测试集被错误加入线上不能运行的用例的问题

上述几个如果做到了的话，那么如果一个测试人员要让一个本不该在生产环境跑的用例，到生产环境跑，必须拿到 jenkins job 的配置权限并改为自己的用例集/绕过组长往线上用例集中加入不该加入的用例，除非故意做，否则不可能由于粗心达到这个目标。这样是否能更有效地避免同类问题发生？

文中提到一个点，做出来的工具没有落地使用，所以价值不大。但从后面的规划看，好像没提到与之合作的团队的声音？

有试过和其它团队一起沟通，以一种合作的方式来进行工程效率工具/平台的建设吗（比如前期需求目标确认，喊上合作团队的同学一起参与；每部分功能完成后，都邀请合作团队试用）？有轮岗到业务团队一起去完成一次业务项目，从中感受下业务团队的痛苦点吗？如果没有，那很多时候并不好抓住最痛的痛点，因为看问题的角度并不一样。

个人建议，可以尝试参考腾讯的《不测的秘密 精准测试之路》里面的模式，业务组一个同学 + 工程效率组一个同学 + 一个 leader 级人物一起合作，大家朝着一致的目标，完成一次效能提升。

嗯，那看来情况不同。

我们是用代码实现的话，多接口加密会导致代码重复比较多，不好维护。

这篇看过不？

https://juejin.im/entry/556f01b6e4b08ae2e1b4acce

现成开箱即用的应该没有，即使是 oc 也是要自己去探索一下的。

用 JSR223，会不会调整参数不方便？

对于这类加解密，我们一般是通过增加 http 实现来做，便于继续复用 http 界面进行入参编辑。

没有尝试过。已经一段时间没有弄 app 相关的东西了。

这个问题有点伸手党呀，公众号、百度有尝试过不，如果有，也把相关记录贴下？

我们公司有在使用，公司的 java 规范就是基于阿里规范调整而来的。

只是这块更多是由独立的 代码评审委员会 做，测试同学参与不是太多。

额，你没有再确认下，mock 写入大致指的是什么？

“mock 的写入” 这个术语我也是第一次听，能猜想的可能有两个：

1、mock 逻辑的写入。类似于 mock 规则怎么写
2、把应用中写入相关的逻辑 mock 掉

但真的无法确认是哪个。

建议完整回忆下问题的上下文？现在这个问题大家都一头雾水，各种回答好像有道理，但又好像和你想要的不一致，讨论不起来。

因为支持需要进行扩展开发，工作量和支持内嵌视频差不多，所以要先评估下使用的价值。

你提出的这个示例，没太明白此处为何必须用上标？个人理解这个示例里面的 1 不是上标，应该也问题不大吧？

不知道 mock 写入，是不是类似这样的场景？

一个添加用户操作，需要写一堆转换逻辑，然后往真实 db 写入，写入完再继续转换。
而此时测试主要想测转换逻辑，但不想真实地进行 db 写入（比如想降低环境要求，或者 db 写入有幂等校验，第二次写入无效导致不满足可重复的测试等）。

那这个时候，就可以通过 mock 把 db 写入变成一个虚假操作，指定返回成功。单测时不调用真实 db 组件进行写入。而校验条件则是是否有调用写入 db 的函数、调用的参数是否正确。
具体框架实现，可以参考 https://www.jianshu.com/p/a07ac78a6d86

写得很赞，浅显易懂呀。

建议和你们前端沟通下，他们是通过什么函数或者变量捕获这个提示信息的，你也去捕获相同的变量试试？

selenium 支持内嵌 js 到浏览器页面的