没经验、没有相关技术强人带、没算力，还是老老实实调 API 吧

以业务为锚，辅以代码走查进行评估。
另外回归测试吧，不存在无意义，至少证明某种场景是成功的。

为啥靠前 30cm 呀，前面凸出来咋整。。。你要是停个迈巴赫或者尊界这种长车，不得把路挡完~~

L034 能入绝对第一选择，独立车位谁用谁爽。
其他就 35 36 77 76 吧

让开发把测试环境调用拍照的方法改成读取指定的照片

兄弟，你 ID 暴露了公司，你是真不怕 charles 给公司发律师函呀

别焦虑，死亡的方式很多种，食品安全是其中起效最慢并且可以避免的一种，健康过好每一天比担心十年之后好。

1. 测试要对整个产品的质量负责，而不是针对某一个需求（甚至是未经评审的需求）。
2. 做好需求评审，避免出现没在需求内的功能点。
3. 做好和产品、开发的沟通工作。

多打几个日志就看出来了吧。

不过像这种查询没出过问题，提交数据有问题来看，可以考虑以下几个方面：

1. 存数据库的逻辑是不是有硬伤，未处理的异常、死锁、死循环啥的
2. 量，是不是写入量太大了，导致服务器或者数据库资源瓶颈
3. 其实和 2 也差不多，一个从客户端考虑，一个从服务端考虑。不响应时看下服务端负载
4. 浏览器（或者前端软件）本身兼容性或者其他问题

仅供参考。。。

以现在的国际形势，不考虑生命安全的话，雇佣军很缺人。

你年测 300 万行代码，年看 300 万字的小说，年产生 3000 万的价值，为 3W 亿的负债贡献过，世界因你更加和平。

没发现 BUG 或者发现的少，正常的老板也会认为有价值的。但是 BUG 少=你价值低，这一座大山是所有非测试人员的共识。

只要自己觉得合适，你用 txt 管理都行

偶尔借出->频繁借出->组织重新划分,合并到项目组->测试边缘化

友情提示，fiddler 自己学倒是没啥，公司或者企业使用有可能被发律师函~

供参考哈，仅个人思路。

1. 先明确业务问题

下架报异常导致的下架失败，是真失败还是假失败，这条数据还展示的 c 端商品列表，是应该展示，还是不应该展示。

如果下架接口报异常，但是实际是成功的，比如数据库状态发生变更等，理论上 c 端商品列表不应该展示，那就结合代码或者开发人员去定位问题，此时应该要去定位三个问题，a.下架接口报异常的问题 b.下架接口报异常，但是却成功下架的问题 c.下架接口报异常，但是成功下架，C 端商品列表还展示的问题

如果下架接口报异常，实际也是失败的，这条数据应该展示在 c 端商品列表，那么就需要看下架接口为什么报异常。是环境问题还是需要定位的缺陷

1. 再回到自动化测试本身

从得到的信息看，是接口自动化测试，那么以上场景应该划分到下架接口，还是展示的 c 端商品列表接口（比如下架失败，展示商品列表接口的用例），应该有明确的规范，避免用例重复覆盖。

另外，这条用例失败后，会不会影响自动化测试稳定性，自动化到这里就不再执行了，还是说就是普通的一个用例失败，也是需要考虑的。

自动化测试用例，很多时候因为各种原因，不会覆盖异常、失败的场景，此时是否需要把这些场景支持或者用手工测试覆盖，也是需要考虑的。

研也匆匆 测也匆匆 恨不能想疯
改也匆匆 上也匆匆 一切都随风
狂测一轮 延期一轮 快上一轮
背锅一轮 谁与我生死与共

有，如果看不了代码，会给工作增加很多困扰和不确定性

窮

只要不被裁，蒙着眼走

一杯茶的功夫，你就被优化了

没管理者乱来谁愿意搞这些鬼名堂

有目标有行动的苟着

最大的作用是代替了以前需要查的工具书。

AI agent 基本都长这样