基于人工智能的系统，也称为神经网络（NN Neural Networks），和其他应用程序一样是 "系统"，因此需要测试。本文将指导你测试AI和基于NN的系统，并理解相关概念。

测试人工智能系统的不同之处是什么？

"传统 "的软件是建立在内部确定的算法基础上的。例如，对于将摄氏度转换为华氏度的系统，它将使用简单的F=1.8C+32公式。

人工智能用于 "公式 "未知的情况，但你有足够的输入和输出的例子，可以根据例子来估计公式。

最终，人工智能并不创造公式，而是根据以前的知识创造一个决策网络。如果人们知道这个公式，那么用人工智能来解决这个问题的价值就非常小。

我们能一直使用一个公式吗？比如，这幅画里是一只企鹅吗？没有简单的公式来确定图片中的企鹅是什么样子。有无穷无尽的 "企鹅图片 "的例子，它们的大小、位置、颜色、灯光、类型等都不一样。

人工智能实际上是模仿人脑在训练方面的运作方式，并根据以前学到的例子给出最佳猜测（即准确性）。对于人类，我们将判断 "企鹅 "的能力视为我们智力的一部分。

就像人类一样，AI也会犯错或被欺骗。这就是 "测试AI "发挥作用的地方。看一下上面和下面的例子。这是一只企鹅，或者，如果你倒过来看，也许是一只长颈鹿？

测试AI应用： 重要的考虑因素

• 准确度
  人工智能会给出具有一定准确性的结果。对于积极的结果，获得100%的准确性是非常罕见的，对于消极的结果，获得0%的准确性也是非常罕见的。

好的人工智能将在和作为正数和绝对准确率（100%）的因素之间有一个明显的delta。当你在测试时，你会得到不同程度的准确性。这很正常，但如果你在对象A上得到99.99%的阳性结果，而在对象B上得到98%的阴性结果，要确定哪个是阳性，哪个不是，可能会有问题。

99%并不总是比90%好。它是相对于其他结果而言的。如果阳性是80%，阴性是30%及以下，你的人工智能是可以的。如果正数高于99%，负数低于98%，那就有问题了，要确定。永远不可能测试所有的输入，所以测试者的作用是确定人工智能的质量。

• 静态或动态

静态人工智能是 "按原样 "提供给应用程序的。在更新之前，它将有相同的输入结果。静态人工智能通常由外部供应商提供。例如，你的应用程序可能使用由第三方提供的图像识别或NLP引擎。

从测试的角度来看，静态人工智能主要是作为开发过程的一部分（作为验收）和作为版本发布的理智测试的一部分来测试的，这一点很重要。但是，由于是静态的，开发人员和测试人员并不真的需要反复测试它们。无论你现有的OEM策略是什么，包括外部第三方组件，它应该是测试静态AI的相同策略。

动态人工智能正在不断改进自己。它的开始方式与静态人工智能相同，但一旦发布，经过验证的输出会再次注入人工智能，作为额外的 "教学数据"，以提高准确性。这与我们大脑的工作方式非常相似。

与我们的大脑一样，更多并不总是更好。"改进 "可能会对人工智能产生负面影响，测试人员应始终执行 "生产测试"，以确保人工智能确实在改进，或至少保持它过去的样子。

要做到这一点，要使用一组静态的测试数据和准确率数字（如果有的话）。你可以使用与开发原始人工智能时相同的20%的测试数据，因为它不是教学数据的一部分。测试数据应该产生相同或更好的结果。节奏通常与教学数据的增长百分比有关。一个好的起点是1%。

例如，如果原始的人工智能教学数据是100,000个输入点，每引入一个新的1000个额外的数据来改进人工智能，运行测试数据并检查其结果。小于1%可能不会对AI值产生重大影响。

• 单NN还是多NN？

这是一个非常重要的问题，可能会很难理解。让我们以一个聊天机器人为例。聊天机器人可能是基于消息平台或语音平台的。在语音平台的情况下，在用于确定对话背景的任何NLP之前，有一个基于NN的语音到文本。

这意味着，这里有两个NN在起作用。在某些情况下，这可能是很棘手的。例如，一个碰撞检测系统可能使用人工智能来分析基础图像，并使用相对简单的算法来确定是否可能发生碰撞。

在大多数多NN的情况下，你实际上只测试一个NN，你依靠其余的NN来提供基本信息。

• 虚假或欺诈：人工智能的安全

几乎在所有情况下，人工智能都有潜在的攻击载体，可以用来进行欺诈。在相关的研究中，有人举了一个例子，"红色交通灯 "+额外的11个白色像素可以被确定为 "烤箱"。

即使图像的轻微变化也会使人工智能感到困惑，使其容易受到欺诈。

为了更好地确定你的测试需求，请考虑以下几点：

1.我是否期待欺诈输入？为什么？

