你是从哪里看到 mockjs 可以进行接口正确性验证的？不知道你的上下文，不好回答。

硬要说的话，对于那些透传或者依赖下游服务的接口，通过 mockjs 可以把下游服务模拟掉，便于上游测试接口，也算是一种接口正确性验证的辅助手段。但我了解的 mockjs 大部分用途是前端开发在联调前辅助自己自测用的，前面这种场景用得会比较少，毕竟后端大部分都不是那么熟悉 js 语言，用自己顺手的语言对应框架更趁手。

别迷信这类练手项目，和实际公司项目差的太多了，基本这个项目的经验在面试官眼里面等价于没啥经验。去外包或者创业公司练一练都比这个强。

因为你不会经历产品需求不清晰需要不断沟通澄清、开发实现影响范围写得模糊需要沟通确认甚至看代码倒推、测试时间很紧张只能从风险角度挑着测、上线后要会看监控确认无故障这类真实项目家常便饭的场景，所以你对这类情况的处理解决能力也无法得知。

个人建议，你就直接持续跑着 5 个左右的 appium 服务，脚本只需要选择用哪个服务就好，这样也可以并发，而且技术上更简单。当然，要记得脚本里面确保每次执行完毕都结束 session 。

如果要搞用到时启动，你需要了解 python subprocess ，需要知道如何从命令行启动 appium ，需要能监控 appium 服务是否真的启动成功。从你目前的回答看，你对这些方面的知识了解其实并不是很多，所以直接持续开着 appium 服务，脚本只管选择，这个方案可能更适合你。

当然，有一个绕不过的点，那就是你还得知道如何从命令行，而非 appium desktop 启动 appium 服务，否则做不到多开。这方面的知识一楼已经有说过了，建议可以结合社区搜索一下知识理解一下。如果实在还是不理解，可以再发帖说你找到了哪些文章，个人理解是如何和卡在哪里，便于大家协助你。

自动化测试中，验证码的最佳解决方案是万能验证码或者直接可跳过。

不能做到独立无人工介入的，都只是半自动化，不大适合用 jenkins 自动触发执行。

往年 MTSC 大会都有小程序测试的相关议题，甚至有邀请到微信的同学来分享。建议可以先看看？

交流是要相互的，建议你先提出你自己的观点和看法，别人才能回应交流。只是抛问题只能称为咨询。
而且任何具体工具使用都是依附于当前业务需要的，你也没介绍你的业务情况、痛点难点，大家也不知道给啥建议你好。

信息太少了，而且除了薪资，你也没提到你所在城市或者公司这两个职位之间你的感受对比，无法给出建议。

从大的行业来说，前端开发对业务的贡献会比自动化测试大，门槛也高一些，所以应该前景更好。但到了具体公司，这并不一定，如果质量是公司瓶颈，测试开发也会很吃香。

我不是活动主办方，控制不了这些 ppt 。

建议你可以在那个公众号下留言给他们。

各个地区、各家公司要求不一样，这个问题建议你查招聘网站 jd 以及去自己直接面试下，得到的答案才准确。

PS：自学不管做到什么程度，从公司角度你的实际项目经验还是近乎于 0，需要不少时间才能上手实际项目。深圳竞争还是比较激烈的，非应届且没多少测试方面的经验，不知道好不好找。建议空杯心态，多去试试吧。

看漏了个 Manager ，原来是平台呀。

可以和作者沟通下，提个 pr 或者直接 fork 到你账号另外维护呀。

谢谢反馈~我们看下是否设置有误。

你要测试的是哪个点，举个具体的例子？

浏览器的 UI 自动化测试工具（如 selenium、Puppeteer）适用吗？vue 自己也有单测的手段，适用吗？

上下文太少，无法回答这个问题。

PS：中高级测试的面试，不大可能不涉及测试技术问题吧。

可以直接给 httprunner 提个 pr ，修复下这个问题？

建议先和领导沟通确认下，他想要的到底是啥，想解决什么具体问题？

领导给的是方向，我们要沟通得出他为什么想要做这个，具体想要做成什么样，澄清他的需求。把方向直接当做目标，不一定就是正确的。

