写得挺全面的，加个精便于更多人看到。

把你的用例发出来？

看不到你的完整用例是长啥样，不好确定你的问题点在哪。

按照日志提示，加上 -X 再执行一次，然后完整日志发上来看看？

信息太少了。不要只给错误日志，给下完整日志？完整日志才能看出完整过程，才能定位问题。

不错的工具，用起来也简单。

建议可以到社区的开源项目板块提交下？

我作为面试官，最关注的是项目经验，其次工作经历，太长的话只会看近 3 年的。其它基本都是快速略过。

说实话，简历是个很容易管中窥豹的东西。简历这么重要的东西都写得不合格，说明归纳总结能力一般，很大可能学习能力也一般。

PS：文中都是要避免什么，建议像以前的文章那样，给个正例反例供参考？

可以问下开发为何不要用 ip 直接访问，是出于什么原因？

我们只有线上用域名，测试环境大多是 ip 。如果要配置域名，不同环境的域名一定是会区分的，要不会乱套，也非常容易连错（配置改得多，错误率自然也会上升，而且你本地的东西，谁都无法复现解决。。。）

无法解决。跨域是浏览器限制的措施，除非服务端允许跨域（得改服务端配置），或者通过 nginx 之类的转发绕过跨域（但同样开发得把后端地址配置为同域地址，发给 nginx ，nginx 再转给实际服务）。

有个疑问，测试环境会有跨域问题，线上不会有么？如果不会，那是不是测试环境的部署和线上差异太大，需要调整部署方式？

有个点不大理解，为何必须要绑定域名这个东西？是有什么特殊需要吗？

本来域名就是为了避免 ip 难记所以才弄的。如果既要有域名，又要有 ip ，何不直接用 ip ？

我们目前做法是，框架提供一个环境名称配置项，可以根据这个配置项的值调整，选用不同环境的配置文件，配置文件里再具体写这个环境里各个服务的地址信息。这样启动命令里面给不同的环境名称，就可以切换不同环境了。为了方便不改代码加配置，也支持通过环境变量或者直接写具体配置项名称，覆盖配置文件里面的值。

spring boot config 在这方面可以说是做到了极致，支持 17 种配置方式，甚至还支持配置的继承，推荐看下：https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

是的。个人觉得不用纠结用是框架还是平台，能简化这 80% 的场景的工作量，就产生价值了。

所以能做到这些，是加分项，也是独特竞争力。

从整体质量保障角度，能做到这些，对降低成本收效更大，因为这个阶段修复的问题成本比测试阶段修复要低。所以能做到这些，公司也才愿意给你更高的待遇。

现在已经是敏捷的年代了，跨界是个很普遍的事情。产品要懂开发，便于设计合理且开发成本低的系统；开发要了解业务，便于需求太复杂时提出意见，在保持需求价值的同时降低复杂度。如果测试还只是停留在测试阶段，对自己要测试的系统除了功能一无所知，那就会被淘汰了。

框架和平台，我觉得本身特点和定位不一样，各有优势，但两者可以并存共赢。debugtalk 提出的框架来实现测试用例的开发调试和运行，平台只做用例展示和结果展示，也是挺好的结合方式。

框架/工具：
优点：灵活度高、可以套各类设计模式、idea 自动生成 + 断点调试等，简单的说就是写用例很爽。
缺点：要有编程基础，要装运行环境。简单的说就是执行测试不那么爽。

平台：
优点：不用本地装任何东西，有个浏览器就行。非常便于推广到非测试团队使用（如开发点一下就执行测试），也便于数据收集统计。简单的说就是执行测试很爽。
缺点：GUI 交互的灵活度会低一些，业务复杂度高的用例写起来可能不那么方便。如果采用写代码类的方式，因为缺少断点调试和自动生成，效率也会降低。简单的说要做到写各类用例也爽不容易。不过如果是轻量级的接口测试（录制或导入接口文档生成 request ，校验主要验证返回码 + 少量返回值，涉及多接口调用的链路不多），这个问题估计也不大，甚至使用上学习成本比写代码低不少。

个人觉得这个事情没有绝对的对错，要根据实际情况来看。适合当前公司团队的才是最好的。至于那些说做平台只是为了装 B 的，说明他们在了解团队实际需求上没做好，只是按自己想法去做，而不是按大家的想法去做。这类情况可以参考的一种解决方法，就是让测试开发开始设计平台前，先到业务测试组轮岗 1-2 个月，熟悉业务测试的实际情况，以后也好相互交流沟通。

可以看看 rest-assured 。链式调用的校验阶段返回的对象，除了可以通过链式调用做断言，也可以取出任意返回值。

框架能满足 80% 场景的需求，剩余 20% 通过高成本一点的手段能满足，我觉得这就是一个挺不错的框架了。

