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

本来域名就是为了避免 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 错误，不应该页面卡住。这里面应该还有其他的问题。需要你提供上面提到的实现细节才好定位解决。

建议详细说下你这个 “点击测试” 按钮点击背后，到底平台做了啥事？

信息太少，只有个截图，也没有齐全的日志（浏览器的、平台服务端的）、大致功能实现逻辑，大伙也不好给你出主意，只能靠猜。实现逻辑猜错了，给的意见也很难有参考意义。

这个坑确实挺深的。想请教下，应该怎么做能避免踩中这个坑？

设置成不可见只是一个选项，便于作者做一些个人私藏的记录。专栏的核心点是提供更好的个人社区影响力。

至于发的帖子很少人回复，可以换个角度想下，会不会是帖子内容对大家吸引度有限，无法引起大家回帖的兴趣？一般大家回帖，要不是有同感，要不是发表自己不同观点，但这类帖子大多都是有作者的观点或者感想。一些不包含作者观点或感想的（如消息公告），容易无感导致没找到能回帖交流的点。

建立专栏本身，也期望大家更多去分享自己的独特经验或观点，便于社区的其它同学更好地认识你。

挺不错的，敢于突破。如文中领导所说，已经超越 95% 的人了。

功能做得挺全的，基本上大部分核心功能都有了。但个人比较好奇，这个平台的相比其它已有平台，独特的点是什么？或者说哪个点其它平台没满足，而这个平台可以满足？

后续周边功能方面的建议（仅供参考，具体还得看公司实际需要）：
1、和持续集成的对接（如支持通过调用指定接口触发测试任务执行、支持自动发送测试结果到邮件/钉钉）
2、对流程类用例更友好的支持。从介绍上看，一次接口调用为一个用例，那对于流程类用例（调用多个接口的），是怎么处理？如果用用例集管理，那 3 个核心流程的用例要变成一个用例集一次性执行，是否可以配置？
3、对于多项目的支持（每个项目有自己的独立的环境配置、用例集、定时任务等）
4、数据报表（如趋势图、饼图）。这个领导会比较关注

另外，通过平台降低技术要求是一个挺好的切入点，但如果要把自动化坚持下来，逐步让测试关注技术、推动规范统一还是需要的，要不维护用例会累死，自动化发现不了什么问题也会导致大家不认可。

我指的不是线上回滚，是测试环境切换版本到可以验证的旧版本

1、先把问题归类。bugly 之类的平台已经会自动按出现次数排序了。
2、寻根问底是什么原因导致的问题。可以参考 5 why 原则，了解到根本原因，再从根本上解决。

假设占比最大的问题，从崩溃平台上看到原因是空指针，可以按照类似下面的套路询问：

• 这个空指针具体是哪个值为空导致的？——xx 属性
• 为啥这个值会为 null ? ——坑爹的服务端没返回这个值
• 为啥服务端没返回这个值？——因为服务端本身存储的数据里就没这个值
• 为啥服务端存储的数据里没有这个值？——因为前面的流程这个值不是必填的，刚好用户没填，所以没有
• 为何对于这个本身服务端就可以不返回的值，客户端没有进行兼容？——当时不知道这个字段是非必填的
• 为何当时不知道？——接口文档没写
• 为何接口文档没写？——以前就是这样的，一直都不会写
• 如果要加上，会有什么困难吗？——接口老是调整，改完代码又得该文档，维护接口文档成本太高了

那问题的原因就比较清晰了：接口文档的维护成本太高，导致客户端没考虑到这个场景，最终导致这个空指针。那解决的方法，可以考虑用 swagger 之类的自动生成接口文档工具生成接口文档，免除接口文档的额外维护成本。当然，也可以更进一步，了解为何接口总是要调整，是否团队人员经验太缺乏导致设计没做好，还是需求改动太频繁导致系统必须配合调整。

同时，也补充一个，使用前判空是一个很关键的编程习惯，可以团队内分享下各种遗漏判空导致的损失，以及形成什么样的习惯来避免空指针异常（调用这个对象的子方法/子属性前，都先判空）。