这类文档规范很多，例如 google 的 Lighthouse ，但要做好要耗费不少精力的。首先得能监控到线上的访问速度数据（测试环境再快也没用，用户慢还是慢），然后对于特别慢的针对性定位解决处理，积累经验。最后再逐步把这个事情常态化，变为规范在开发阶段就遵守落地。

一上来就直接到最后一步，整体团队很多时候并不那么容易转变过来的。在性能不能和当前业务需要挂钩时，做性能是很难得到团队的支持的。

可以试试文中的套路？如果是有具体哪个点卡住了可以具体发出来。

非常同意，放弃怀疑其实就等于放弃了提前发现问题的机会，问题是不会自动消失的，所以整个团队最后还是会被这些问题所累。

而且很多时候放弃怀疑的人在很多地方也都放弃了思考，变成单纯的执行者，只有工作年限带来的经验值，很容易被保持思考的应届生超越。

建议排查思路：

1、看下 appium 服务端日志，看下具体的报错信息是什么？
2、看到报错信息，再对应去排查。

现在你的错误日志已经在引导你去看 appium 服务端日志了（unknown server-side error，未知的服务端错误），所以你下一步最好就直接去看服务端日志看具体是什么报错。

没有这个报错信息，大家也很难协助你，因为线索太少了。

小建议，rabbitmq 有 java client 的，直接用那个把消息加到 mq 里是不是更直接省事？

按照我们目前实践，除去配置项，用 client 5 行代码内应该就可以完成连接队列 + 插入消息的操作了。

哈哈，认同。

不是修改后问题消失了就是解决了，很可能问题其实没消失，只是变成另一个问题了，所以现象不同了。

我测试了下，这个写法没问题。

完整用例：

- config:
    name: testcase description
    variables: {}


- test:
    name: /account/sign_in
    request:
        headers:
            If-None-Match: W/"bc9ae267fdcbd89bf1dfaea10dea2b0e"
            User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36
                (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
        method: GET
        url: https://testerhome.com/account/sign_in
    extract:
        X_CSRF_Token: <meta name="csrf-token" content="(.*)" />
    validate:
        - eq: [status_code, 200]

- test:
    name: /account/sign_in
    request:
        data:
            commit: Sign In
            user[login]: chenhengjie123
            user[password]: xxx
            user[remember_me]: '1'
            utf8: ✓
        headers:
            Content-Type: application/x-www-form-urlencoded; charset=UTF-8
            User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36
                (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
            X-CSRF-Token: $X_CSRF_Token
            X-Requested-With: XMLHttpRequest
        method: POST
        url: https://testerhome.com/account/sign_in
    validate:
        - eq: [status_code, 200]

不知道你贴上来的用例是否完整，如果是，那你少了第一步的 get 请求（打开登录页面），所以导致没有生成 $X_CSRF_Token 变量。

多用。

同时简历里别写自己都好久没用的工具，被问倒反而变成扣分项了。

repeater 的主要特点是，针对写（post）操作，除了录制服务的流入流量，也可以录制服务的外部调用或者特定调用（如数据库查询、第三方服务调用等）。

goreplay 看了下简介，没提及针对写操作的针对性适配，不确定是否也有类似能力。

这块其实是工程化的部分了，并不复杂，所以暂时没有计划专门写文章分享这部分。建议可以自己探索学习下。

repeater 是一个底层组件，还是需要不少探索改造才能在项目上实际使用的，建议要做好自己要额外开发一些配套东西的准备。

repeater-console 里没有对应方法，要用 repeater 里面序列化库的反序列化方法。

从你前面配置步骤，没看出太大问题。但你的截图里总是有些像乱码一样的奇怪字符，不知道是不是你的系统默认字符集不大对。

另外，有个很奇怪的点，你倒数第二个截图里面，repeat 请求返回的 data 值，没见到具体值是啥，展示不完整。

然后最后的 callback 里用的 id 是必须用 repeat 返回的 data 里面带有的 id 的，因为它查询的是回放结果，直接用和请求 repeat 一样的 id 是不正确的。我刚刚也微调了下正文里的内容，强调一下这个点。