PS：我司内部目前基于 rest-assured 推广接口测试已有超过 1 年时间，但实践中大家对于全链式调用的接受度不是太高，因为实际用例中 request 部分大多差异不大，但 response 校验部分差异较大。而全链式调用从头写到尾，会导致 request 部分重复度高。

目前优化后的用法是：
1、 request 部分封装成函数，返回一个 rest-assured 的可链式写断言或提取表达式的对象，供用例进一步使用。
2、一些通用类参数或统一加解密，做到 filter 中（类似于 spring 的 aop ），用例不需要为此额外写任何东西。

很好的分享，可惜没能搬运过来。

讲师一般最后都会加入到该专场的群里的，可以在群里问下哪位是讲师，然后加好友交流。

个人想法：

本职工作：

• 最终的质量水平（线上 bug 数、客户程序问题反馈数）
• 用例设计深入度（针对实际代码实现补充用例，发现一些别人不容易发现但重要的问题，避免了多少损失）
• 合适的测试策略的拟定（什么重点测，什么不用测，怎么测试最便捷有效，在保证质量的前提下，比原计划减少了多少测试时间）
• 质量提升贡献（如推动产品优化了设计、推动开发发现并解决一个偶发但影响严重的 bug，避免了多少损失）

改进工作：

• 合理的工具开发/应用，提升工作效率
• 测试左移（产品设计时提改进、开发技术设计时提意见、开发阶段 review 代码）
• 测试右移（线上数据监控并第一时间发现及跟进解决、拨测应用、舆情关注）

核心讲你的独特点，别人没有而你有，或者别人做不好但你做得好的。提到价值，核心就是增加收入、降低成本，从这两个方面讲出你独特价值就好。

想问下，你是想测试 proto buffer 这个通讯层，还是 rpc 这个功能调用层？

如果是后者，直接测试 grpc 提供的 rpc 方法可能比较直接。毕竟 rpc 层已经帮忙把常规的缺字段、字段值类型不正确这类问题都挡住了。

想了解下在实际落地时，通过解读文中提到的指标，得到什么样的结论，并对应采取什么样的措施改善，效果如何？
落地过程中有遇到什么困难（如数据没有及时更新导致不准），大概怎么解决？

后续也计划做类似的度量系统，但比较关注的还是度量后，是否得到了更准确的信息，进而定位到阻塞点，重点改进。

可以了解下 MBT。
社区相关帖子：https://testerhome.com/topics/18475

不过目前还不成熟，同时模型的建立其实也依赖人，也许等 DDD（领域驱动设计）流行后，里面的模型可以也套到 MBT 里面，且结合 ai 优化路径遍历算法，有可能达到以可接受成本落地程度。

直接脚本配置里配置被测应用以及其依赖应用的 ip ，会有什么困难？或者说你用的是哪个接口测试工具，分享下，大家说不定可以告诉你对应的方案？

用 host ，作用域都是整个服务器，所以会出问题。但如果是脚本里配置，那作用域就只有单次执行的进程，可以做到相互独立。

感谢支持~

你这段是你当时说会卡死的代码么？好像没看到你提到的 timeout 配置？

好吧。。。

建议弄台 linux 虚拟机，或者给官方提个 issue 。这块比较深入 windows 和 linux 的差异了，我也不大知道怎么解决比较好。

刚找了台 windows 机器结合 git bash 试了下，貌似 ps 不会显示所有进程。可能是 windows 下不支持。

可以试试直接改为用控制台找到的 pid ，继续进行后续的 attach 步骤。

那就好。不好还是比较好奇，为啥一个 timeout 会导致 http method 都消失了。方便把你之前存在问题的代码附上来不？

另外，建议下次提问，可以把关键代码加上足够的注释，直接贴出来。这样沟通成本低很多。

你的异步请求代码是怎么写的？这个请求很奇怪，连 http method 都没看到用的是哪个。

这个太粗了吧。。。

会向后台提交这些步骤 ，具体是怎么提交，同步还是异步，一次交互还是多次交互？
去调用我判断这些元素并执行相应的方法去找到对应的关键字驱动 ，这个是纯服务端还是服务端 + 客户端的操作？

建议画个 uml 时序图（可以用 plantuml 或者找些支持时序图的 markdown 编辑器），说明下网页点击这个 测试 按钮后，浏览器端和服务端的交互。比你写文字清晰多了。或者直接把你这方面的代码贴出来，也便于了解具体实现细节。

另外，从你的说明上，大致猜到你是用了同步请求，但正常来说同步请求浏览器或者服务端会有个默认超时时间，达到时间只会返回 504 或者 timeout 错误，不应该页面卡住。这里面应该还有其他的问题。需要你提供上面提到的实现细节才好定位解决。