嘉宾 | 李永刚
编辑 | 忠良
随着人工智能的不断发展，各行各业与人工智能的融合也越来越多，智能化测试就是其中之一，本期我们采访了 ArchSummit 全球架构师峰会（上海站）专题出品人李永刚老师，他从软件测试的发展历程入手，为我们分享了智能化测试案例、自动化测试与智能化测试异同以及企业如何做到智能化测试等等，本文为采访整理文，期待对你有所启发~
智能化测试
InfoQ：在您看来，软件测试历史可以分为几个阶段？
永刚：软件测试的历史不长，但阶段划分方式众说纷纭，大体上我比较认同的软件测试阶段是这样的。电子计算机诞生初期主要应用于军事价值较高的领域比如破解加密通信、曼哈顿计划等，从事的更多偏纯粹科学计算类的工作，这一阶段程序开发、调试、验证还没有形成明确的分工，测试的目标是定位并修复缺陷，也即所谓面向调试的（Debugging-Oriented）测试；
之后随着应用范围的扩大进入专用系统时代，测试成为一种独立的活动，其主要目标是确保系统满足设计需求，证明系统能够正常工作，因而是面向演示的（Demonstration-Oriented）测试；
然后进入了计算机快速普及的 PC 时代，商用系统成为主流，企业对软件质量的要求推动了测试的崛起。测试先呈现出攻击姿态，目标是攻陷（Break）程序、发现其中任何潜藏的错误。缺陷的发现绵延不绝、软件也就迟迟无法交付，最终导致保护式编程作为一种应对策略成为开发人员的基本素养。而人们也开始接受无法穷尽所有缺陷的现实，转进到面向质量评估式（Evaluation-Oriented）的测试阶段，测试目标升级为评估和度量软件质量，质量达到可接受水平即可发布；
再其后，我们就进入了互联网时代，互联网催生新的软件形态的同时也使得交付节奏不断加快，敏捷软件开发兴起，持续测试的要求驱动测试迈向自动化，LAMP 架构大行其道，UI 自动化测试框架 Selenium、接口测试工具 SOAP UI 广为流行；
最后是移动互联网时代了，智能手机普及，移动端应用爆发，微服务架构成为服务端架构事实上的标准，全链路压测成为验证复杂系统稳定性的仅有手段，移动端 UI 自动化、性能体验、稳定性、兼容性要求凸显，新的测试理论如探索式测试、测试驱动开发、行为驱动开发等成为一时热词之后却没能全面普及。总体而言，在开发领域从理念（敏捷开发）、架构（微服务、动态化）、方法论（领域驱动开发）、实践（开源、组件化开发）等方面全方位变革的时代，软件测试领域并没有形成系统化的应对，我们正在掉队……
InfoQ：您认为目前有哪些案例可以算得上是智能化测试？智能化测试应该如何定义？
永刚：智能化测试目前还没有一个准确的定义，至少还没有在业界形成广泛共识。在我看来，智能化测试主要是指人工智能相关技术在测试领域的应用，是伴随着人工智能领域的技术突破而出现的智能化浪潮的一部分，就像无人驾驶、智能音箱分别是人工智能在车载、家用场景的具体应用，只是后者由于面向大众消费市场而更受瞩目而已。
智能化测试方向近几年已经出现了一些很有意思的尝试：国外比较知名的有 Facebook 在移动端应用上进行自动化探索式测试的 Sapienz 以及自动修复 NPE 类型缺陷的 SapFix，国内移动端有公司通过对 Crash 日志进行数据挖掘解决 Crash 定位难题，服务端也有基于少量既有用例进行智能化测试用例推荐 / 膨胀的实践。这些案例都在一定程度上体现出智能化的特点。
InfoQ：之前看到一些大家对于测试的评价——“智能化无非就是 AI 图像识别，设计一些算法不断优化”，这个您怎么看？
永刚：我理解智能化并不仅仅局限于图像识别，人工智能涵盖的范围很大，从底层技术像深度学习、增强学习、对抗性神经网络到应用层面，比如自然语言理解与翻译、语音识别与合成、图像识别、场景合成、姿态交互等等，都可算是人工智能领域的一隅。把智能化局限在 AI 图像识别，其潜在的风险在于一方面可能意识不到智能化技术给测试带来的新挑战，另一方面也看不到智能化技术给测试带来的新机遇，导致测试领域难以满足新时代的要求，从理念到实践全方位掉队。
InfoQ：经常听到自动化测试，智能化测试与自动化测试的最大区别在哪里？如果增加了智能这一项，智能化测试用例的维护成本是否会高于其节省的测试成本？判断标准是什么？企业什么时候可以做智能化测试？
永刚：自动化测试通常是指测试工程师通过编程的方式实现一系列可自动执行的测试用例，就像开发工程师通过编程实现的系统功能一样，测试用例一旦编程实现就可以反复地、自动化地运行并报告测试结果。虽然有很多测试框架或者流派，但大体上逃不脱 Step By Step 式的编程过程，只是抽象层次有些差异，本质上都是人通过程序固化操作步骤，测试程序（也即测试用例）本身不会进化，因其没有适应性和学习能力。
而智能化测试，我理解很重要的一点就是这种适应性和学习能力。它使得测试能够响应测试覆盖目标及策略的调整，甚至能够伴随被测对象演进。因此其表现形式会更多具有引擎化的特点，可以根据指定的规则、策略甚至目标即时生成一系列的自动化测试用例代码，不再是一组固化的、具体的测试用例，因而也谈不上测试用例的维护成本。我们自己的实践中有些场景比如接口 / 系统健壮性测试，甚至跳过生成代码阶段而直接执行测试用例，所谓维护工作主要是更多在于规则、策略以及工作机制的迭代优化而不是作为中间产出物的测试用例。
至于要不要搞智能化测试或者智能化测试是否有效的判断标准，我认为它与自动化测试或者其他测试方法并无二致，还是要回归到投入产出比（ROI）上来。如果预期需要投入很多资源但潜在收益很小，在资源比较紧张的情况下还是谨慎为上。另外，团队在智能化技术方面的自身能力、人才储备也很关键，只有智能化测试的梦想并不足以确保成功。
InfoQ：您目前是在做后台系统，在微服务架构下进行链路分析，这些工作涉及到如何做智能化测试了，这方面整个的过程是什么样的？有什么样的坑可以借鉴给大家？
永刚：微服务架构的系统初期可能只有几个服务，彼此间的调用关系一目了然，随着业务发展快速进化成微服务森林，琳琅满目而逐渐迷失，高度复杂的系统看上去已经很像一团星云，每一颗尘埃都是一个独自进化的文明。对于这样高度复杂的分布式系统，我们还指望开发、测试人员都能全面而深入地理解系统的每一个细节已经全无可能了。
那怎么办？我们决定换个思路试试，借助技术增强人对变更的感知能力，而不是无止境的拔高对人的要求。借助服务调用链路分析局部变更的扩散路径和范围，帮助开发人员评估范围、感知上游变更、识别兼容性风险，面向测试人员推荐测试用例、评估测试覆盖。相关的工作还比较初步，但已经取得了阶段性的效果，更重要的是显示出较强的通用性，感兴趣的同学不妨关注我们在本届 ArchSummit 上的专题分享。
至于说有什么样的坑？我认为最重要是有合理的预期：首先要对探索智能化测试的困难有心理准备，智能化测试不是更容易，而是不一样，对人的专业知识技能和工作思路都有不同的要求；其次是对智能化测试的效果，智能化测试不是万灵丹，不会因为用了所谓的先进技术就一步迈入完全智能化的天堂。智能化技术的成熟度、团队对相关技术的应用能力、技术路线选择与待解决问题的适应性都会影响智能化测试的效果甚至成败。
InfoQ：如何做到智能化测试？我们否真的可以做到智能化或半智能化？未来的智能化测试可以做到什么程度？
永刚：所谓智能化我认为是个持续的过程而不是某个明确、可达的目标。就测试而言，我们所追求的跟广泛领域内的人工智能其实没什么差别，那就是不断提高智能化水平，让专业人员与人工智能各得其所、相得益彰、相互增强而不是彻底替代、非此即彼。如果“做到智能化测试”是指彻底不再需要专业的人员参与测试的全过程，我不认为是一个合理的预期，除非从需求形成到系统实现的全过程都能实现无人介入的智能化。
至于如何迈向智能化测试，我以为还是要回归到测试的框架来寻找机会。完整的测试活动开始于对被测对象（需求、系统）的理解和分析，在此基础上结合特定的质量目标寻求合适的策略，然后才能设计（尽可能）完备的测试用例并执行，最后通过对测试结果的分析完成评估。从理解被测对象到选择测试策略、设计测试用例、执行测试用例并断言、直到测试覆盖评估等所有环节我认为都有智能化技术发挥的空间。
分析理解被测对象方面，除了前面提到我们在尝试的链路分析，当然还有很多其他可能，比如系统行为建模、UI 意图识别等，策略方面有目标驱动的（例如覆盖率、Crash）、基于模型的（常见的如状态机、决策树）、基于规则的、用户场景挖掘等不一而足，执行环节有大量的研究围绕用例筛选、动态执行，结果验证（也就是 Test Oracle Problem），目前很多团队已经尝试引入视觉技术进行 UI 智能断言，就连测试覆盖评估也可以超越传统的代码覆盖，而有更多业务属性。
总体而言，智能化测试还处于非常早期的阶段，基本上各个环节都有一些探索尝试，也能看得到很多新的机会，但还没有形成体系化认知。现在这个阶段去预言智能化测试能够达到什么程度，可能言之尚早。就像无人驾驶等很多人工智能浪潮波及的其他领域一样，智能化测试的未来是什么样子，我们只有创造出来才知道。毕竟预测未来的最好方式是创造未来。
聊聊测试工程师
InfoQ：很多人第一印象会觉得做测试比做开发简单很多？
永刚：和开发的工作内容有很大不同，相应的能力要求也有很大差别。让人产生做测试比做开发简单很多的原因，也许在于对测试人员的编程能力等硬的技能要求相比开发确实会低一些，但测试工程师通常要具备更为开阔的视野，不能仅仅关注作为增量的变更本身，更要留意变更对既有系统的影响，所以测试工作中很大的比重是回归测试，即确保系统既有质量（功能、性能、安全、兼容、用户体验等）不因新近的变更而出现回退。
即便都要做程序开发，测试工程师编写的代码（通常是测试用例）也往往由于呈现出较为相似的模式而不那么复杂，难以体现出很强的编程技巧。当然从测试代码的可靠性和可维护性角度而言我们也要求尽量避免复杂的代码逻辑，因为复杂的代码逻辑意味着潜藏缺陷的概率更大、每次用例运行失败时定位排查耗时、测试代码维护成本较高。而开发工程师开发的产品代码则由于处理的问题模式化相对较弱，可维护性挑战不那么严峻而有更高的复杂度。
除此之外，优秀的测试工程师和开发工程师都需要具备良好的软素质，但相比而言，测试工程师在客户意识、逻辑思维、沟通协作等方面的底线要求会更高些。
InfoQ：测试工程师有哪些职业方向？
永刚：这个问题经常被问到，充分反映出测试工程师们对职业发展前景普遍比较困扰。
大体上我认为有三个方向很有前景：首先是质量顾问，对于不同业务 / 系统有全面而深入的理解，能够据此制定较为系统化的质量保障策略，从基础设施、流程规范、架构设计、测试方法、工具选择、工程文化等多个维度推动落地，挑战在于知识面要求较宽，未必一定要每个方面都专精；其次是测试技术专家，在软件测试的某个领域比如性能、安全、自动化测试、全球化 / 本地化测试等比较深入，能够指导团队完成专项测试、输出专项方法论；最后是测试工具 / 框架开发工程师，能够理解业务研发测试团队的痛点和需求，并通过开发通用化的工具或框架予以解决，是测试团队里的开发人员。
InfoQ：作为测试工程师需要掌握那些关键技术？您认为优秀的测试工程师应该具备哪些能力？
永刚：与掌握某个具体测试技术甚至技巧相比，我觉得测试工程师有扎实的计算机科学基础和软件测试理论更重要。工程师区别于工匠的地方就在于，前者基于科学的知识和理论指导自己去解决实际的问题，而后者主要依赖经验积累和个人悟性，不具备标准化、规模化解决问题的能力。
就我观察而言，优秀的测试工程师通常都有强烈的用户至上意识，总是把自己的脚放在用户的鞋子里去理解用户诉求、关注用户体验；其次，良好的理解能力，如此才能快速而准确的把握被测对象要点；第三，一定的技术能力，以便理解研发的架构设计和关键细节，而不是依附于研发的应声虫；第四，较强的逻辑思维和沟通协作能力，缺乏前者可能导致测试疏漏，缺乏后者则难以保证交付过程的顺利推进。
InfoQ：您目前是否有关注一些测试的新技术？
永刚：工作需要会持续关注测试领域内技术趋势。近几年比较感兴趣的有变异测试、污点分析、符号执行、基于模型的测试、基于搜索的软件测试以及数字孪生在测试领域的应用探索等。其中的大部分都不是新近出现的技术，但和我们面临的问题结合起来会提供一些新的思路。
嘉宾介绍
李永刚 美团优选测试团队负责人，拥有十多年测试领域从业经验，先后涉猎过传统 PC 应用、云计算 / 分布式系统、移动端应用等领域，对探索测试方法、推动过程改进、达成高效持续交付较有兴趣。
