不知不觉在质量技术领域也走过了七八年之久，从最早的覆盖率测试工具，UE4游戏客户端自动化，到后续的数据变更风险防控，再到变更风险防控平台架构建设，期间做过很多思考，也沉淀了许多技术文章。随着业务测试->质量提效->技术风险SRE->稳定性架构师的工作内容变化，笔者也自觉自己未来的工作从垂类角度，也会逐渐独立于质量技术，转而更加深入做SRE稳定性和后端架构领域。所以今天这篇博客，也决定和自己多年来的【测试人生】做一个暂时的道别，当然也借着这个机会，聊一下自己对于质量技术的现状和未来发展的思考。
首先聊一聊现状，坦白来讲因为AI时代的到来，质量技术又再一次焕发了生机。主要体现在以下几点：
- 自动化脚本的实现与维护成本大大降低
- 可深入挖掘的代码缺陷越来越丰富
- 质量缺陷发现和解决的时间线逐渐左移
- AI的不确定性为质量保障带来更多挑战
第一块是自动化，过去写自动化脚本，是个实打实的“体力活”。自动化实现方面，本身从元素定位、脚本编写到后续维护，每一步都需要测试工程师投入大量精力，并且如果产品方案变动，脚本的维护成本甚至会超过重新编写的成本。再加上质量行业技术水平的局限，自动化测试工程长期就会存在瓶颈，难以突破。
AI时代的到来，从根本上改变了这一局面，可提效的点，一是测试操作可以用自然语言描述，底层自动化代码就可以AI生成，不需要人类做代码开发，二是自然语言本身维护成本低，在产品迭代比较频繁的节奏下，自然语言的迭代维护的成本相对于代码开发就低很多。两者结合起来一起看，AI自动化测试的ROI就显著有了提升。
第二块是代码缺陷，传统的静态代码分析工具，主要关注的是代码规范还有潜在的安全类等问题，但真正致命的缺陷，比如业务逻辑错误、并发问题、边界条件处理不当等，传统工具很难深入挖掘，这个时候AI介入就能够自主驱动去识别更多潜在的问题。
从技术上来讲，结合代码的模块依赖关系表达以及业务沉淀的知识库，AI可以发现很多和业务相关的问题，而不仅限于代码本身的实现。结合日常的需求迭代，AI可以在某个commit的基础上，根据需求/Bugfix的信息，判断某个commit的实现是否合理，这样的判断也会更加准确。
关于这一点就涉及到第三块，将AI结合日常的工作流，让深层次质量缺陷解决逐渐左移。首先AI可以对需求文档和技术文档本身的合理性做分析，既可以发现需求中的歧义、遗漏和矛盾，也可以分析系统设计的合理性。然后，编码阶段可以做实时的代码检查和commit检查，这样就不需要等到测试预发才发现问题了，由于单测生成也会更加方便，一些基础逻辑也能够有底线的质量保障，这样就不需要再自主写一堆单测逻辑做测试驱动开发，研发自测成为可能。
第四块是AI的不确定性带来质量保障更多的挑战。这么说是因为现在各行各业都在推广AI Coding，但AIGC是具备不确定性的，那么怎么衡量AI Coding的产品质量，就会成为质量保障的挑战。这里的关键是评测体系，对于AI Coding的输入和预期输出，可以梳理一套完善的测试集+AI驱动的评测能力，从而快速对AIGC做质量衡量。除了AI Coding之外，基于AIGC的产品，比如Chat Agent，也需要背后的评测体系去保证执行质量，可以理解新时代的产品需要新的测试范式，以前点点点的质量保障从ROI来看确实变得越来越小。
基于这些现状，从质量技术建设角度，一方面是需要基于以前的业务流，引入新的质量保障思路，另一方面是AI打平了以前很多样的研发角色，那么质量保障本身也不再仅是测试团队的责任，而是整个研发团队共同的目标。所以长期来看，如果AI相关的能力发展成熟，研发角度，以后可能不再有测试开发工程师，只有业务开发、Infra、DevOps还有SRE工程师的角色，每个角色都利用AI技术去保障自身产品的质量，做到相互协同。业务角度，以后专职做业务质量的角色也会越变越少，这类角色可能也逐渐过渡到产品线，成为产品经理或业务前线。
虽然在以后，质量技术包括质量保障的概念，可能会逐渐模糊，打散到各个其他角色当中，但质量保障的理念、风险控制的方法、系统思维的视角，这些事情对于产研领域其它角色而言，都是需要承担职责，也是需要深度掌握的。所以对于质量技术的未来怎么发展，笔者的观点是质量技术将会是大家共同建设共同发展的，不会只局限于传统的测试和质量保障领域，以后还会有更多的可能性和定义空间。