听起来，像是第三方没有正确回调，并且自己系统的补偿机制没有生效，导致数据一直没有同步更新。

个人了解，MS 的性能测试应该是不收费吧？

为楼主的这份思考和实践分享点赞，感谢楼主末尾还分享了这个轻量级反向代理工具。

多套测试环境切换已经改成使用公共代理（nohosts）+ 特殊请求头（标记去请求哪套环境或开发的后端服务）的方式了

好奇问下，为何不能直接沿用这套机制呢？我理解这套机制里，应该有一些手段记录某个主机的请求来了后，是走哪个环境的。这套机制应该也能适用于主机地址相对固定的第三方回调？

另外，这个统一对外，并基于配置转发给内部其他服务的反向代理，在很多的架构中会称为网关（gateway），或许楼主把搜索关键字改为 gateway ，会找到一些合适的工具。

我觉得这个问题，和每个人所处的环境和追求的目标有很大关系，不好讨论。

只能说，真心想存的人总有办法存，相比存钱更关注享受现在的，也大概率会存不下钱（消费会和收入一起增长，导致收入增加后还是没有余钱存在下来）。

在今年这个大环境下，最好还是存点钱，抵御未来不可知的风险吧。

没太理解 “就是大部分都是同一个页面上有不同的切页或者下钻弹框。”，具体是什么意思？每个页面的 url 是一样还是不一样？

前面提到一个个点击，我理解你想要的应该是基于可交互控件进行遍历的工具，这类工具大多针对的是 app ，针对 web 的没怎么见到过。建议可以找个针对 app 且基于 appium 的进行改造（appium 的协议和 webdriver 基本一致，改起来相对容易一些）。

从测试套件这一层的角度，它不应该限制用例必须是接口的或者是 web 的，它只需要管理好用例的执行顺序，记录好用例的执行结果，并提供一些用例间信息传递的机制（比如全局变量）就可以了。

现实中 web 和接口一般会分开不同的套件，分开编写用例和执行用例，主要是因为分开后问题定位以及用例维护复杂度都能降低。

接口测试能比较纯粹地测试接口，不用耦合 UI 界面，失败基本可定位为服务端问题，和客户端无关；而 web 测试则是偏集成测试，服务端 + 客户端（前端）都会集成在一起测试，一旦失败需要再定位是服务端原因还是客户端原因。

所以一般使用上，会先通过接口测试保障服务端没问题，然后再通过 web 测试保障两端集成后也没问题。两边会分开在不同的套件中，分别执行。偶尔会遇到的需要合在一起执行的场景，一般是借助接口调用造数据供 web 测试使用，这个时候接口调用只是作为前置条件，并非用例本身，所以严格意义上说，也不算融合。

不错的解析文，点个赞！

资料有点少，不好评价反馈，只能留点疑问，楼主可以看下有没有做好：
1、UI 自动化里面，框架是否有提供什么机制便于提高用例稳定性？（如找元素的自动等待等）
2、UI 自动化脚本的写法里，怎么尽可能让代码容易复用？（如 PageObject，从代码看有 Page 的概念，但不确定是不是用了 PO 模式）
3、一旦有报错，框架层是否可以捕获并输出足够清晰的日志等信息，便于使用者基于日志就可以定位并解决问题？

接口自动化：
1、一般接口自动化的特点是数量多，如果每一个都得写不少代码的话，编写维护成本会相对高。针对这块是否有评估过一个接口用例按现在框架写，大概要多久？
2、从这个截图看，有不少代码是为把报告输出到 allure 服务的。不确定这部分是不是用例，如果是，可以考虑下把这部分由框架直接代劳，而不用每个用例自己写？
3、类似 UI 自动化，接口自动化也有流程型的用例的，通过调用多个接口形成一个流程进行测试。不知道是否有考虑过脚本如何分层，让流程型用例和单接口用例，都能尽量复用一些公共代码，降低编写成本？
4、接口测试很多时候会需要测试多个环境，从脚本看像是从一个全局配置文件里直接获取 url 的，建议框架可以提供多环境分开配置的能力（类似 spring 里面可以分别为 dev 和 prod 设定不同的配置项对应值）。

除了图，是否也可以分享下一些关键技术点或者设计思路？

不是瞧不起，无意引战。

postman 本身是很好的接口测试工具，日常的接口调试或者简单测试，我也喜欢用 postman 。上手比 jmeter 还要简单（不用管什么线程组、sample 这堆术语），当然对应的灵活性扩展性等也会比 jmeter 稍微差一些。

我这里举这个例子，只是想说明有很多团队对于接口测试工具的需求其实并不那么复杂，类似 postman 这样的灵活性弱一些但简单好用的工具，也可以很好满足。

Jmeter 用的人多，个人觉得主要还是因为它可以做接口 + 性能测试，对于新人来说，学一个工具可以做 2 个事情，肯定会比要学 2 个工具有吸引力。况且国内 Jmeter 有大量文档可以参考，这对于新手自学也可以起到很大帮助。

