软件测试自动化， Selenium / Playwright， testNg, pytest 这些工具或框架本身。因为从技术上看，这些框架其实已经比较成熟了，能够支持应用程序的很多场景测试，而且也支持 CICD 的 集成运行。

真正的挑战更多是指应用落地和工程化层面，不同团队确实会有各自的痛点，比如用例设计、环境稳定性、数据管理等，这些最终会体现为 “自动化不稳定、不可靠”。 还可能感觉上没有手动快比如说一些新功能上线时。

针对这一个痛点，可以分 3 层 来看：

1， 没有手动快 - 是因为手动测试时人脑 在同一时间处理 执行 、分析结果、给出测试判断，定位？ 一次完成观察、调整、结果。 而自动化 是机器，是代码，它只能在一个时间段完成一个任务 “执行”，预定义路径 + 机械执行 + 结构化输出 而后续 “ 分析，判断，定位”（可这需要人为二次介入，可是这介入的代价太高了）因此 得出来的结论是手动更有效 在一定场景下。

2， 测试对象本身的持续变化， “正确性” 不是静态的。 而自动化测试中代码 是一种 固化的 “数据验证”， 一旦测试对象有了变化，自动化代码是不知道的，它是盲目地 抛异常，抛失败，抛缺陷。而要分析这些 “真”、“假” 缺陷又是人为的介入。 结果就是测试人员维护测试代码的时间团队可能接受不了（ 因为测试代码本身也是一个系统）

3，由上面二点， 我们可以看出 自动化测试无法形成一个想人脑那样的 闭环系统在执行用例的同一时间。 而当前市场上 没有一个软环境 支撑/接收 自动化运行、完成以后的输出（不否认，现在有很好的报表，LOG ，但是 收集数据不完善,不具体，不结构化， 而且还是分离的）

个人认为导致 自动化很难落地的根本原因 就是 代码测试执行以后的价值 没有完整 的 体现出来。 就如上面提到 的，会形成一恶性循环

越不好用 → 越不愿意用 → 越不愿意用 → 越难投入 → 进一步变得不好用。

导致自动化测试在团队里尤如一个鸡肋，用吧，不稳定，不可靠。 不用吧 ， 又担心公司失去规模化回归能力，失去市场竞争。

而我们目前就是针对这一痛点给出的解决方案，我们开发这样一个平台与市场上主流的 自动化框架 无侵入式 接入。 通过将测试执行结果进一步结构化、语义化，并引入统一的归因与聚合机制，使自动化测试从 “执行工具” 升级为 “可被系统消费的质量数据基础设施”，让自动化测试真实地扎根到团队里，让团队中的每个人都感受到 ：
自动化测试带来的不是额外成本，而是持续可用的质量反馈能力与决策支持能力。