5.6 智能化测试
在介绍智能化测试之前，我们先了解一下“智能”的概念。这里所说的“智能”指人工智能（Artificial Intelligence，AI），这是一种通过普通的计算机程序呈现人类智能的技术。美国麻省理工学院的温斯顿教授把人工智能定义为研究如何使用计算机做过去只有人才能做的智能工作。在这里，所谓的智能工作指通过人类智慧完成的工作流程、内容和方法。
20世纪50年代，人工智能开始逐渐走入人们的视野。当时人们对人工智能的理解还很肤浅。随着越来越多的科幻电影和小说不断加入对人工智能的描述，人们才逐渐意识到人工智能将会给人类带来巨大的影响。
到了20世纪80年代，机器学习作为人工智能的一个重要分支出现了。机器学习是人工智能的核心，研究如何让计算机模拟或实现人类的学习行为，以获取新的知识或技能，然后重新组织已有的知识，从而不断改善自身的性能。
2010年以后，深度学习逐渐出现。深度学习是机器学习的研究领域之一，通过建立具有层级结构的人工神经网络，在计算系统中实现人工智能。
智能化测试即人工智能驱动测试（AI Driven Testing，AI-DT），研究如何使计算机做过去只有人才能做的智能测试工作。测试工程师在测试过程中不仅是决策者，还是工具链的维护者和创造者。
如今，被测系统从来没有像今天这样复杂。微服务化使得系统之间可以通过无数的API联系在一起，测试场景变得越来越复杂，系统复杂度的非线性增长使得测试用例的设计仅靠人工越来越难以覆盖绝大部分场景。
随着项目交付周期不断缩减，测试工程师需要更高效、更准确地评价并反馈被测系统的质量。在DevOps盛行的当下，过程化测试变得越来越重要。随着之前月级别的交付逐渐演变成当下周级别的迭代交付和日级别的构建，流水线式的质量保障手段得到很大发展，过程化的测试流程变得尤为重要。
智能化测试走到今天已经不再仅仅是学术领域的事情，而已经逐渐在很多团队中落地推行。这里既包含开源工具的落地引入和改造，也包含自行研发的智能化测试工具的落地实践。但无论采用哪一种落地实践，它们都是对智能化测试的推动和发展。以人工智能驱动测试并通过算法避免繁重的手动测试，应该是目前行之有效的方法。
智能化测试是测试平台化发展的一个必然产物，测试平台化发展会让测试工程师开始将持续测试的视角从质量保障扩展到自动化质量保障；从利用平台完成自动化测试的执行逐渐发展到利用平台完成全部自动化测试步骤。我们希望通过一些智能化的方法使测试过程中繁重的手工劳动由机器完成，测试工程师变成规则的维护者、阶段的决策者，从而提高团队的工作效率。
智能化测试不仅可以完成测试逻辑的建立、测试数据流的设计，还支持后续的测试执行、测试结果收集和分析，这在很大程度上释放了人力。而释放出来的人力就可以做更需要主观判断、决策等的事情。
时至今日，软件测试已经发生很大的变化。在软件测试的早期，手动测试在整个软件测试行业占据主导地位，各种测试设计方法、测试实践层出不穷，如软件测试用例的设计方法、软件测试的分类等，这些测试设计方法和测试实践直到今天仍指导着软件测试从业者。
随着软件规模的不断增大和迭代周期的不断缩短，单纯依靠手动测试已经很难平衡质量和效能的矛盾。因此，自动化测试逐渐走向测试行业的前台，这推动了测试技术的快速发展和落地。正如我们看到的那样，自动化测试就是利用一些特殊工具和专属框架等完成测试的执行，以及测试结果的收集和对比等工作，然后将那些与预期结果不一致的流程，使用某种手段告知相关干系人。
在实际工作中，回归测试需要反复进行，自动化测试使得测试工程师可以将精力和时间聚焦于新业务的测试，而不是一次又一次地完成相同的回归测试。不难看出，自动化测试不仅解决了手动测试的很多痛点，还提高了测试覆盖率。目前，绝大部分自动化测试是通过自动化框架驱动的——通过对测试框架进行封装，完成自动化的回归测试任务，这样既能贴合团队的使用习惯，又能充分发挥自动化测试的作用。
近年来，IT公司开始积极实施敏捷开发。在实施敏捷开发的过程中，持续集成、持续交付等变得尤为重要。一支IT团队如果想要实施敏捷开发，实现持续集成乃至持续交付，那么持续测试是不可能逾越的。测试工程师要想跟上研发节奏，提高团队的工程生产力和工程效率，就必须有更加高效的质量保障手段。
在这种需求下，原来的自动化测试虽然提高了测试执行、测试结果收集及分析的效率，但是测试逻辑的建立、测试数据流的设计等工作仍主要依靠人力来完成。因此，要让测试在持续交付过程中发挥作用，而不是成为高效交付的障碍，我们就要想办法解决相应的问题。智能化测试能够很好地解决此类问题。智能化测试不仅可用于实现测试逻辑的建立和测试数据流的设计，还支持对后续测试的执行、测试结果的收集和分析等。智能化测试能在很大程度上释放人力，让测试工程师专心做主观判断及决策等。
通过前面的讨论，得出如下结论。
智能化测试主要研究如何用计算机去做过去只有通过人力才能完成的测试工作。通过智能化测试，测试工程师就能够从复杂、枯燥的业务流程测试中解放出来，变成测试过程的决策者、智能化工具链的维护者和创造者。
图5-10展示了智能化测试的优越性。
图5-10 智能化测试的优越性
智能化测试使复杂、枯燥、反复循环的工作由机器完成。人在反复执行某一工作时，会出现思维惯性和惰性，从而出现认知疲劳，最终影响测试的结果，但是计算机不同，它会永远按照约定好的规则和逻辑执行下去，这样就使得测试结论更加精准、可靠。
智能化测试可以同时执行大量用户的测试任务，但是这里的大量不仅指模拟了大并发，还指更加接近系统中真实用户的访问行为和访问规模，更加接近系统的真实服务场景，且测试可以不眠不休地执行。
伴随着自动触发、执行、输出结果，智能化测试会逐渐地将测试过程化，直接赋能研发工程师，提高工程交付的自动化程度，在测试深度和测试广度上达到人工难以企及的水平，并能在测试过程中依据已有的测试结果调整测试，不断优化，达到最优的测试覆盖率。
显而易见，智能化测试能够让项目的交付速度更快，节省更多的人工成本。但是智能化测试并非马上就能发展到非常智能、非常自主的程度，需要不断地发展和演进。智能化测试的分级模型如图5-11所示。
图5-11 智能化测试的分级模型
Level 0也称为原始级。它处于最原始的测试工作状态，测试工程师每天还在针对各个应用手写测试用例，一遍一遍地针对每个发布版本执行相同测试用例。在这里，测试工程师的精力都放在如何更全面地测试上，没有人独立出来写自动化测试脚本。手工测试工程师负责撰写用例的自动化测试脚本，将手工测试用测试的脚本重复一遍，任何功能的修改都意味着测试用例和自动化测试脚本的人工维护。在开发工程师对系统进行全面修改时，绝大部分测试用例失效，需要重新维护，并且要验证全部的失效用例，以确定是否是软件缺陷。
Level 1也称为辅助级。在辅助级，智能化测试框架可以分析被测系统的修改是有效的更改，还是无效的更改。智能化测试框架通过算法辅助测试脚本的开发，通知智能化测试框架可以执行测试并决定测试结果是否通过。如果失败，框架将通知测试工程师并由他验证缺陷的修改是否正确，确定失效的原因是否是一个真实的缺陷。当被测系统发生更改时，AI算法驱动测试完成全量检测，避免人工重复执行大范围测试用例这样枯燥的工作。
Level 2也称为部分自动化级。在部分自动化级，智能化测试框架可以从系统用户的角度学习术语差异，对更改进行分组，同时算法在持续的自我学习中可以自行更改这些分组，通知测试工程师对应的更改，人工可以介入、撤回更改。智能化测试框架可帮助您根据基线检查更改，并将单调的工作转化为简单的工作，但是仍然需要人工审查全部测试出的缺陷，并进行确认。
Level 3也称为有条件自动化级。在这一层级中，智能化测试框架可以通过机器学习完成基线的建立，自动确定缺陷。例如，智能化测试框架可以根据自学的基线和相关规则确定UI层的设计（包括对齐、空白使用、颜色和字体使用情况及布局）是否合理。在数据检查方面，智能化测试框架可以通过对比确定页面显示的全部结果是否正确，接口返回结果是否正确。智能化测试框架可以在无人干预的情况下完成测试，测试工程师只需要了解被测系统和数据规则即可。即使页面发生很大的变化，只要正确的逻辑无变化，智能化测试框架就能很好地学习和使用被测系统。收集并分析全部的测试用例，通过机器学习等技术，人工智能系统可以检测到变化中的异常，并只提交异常，方便人工验证。
Level 4也称为高度自动化级。智能化测试框架可以检查一个页面，并像人类一样理解它，所以当它查看登录页面与配置文件、注册或购物车页面时，可以理解它们。因为它在语义上理解作为交互的一部分的页面，所以智能化测试框架可以推动测试。虽然登录页面和注册页面等页面是标准的，但大多数其他页面不是标准的。在这一个级别中，框架能够查看用户随着时间的推移进行的交互，可视化交互，并了解页面或者流程，即使它们是智能化测试框架系统从未见过的类型。一旦智能化测试框架了解了页面类型，它就可以使用强化学习（一种机器学习）等技术自动开始测试。它可以编写测试，而不仅仅是对它们进行检查。
Level 5也称为全量自动化（科幻小说）级。在此级别上，AI将能够与产品经理进行对话，了解应用程序，并自行完成驱动测试。
从智能化测试分级模型可以看出来，智能化测试的发展方向就是去人工化，但是不要恐慌，即使发展到Level 5，测试工程师也仅改变了工作方式，质量保障流程仍然会存在。对于当今的测试框架和平台，绝大部分自动化框架属于Level 1，同时有往Level 2发展的趋势。要达到Level 3——有条件自动化级还需要很多努力。要实现Level 4及其以上级别还需要经历很长一段时间，这需要所有测试从业者共同努力。
下面介绍部分当今相对比较成熟的智能化测试开源框架。
5.6.1 开源的智能化单元测试框架
智能化单元测试框架在智能化测试中相对比较成熟。在智能化单元测试中，主要有静态分析法、文档分析法、随机法、搜索法和最大化覆盖法等测试用例生成方法。
静态分析法是最早的一种智能化单元测试用例生成方法，应用该方法的优秀开源工具主要有Symbolic PathFinder和JCute。
基于文档分析法的智能化单元测试框架其实并不是常规理解的一个Word文档，而基于代码中的注释完成单元测试的编写和执行。相对成熟的测试框架是Toradoc。在工作中，很多时候，除抱怨项目没有单元测试以外，我们还会抱怨没有注释，所以对于一个没有注释的项目，Toradoc就显得力不从心了。
随机法是一种比较流行的智能化单元测试用例生成方法。虽然它也有比较成熟的测试框架，但是对单元测试的支持并不完美，在单元测试的覆盖率上，也无法保障一个稳定的度量值。
对于基于搜索法和最大化覆盖法的智能化单元测试框架，这里推荐使用EvoSuite、JTExpert、Testful。每款工具都有它自己的特点，也有共同之处，具体如何选择还需要根据实际情况而定。
在这些开源智能化单元测试框架中，推荐使用EvoSuite。这是因为EvoSuite生成的测试用例符合JUnit标准，可以直接在自动化测试框架JUnit中运行， EvoSuite也支持持续集成流水线。
在运行EvoSuite时，它会自动启动mokito框架，并为所有测试函数生成一份测试Mock服务，同时依据它自己的算法生成测试入参和Mock服务的参数，这样就为被测服务建立了一个沙盒机制，从而保证它是代码覆盖率最高、测试用例数最少的测试用例集合。尝试在Maven项目的pom.xml文件中加入代码清单5-5所示的代码，将EvoSuite导入项目。
代码清单5-5
在完成上面的配置后，我们通过如代码清单5-6所示命令可以完成单元测试脚本生成、单元测试脚本执行并查看测试结果，同时看到生成的测试脚本（EvoSuite的部分使用问题及解决办案参见附录D）。
代码清单5-6
5.6.2 开源的智能化UI测试框架
智能化UI测试目前主要在Web端和App端使用，主要借助一些智能化技术完成业务流程执行、结果识别、容错及多场景适配等方面的工作。
智能化测试在UI测试方面的发展重点就是解决自动化UI测试导致的低ROI问题。纵观智能化UI测试的发展历程，它的优越性非常明显，如它使得测试更加精准、智能和高效。在Web端的智能化UI测试解决方案中，retest开源的recheck-web就在脚本自动化容错方面做得非常好。recheck-web是基于Selenium的测试框架，能够让使用者轻松地创建和维护测试脚本。做过Web界面自动化测试的测试工程师都遇到过如下问题。
脚本好不容易调试完毕，却因为开发的某一个元素的ID发生了变化，自动化测试失效。
在测试脚本中，使用的元素查找方法都没有问题，但是脚本仍旧在运行的时候报错。
而使用recheck-web，可以帮助测试工程师避免这些问题。具体来说，运用recheck-web时，它会创建一个网站的副本，这样每次分析时，都会基于该副本的语义进行分析比较。于是，对于那些并不决定业务流程的变更或者无关紧要的变更，recheck-web都可以基于副本分析找到对应的元素，并识别出已经更改的元素，从而自行完成自动化测试流程。
recheck-web的工作原理如图5-12所示。
图5-12 recheck-web的工作原理
当页面的文字描述发生变化时，UI自动化测试仅仅显示了变化，但是自动化测试脚本并没有出问题，这个脚本的执行结果还是Pass。对于任意一个基于Selenium的Web UI测试项目，如果想要加入recheck-web的支持，只需要把Maven项目的依赖加入pom.xml文件中，然后把一些断言类的语法替换即可。至于具体的语法，请参阅GitHub项目中的帮助文档。
对于App端的自动化测试框架，要介绍的是智能化测试工具Test.ai，它同样与Appium搭配使用。Test.ai这个智能化测试工具的推动者和Appium合作开发了一款供Appium专用的AI插件，该AI插件是专门用来查找元素的。这个插件能够自我学习每一个图标代表的意思，如表示一个购物车按钮，还是其他意思等。
在使用Appium进行测试脚本设计时，无须知道App的架构，也无须让研发工程师必须按照元素的选择器的约定进行处理，该AI插件能够基于展示层找到对应的按钮。这种方法比基于ID等的定位方法更加直接。只要训练好智能化测试算法，让它主动识别图标，这样既不需要学习上下文，也不需要匹配精准的图标，就能满足跨平台、跨硬件的兼容性需求。