Jmeter 我觉得核心的硬伤主要是团队协作，以及脚本封装复用。大部分公司做接口测试规模并不大，团队协作需求相对不那么强，脚本也不算很复杂，没有太多需要相互复用的地方，所以也可以大概理解。甚至其实还有不少团队在用 postman 做接口测试呢。团队协作需求强的，一般都会上平台，光靠工具很难解决。

至于 "问题定位" 这块，其实实际使用并没有这样的问题。jmeter 配合 ant 插件，可以输出包含类似 result tree 内容在内的报告，方便查看请求参数和失败的返回值内容的。

以前 deviceName 这个配置项，名字就叫 deviceName 。刚查了下官网 https://appium.io/docs/en/writing-running-appium/caps/index.html ，名字好像没变。

楼主是在哪个资料看到名字叫 appium:deviceName 这个的？

如果是服务端，可以直接借助拨测工具进行测试，包括直接写个脚本让当地人跑，或者直接用商业/免费的拨测工具。

如果是客户端，可以考虑用海外云真机。

另外，海外连接服务的延迟情况，和机房位置也有很大关系。机房选址的时候，建议做一些网络速度联通情况的测试，避免后面再迁移机房那么痛苦。

看了下，基本原理上应该还是离不开要单独有个进程/线程去接收 ws 的推送消息的了。

至于用例怎么去校验推送过来的信息，建议可以搞个 queue（队列）。接受 ws 推送的进程，把收到的消息记录到 queue 中，包含消息内容 + 收到的时间戳。然后封装一个断言函数，里面判断在什么时间段内，应该收到什么样的消息，接着就到这个 queue 里面检查有没有符合条件的数据。用例通过这个断言函数就可以进行判定了。

移动网络的弱网（如强制降低到 2g 模式），可能会存在并发 tcp 连接数受限的情况，导致本身可以一次性并发的请求变成小批量串行。

这块好像一般的网络模拟软件模拟不到。

另外，你是在哪个文章看到，可以发下地址，大家一起看看，判断一下？

哈哈，后面你也可以来分享下你的成长经历~

人比人容易逼死人。

说句不好听的，楼主现在应该就是挑战太少，公司工作上需要做的事情都已经游刃有余，所以才会觉得焦虑。如果是忙到飞起，或者工作上的事情已经要绞尽脑汁解决，一般都不会太焦虑这个。

建议楼主可以遵循自己的梦，先不要一下子给自己太大压力，给自己放个小假，放松一下。然后再逐步想下自己后续想怎么进一步发展，3 年后的自己想成为一个怎样的人，给自己定个明确的目标（比如要进 xx 大厂，或者达到 Px 级别的水平），然后专注地去达成它。

也推荐读一本书：《被讨厌的勇气》，能让你在被外界压得喘不过气的时候，意识到其实自己才是自己的掌控者。

这几天各种忙，周五终于早点下班了。我作为最近几届大会的议题主编，全程参与了议题的投递、审核过程，也在这里回复一下吧。

其实脉脉这个帖子，发出来当天社区小伙伴就有留意到了，只是考虑到脉脉匿名区本身的调性，去回复澄清也没啥意义，就没有太去管。后面看到有小伙伴也在社区匿名发帖了，说明社区小伙伴也比较关注这个，也借这个机会回复一下。

关于 “落地不靠谱”

落地这个问题，其实从前几届我们就有开始关注。有很多时候大厂创新性很强的东西，基本都是基于内部已经比较完善的基础设施来做的，确实落地成本对大部分公司来说都比较高。

针对这个问题，我们核心做了两个事情：

1、在议题评审标准中，除了创新性，也增大了可落地性比较不错的议题的比重。大家有留意的话，会发现最近几年中小厂议题数量是在增加的，里面也有不少基于开源项目二次开发而来的实践分享，落地成本相对低。
2、持续开展开源场，并邀请优秀的开源项目来分享。开源项目的东西基本大家都是拿回去可以直接用的（当然怎么用这个还得靠大家），落地性也会比其他只能听思路的强。

但诚如楼上其它同学所言，很多议题背后的实践能落地，其实都是和所在公司、业务、团队息息相关的。很多创新性比较强的实践，背后基本是一个团队持续投入半年以上时间才能得到。如果想着参加后 3 个月左右就能落地出类似成果，实在太难。更建议大家取其精华，选其中 1-2 个适合自己的所在业务和团队的，尝试实践落地，其他的，加入到自己的知识库中，和团队同学分享就好。

关于议题质量

议题的质量是大会的核心，所以我们一直都不敢懈怠。

我们组建了大会的技术委员会，邀请了 30 多位业内有丰富经验的同行加入。然后针对每个发过来的议题材料，大会的技术委员会都有做严格评审，并反馈修改意见，大部分最终能上大会的讲师，ppt 都改过 1 遍 2 遍，甚至 3 遍以上。此外也专门邀请了曾在 QCon 做过不少分享的资深讲师，给讲师们做怎么做好技术分享的培训，让大家能在大会上收获更多。

至于说像述职报告，其实我们评审中也有发现，最近几届大会收集到的议题 ppt，初稿中有不少是类似风格，像是内部 ppt 直接拿出来用。针对这类问题，我们也一直在和讲师沟通优化，不断调优 ppt，尽可能保障内容有干货、能闭环，大家听完能有所收获和获得启发。

