我理解你的意思，确实是会有这样的人，做完平台后只简单落地一个项目，写几个简单的用例，就拿着这个平台出去跳槽。

但领导也不傻，大家也不傻。这种情况下做出来的平台，谁敢用。。。既然领导都想强推了，说明还是想做长期的（领导自然得去想怎么让平台能长期发展）。既然做长期，那还是有机会达成共赢的。

而且我觉得，就算沟通到最后发现真的是这种残酷的现实，没法往下走，但也不代表这个沟通就是不必要的吧。个人不喜欢猜测别人的想法，更不喜欢基于自己的这些猜测去限制自己的行动。别人想啥你控制不了，但你做啥是你能控制的，是否要主动去沟通也是你可以控制的。主动然后碰壁总比窝在自己的世界里要好吧，而且就我自己个人经验，主动去沟通了，结果总会比完全不沟通要好，甚至很多时候会发现结果比自己想象要好得多。

可能观念不同吧。我的基本观念是大家都是同一个团队的战友，应该能合作获得共赢。多一个敌人不如多一个朋友。

如果能共赢，做平台开发者的踏脚石也没问题，本身平台也是自己的踏脚石呀，以后出来了说自己业务实践中自动化测试做的怎么怎么牛逼，也是对自己有好处的。

把你实际使用中不好用的点都罗列一番，然后把你用脚本写的好处都罗列一番（特别是效率上和效果上，平台写一个用例的时间脚本可以写好几个，或者有些挺需要自动化的用例平台上没法做），做个比较给领导和平台开发同学看。名义上可以说是这个平台在你所在业务的落地成果汇报。

如果领导有最终为业务服务的想法，应该是愿意听取你的意见的不直接强推的。平台开发同学如果不是自嗨型，也应该很愿意接受你的意见，去兼容脚本或者优化平台上的功能。

不过有一个点要留意，一般领导最担心的是每个人都这么单干团队就没法管了，百花齐放然后人一走变成烂摊子没人接。所以还是得取得一些平衡，比如把脚本和平台结合起来，数据上报平台，脚本编写也有一些基本框架规范限制。这块其实一般能做平台的测开同学也能做脚本框架，可以一起沟通达成共识。

那就写呗。自己作为用户，换个做自动化的方式不是应该很容易么？

建议你可以看看 agileTC 官方 wiki 里他们的调研报告。

只是可以比较确定的是，基于脑图的在线用例管理平台，且开源的，目前看到确实只有 agileTC 这一个。各个大厂内部基本也都有（比如几年前 360 就有分享过），基于百度 kityminder 做改造，但基本都不对外也不开源。

突然发现社区里广州的同学不少。。。

AgileTC 能满足你这 3 个要求呀，建议直接用吧。

现在脑图的在线用例管理平台，各家基本都没开源。

很精彩的 2020 年~

看来也是转变挺大的一年，结果也都不错，握个爪。

2021年能不能把房贷清了 为这句话点个赞，现在都不敢想象提前还贷。。。

我的体质是比较特别，偏瘦。。。不过最终目标都是一样的，都是为了健康。

是呀。话说为什么是 也 ？

谢谢~

已开通，试试吧

已开通，试试看吧~

请问 des3 是什么加密算法？搜索找到的都是 3DES、DES 加密算法。

思路上，我理解楼主已经搞定第一个接口的获取参数和加密后传入第二个接口了，只差中间怎么加密？如果是，那这个具体加密算法可以问下研发分享下，甚至找研发协助打一个程序包出来，命令行调用直接明文变密文。

会不会填充内容是通过 js 另外异步请求填充的？requests 获取的只有原始 html 内容，不包含 js 执行部分的效果。

不错的一年呀，特别是写文章的习惯养成，持续下去必然能给你带来更大的影响力和收益。加油！

欢迎也分享到社区来，大家一起交流。

PS：我这看有部分图片打不开，能否修复下？

2020-12-30T09:43:56.648483019Z 2020-12-30T09:43:56.648Z FTL/device:plugins:screen:stream 415 [977707a29807] Frame producer had an error FailError: Failure: 'closed'
2020-12-30T09:43:56.648511355Z     at /app/node_modules/adbkit/lib/adb/parser.js:183:29
2020-12-30T09:43:56.648518517Z     at runCallback (timers.js:789:20)
2020-12-30T09:43:56.648522721Z     at tryOnImmediate (timers.js:751:5)
2020-12-30T09:43:56.648526654Z     at processImmediate [as _immediateCallback] (timers.js:722:5)
2020-12-30T09:43:56.649306279Z 2020-12-30T09:43:56.649Z FTL/util:lifecycle 415 [977707a29807] Shutting down due to fatal error

看起来是 adb 连接断开了。有试过别的手机吗？

个人理解，录制回放主要好处是能以比较低成本的方式直接验证线上出现最频繁的场景。它不追求全，追求的是有限资源下尽可能保障不出大问题。

