能洞察质量、能效等问题，通过分析，制定并落地计划。 这个计划可能是大家常说的，自动化测试，工具开发等， 但这仅是包括，但不局限。

羡慕

研发侧也需要考虑， 怎么避免全删，要拦截这种操作。

https://www.yuque.com/testdevops/devops/wux7a6 看看

再说个， QA 不要出现低级错误， 例如用例写了没执行， 执行了没检查到位。 或者人家产品，研发都提醒你了，这个模块受影响， 自己没测到。 那就真 QA 不应该。

再来不要线上验证产生的数据或者为了方便验证造的一些数据影响到了用户等。

别的线上问题就拉出来遛一遛， 是驴是马，分析分析， 产生的根因是啥， 产研测都哪里没做好，后续如何改进防范。

测试要做的， 能说清楚所测系统的质量好坏，团队要为质量负责，不仅仅是测试。

团队人员，认知问题。
成员认知没达到，TL 问题。

精准测试的代码覆盖率能很好落地执行，几乎 0 成本使用，得益于 1. 统一的研发架构 2. 统一的 CICD 打通 3. 质量流水线 - 分支模型的推广 4. 软路由多泳道环境的具备。 这些有各自的作用，又促进了代码覆盖率的易用性。

嗯， 所以这里又涉及到代码分支模型管理，例如你多个版本合并一块测试，又分开上线，那这个覆盖率一会合一会分，确实都很头疼。 但是，这再我们这边基本不存在，不是所我们没需求并行，而是我们也做了这块治理。 其中涉及到质量流水线治理，我们控制着提测和上线的出入，我们覆盖率根据自动生成的 release 分支生成，不同需求会生成不同的 release 分支，版本并行多了，release 分支多了，避免互相抢占环境，我们又做了环境治理上做了多泳道，不同需求不同泳道服务，不同覆盖率不互相影响，同一个服务的一次版本我们手工或者定时拉取覆盖率是做自动合并的，下个版本或者并行版本 release 分支不一样了，自然不会互相干扰。

再提一个，精准测试中代码覆盖率对我们统计的一个落脚点：我们把代码覆盖率和自动化测试打通，我们能给出每次执行自动化的服务的代码覆盖率。 也许你会觉得花里花哨，但是我认为他也是一种考量你自动测试覆盖率的一个重要指标。