压测指标应该都能搜到，应该主要考虑的是压测的依据，模型，环境，压测脚本的准备，比较综合的内容

整个流程在，通过请求数据数据， 压测日志有定期归档，消息会屏蔽。考虑生产压测与真实用户场景使用要保持一致。单独的压测环境，应该是单节点的，只能压测场景单一的场景

表达的意思:，发布及构建自动化，需要集成到流水线上

谢谢回帖， 后续有点实践成果、会及时分享

好的

“然后你这两个部分，感觉相比前面的 12 个步骤，会不会有点过了？。需求质量、代码质量在你抽象后都没了，这个我理解应该是你标题说到的 测试过程左移 的核心之一。” --这个话题想表达，站在 2/8 原则的角度，测试应聚焦自己的专业能力，然后又遐想了一下 。左移的目标，其实就是将测试手中的工作释放，团队对质量负责，杜绝保姆式工作，12 个步骤具体做哪些事情，是质量体系建设的工作、后续可以再总结下

1、TCDD: 测试用例驱动开发，但对测试要求比较高，也是老大力推的一个概念。百度不出来这个关键字；
2、抽象出三部分，前两部分是测试重点关注的；这块笔误。
3、抽象成 3 部分 - 其实从需求评审到发布上线， 在敏捷开发过程中，其实考验的是测试的基本功和测试脚本转换能力，划分的 12 个部分，只是我们象征性要参与这么多事情。本质上，测试需要贡献的价值： 质量和效率.....，这块跨的步子有点大，后面把思路拆小点。??

对的事情，坚持去打磨，万一老板发现你这个良好实践呢