所以对于问题 1，如果线上这 3 个场景的查询使用频率都不低，那应该可以覆盖（也可以手动做一些采样方面的调整，尽可能确保 3 个场景只要有触发都有录制）

对于问题 2，不实际针对业务做一次 diff 降噪是不知道的。笼统点讲就是会去掉没有和外部服务关联的那部分数据（如我正文里的示例项目，id 是程序自己生成的，没有依赖任何外部服务），但这部分数据具体和哪些场景有关得看具体系统情况了。

比如 createTime 、updateTime 这类和时间有关的参数。

既然最终要拉线上的数据，多多少少会影响到线上服务的性能，甚至功能，这块怎么能将风险降到最低

之前官方有分享对线上服务的性能影响，具体数值忘记了，但只要采样率设置得当，影响不会太大。要对线上抱有敬畏感是对的，但只要做好足够的测试以及对原理足够熟悉，风险相对还是可控的。

敏感数据如何解决，涉及到用户敏感信息、金钱相关的，很多大公司这块审计的比较严

我理解可以在录制回放的平台上加脱敏？原始流量脱敏就不能用了，所以存储的流量不能脱敏，那就只能在录制回放平台上做脱敏了。我理解保障普通用户看到的数据都是脱敏后的，就不影响审计。

那是不是说明通过这种方式回放必然存在局限性，还是有其他解决途径

我理解是有局限性的。其实类似于单元测试，我这个小的单元没问题，不能代表集成起来没问题（脑补一下最经典的 2 扇对外打开的窗，刚好安装时成 90 度，变成一个开着的时候另一个无法开。单元测试来说两扇窗都是可以打开的，但集成起来就出问题了）。线上追求的是服务集成起来后没问题，单元没问题只是一个前提条件。
目前了解到大部分录制回放使用的场景都是回归本身项目中预期应该是没有变动的或者不受影响的部分，最能发挥威力的使用场景是客户端不会动的服务端重构或服务整合。至于日常版本里新增接口甚至是多个服务一起联合改动，这个不是录制回放能发挥威力的地方，这个应该用普通的接口测试做集成测试，会比较有效。

1、线上流量采样，采样出来的数据分布是什么样的，有没有代表性

我理解所有的测试都是为了尽可能模拟真实用户，线上流量的采样用最简单的百分比其实分布就能做到和真实情况比较一致。而且看酷家乐后面的分享文章，为了不至于只有高频接口，还额外做了一些处理，让低频接口也能被采样到

2、diff 降噪，降噪过滤掉的数据是不是不重要的，不需要关心

diff 这种降噪方式，不是要过滤掉不重要的数据，而是要过滤掉回放一定会不一致引起误判的数据。如果业务中确实有存在回放一定不一致，但实际是需要关心的数据（比如 insert 时，直接在代码基于时间戳生成数据的唯一 id ），可以用其它方式去进行自动化，不一定要通过录制回放。

录制回放背后的思想是，线上的结果是对的。所以线上的输入 + 输出就是测试用例的输入 + 输出，回放的时候直接校验新的代码是否和线上的一致。我理解应该不至于是 “对于输入和输出的都没有明确的预期” ？

关联多没关系呀，类比业务系统里面微服务架构，各个 service 相互调用关联也很多。

但要保障的是，用例之间是需要有独立性的。可以封装背后的一些流程，但不要直接调用用例造成用例的依赖。

举个实际点的例子，信贷业务，完成流程需要完成 注册 - 登录 - 授信 - 审批 - 提现 - 还款 这么长的流程。还款的前提是前面 5 步都得完成。我们实际使用的时候会建立一个操作层（叫 operation），用来封装一些流程，比如会封装 授信 流程，里面会包含 注册、登录、授信 三个操作。然后封装审批，审批会包含 授信、审批 操作，如此类推，最后得到一个从零到完成提现的 提现 流程封装，还款时就可以直接调用这个封装作为 setUp 了。

在这些流程操作里，尽量不要有太多断言，只负责操作，不负责操作结果，这样才便于用例复用时用于各种异常场景。

同时这些流程封装，还可以抽离到一些 controller 暴露接口出来，用于平时测试时造数据。

不过其实一开始用例不多的时候，可以先直接把这些用例从头撸到尾，把那几个最重要的流程自动化用例搞出来在项目里使用。再逐步在增加用例的过程中重构抽离，找到自己最合适的方式。

今年换了公司，暂时新公司还没落地。预计明年再分享吧。

另外，你说的 “蛮干” 是什么意思，可以详细说下不？我也有听酷家乐分享以及他们在社区的实践分享，结合各项降噪工具，看起来已经做得挺不错了呀。

建议可以分一下层，把一些多个用例可能用到的部分抽离到一个操作层。
操作层只封装操作，不封装断言。和用例相比主要差一句断言。

举个例子，登录 login 可以封装到一个操作层，参数是 username 和 password ，返回值是整个 response
用例可以直接调用 login 获取 response 做断言，形成登录相关的用例
也可以调用 login 放到准备阶段，作为被其他用例依赖的操作