没恶意，只是 Monaco 的功能还是比较丰富的，可能不是所有场景都能把它替换掉。

虽然问 gpt 还挺有意思的，但是换了个工具也叫优化嘛

比如订单号，首先你这个订单号要在数据库里面存在，然后我可能通过这个订单号查询到商品信息，然后我还要对商品信息做校验，不同的商品信息有不同的逻辑，那我是需要先要造商品，再造订单，再用造出来的订单号作为造数工厂的数据吗？拿感觉和我自己写个前置接口的方式也没区别吧。

请问这个造数工厂之所以实现逻辑能打通，是不是基于【现在很多微服务基于 DDD，后端开发各自专注于自己的领域中，对依赖服务的内部逻辑和数据结果并不关注，只关注交互接口提供的数据结构和含义。】这句话的呢？如果对数据有校验的场景造数工厂就无法使用了。

也不是不行，你要先解决一个问题，在页面还没开发之前，你人是怎么思考的，你准备如何着手 UI 测试，这里说的不是自动化，仅是 UI 测试。如果你本身都不知道怎么做，何谈自动化。
如果是做准备的话可以根据 UX 和需求文档把大致逻辑捋顺，mock 一些 xpth，后续再对接上真实的。

异步的呗，获取的时候还没被渲染上 dom

哪个岗位不卷，都卷，只是换个方式卷，一样累。

完全不够

这回答也太 GPT 了。。。。

我是这么觉得的，只写亮点的工作当然是非常好的，但是需要满足一些前提。
1、确定这些亮点是对方公司所需要的
2、对于自己的职业有非常明确且坚定的规划，除了亮点工作外都不做。
我觉得做到这两点是非常需要勇气的，或者说不是所有的测试人员都有实力能够做到。大部分的测试人员还是希望能告诉公司方自己涉猎的广度，在广度中找到匹配公司需求的能力，从而入职。
如果说您只做侧开，或者只做侧开中的某一项具体实现，并且非常精通，那么我佩服你。但是你也需要承担分公司对你技能应用不匹配的风险了。

大部分的 Java 项目，你不学设计模式是看不懂的。
最多只能看看 controller 里面的业务代码，其实本质上只是条件控制，意义不大。
特别像 Java 这种，使用面向对象已经近乎癫狂的语言，想要提升就只能自己动手实践。

我怀疑你老板在洗

根本说的不是同一个问题，频繁提交代码修复 bug 反应出来的是一个程序员本身的素质问题，和你是不是想最小范围 merge 代码是两件事情。
1、这个人没有做单元测试的习惯，在一个没有审核 merge 的 git 环境下对其他人简直是灾难。
2、体现了你代码结构有本质的问题，你的代码更加难以阅读，流程控制更加难以理解，问题更加难以发现，以至于你自己都不能清晰的发现代码本质问题在哪里。所以才会出现频繁提交代码的结果，如果一个结构清晰，命名明确，各个方面都良好的代码怎么会需要改这么多次？
3、再不然就是你自己本身就不理解代码在干什么，ctrl+c 了一段代码，真正跑起来才知道原来这里并不通用，然后就一直修改提交，修改提交，修改提交。

忽略标题先，只是觉得一个 createDeedReportForPlan 修改了 11 次，没有人抓 git 提交记录的吗？我们这里要是谁这么频繁的提交代码，他的代码绝对会被例会全组 review，是写的多烂啊。

我是用 koa+http-proxy-middleware 来实现的，异常方便和轻量。

asyncio 了解一下，网络通信用携程不要太爽，根本不用开线程。

pytest 在执行过程中会把每个 test 方法拆分到不同的实例 feature 里面去执行，所以每一个 test 方法中的 self 实例变量已经不是同一个了。这点真的很变态。我猜 pytest 应该是为了做参数注入、depends 依赖顺序而这样做的。反正，你现在书写的 pytest 类已经仅仅成为了一种格式化的书写规范了，self 也没有了上下文的功能了。

展开讲讲，搞得我以为之前业务组写的 3000 多条接口用例是我的幻觉。。。。

真的很烦面试官问这种问题，你回答的直接吧，说你浅显，你拿其中的一个点来回答吧，又基本不可能回答的全面。我就喜欢那种直接的问题，妈的上来直接写一个 spring 生命周期，直接要你写一个红黑树，死也知道是怎么死的。

从情感上来说，我这个过来人给你几点建议吧。
1、首先是要完全获得领导的认同，最起码是你的直接上级的认同，阐明这件事情是可行的，且能够给他带来好处。
2、在这为数不多的测试团队里面找到一两个能够和你合拍的同事，让他们能和你一起着手去做这件事，不然负面情绪会淹没你，而你没有任何的帮手。
3、积极、主动。还是积极、主动。这件事情的成败很大程度在你自己的推动，很大一部分时间内，都是你自己在闷头做。你有好的解决方案，一定要积极、主动的去提出来和落实。正常的领导不会拒绝一个主动性拉满的员工，他知道这件事情你做了不仅是为了团队，更加是为了自己，所以不会马虎。
4、可用性和交互非常重要。千万不要相信领导说的什么能用就行，可用性和交互不重要。你这个平台能不能推广出去很大程度就是同事喜不喜欢用，如果交互上难用，下场就是没人用，然后草草了事。

恩，设计上肯定有问题，但是问题始终不是很明确，是以我对 http 的理解上去做的。导致的问题就是他们在 postman 发送的请求和平台上发送的结果不一致。我是怀疑 postman 做了很多请求的优化工作，所以想是否能直接使用 postman 的库来做 Python 端的发送模块，这样只要在 postman 上面调试好了与平台就能够保持一致了。

在 selenium 里面用 js 的代码本来就是一件很曲线救国的事情，不管是延迟还是异常捕捉都很令人抓狂。。。

Linux 机器上没有显卡怎么办
还有截图的是啥游戏

我反倒觉得，自动化远远不是以自动化程序的方式去测试现有的接口，而是自动化所能解决的痛点。
自动化也不是局限于写接口自动化脚本。
对于现在的你或你们公司而言，能够通过 “自动化” 解决接口频繁变动带来的测试成本才是痛点，你能解决这个痛点才是价值。

坐标撒，屏幕宽高比例计算出坐标