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

建议可以参考下：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 才是复杂和精髓之处呀。

好工具。

加油！

有和开发沟通过大部分 bug 自测应该就能发现这个问题么，开发的想法是怎样的？

看到历史已经有同学问过类似问题，可以看下是否可以参考？

https://testerhome.com/topics/18304

个人理解并不是没有启动，而是 jenkins 执行完 job 释放资源时，连带把你启动的 tomcat 集成也一起杀掉（释放）了。

突然被 @ 了好惊喜呀，这个项目挺不错，让 golang 的同学也可以用上 WDA ，点赞！

她们的诉求是造数据能不能只给出看到 code 值（页面上实际展示的编码），id 界面上看不到，也不知道是什么

如果 code 和你接口用到的 id 有一一对应关系，我理解也可以呀，你在底层做一个 codeToId 的转换就好，根据 code 到数据库查 id 。不过说实话，如果界面看不到就不知道怎么查的话，感觉做接口测试这类相对灰盒的测试，有点早？

能问下你这边指的思路也是通过调用接口去生成吗？但是抽取出来？

调用接口后，去数据库查出来。没有通用组件那么复杂。我们的业务是借贷业务，贯穿全程的是用户和账单信息，1:n 关系（一个用户可以多个订单），所以做了一个 model 统一存储一次流程中这些会强相互关联的信息。model 里面的值可以从手动写的配置文件取，配置文件没有那就调用对应造数据方法造出来 set 到 model 的实例里，这些写在一些全局 setUp 的方法里就行。

关于最后一点，“其实本质上所有协议都是数据传输加接收” 这一点我时间认同的，有两点疑问，一个是抽象出来的 model 是包括了 url、header，请求内容和期望的吗？现在只是基于 testng 将请求内容和期望外加描述信息做了一个抽取，请求的 url 是单独的一个配置，能具体描述下 model 的全貌吗？另外，你这边指的 send 方法类似于 httpClient 中的 execute 这种感觉吗？

url、header 本身就是 http 协议的一部分，应该属于请求执行方面的东西，model 不需要包含。model 只需要管理这个接口对应的数据模型即可。这只是抛砖引玉哈，我们公司内部项目基本上是比较统一的 http 协议，所以暂时用不到这个。我这里的思路有点类似于 rpc 调用，程序只需要知道方法，直接去调用即可，具体用什么协议由 rpc 框架来负责。比如 dubbo 支持多种不同的网络传输协议 (https://dubbo.apache.org/zh-cn/docs/user/references/protocol/http.html)，切换协议只需要调整一些配置，不用调整代码编写方式。
send 方法类似于你说的 execute ，本质上就是一个通用接口，固定函数的格式。不同协议，提供不同的实现即可。

关于 1：例如我调用新增订单的时候，我需要选择一些额外的系统信息（必填项），例如用户、店铺、商品等等，那么如果这些是前置造好的话，那么每个环节新增用户生成的 id 什么的都不一样，所以才会不好配置，因为这些属性太多了；但是如果我为了新增订单，每次再去新增用户、店铺、用户等信息那么我觉得链路过长了。

我理解你的目标应该是造数据给第八个接口用？如果是，那先保障第八个接口的需要，如果第八个接口可以使用固定的用户、店铺等信息，那就在你的接口调用里直接把这些 id 做成配置项传入即可。id 管理由人来做。到后面有需要那就把配置项改为不是人写上去，而是程序自动生成和记录即可。

另外还有个痛点是，现在系统相当于是三种不同架构模式的...

这个是老系统持续重构的常见问题，严格不是技术问题，而是取舍。最低成本当然是统一架构后再直接基于新架构写接口用例，但这样价值也最低，因为重构过程中用不上。如果重构也希望有自动化协助，那就要增加成本（新老架构各写一套用例）。

至于接口调用实际使用协议的差异，其实本质上所有协议都是数据传输加接收。框架设计得好数据应该是抽象的模型（比如 model 层），具体协议可以直接基于模型写生成方法（如 json、xml、yaml 等），请求发送也是类似，统一命名为 send 方法，使用者只需要用这个方法即可。至于实际用的是 http 还是别的协议，由负责维护这个接口的同学写具体实现即可。我理解并不是不能做，而是这么做框架设计会变得复杂一些，所以需要像上面说的，衡量投入产出比。

比如 jmeter 支持把自己设置为 http proxy 后，自动录制经过的调用为 http sampler ，然后调整改动下后可以变为接口调用的封装。
又或者把你的抓包记录导出为 har 格式，然后用 httprunner 生成对应的调用 yaml 用例，同样把需要变化的入参变为变量传入，也可以成为接口调用的封装。

可能数据有点太乐观，1 天我这里指的是编写用例的时间，具体调通 8 个接口并可以连起来，如果遇到阻碍或者疑难杂症（比如环境有问题、用的是非 http 接口、数据带有加解密之类的），估计会需要更长时间。

看投入产出比。

个人经验，假设说现状是没有隔离，如果有下面的情况，建议隔离：
1、经常出现一个功能一会可以，一会不行。问了整个研发团队都没人反馈，只能不了了之，上线时这个功能是可以还是不可以都得碰运气
2、阻塞性问题出现频繁，而且卡住后大家一起上都得解好几个小时，其他人只能等，然后加班赶进度
3、有些配置或开关，打开后会严重影响其他人使用（比如直接通过开关关掉用户登录）。但开发需要开，测试需要关，两边需要有冲突

不过隔离后必须要解决的问题是，开发环境的持续维护。
一方面，开发人比测试多，变更更频繁，且上去的很可能是没有跑通过的代码，出问题可能性更大。
另一方面，如果系统服务比较多，链路比较复杂，开发不熟悉整个环境，容易自己改动破坏了流程的正常使用而不自知。

这个持续维护的成本，很可能对开发团队而言挺高的。但不处理好的话，开发环境就会变得无法使用（流程都走不通，也没人知道怎么解决，相当于废掉了），为了项目进度，测试环境还是会被开发占用做联调。

最好的办法是，一套公共环境维持和线上版本一致，然后每个需求开发自己可以基于这个公共环境复制一套，测试也自己复制一套，上线后这些环境回收，并更新公共环境。这样就不用持续维护一个环境了，而且以需求为单位人数会少一些，也避免了太多人使用相互影响。不过背后就需要有比较完善的环境管理平台了，人工操作成本太高了。