从保护自身的角度，需要提 bug 或风险作为记录， 且尝试进行复现和开发确认沟通

因为只要有度量且考核，数据一定能做出来，这种完全失真，只剩下卷

个人觉得没啥讲究，这两种都行，"超级大列表"这种担忧不存在，测试用例能有多少，不行还能分库分表呢

早几年和朋友讨论过这种类似的问题，当时没有想到可行的方案，现在能看到一篇能实际落地的方案，厉害

postman 可能会自动填充一些 header 的参数，可以抓两次请求的报文详细比对一下

封装这块也不是很了解的话，框架本身其实没法很好解决，还是需要多写代码，要有思路，看看大佬的代码实例，学会总结，可以反思自己之前写过的代码能怎么改良，可以练练手

遇到过加解密方法有问题导致内存泄露的，建议还是尽量真实模拟加解密做压测

先说个最简单的做法， 手工测试怎么改的数据，可以用代码实现，加在用例 setup 阶段，如果要减少自动化数据的影响，可以再 teardown 阶段做一下清理和恢复

保持良好的心态很重要

1、存量商品可以写死一个之前已有的商品（如果怕被人误删或者误改，可以写个方法每次执行前插入 or 更新数据库的对应数据）
2、新增商品接口，获取新增的商品
建议以上都考虑实现，因为分别覆盖的是存量和新入库商品的场景，都需要测试覆盖

针对项目进度落后这件事， 之前考 PMP 的时候，有说这几种情况的处理方法：1、项目的计划变更；2、快速跟进（把串行的事变成并行，比如分批提交测试使测试时间与部分开发时间并行）；3、赶工（所谓的追加资源，比如加人力或者加班）；4、重新谈判（这点个人觉得主要是对接外部或者跨组织项目时进行安抚和谈判，这种做法本质上是将延期的风险转嫁给了他方）

目前的形式来看，外包也是一个选择了，而且个人觉得只要有能力，不存在 35 限制和外包歧视

领导要的我理解更多的是切实有效的措施，可以规避后续同类问题的出现，甚至举一反三发现更多可能暴露问题的点和改善措施

用 flask 是起一个服务使造数功能以 http 接口形式输出？如果是这样的话，在 flask 上这些 “造数脚本”，可以在测试平台配置页面或者直接跳转支持调用就行了