测试发展变革史
借用一幅图先让我们快速来回溯一下测试变革所经历的几个不同的时期，从最早期的纯手工测试，随着整个IT技术的发展，测试也历经了不少的变革，每一次变革我们不难发现侧重点都有所不同。
从最初的验证软件的可工作状态，到强调释放生产力的自动化诉求，从封闭式的自动化能力到基于社区模式的开放式能力建设，再到从更加全面的研发流程体系来构建的持续集成的自动化能力，我们不难发现每次变革背后似乎都有一个核心词在推动，那就是“效率”。但这个效率又有所不同，就是不同阶段对于效率在逐渐从单点效率往系统性效率迈进。
如果我们认为前边四个阶段都是基于规则为核心的测试，而未来则会打破这种模式，推动这个核心改变的模式可能主要来源两个方面，第一是研发技术的升级，第二是研发模式的更加敏捷和分布式开发，这两者都打破了以规则为核心的测试理念。
因为我们可能面对更多的研发人员，更复杂的研发场景，更复杂多变的应用系统，在此基础上便催生了对于软件测试新的思考，那便是如何让软件测试变得更加的“Smart”，这便是我们正在经历的时代，不过很不幸的是，我们可能大多数情况下测试还不够“Smart”，很有可能我们在某些情况下我们还处于“1980-1990”的时代，我想这也是测试人员之痛。
图片来源：https://becominghuman.ai/ai-in-testing-the-third-wave-of-automation-cfdd43f55d9c
如今测试发展面临的主要挑战
对于软件测试而言，其实互联网的发展和兴起对软件测试的发展带来了巨大的挑战，这不得不从本质问题说起，相对互联网时代之前的传统IT时代，软件通常研发周期较长，软件功能庞大，软件更新频率较低，软件是作为支撑企业业务发展的配套设施，之所以叫配套设施，也就是对于企业而言及时没有这个配套设施，业务发展依然可以进行，无非是管理效率可能会受到一些影响，而互联网时代，其本质上软件本身就是企业的商业模式的核心能力，不再仅仅是一个配套设施，而是核心设施，核心能力，其直接决定了在复杂多变的商业环境中是否具备核心竞争力。
因此对于软件无论是在研发模式、交付模式上都提出了更高、更快的要求，“敏捷”研发思想和模式应运而生，敏捷的本质是为了获得更快的Go To Market的能力，从而让企业能获得更快的商机，在敏捷模式下，本身是一种好事，这种模式下需要软件更快的交付能力，而不是等着专业的软件测试人员慢吞吞的进行功能验证。
如果不是等着专业的软件测试人员进行测试，那还能谁来参与测试？开发人员？但是开发人员测试自己的软件还并没有成为主流，大多数开发人员不会写测试来测试自己的代码，他们选择手工测试或者等待专业的测试人员来测试他们的软件，从而保证软件可正确运行。
这正是测试面临的挑战，如何能让研发能参与测试？很不幸的是，目前AI在此领域还不能帮助太多，但也并非完全不能做什么，在理解这个问题之前，我觉得有一个很好的问题，就是我们不妨来思考一下自动化测试的6个层次与人工智能的关系。
人工智能测试的六个层次
什么是自动化测试的6个层次？这6个层次是我目前看到的对于AI和自动化测试相对清晰的一个抽象，先简单介绍一下这6个层次的来源，这是由Applitools 的高级架构师 Gil Tayar在 Craft Conference 2018上介绍他们如何将 AI 技术应用到自动化测试的内容中提到的6个层次，分别为：
层次一
完全没有自动，你需要自己写测试！
层次二
驾驶辅助——AI 可以查看到页面，帮助你写出断言。你还是要自己写“驱动”应用程序的代码，但是 AI 可以检查页面，并确保页面中的期望值是正确的。在这种模式下，软件测试工程师需要自己用传统技术解决流程驱动的问题，但无需在脚本中做Expectation的校验或者无需用脚本方式写Check Point，而把校验的工作交由AI来完成，AI技术在此过程中核心起到辅助的作用。
层次三
部分自动化——虽然能分辨实际页面和期望值的区别这一点已经很好了，但是第二层次的 AI 需要有更深层的理解。比如说，如果所有页面都有相同的变更，AI 需要认识到这是相同的页面，并向我们展示出这些变更。
进一步来说，AI 需要查看页面的布局和内容，将每个变更分类为内容变更或是布局变更。如果我们要测试响应式 web 网站，这会非常有帮助，即使布局有细微变更，内容也应该是相同的。这是 Applitools Eyes 这样的工具所处的层次。在这种模式下，AI逐渐具备了贯穿上下文的能力，如果相对层次二而言，层次二停留在”点“上，层次三模式下的AI已经具备了”线“的辅助能力。
层次四
条件自动化——在第三层，软件中检测的问题和变更仍然需要人来审查。第三层的 AI 可以帮助我们分析变更，但不能仅仅通过查看页面判断页面是否正确，需要和期望值进行对比才能判断。但是第四层的 AI 可以做到这一方面，甚至更多其他方面，因为它会使用到机器学习的技术。
比如说，第四层的 AI 可以从可视化角度查看页面，根据标准设计规则，例如对齐、空格、颜色和字体使用以及布局规则，判断设计是否过关。AI 也能查看页面的内容，基于相同页面之前的视图，在没有人工干预的情况下，判断内容是否合理。在这种模式下，AI逐渐具备了自我学习的能力，能从”面“上进行辅助自动化，但这实现起来非常的困难，目前相对不够成熟。
层次五
高度自动化——直到现在，所有 AI 都只是在自动化地进行检查。尽管使用自动化软件，还是需要手动启动测试，需要点击链接，而第五层的 AI 可以自动启动测试本身。AI 将通过观察启动应用程序的真实用户的行为，理解如何自己启动测试。这层的 AI 可以编写测试，可以通过检查点来测试页面。
但这不是终点，它还需观察人的行为，偶尔需要听从测试人员的指令。在这种模式下，相对前边的几种层次，这个层次的AI已经摆脱了人工”驱动“的模式，核心改变就是从人工”驱动“发展为”AI“驱动，如果说前边几种模式还需要测试人员编写流程驱动脚本，而在这种模式下，测试人员将摆脱这一束缚。
层次六
完全自动化——我必须承认，这个层次有点恐怖。这个层次的 AI 可以和产品经理“交流”，理解产品的标准，自己写测试，不需要人的帮助。这种模式可能是我们所希望追求的最高境界，或许发展到这个阶段，测试这个岗位需要重新被定义。
运用场景
AI技术在测试领域的运用并非新鲜话题，但业界对此讨论的一些方向也值得我们思考和探索AI和ML（机器学习）技术能如何被运用到测试场景，常见的三种运用场景包括：
Unit Tests
单元测试对于确保每一次Build都能构建出稳定和具备可测性的软件非常重要，但单元测试的构建和维护本身也面临很大的挑战，在业界例如像RPA这样的AI-Powered Unit Test工具，试图帮助开发人员来更加有效的维护单元测试用例，利用AI技术对代码进行分析和学习，从而有效的减少那些无用的用例集，从而维护一个更加可靠和稳定的单元测试用例库。
API Testing
在敏捷开发模式下，测试人员会面临常态化多变的UI界面，此时针对系统API（接口）的测试其有效性和效率可能会大于UI自动化测试，在此领域有非常多的一些使用AI技术的工具能帮助测试人员对手工UI测试自动转换为API测试，从而帮助组织更加高效的构建起复杂和完善的API测试策略。
UI Testing
目前对于UI自动化测试主要思想主要还是如何把手工测试用例转换为自动化测试用例，AI技术在此场景下目前大多被运用在结果识别以及多场景的适配测试领域，从而降低对UI自动化的维护和运行成本。
业界在AI测试领域的解决方案
针对上述提到的运用场景和不同的六个层次，目前业界在此领域也有非常多的AI Powered Testing Tools，我们可以快速做一个了解（工具排名不分先后）。
Applitools
这是一个运用了AI技术的Visual Testing解决方案，他运用AI技术智能化识别UI界面上那些有价值性的改动，并主动识别其是否是潜在的BUG或者是有意义的改动而并非BUG，从而让自动化脚本的维护从规则化升级为智能化，例如下图中我们可以看到应用的图标位置发生了改变，该工具能自动识别这种变化，其主要主打方向是软件测试的Look & Feel领域，或者我们可以叫用户体验领域。
用该公司自己的话来说其核心价值如下，从其官方价值不难看出，其主要解决的问题是在软件UI影响用户体验的领域，比如像视窗存在遮挡，界面元素颜色、大小、位置可能存在问题等，这对于一些非常重视用户对软件产品体验方面的领域还是具有一定的价值，而这些领域的测试如果用传统的基于规则的自动化，实现成本和维护成本会非常巨大。
Appvance IQ
Appvance公司出品的解决方案，官方宣传口号“The Only True AI-Driven Software Test Automation Technology Create 1000's of regression tests in minutes”，翻译过来大致的意思是这是一个真正的AI驱动的自动化测试解决方案技术，该技术能在1分钟内瞬间产生1000个左右的回归测试用例，从官宣口号中不难可以看出，其主打的是“效率”二字，核心希望解决回归测试的痛点，该公司也提出了一个5层自动化模型，这5层模型和前边提到的6层模型其实有异曲同工之处。
Eggplant
该工具获得2019 SIIA CODiE WINNNER（Best DevOps Tool Digital Automation Intelligence Suite），该工具的Eggplant AI功能号称能自动创建Test Case，并优化测试执行来发现更多的BUG，其提出的测试覆盖率思想提出了一个“User Journeys”的思想相对有些有趣，官方有这么一段介绍“Eggplant AI automatically generates test cases and optimizes test execution to find defects and maximize coverage of user journeys”，其实这里的Customer Journey也即是我们常常说的不同的测试场景，为了达到对于Customer Journey的覆盖，其核心实现逻辑抽取出了Model和Tag的概念，前者是Journey建模，后者实际是数据驱动。
Customer Journey
图片来源：http://docs.testplant.com/
Journey建模
图片来源：http://docs.testplant.com/
Test.AI
这是业界比较知名的两本书籍（《How Google Tests Software》、《App Quality: Secrets for Agile App Teams》）编写团队所创建的一个AI自动化测试平台，其核心能力是将AI大脑添加到Selenium和Appium的工具来提升其智能化能力。
MABL
一帮前Google工程师创办的企业，主攻领域就是提供End-To-End的端到端测试解决方案，AI也是其中很重要的方向，MABL具备自动检测测试对象的变化并动态更新测试脚本的能力。在传统的自动化测试中，可能UI界面的类型变化可能会阻塞脚本执行，而MABL具备自动识别的机制和能力来缓解这类问题。
Sealights
从官方的宣传口号来看，不难看出，其核心定位是利用AI技术做质量管理和质量分析和其他几个的定位略有不同，主要用户主要针对R&D Manager，所以我们可以理解为其核心解决的不是测试自身的问题，而是偏管理方面的问题，利用智能化技术针对此领域希望能更加智能的给予决策人员更加准确的决策信息，提高决策效率。
Sealights
图片来源：https://www.sealights.io/
Sealights质量趋势智能分析
图片来源：https://www.sealights.io/
ReportPortal
从名字上不难看出，这款工具主要是聚焦在测试结果分析和管理方面，这一点和Sealights有些类似，主要基于测试执行的数据利用AI和ML技术进行挖掘，来快速评估新的风险。
ReportPortal产品
Functionlize
该解决方案主打AI自动化领域，其核心能力是其所为的AEA（Adaptive Event Analysis）技术，该技术能自动发现case执行过程中的Broken问题，并自动修复，从而让你的用例Never Break And NO More Test Maintenance，其利用ML技术的智能识别号称覆盖以下一些UI场景，如果在你的测试中有涉及下边这些的Change，利用AEA技术可以自动识别更自动更新测试脚本，无需人工干预：
- Size of Element
- Locaiton on Page
- Previous sizes and locations
- Visual configurations
- Xpaths
- CSS Selectors
- Parent and child elements
- Visibility
除了上述提到的这些目前业界已有的解决方案以外，还有很多厂商也在自己现有的工具能力中注入了AI和ML的能力，不过从上述几个中我们不难发现，目前业界在测试领域使用AI和ML技术大致可以分为几类：
- 利用Computer Vision（计算机视觉）技术对测试结果进行辅助检测，对于检测的结果要么用于结果判断，要么用于更新脚本。
- 利用Natural Language Porcessing（自然语言处理）技术对测试对象进行分析，或者对测试数据进行分析，从而进行测试决策辅助和脚本优化。
- 利用ML（机器学习）技术或者深度学习技术，对采用CV和NLP技术所获得的数据进行深度加工，从而来解决自动化脚本Break，或者快速创建大量自动化脚本的目的。
小结
在我看来AI技术的发展应该是测试人员需要重点关注的领域，我们往往会因为有些技术可能当下并不成熟，或者当下并没有很好的落地场景，从而忽略对未来技术的关注度，在测试领域对于AI的探索也是如此，同时不难发现在业界其实已经有非常多的公司已经在自己的商业化解决方案中注入了AI能力，这种趋势也是值得我们持续关注，最后我个人比较推荐在AI领域的落地和时间可以尝试从本文提到的6个层次模型中去由浅入深的探索，这有利于在AI和测试的道路上有层次的循序渐进。