用手机运行，只是形式吧。最终目的难道不是你不用去特意动手机，就能自动完成签到么？

我的思路是，如果是用网络请求，代码处理起来会简单很多（网络报文本身就是便于程序阅读的），也不依赖手机，公司电脑不关机，定时任务执行就可以。

如果是纯手机运行，solopi 等都可以，具体使用建议可以看下官方的一些文档以及社区的分享。但这些软件我理解比较难做到纯后台定时自动运行（基本上锁屏状态下各个软件能做的事情不多，都被操作系统限制住了）。当然如果你需求只是我把 10 步操作变为一键点击，那这些软件应该可以满足你。

其实，可以考虑换个思路，直接抓包拿到所有请求，然后直接搞个脚本重跑这些网络请求就好？

说明你停留在 了解 阶段，看起来都懂，但面试一问就想不起来。还没到 掌握 。
除了看，还要写和用。写得多、用得多，自然就熟练了。

结合公司内部实际的一个很好的落地时间经验，加个精鼓励下

信息不够全，你给的信息看起来都不会导致这个问题。

Jenkins 构建日志、完整 pipeline 脚本也发下？

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

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 这一层的处理能力比你系统的处理能力差，要想办法优化下网络环境？