关于大会规模

今年确实是有点失策了。原想着借助双十之际，能好好让大家聚一聚，而且前期征集收到的议题投递也比较多，所以想着保持 2 天规模。没想到上半年上海疫情严重，然后深圳最近也不稳，只能无奈延期。

至于线上分享，社区其实现在也有在陆续做线上的沙龙分享。但我们也发现，大部分讲师其实还是更希望能做线下分享，和观众能有更好的互动，所以我们今年还是坚持要办一次线下的大会（其实规模已经不大了，大概 800 人左右）

楼上大家提的减小规模、改为线上，都是非常好的建议，后面我们会结合这些意见持续优化。

关于大会未来

15 年第一届大会的时候，社区大伙都是凭着一腔热血把大会从零到一办起来。开始不易，但坚持更难。随着行业技术逐步成熟，目前基本上已经没有什么特别新的完全创新的技术出现了。相信很多楼上的同学反馈 18 年后新东西减少，应该也主要是这个原因。实际不是大会新东西少了，而是整个行业新东西都少了。

但个人觉得，这个 “少了” 并不代表就到天花板了，只是那种非常眼前一亮且通用性比较强的东西减少了。现在其实还是持续有很多新东西的。服务端领域服务网格，客户端领域类似 flutter 的跨端开发技术，都在持续出现，并持续提高研发的效率。而对应质量保障手段是否能同步提升，避免 “拖后腿”，将是未来大家面临的重大挑战。

从我个人来说，还是很希望能继续坚持办大会，让行业里面各种优秀的实践能有一个平台进行扩散，大家也能有一个平台相互交流学习。当然，未来大会也会尝试扩展更多方向的议题加入，帮助大家获得更多启发和收获。

最后

感谢大家给大会提出的各种意见。我们无法取悦所有人，只能坚持自己所想所做，让更多人能获得收益，实现共赢。未来欢迎大家有好的实践，继续投递大会，如果对于大会有什么更好的想法，也欢迎在社区开贴提出。

从应用角度，这两个原理在实际应用上用得相对不多。AOP 可能在某些需要打点的场景会用到，IOC 基本上用到得比较少。

但对于面试这个场景来说，很多时候不只是看你现在已经掌握的东西，还会看你的未来潜力。看潜力的其中一种方式，就是看对相关知识的探究了解情况。只知道怎么用，和知道背后的原理，在潜力上会有明显的差别。

不过我个人角度，不大喜欢这类偏八股的知识，很多都只是看了别人的文章然后复述，实际上其实也不大懂。我一般更多会问他掌握的某项技能是怎么学的，从学习方式等行为角度，来评估潜力。

微信小程序的自动化测试框架，越来越完善了，赞！

这个问题有点太直接了吧。。。对于回帖人来说，是纯输出，没有收获，回帖兴趣会不高。

建议楼主可以先分享下自己的，抛砖引玉？

坚持分享文章，并且文章质量持续提升。

然后达到一定水平后，到沙龙/大会之类的做分享。

如果有一个不错的开源项目在手，并且持续经营维护，出名会更快。

上家公司有同学做了个自动生成数据库几乎全字段校验的功能，分享下思路，楼主看看有没有帮助？

背景：金融类业务，数据库需要校验的字段很多，手写效率太低，所以想自动生成。
手段：
增加录制/校验两种模式。录制模式时，把数据库查询到的数据统一存到用例对应的 csv 文件中；校验模式（默认）时，校验查询到的数据和 csv 文件是否一致。
由于有少量字段是无需校验的（比如时间相关的字段、某些自增的 id 字段），因此 csv 中提供了白名单机制，可以人工在里面配置需忽略校验的字段。
后期也优化为录制模式时每条用例会重复执行 2 次，并自动把两次执行不一致字段加入 csv 的白名单。

优点：
节省了很多数据库校验相关断言的编写成本
不足：
仅能校验等于，对于校验条件为不等于、某个范围内之类的，无法校验。（不过对于我们当时来说，已经够用了）

这个思路，理论上对于接口 response 也是适用的，只是可能存放格式要从 csv 改为别的格式（对象可能有多层，所以 csv 格式不一定适用）

这个和团队文化有关。

你有这个意识是挺不错的，如果实在施展不开且难以改变现状，可以考虑换到一些对这些方面更为重视，而非单纯按需求测试的团队里吧。

是的，对能力要求会比较高。

看代码其实不一定会很花时间，在了解整体技术方案的前提下，直接看分支间代码变更情况，有个半天基本能看完开发写了两三天的代码了。不过这个确实看团队文化，如果大家都不重视这个（比如开发可能连技术方案都不设计，就直接动手写代码，或者团队觉得测试不懂技术，技术方案不会给测试看），那基本是不会给你时间做这个事情的。

最后代码能力很强的，是否会在一线，这个我觉得还是会有的吧。毕竟一线也有分初中高级别，到了高级甚至资深，这个能力应该是会有的。