要看公司的情况，权衡自研还是采购
1、katalon 开始收费，价格还不便宜，并且相较于其他商用工具优势没那么明显
2、有没有自研能力，自研出来的框架/工具能发达到预期

问题 1：大概是这么个过程：

问题 2：
接口自动化框架，支持数据库断言是必要的，与环境无关

问题 1：可以考虑将所有 response 存储一下，用的时候使用jsonpath获取一下
问题 2：数据库查询时传入参数（类似于问题 1 使用 jsonpath 方式获取到的 id）
问题 3：建议将用例和测试结果解耦，Excel 只用来维护用例，测试报告使用 allure 插件；
用例和报告解耦有几个好处：
1、用例多了后 Excel 会非常庞大，写数据比较慢还可能造成文件损坏；
2、allure 内容详尽，样式美观，可以作为标准的测试报告进行输出。

可以多看看HttpRunner的实现方式，是非常优秀的
同样是在 0 到 1 的过程中，共同进步

试试 allure 动态生成功能：allure.dynamic.title(casename)

现在的问题是，会议组织者怕遗漏或者担责任，拉会议时不管是否想干的全都拉上，导致大家参会越来越多，效率确越来越差。

生成用例不难，难的是怎样拿到接口数据

面覆盖到了，深度呢？比如接口自动化平台，有没有自动生成用例的功能、代码覆盖率统计、接口覆盖率统计、覆盖率提升相关统计、精准化测试。。。

5 楼说的是一个值得关注的点，还有可能就是自动化执行期间，用户被被人登录了，造成自动化获取的 token 失效

并不存在统一的规范，还是要看项目的情况和接口使用的具体场景来确定题主说的问题是否需要修改
1、如果是产品形式，要交给客户方使用和维护，某些问题就需要修改。
2、如果接口要提供给第三方调用，某些问题就需要修改。
3、如果接口只在此项目上使用，而且项目的规模不大，业务场景不负责，问题可以暂时不修改。
4、当然以上分析是要在跟团队沟通、向领导汇报前提下再确认的。

数据采集任务一般是根据系统需求，设置固定频率执行，测试单次采集任务的压力意义更大一点，主要考虑以下几点
1、单次采集数据量较大，采集服务处理速度与准确性
2、采集过程中数据异常、服务异常、三方接口异常情况的处理
3、采集服务数据库读写情况
4、了解三方接口返回数据的逻辑、限制 (频率、数据量等)、完整性

1、目前国内测试行业的发展程度来看，业务和技术能力共存的概率很小，而且技术是服务于业务的。
2、从公司领导的角度来看，业务显然是高于技术的，所以在资源方面会倾向于业务型人员。
3、想做好技术的，不能单纯只提高技术，而是要结合项目，结合测试工作整体提高。

第一天打卡

请问楼主，前端框架是自己写的吗，想要借鉴下前端构建的思路

脚本距离框架还有很长的路要走，要想做一个团队都能用的框架，至少要解决几个问题：1
1、用例去脚本化，比如 Excel、json 维护用例
2、入参数据解决，比如数据库依赖、接口依赖
3、断言问题与问题 2 类似
4、登录、加解密、验证码等项目非通用性问题
5、报告输出，不能光有简单的执行结果，还要统计接口数、覆盖率等更丰富的数据展示维度
共勉

楼上总结的很充分了，我说下自己的个人体会：
1、千万不要试图越级反馈，把你需要表达的反馈给直属领导，数据和理由给出来，积极参与就行；
2、这不是一蹴而就的事情，可能涉及多轮次沟通还未见任何成效，要做好心理准备；
3、做好自己的事情，多沟通多记录，免得最后引火上身；

说句不中听的话，想要拿期望薪资，很难，学历是首要问题。
稍微大点的公司进不去，小公司给的也很有限。
建议打磨自己的技术，精专一两个方向，有机会提升学历。多找内推机会

主要是 baseurl，数据库配置、基础数据 (登录用户、产品信息等)，要实现可配置、参数化

可以尝试下 password 参数不传

1、对接接口文档，同步接口数据；
2、参数和接口分离，每次只需要改动参数即可；

我们团队目前的实现就是用的思路 2：Python+Pytest+Allure+Request+Excel
1、只需为每个项目创建一个 Excel 文件，维护测试用例即可，无需编码；
2、实现了案例读取、执行、断言、报告聚合、消息发送、用例自动生成等功能；
interfaceEx 接口自动化测试框架
欢迎交流

个人建议：不懂的要多问。当然不是遇到问题就问，而是要把不清楚的总结下来，先自己思考下，再统一找同事或者导师交流一下。这样既能防止因为项目/环境不熟悉造成漏测，也能在交流过程中形成自己的沉淀，认识不足。