加上流量录制跟契约测试。其实把自动化测试搞好就不错了，搞这些潮流的只有有钱又有闲的公司才能搞。

测试平台解决不了你这些问题。从流程，工具，人员三方面来看，在流程层面可以制定一些用例编写与维护公约；工具层面做数据汇总展示，可以把执行数据存入数据库，用 metabase 来展示，这个不需要太多的开发量；人员层面搞一些自动化相关的知识培训，提升团队的自动化测试能力。技术不是解决问题的唯一途径。

像这种场景我是在项目里面挂载 python 工程，通过映射关系动态加载自定义关键字跟方法

看过，跟自己的工作相互映证，不能说完全一样，还是有些参考意义的

可以尝试通过 allure 的 feature story title 标记去合并

我觉得关于业务数据不能插库的很好理解，比如你要生成一笔支付数据，直接插入数据库，如果有多表关联、缓存或者消息队列的逻辑，一旦写漏了容易产生脏数据，还比较费时，所以直接调用接口是最省事的，也最符合系统行为；关于 ‘接口测试之间不应该相互依赖’ 这点，我觉得应该是 ‘接口测试用例之间不应该相互依赖’，有要重复使用的需要封装成方法或者关键字。

目前项目分为两块了，驱动层跟用例层。
驱动层的已经基本完成了，整合了 android 跟 ios，用脚本写了几条登录退出的用例。
用例层的话还在试用，我们的用例是在 web 平台上编写的，最近在推 app 元素定位规范，这个搞定了才会投入使用。

ok，多谢指点

这个代价太大了，那我还不如卸载再重新安装呢

问几个问题啊：
1、契约文件谁来编写维护？
2、契约校验生产者的时候，调试数据有前置依赖的怎么处理？比如针对查询订单的契约，生产者需要自己调试，但是没有对应的订单数据。

意思是一个人当两个人用？

现在求职都能这样玩么？

同感，看着自己以前写的代码跟屎一样

专门准备一套自动化测试账号，跟手工测试分开

老哥加油

我觉得没必要整合到一起，requests 跟 selenium 和 appium 数据是有差异的，整合到一起肯定很难看；我目前的做法是封装一层业务方法，方法中的步骤执行去调用 requests，selenium 和 appium，框架只是提供一个基础能力

metabase 了解下，基本配置下 sql 就可以展示图表

在 excel 里面加个标签，读取用例数据的时候根据标签过滤。比如在 sheet 名称后边加个后缀，或者 sheet 表格里面加一列是否跳过标识，具有这样标识的都跳过。

接口自动化测试不是为了发现问题，是为了验证已覆盖的场景是否 ok，发现 bug 只是额外的产出，要把接口自动化持续运行起来才会产生价值

研究过，还没落地，契约测试本身难度不高，更多的是流程规范问题，谁来维护这个契约，什么时候使用

ok，我试下

cv 对比图像不靠谱吧，要是页面内容变了不就挂了

早点跑路吧，看你这描述太吓人了，团队工作氛围也不行，真的没啥搞头

目前来看，我觉得固定业务流程的自动化脚本 + 探索性自动化测试的模式更好一点，case 自动生成还是需要人维护

这是从国外翻译回来的吧，条条框框太多了。我觉得问问题的要点是提问之前要先思考下，最好能先尝试自己解决下。