如果内部人员（建议范围扩大到全公司，产品、运营一般做竞品分析都会自己资料给竞品了，自家产品一般也愿意的）愿意提供自己信息走流程，最好。征信这个可以在授信环节的征信查询和放款后征信上报那部分代码加个白名单，公司内部人员都加入白名单，白名单里的都跳过征信这部分。

PS：授信审核部分可以做一些白名单，不管提交什么授信信息都给额度，这样授信信息可以直接给不真实的，也能解决大家担心自己信息泄露的问题。

如果内部人员不愿意，或者确实条件不具备（比如要测试一些和合作方连在一起才能走的场景），那就只能做小流量监控。系统支持按百分比或白名单分配流量，然后日志、线上用户行为埋点做好便于观察这次上线改动的某个节点是否正常。

@98killer 首页 android 客户端下载地址及对应二维码已修正，你试试？

至于 android 客户端内登陆界面，点击 github 按钮后无法跳转的问题，得等周末有空再看了。

等可以摘口罩了的时候再组织吧，现在组织，安全方面还是比较有风险。

写得挺全的，但感觉都做好不容易。特别是需求、设计、代码，这三块要产生影响力不容易。

期望楼主后续可以继续分享下，自己实际工作中的实践经验。

这个是之前 fir 域名更换导致，原有的下载地址都会无法使用，暂时还没重新上传。
我这周内重新上传，把这个问题修复掉吧。

android 手机在家里，回到家试试

客气啦

受教了，原来还有这么多陷阱。

信息太少了，用啥框架、语言，两个不同地方跑出来的内容有啥差异，有没有报错？除了一个笼统的现象其它一概不知，想协助但真的无从下手。

建议可以参考下：https://testerhome.com/topics/16747 。技术类问题贴代码 + 日志一般都是最直接有效的。

你这个比较特别，包住这个问题文案的 td 标签，内部实际包了 input + a + span + br + 这段文字 。恒温那个方法应该可以，获取 text() 属性，就是只获取标签中的文字，忽略其它同级别的 html 标签内容。

还有一种思路，就是直接用 xpath 等方法把整个 td 标签拿到，这时候它应该是一个 Element 对象。然后再获取这个对象的 text 属性，这样应该也能单独拿到这段文字。

性能测试必须在功能测试通过之后进行

不得不说，确实不少公司就是这样的。真正有专业性能测试人员、可以贯穿项目整体流程的公司并不多，比较多是功能基础上有需要就增加性能测试，没需要就直接上线。线上性能好点的会有 APM 工具辅助监控线上性能，一般的基本就是靠运维看各种服务指标有没有爆炸，或者等用户反馈。

比较好奇，具体是什么方法论问题？

个人觉得，本质上都是回归到统一状态，便于不同用例可以乱序执行。

至于回归的方法，是一路返回或者直接调起 launch activiry 到首页，还是重新 setup 直接重装应用，就根据成本和收益评估吧。

另外，如果是为了支持乱序同时也节约时间，不妨考虑增加一个多用例集的概念？同一个用例集内共用 setup 以便支持乱序，不同用例集 setup 相互独立。然后所有用例集的父用例集 setup 负责启动应用进入首页，子用例集 setup 则是负责从首页开始到自己用例起始页的操作。

不用太受打击，估计是开发没有面测开经验，所以按开发的水平来面了。

一般下结论的时候，会重新适配回测开的需求来下，不一定答不上就不给过。

不过倒是可以考虑作为一个学习的机会，让你看到开发的深度。以后想更精进开发能力，可以作为参考。

这个是迁移过程中一些沟通上的差错，误解为这个邮箱不需要迁移，所以禁用了。

目前已经解除禁用了，你再试试？

那你的场景或者说目的是这些接口都要一起测，还是分别单个测？

或者说，把你现在脚本的具体写法发出来？现在你的目的和现状都不是很清晰，不好给建议。

你的意思是，需要压测中，每个接口最终请求量比例接近 1:1？

如果是，可以看看 https://testerhome.com/articles/16532 ，大致原理上可以变为给每个接口一批虚拟用户，控制这些虚拟用户的比例即可。

但不大明白这么做的目的是啥？一般主要关注压力发生的比例，而非最终请求结果的比例。相当于有的接口对应功能用户多，有的少。比较少见到比较最终请求量的。

