使用了一下，云真机好流畅，和自己内网搭建的 stf 流畅度和清晰度上，达到同一水平。

没明白你的问题。“回归能力” 这个词第一次听，它的定义是？

如果是指自动化测试的价值，那很简单两个问题：
1、如果没有自动化，你这些测试是不是会变成人工去测试？（确认会不会做了些其实本来就不需要做的事情，画蛇添足）
2、如果是，人工去测试的校验点，自动化是不是都做到了，甚至更全了？（确认自动化是不是做到位，会不会出现校验点不足导致不信任自动化，自动化完还得人工再验一次才安心的情况出现）

如果两个都是肯定回答，那自动化是机器取代了人工，释放了重复劳动，所以应该是有价值的。

1、你这个写法，违反了 测试用例间相互独立 这个原则，test_2 对 test_1 存在严重依赖，相互不独立。应该要把用例分为两大类，一类是专门测登录前功能，另一类专门测登录后。第二类在 setup 里面完成登录操作。
2、不知道你是怎么执行 test_1 的，具体步骤发下？

感觉你的矛盾点：
1、想找本行业且待遇至少和现在能匹配的工作，但基本都不在宁波
2、想找宁波的工作，但本行业的职位少，待遇也低

破局点：仅通过工作，做不到地域和待遇两个都满意。但收入并不仅仅是工作的待遇，还可以有其它。

可以试试：
1、先找待遇不错的本行业工作，不局限宁波。但待遇可以争取尽可能高
2、存下钱做理财，积累更多财富，并获取更多被动收入
3、孩子大了后，回到宁波找个低点待遇的。待遇差的部分通过被动收入弥补。

可以问问你的 leader ，当时招你回来是期望你发挥什么作用。

如果真的没有专职测试人员需要，应该是不会招这方面的人的。

问题一：首页的最新收录开源项目，和开源项目板块首页内容有出入。
原因：首页的过滤条件，遗漏了不显示未审核通过的项目设定，因此存在此问题。
修复代码已提交，待 review 上线。关联 pr ：https://github.com/testerhome/homeland/pull/101

问题二：URL 不正常
原因：slug 若未给出，地址会类似 https://testerhome.com/opensource_projects/92 ，以项目 id 结尾。但不至于会如截图中显示好几个破折号，问题无法重现。

问题三：点赞在刷新后消失
原因：目前除了专栏文章，不支持对自己发表的内容自行点赞。至于前端显示点赞成功，主要是为了提高用户体验，让用户明确感受到自己点击成功，前端在点击后均会显示点赞成功，而非在后端返回成功后才有反应。相关代码：https://github.com/testerhome/homeland/blob/master/app/models/user/likeable.rb#L21

谢谢反馈，今天我抽时间处理下，处理后也帖子里同步下

纯回放流量是这样的思路，没问题。
但帖子里的例子是包含了子调用 mock，子调用 mock 记录和入口调用的关联条件之一是 url ，所以需要 url 匹配。

不要懒得翻，善用搜索。。。
你说的这些不少智能化的 monkey 都有的。

额，帖子里说了，回放会根据 url 匹配，因此放在 url 中的参数也需要保持一致。

不过这种回放方式只是用来跑 demo 尝尝鲜。实际项目玩法，建议参考我第二篇文章里提到的 repeater-console 的使用。

建议先试下去面试，对自己水平有更全面的认识，再作决定。
单纯为了涨薪去跳槽，你会少考虑很多更需要考虑的事 (公司前景、职业规划等)。
薪酬是你在公司价值的体现，价值没变，薪酬上涨，这个很难持久的

可以提交到社区开源项目版块，让更多人知道？

Failed to execute goal on project repeater-console-service: Could not resolve dependencies for project com.alibaba.jvm.sandbox:repeater-console-service:jar:1.0.0-SNAPSHOT: Could not find artifact com.alibaba.jvm.sandbox:repeater-plugin-core:jar:1.0.0-SNAPSHOT -> [Help 1]

缺少依赖，估计是因为你之前没 build 过 repeater 的其它 module 。
可以先 cd 到 repeater 项目根目录，执行 mvn install ，再按文中步骤到 repeater-console 执行这个命令试试？

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

把你的用例发出来？

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

按照日志提示，加上 -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 ），用例不需要为此额外写任何东西。