技术都是为项目服务的，新技术更新对于底层架构的影响肯定是有，作为一名效能工具开发者，要结合业务需求、公司流程、现状等不断更新工具能力，抛出这个问题，是因为考虑到在长时间的演进中，需求能满足了，代码优化了，贴合业务实质了，那还有哪些地方可以提高呢？

感谢分享，几个问题都补充了我之前对方案梳理的欠缺，特别是结尾的这句话，也是一个值得深入的问题。

不管是测试还是开发，终究都是项目 + 技术维度的复盘和演进，沟通、协调、项目流程、质量体系固然也重要，但在这里我们讨论的主题已经框定了技术的范围。

今天去看了一下，这个平台做的挺好的，值得借鉴，再根据实际公司项目，贴合实际需求进行构建

看似和我的想法比较像，可以具体说说

只有上海有坑吗?

这个问题实际上指的就是怎么测试加密接口.

1. 找开发要加密方式，你把参数加密后再调接口
2. 让开发暂时取消加密，或者类似的处理

按我的理解，fixture 就是面向 testcase 的一个功能，底层决定了。
要实现你的需求，在非 testcase 模块或方法中自动调用，除非改源码 (一般不这么做，也很难)，否则就得换思路。
你的需求描述不够详细，比如你可以把 host 方法写到一个自定义类中，然后添加一个动态调用的逻辑，在需要调用的时候去调用，不知道是否能帮到你

你说的写接口，指的是使用 python 代码发送接口请求吧。
requests 是基础框架，要实现自动化，就要学会自己封装，封装无非就是不断抽离的过程。
我有一套接口自动化的框架，自己基于项目写的，excel 做数据驱动，也是比较常见的一种方式，可以一起讨论。

现在基本上就大厂能给到 15K 以上，其他的看都不能看，后悔去年没跳出来了，现在的架势看只能等明年了

你现在情况可观的话，建议不要回，除非不差钱，行情真的很稀烂

这个还真没保存

我工作十年

我的理解：
你要获取商品库存，首先数据库要有商品，不管是涉及 1 张表还是 2 张表，这是必备条件。
一般是 2 张表的方式，比如:
A 表字段：商品 ID，商品名称
B 表字段：商品 ID，库存数量
所以要确定的是

1. A 表中的所有商品 ID，在 B 表中得有，哪怕库存数量为 0，这是前提条件
2. 并且这个前提条件的实现方式，一定是测试前造数据，或执行用例时动态造，有这两种方式来完成

那么操作步骤，一定是先查询，或先创建再查询，意味着你可以查到一个商品 ID 的集合，比如查前 10 条
然后构建一个随机选择的方式，得到某个商品，最终，你就可以调接口看返回值了。

1. 只有后端人员写测试用例？你们那没测试么？实在不行就用关键字框架，以 excel 的形式驱动啊，测试人员不懂代码 excel 总会写吧
2. 没有成熟的自动化用例？自动化用例都是从功能转化的，难道你们不做功能测试？
3. 自动化测试难道不是在测试阶段进行的？手工都测完了还去跑自动化有什么意义？
4. 异常，按你的描述，猜想是页面的切换导致的问题，比如说渲染过程中异常，加载过程中异常，在框架里加入异常报告截图啊，多分析一下就能找到具体原因了。

至于有没有必要做，看能不能提高能效，减少错误率啊，总之就是一点，不要为了做自动化而做，而是为了降低时间成本，减少错误率去做