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

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 放到准备阶段，作为被其他用例依赖的操作

有个疑问，对于第三点提到的场景，第一个环境点完了，后面的可以直接回归。但不同环境数据乃至账号都不一样，怎么确保录制的脚本在数据不同的情况下还能正常回归？
另外，录制的脚本，对于界面关键元素展示的校验，应该还是得手动加上的吧？

由于翻页后，元素未来得及刷新就开始获取了

人肉是如何确认元素刷新完的？把这个标志也引入到自动化里面作为确认刷新完成的标志？不用 sleep 的话必须找到合适的标志表明刷新完毕。你现在问题是找到的标志不可靠。

另外，也可以换个思路，只要出现 IndexError ，那么就捕获这个异常，并在捕获异常后的逻辑里二次校验此刻表示界面共有多少条数据的标志是否等于当前 index +1（这个时候如果这个标志还没刷新，可以直接给研发报 bug 了）。如果是，那就直接吃掉这个异常当做用例成功就好。虽然有点坏味道（把异常当做业务逻辑处理），但这个场景下这种方法会比较简单

但是每次线上出 bug 的时候 下意识的第一个想法 都是 这个测试是不是不靠谱啊

这种情况，就得在线上出问题后复盘时，测试一起参与甚至主导了。先得要明确，线下的测试无法发现线上所有缺陷，有的缺陷确实是测试环境无法复现，或者测试成本极高的（比如必须要用线上的数据才能出现）。另外，要引导说明，预防这个问题再次出现，测试、开发甚至产品需要做什么。让老板知道，解决问题不只是测试要干活，开发、产品都要干，意味着他们都有责任。

不过有一个基础要做好，不要出现那种很简单就能发现而且是 P0、P1 级别功能的 bug，并且造成不小的损失。出现这类问题，不管怎么说测试都有责任的。

但是公司只会换测试而不会去换开发

那可以预见换多少个测试都没用，因为 bug 都是开发写的。。。

开发技术越弱的团队测试地位越低

不一定呀，只要测试指出了这个点，并且去各种推动开发提升自己技术和质量，那测试地位就不比开发低。如果说测试只会在出问题后后知后觉，那地位肯定高不到哪里去。

最后多少几句，如果说老板本身的态度就是 “测试是为了保障系统不出问题的，出问题都是测试没做好”，那就要明确，要做到确实没问题可以，成本增加 2 倍甚至 3 倍。就像同一个代工厂，可以生产高质量的 iphone，也可以生产低质量的山寨机，只取决于你的质量标准多高，愿意付出多少成本去覆盖不良品和检测成本。老板们都不笨，所有缺陷和故障背后都有 roi 的，比如一个服务器机房造成的故障，作为公司要彻底解决那可能得多地灾备或者搬另一个机房，但如果这个缺陷其实造成的损失不大而且出现频率不高，最后其实还是会保持现状的。

另外，感觉你有点悲观，观点里有许多 “不现实” ，“不可能” 。积极点看，应该是 “很难” “几乎不可能”，但概率绝不是 0。确实个体力量很难扭转大局，但从自己做起，由己及人，积沙成塔，也是能产生不小的影响的。莫以事小而不为，只要觉得正确，就去干吧。

我也不大清楚，没怎么用过。只是直觉上觉得这个选项和重复执行场景有比较大关系。

提示无法找到该用户，你注册钉钉用的是这个邮箱吗？

建议说服开发开给你就好了，没必要为了一个几分钟加个开关 + 切 webview 就能解决的事情，想各种曲线救国

既然开始做 ui 自动化了，就得想办法拉上开发给你提供便利，高大上点说就是为了可测性进行调整。曲线救国会明显降低 roi，引入更多工具也会让自动化变复杂、变慢和更不稳定，而且后面总会遇到没法曲线救国的地方，这时候才找开发人家已经习惯你单干，不一定愿意帮你

可以通过沙龙等活动，认识一些朋友呀

社区也可以，不过一般还是线下活动效果更佳。

这个就要和老板沟通了，否则测试永远都没地位。
不过一般至少 CTO 级别的还是了解测试是不可缺的，cto 控制好也可以。