一、大家在找工作面试时候，不要只准备一封简历，特别是简历中项目的介绍，为什么这么讲呢？1、假如你之前参与的项目本身没有太复杂的业务，面试官要你介绍项目时候，会像楼主一样，因为项目介绍容易让面试官觉得你对业务不熟悉；2、你之前参与过的项目所属行业 和面试的公司业务毫不相干，比方说你面试的公司是搞电商的，你简历上面项目是游戏，大多数结果就是没有相关行业业务经验。面对这种情况，大家在收到面试通知时候，可以把面试时间约的迟 1 到 2 天，一来显得自己手上有好几个面试资源，二来有个 1 天时间可以去找下面试公司相关的市场产品试用，临时编个项目，当然面试约的时间不能太久，不然显得不够重视。
二、面试测试开发岗位，特别是大厂这种，很看重算法 设计模式 分布式 并发处理 底层原理 开发语言细节，比如 匿名函数 ==和 equals 区别 切片 构造函数 等等

当你将 @pytest.fixture 的 scope 设置为 "session" 时，意味着这个 fixture 将在整个测试会话期间只初始化一次。这意味着无论你运行多少个测试类或测试函数，driver fixture 只会在第一次需要它的时候被调用，并且它的状态会被保留直到整个测试会话结束。
而当你把 scope 设置为 "class" 时，fixture 每当遇到一个新的测试类时就会重新初始化一次。也就是说，对于每个测试类，都会创建一个新的 driver 实例。
在你的例子中，device_name marker 是通过 request.node.get_closest_marker("device_name") 获取的。request.node 在不同的 scope 下代表不同的对象：
当 scope="session" 时，request.node 指的是整个测试会话的根节点。
当 scope="class" 时，request.node 指的是当前的测试类。
因此，如果你使用 scope="session"，那么在 driver fixture 被首次调用时，它实际上是在尝试从整个测试会话的根节点获取 device_name marker。然而，device_name marker 是在具体的测试类（TestLogin）上定义的，所以根节点上并不存在这个 marker，这就是为什么你会看到它是空的。

1、刚开始实习那年，做 HIS 软件实施工程师，就是医院、社区社康那种门诊软件，有次去一个连锁社康做实施，人家对方信息部人好不容易组织他们药房几天整理出来的药品信息，被我部署调试时候一下子干没了，当时对方和我们这边都没有那么规范，也没有备份，结果导致人家药剂师天天加班整理数据，还上报上去了，后面被老板骂，每次去那个社康药房主任都瞪眼，实习时候带我的师傅也被牵扯；
2、刚入职新公司半年，对业务细节还是不是很熟悉的那种，由于某个 BUG 导致库存扣减数量少扣减了，这个 BUG 并且不是第一时间发现的，而是运行了半年左右才反馈，后面导致修复历史数据用了 1 年的时间长把库存平掉

插件自带

你这个技能软/硬件都会，还会写代码并且前后端都会，30K 妥妥的没有问题，我们公司纯功能测试都有 22K

1、UI 自动化把每个操作步骤后界面截图保存存放，然后人工只用切换图片查看图片上信息即可，省去了人工操作 APP 的成本；
2、按照恒温方式，结合 chatGPT 搞，但是准确率就不敢保证了

前端点击某个按钮提交请求，F12 看接口一直没有响应，这个通过查日志是可以找到问题的，但是你说开发查日志查不出结果就尴尬了：
1、你们是微服务吗？如果是微服务，这个流程可能涉及多个服务调用，有没有可能是日志排查方向错了；
2、接口没有响应多半是接口代码报错，比如空指针，项目日志打印级别调整一下，再不行 log.info 隔几行打印一次；
3、接口没有响应还有种可能就是，代码不报错，但是这个操作涉及大量的数据导致一直在处理，或者数据库表出现死锁；
4、项目方面没有问题，那就是服务器资源问题了；
这种问题可以针对出现未响应按钮接口，用 jmeter 压测，这个压测不要一上来就大批量，可以呈阶梯式增加，一定会在某个阈值出现这个问题的

讯飞的这篇文章可能会给你提供思路

1、整个测试团队除了产品了解整个项目流程，就只有测试了，平时工作中不能埋头工作，还要利用点时间学习需求分析、市场调研、竞品分析怎么弄，学会 Axure 原型工具的使用，所以测试转产品也是一个很好的备选。产品我个人觉得只要你对这个系统的规划和把控能力强，比测试吃香。我们部门刚招的一个产品 82 年的，早就过了 35 岁的坎；
2、在平时项目开发过程中，其实测试对项目进度起着关键的作用，稍微上进心能力强点，性格开放点的，我觉得考个 PMP 转 PMO 岗位也是很不错的，我们部门招的 PMO 岗位 79 年的

如果你有驾照，驾驶经验还可以，可以搞代驾；
如果你有驾照还有车，可以跑滴滴；
如果你既没有驾照又没有车，但是有个小电驴，可以跑外卖；
如果你既没有驾照又没有车还没有小电驴，但是有个手艺啃吃苦可以摆摊；
如果你既没有驾照又没有车还没有小电驴还没有手艺，但是你有好的脸蛋和身材，可以搞短视频搞流量；
如果你既没有驾照又没有车还没有小电驴还没有手艺还没有好的身材和脸蛋还又不肯吃苦，但是你有个局长老爸，可以躺平；
如果你既没有驾照又没有车还没有小电驴还没有手艺还没有好的身材和脸蛋还又不肯吃苦还不能啃老，那就提前回家养老，种点小菜园自给自足，记住千万不要提前过渡消费！