例如，在上面的例子中，如果有人想造成车祸，他可能会使用上述的异常情况来欺骗一个特定的交通灯。

然而，对于聊天机器人来说，如果输入没有被正确识别，其结果很可能在本质上不是欺诈性的。这意味着，你可以造成错误的识别，但出于什么原因？

2.错误检测的代价是什么？

在交通灯的例子中，无论是否有欺诈行为，不良检测的结果可能是灾难性的。它可能是由有邪恶意图的人或几滴雨造成的。好的测试应该检测出这样的异常情况，因为错误的检测可能会带来很高的成本。

在你的聊天机器人的例子中，错误的检测通常会导致一个 "对不起，我没有收到 "的回应，除了一个恼人的界面，没有任何伤害。虽然你显然想确保将错误检测降到最低，但错误检测的成本并不是灾难性的。

3.系统是自主的还是不自主的？

在大多数情况下，自主系统的错误检测的成本更高。它并不总是像上面的交通灯例子那样与生命对待的情况有关。但它仍然可能导致高成本。

一个错误的车牌检测可能意味着停车场障碍物不会及时升起，或者一个司机可能被错误地收取收费公路的费用。

如果系统的FLOW包括一个可以 "修复 "人工智能错误的人，错误检测的成本通常会低很多。

• 可能的输入数量

在大多数情况下，人工智能被用于可能的输入数量非常大或几乎是无限的地方。例如，在一个用于确定给定图片是否是企鹅的系统中，根据定义，可能的输入是 "任何图片"。

实际上，了解有多少个可能的输入并不重要。而且很明显，你不可能对所有的人进行测试。需要的是确定一个可靠的测试数据策略。

1.测试输入的数量

有几个因素可以帮助减少测试输入的数量。

你有兴趣测试的输入

之前，我们讨论了多层NN。例如，如果你的系统是依靠计算机视觉（CV）组件来识别物体（例如，返回给定图片中的动物列表的系统），你其实不需要太多或者太频繁地测试这个组件。而且它可以大大减少输入的列表，即 "动物列表"。

2.逻辑分组

NN是以这样的方式创建的，它们根据输入的低级值来分组。这可能解释起来太复杂了，但如果我们正在搜索企鹅，可能的分组可能是 "非动物"、"其他动物 "或 "企鹅"。继续关注上下文，如果你的系统应该检测企鹅，那么 "椅子 "和 "桌子 "之间就没有什么区别，也就是说，测试所有的家具没有意义。

其他分组可以是照明条件、尺寸、位置、颜色等等。

3.矢量

NN往往对输入的轻微变化很敏感。如果你对这些类型的测试很敏感（即主要是自主系统），可以增加一些通过某个参数循环的测试。例如，相同的图像，但有不同的照明条件。

这对非CV、非音频输入也有帮助。例如，如果NN参数是年龄，试着以单日的频率给出日期的向量。

3.欺骗系统

你的 "错误检查 "的一部分应该包括噪音水平测试，这包括带有额外噪音水平的正面输入，如图像噪音、音频噪音等。

注意点

虽然人工智能测试似乎不能自动化，但事实并非如此。如果给予客观的测量，大多数测试可以自动化。

• 如果你有一组已知的输入，并有一组已知的输出（即使这些是数字的范围），它可以被自动化。
• 如果你坐在系统前面，思考如何使系统失败，你就做错了事。
  • 如果你做了一次，它可以被添加到已知的输入和输出中。
• 人工智能不被认为是重在处理。虽然有许多可能的输入，但人工智能是极其优化的，通常人工智能的决定应该花费很少的时间（在许多情况下，以毫秒或更少的时间衡量）。
• 如果测试花费太多时间，你可能会推迟CI周期，所以考虑每天和每周的周期。然而，只有在你受到性能不佳的影响时才做出这个决定，而不是在之前。如前所述，人工智能处理通常非常快。

ML和AI自动化工具

差异化的工具

利用AI和ML算法的工具旨在积极主动地自动识别代码质量问题、回归、安全漏洞等。这是通过代码扫描、单元测试自动创建等方式完成的。

如果你的团队缺乏解决上述目标的技能，或者没有时间持续解决这些任务，请考虑其中一些选项。其结果将是更快的发布，通过减少逃逸的缺陷来提高质量，以及提高开发人员的生产力。

• Facebook Infer
• Launchable
• DiffBlue
• Google OSS-Fuzz

让我们以DiffBlue为例来看看。DiffBlue连接到你的源代码控制库（Git、Perforce等），并通过人工智能自动创建单元测试的基础线。一旦发现回归，就会抛出一个标志，报告这个问题。DiffBlue创建其解决方案的动机主要是通过帮助那些不喜欢自己创建测试的开发者来提高代码质量。

