当然，这个是基于还有 QA 这个角色前提下的设计， 我都认为 这个角色很快都无了， 如果无了， 就没必要这个平台了，对吧。 看看 codex + chatgpt 5.5 这种组合， 已经能自己写代码， 部署，测试，修复 bug ，继续下个迭代， 跑个几天几夜都不带停的，直到最后把功能交付给你。

提供个 ， 后面测试平台设计的整体思路

嗯， 我这比很多大厂更激进， 我把传统用例的设计也颠覆， 应该生成更适合 AI 去检查的用例，而不应该还像以前那样黑盒的用例设计思路。 这个很重要，这个可以少很多用例量。

你问问研发， 他们用 cursor codex cc 配合上 当前的 opus 4.7 , gpt5.5 等， 他们 AI 生成后多少代码能用， 这个比例值是巨高的， 那做功能模块都行，那让去检查某个功能点岂不是更容易？

这时完全可以落地的。 现在 AI 能力，已经很强了。

这个行业都看到尽头了， 何况社区

改了

跟 playwright 定位不是一个东西。

不用一惊一乍，毕竟已经开源那么久，要炸早就炸了

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

羡慕

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

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

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

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

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

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

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

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

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

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

至于很多讲的， 例如 通过代码变动推荐用例，这块难点怎么做到 代码和用例的关联关系。 难，但是也不是不可能，理论可行。 我们不做任何的用例和点关联， 我们只做影响入口判断出来后，把影响入口的自动化全部自动执行一遍。

有个东西，叫变更管控， 变更管控中最重要的就是代码变更管控，如何管控这块， 精准测试 - 代码覆盖率就非常重要。

我理解的精准测试是一个很泛的东西，目前我们主要做了 2 个落脚点：1. 代码覆盖率统计（主要看变更）2. 代码影响入口统计（先不说上下游）。

这 2 个东西对我们团队的质量影响都非常深远，是有实实在在收益。
我简单提 2 个常见场景，你们也看看这 2 个场景在自己团队发生的概率大不大，风险大不大。
场景 1： 开发需求外改动，例如他重构了某个方法，但是没告知你这块有改动。
场景 2： 开发改了 1 个方法，这个方法被多个接口调用，有部分接口不在你这个需求改动内。

这 2 种场景，均会出现未经过测试上线而导致的问题，分析后它们可能均属于测试范围判断不准确，1 属于你不知道开发的改了啥 2 是你知道开发改了啥，不知道影响了啥。

那这 2 个问题如果不通过精准测试，你可能需要怎么去预防，无非就是你需要 CR 代码，你也得对研发代码熟悉，自己能通过 code diff 发现，但显然这对大多数测试来说是门槛巨高的。

那我刚提到的精准测试 2 个落脚点，就是能很好预防和降低问题发生，有了精准测试，那这 2 个场景在我们团队可能场景就会这样。

场景 1 ，测试发现他执行完了测试，但是还是有未覆盖的代码，能力强自己就做一层分析，能力弱点他可以跟研发确认，这个改动方法是干啥的，为啥我测试覆盖不到，我需要补充什么用例呢，这时开发可能就说，哦，这个是啥啥啥的，我做了优化，是啥啥啥功能的。
场景 2，测试根据精准测试给出的影响的接口，这时一个改动模块外的接口在列表里面，测试自然就判断到这个入口也受影响，进而进一步是否需要覆盖验证。

当然一切，还得建立一个完善的质量门禁，合理设置门禁值等一系列看似和精准测试无关，但他又影响到精准测试出成绩的动作。

最后补充下，平台研发成本和使用成本。
研发成本:
我们代码覆盖率基于滴滴二开，当然我们做了很多改动了，包括精准到方法覆盖率的清空等等并和 CICD 等打通，我们从立项到第一个版本上线前后端各自 1 个，大噶 3 个月周期，当然后面我们陆陆续续还加了很多功能和优化，入口推荐同样前后端各自 1 个，前后不到 1 个月就上第一个版本了。
使用成本：
这东西很难定，但随着我们各平台打通，交互上优化完善，目前最大的成本不在平台使用，而是 QA 发现无法覆盖的代码，做判断或者找研发确认，这个成本反而是最大的，但！！！！ 这是必须的！！！

你并发需求多了，并行版本多了就知道为啥要这么多个测试环境了。 研测，测试和测试不互相抢占资源。各大厂的软路由，标签环境，泳道环境可以看看。

可观测
可召回
可追溯
防劣化
ROI
.........

点击查看原文吧