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

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

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

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

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

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

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

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

保持良好的心态很重要

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