我们目前还是操作本地编写用例，导入系统。最终的目标就是方便领导，就是领导想看测试组某段时间归档了什么用例，进入系统看就可以了；再就是测试组做做月度统计时候，提供了一些数据支撑

左右结构，左侧选择项目系统，在左侧按照系统功能模块建立分级，可以细分到按钮，鼠标几点左侧点击，在右侧操作用例，这样用例和模块、用例都绑定了

1、目前在使用过程中，一个用例经历了长达 3 年的版本迭代更新，用例分支很多，采用一次性加载，导致每次打开有点慢，不知道针对这个问题大佬是怎么处理的呢？

为了减缓这个问题，我在点开用例脑图详情时候，增加了一个弹窗，并且给出按照用例 或者按照节点，如果是按照用例则展示整个用例的脑图，可能用例内容多会慢，但是给出了提示语，让用户有个心理预期；按照节点就是，我们用例第三级别基本都是功能点，你可以选择只打开，某个功能点的用例脑图，这样就减少脑图数据的展示了；

2、目前我们没有实现在线协同的功能，最理想的情况是我希望能实现腾讯文档那种在线协同编辑的功能，但是人家鹅厂一个团队弄的事情，我们一个小小的测试开发投入成本相当大，并且很多技术问题不能得到保证，比如突然服务挂了 断电了用例编写的是否能自动保存，总不能测试人员辛苦写的用例就因为你系统的问题，

技术很强，30K 么得问题，不像我 30 岁了还只会点点点

往往这种人更难相处，估计也是个小组长之类的，这种平时工作中就很难相处了

那位已经注销账号的 “面试官” 说了一堆，无非就是两个方面：1、用例设计的粒度问题，就是我们在设计用例时候要能把握好这个粒度，这个粒度是能够可以执行或者评估的，不能够直接说检查某个功能是否正常，要细分到具体的正常元素；2、我们点工通常是针对界面去操作和设计用例，比如说一个输入框的校验，可能前端校验了，后端接口没有校验，这种情况如果我绕开前端直接通过接口调用可以规避这个限制，针对前后端校验的问题，如果条件允许情况下可以单独使用 postman 等工具调用后端接口，不过这个比较花费时间，我平时都是直接拉去项目代码找到这个调用的接口的 controller，看下代码中有没有这种校验逻辑，一般来讲这种校验逻辑放在最开头的地方实现，可以把利用 AI 工具 输入需求进行检查，这样甚至还可以发现这个接口的一些隐藏的 BUG
最后我还想补充一点： 前面说的 1 和 2 是针对功能界面 和接口，其实还有就是最好在测试的过程中，跑完一条流程，去看下这个功能涉及到表的数据存储记录是否正常，表设计是否合理。我就遇到过 BUG，就是表的主键 id int 类型长度设置的比较短，然后这个业务量又是巨量增长的，随着时间推移以后这个主键 id 一定会超过限制报错，后面提了 BUG 改数据类型
最后还想再补充一点，论坛是个交流的地方，大家都是相互学习，论坛里面有大佬也有小白，也许你的经历很丰富，你觉得人家回答的不好，你补充就行了，不想回答绕过就可以了，没有必要去诋毁，真的是没有必要。

只能说羡慕 20+，做梦都不敢想

如果有冲突还是还要找开发

要的就是这种效果

是的

你写到的是追踪到了代码有抛异常，还有一种 BUG 是业务流程上的 BUG，就是代码没有报错，但是某一个数据的处理逻辑有问题，比如有个地方原本需求是 A B 两个字段相加，结果开发是 B C 两个字段相加，导致计算结果出错，这种能追踪到吗？

可以借助精准测试，看看哪些模块的代码有改动，重点回归改动的功能模块 和 使用到这些改动模块的流程；如果这个达不到的话，只能增加人力 + 请外包

如果公司能混到养老就继续混，前提是公司不管什么岗位的氛围都还可以，但是如果说整个公司的文化不行，你对你现在的岗位不喜欢，你就算转岗还是坑

1、我点小疑问，站在测试的角度什么情况下需要去在 nginx 层面实施 mock？比如现在提测了某个功能，这个功能前端操作后会调用 A 服务，A 服务会和 B 服务的某个接口获取拿数据然后处理后返回给前端，如果此时说因为 B 服务没有开发完，需要测试去 mockB 服务的接口给前端，此时流程就基本没有跑通，就是算你现在使用 mock 数据把当前流程验证完了，等 B 服务开发完成了，最后你还是要重新把全部流程跑一边，浪费时间；
2、从项目管理风险角度讲，在人力资源充足的情况下，遇到 1 中的情况，测试提早介入能提前发现问题，这个是好事情。这种情况我通常是把项目代码拉到本地，在本地运行进行白盒走查，构造前端 API 请求然后再本地惊醒 debug 断点，本地断点的话你想要什么模拟数据可以设置，最后检查 API 返回的数据；
写在最后： 目前还没有搞过在 nginx 层面实施 mock 1、还不如直接点点点 2、浸入式的东西不能把控有什么风险，项目经理也不会同意你这么搞
如果后续研究到好的方案，请大佬分享一下，谢谢

有些厂试用期 6 个月