找开发加 content-desc ，或者用 xpath

个人觉得，复杂逻辑和清晰的代码逻辑，两者不一定冲突？比如通过设计模式，能简化很多复杂问题的代码处理逻辑写法。

主要是觉得正文说得有点太绝对，特别是 “拿到数据库表结构，大致上就知道是怎么做的了”。一方面，一样的接口和数据库，资深的人会考虑幂等、补偿、熔断等多种场景的处理，普通人去 yy 可能就只能想到最直白简单的逻辑；另一方面，系统输入并不只有接口，输出也并不只有数据库。

举个例子，登录接口（login，入参为用户名和密码，返回登录结果）+ 用户表（存储用户 id、用户名以及密码），实现登录功能。
最直白的实现：直接给 dao 层执行一个数据库 sql，select user_id from user where username = #{username} and password = #{password} ，找得到就成功，找不到就失败。
但实际情况，安全因素需要密码加盐、加密存储、限制失败频率、账号多处登录互踢等；性能因素需要加缓存（随之带来各种为保障数据一致性问题加入的逻辑）、和写接口（如改密码）并发加锁、营销活动引起大流量时自动排队、限流乃至熔断等。这些并不一定只通过接口清单和数据库就能 “大致知道”，因为不属于这两个部分要考虑的点。虽然看起来是细节，但根据业务场景这些很可能都是必须要考虑且实现的项。

回归正题，主要还是觉得正文的说法有点太简单和绝对了，也缺少详细的论证例子，缺乏对代码逻辑的敬畏，所以看完觉得不大能认可。

SSLException: handshake timed out，简单说是 SSL 通讯建立的时候就超时了，所以没法在建立通讯后发送接口请求。

这种情况表示 gatling 发出的压力，已经超出服务端和客户端之间网络层的承受能力，没法及时处理了。如果这个时候系统响应还处于正常值，资源也没到瓶颈，说明可能你压测环境 https 这一层的处理能力比你系统的处理能力差，要想办法优化下网络环境？

想请教下，测试阶段实际上代码还是会有不少改动的，那此时不可能每次改动都全量回归以获得最准确的覆盖率数据。想了解酷家乐内部是怎么解决这个问题，让覆盖率分析尽可能覆盖整个测试阶段有测试过的代码的？

大致看完了，感谢分享。实时质量这个概念是挺不错的，把质量手段嵌入到业务应用中。但有个比较重要的点，这些质量手段谁来应用，谁来负责？

文中提了不少例子，基本上是属于 “赋能”，即原来其他方做不了或者不想做，给测试同学做的重复性的活，经过赋能让他们也能做，由他们直接判定结果是否符合预期，释放测试资源和负担。但这也会带来一个问题，那就是如果他们没做好（毕竟他们的核心职责不是质量），就没人能兜底了。

个人觉得，对于证实类的工作（确认一个功能是否和需要的一致），确实可以交给其他人做，毕竟这个应该是一个项目所有角色的共识，并不复杂，出问题也非常明显，只要有责任心，一般不至于遗漏到生产上。但对于证伪性的工作（探索这个功能在各种特殊情况异常情况下的表现，是否合理），或者证实特别困难的工作（比如场景组合特别多，比较难考虑周全），个人认为这是测试最核心的领域（测试设计），也是测试的价值。

只是互联网的节奏，对非核心故障容忍度比较高，所以基本上大部分证伪性工作都会放到线上灰度来做，小流量时发现了修复就好，所以好像逐渐也就变成测试最能产出的事情是赋能了，赋能开发进行自测，赋能产品进行验收，赋能业务和运维进行各种数据统计监控，发现问题。

只是一点感慨，目前也没想到特别好的方式破局，只能一步一个脚印，把证伪变为证实（吸取教训，把意外情况变为意料之中，成为需求的一部分纳入考虑和验证），把质量变为大家都认可并愿意花精力去保障的事。

入门就是你正文提到的这些步骤呀，导入源码、修改源码、编译打包成可用的 jmeter 。第一步和最后一步基本都是固定的，中间这步修改源码才是关键。
但你没提你具体要二次开发啥，遇到了什么困难，大家也不知道要怎么协助你？

如果这么容易，那写好设计文档代码都可以蒙出来了。。。

你这里只是 Controller 和 Dao，中间的 Service 才是复杂和精髓之处呀。

好工具。