Launchable在代码拉动请求时自动查看代码，并执行一种代码影响分析，以适应最近的代码变化。然后，它只选择你的回归套件中最相关的子集，以节省时间来批准代码更改并将其集成到管道中。

最后，Facebook的Infer项目也通过其AI算法实现更好的代码质量。

来自Facebook的人工智能引擎可以自动发现Android和Java代码中的空指针异常、内存泄漏、并发竞赛条件等。同样，它也可以在C、C++和iOS/Objective C代码中找到同样的问题以及错误的编码习惯或不可用的API。

视觉AI自动化工具

相对于差异化的工具，视觉测试解决了用户体验层的测试，并在数字平台（主要是移动和网络）上扩展了验证和UI（用户界面）的外观和感觉。

可视化人工智能测试工具解决了UI层不断变化的痛苦，加上不断增加的平台、屏幕尺寸和配置，使得测试覆盖率成为测试工程师和开发人员的噩梦。

属于这个类别的一些AI/ML工具有：

• Applitools
• Percy.io

对于Applitools和Percy，开发者和/或测试工程师需要将SDK或代码片嵌入测试自动化（Selenium，Appium，其他），以建立网络/移动应用程序的视觉基线。在测试平台内的所有目标平台上进行下一步执行时，工具将突出实际和基线之间的差异，将责任转交给测试所有者，以报告一个缺陷或忽略这个问题。

声明式工具

声明式工具与其他工具有不同的使用情况，但仍然旨在提高测试自动化的生产力和稳定性。利用ML和AI的声明式工具具有与NLP、DSL、RPA(robotic process automation)和MBTA方法相关的重要能力。

这些方法之间的共同点是通过智能自动化消除繁琐的、容易出错的、重复的动作。虽然在这个类别中，我们列出了RPA，但这种特定的方法并不只是围绕着测试的自动化，也是围绕着人工完成的过程和任务的自动化。

专注于声明性测试，我们可以把以下工具作为一个例子：

• Functionize
• Tricentis
• UIPath
• Automation Anywhere
  这些只是不断变化的市场中可用工具的一个子集。而且上述每个工具都有不同的方法来使用AI创建测试自动化。

例如，Eggplant AI使用的模型是模仿被测试的应用程序而建立的，然后AI引擎自动通过模型流并创建测试自动化场景。

即使是人工智能，测试工程师也需要考虑维护，随着时间的推移，测试资源的管理，以及规模的执行。如果这样的工具支持所有这些，那就很好，否则可能会有颠簸。

上面列出的其他工具，特别是Functionize，指定利用NLP来创建测试自动化脚本，不需要任何编码技能或开发语言。

这种工具类型的主要好处如下

• 快速的测试自动化创建。
• 不需要编码技能。
• 更快地维护测试自动化方案。

这类工具的缺点是：

• 不涉及编码技能/代码。
• 与工具链和DevOps CI/CD管线的集成有问题。
• 版本管理和测试管理能力。

自我修复的工具

如果我们要说出人工智能和ML在测试自动化领域出现的首要原因之一，那就是由于测试自动化的松散性、可靠性和维护。

基于代码的测试自动化在本质上不太稳定。它需要不断调整每个平台或环境，其整个基础是应用程序对象。这些对象往往每隔几周就会改变，或者最坏的情况是它们的使用效率低下（例如XPATH与Object ID等）。

为此，一个新时代的工具已经发展起来，测试维护由机器学习来协助。在这些工具中，主要的ML引擎存在于记录脚本的自我修复中。

有些工具就像安装网络浏览器插件一样简单（Mabl, Testim）。一些用机器学习辅助测试维护的工具能力更丰富，并被集成到一个端到端的持续测试解决方案中（Perfecto, Tricentis）。

• Perfecto
• Mabl
  这些工具的核心是一个ML算法，在每次执行时和执行之间 "学习 "被测网站和/或应用程序。它根据可靠性和成功找到的概率，对应用程序中每个屏幕的元素定位器进行评分。

报告和分析工具

测试数据来自多个来源：测试自动化工程师、开发人员、安全和运营工程师、分析人员和其他人。团队需要能够理解所有这些来源，并快速做出数据驱动的决定。

报告中的ML有助于对数据进行分类，对其进行切片和切块，在高级情况下，还可以自动对失败的根本原因进行分类，提高团队的生产力。

• Perfecto
• ReportPortal

通过采用利用ML的报告解决方案，团队可以不必担心数据的大小，让机器为他们自动分类，这就消除了管道中的噪音，这样他们就可以更快地发布，并充满信心。

原文 https://www.softwaretestinghelp.com/database-testing-process/

相关python书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md

为了让人、流程和技术在有效的协调和规模下无缝工作，我建议你从小处着手，确定应用人工智能/ML的关键场景。调整工具以补充不同角色的技能，如业务测试人员和开发人员。而且一定要了解你如何扩大测试自动化套件的规模，并连接到CI/CD。