技术文章

几年前，Mike Cohn 创造了“测试自动化金字塔”一词来描述团队应如何看待混合各种类型的自动化测试。扎实掌握不同自动化测试类型的使用对于帮助您保持整体测试自动化套件的精简、低维护和高价值至关重要。

自动化测试类型

虽然自动化测试有很多种类型，但我将本文重点讨论三种特定类型：

• 单元测试：专注于一种方法或类的特定部分的测试，例如在算法中行使边界，或验证的特定情况。单元测试永远不会跨越服务边界。因此，它们通常简短、简洁且速度极快。

• 集成/服务/API 测试：这些测试明确地影响了跨服务边界的流。因此，它们调用 Web 服务和/或调用数据库。由于这些跨服务边界，它们通常比单元测试慢得多。集成测试永远不应该启动或利用用户界面。

• 功能/用户界面测试：UI 测试驱动应用程序的前端。他们要么生成应用程序本身（桌面、移动等），要么启动浏览器并导航网站的页面。这些测试重点关注用户操作和工作流程。

了解良好的混音

我喜欢Mike Cohn 的测试金字塔作为一个比喻，它提醒我系统的不同方面最好通过不同类型的测试来覆盖。有些人对其构成持异议，因为他们不喜欢被迫进行一定比例的测试的概念；然而，我认为金字塔是一个很好的起点，可以用来讨论如何对现有系统进行自动化测试。

例如，验证多个输入值的计算不应通过大量 UI 测试来处理。相反，最好通过单元测试来处理。如果计算在服务器端运行，则可以使用 NUnit 等工具来编写和运行测试。如果这些计算作为某些自定义 Javascript 代码的一部分在浏览器中进行，那么 Jasmine 或 Mocha 等工具就可以处理这些计算。

集成测试（通常也称为服务或 API 测试）应该处理主要系统操作的验证。这可能包括基本的 CRUD（创建、检索、更新、删除）操作、检查 Web 服务端点的正确安全性，或者在将不正确的输入发送到服务调用时进行正确的错误处理。这些测试通常与单元测试（NUnit、JUnit 等）在相同的框架/工具集中运行。通常，会利用其他框架来帮助处理一些围绕调用 Web 服务、身份验证等的仪式。

用户界面测试应验证主要用户工作流程，并应尽可能避免测试最好在单元或集成测试级别处理的功能。用户界面自动化可能编写缓慢、运行缓慢，并且是我在这里讨论的三种类型中最脆弱的一种。

考虑到所有这些，测试自动化金字塔的概念可以帮助我们可视化一种方法：单元测试是金字塔的基础，通常应该构成组合的最大部分。集成测试位于金字塔的中间，其数量应该比单元测试少得多。金字塔的顶部应该是数量相对有限的精心挑选的 UI 测试。

需要强调的是，不存在全面的理想测试组合。有些项目最终可能会包含 70% 的单元测试、25% 的集成和 5% 的 UI 测试。其他项目会有完全不同的组合。需要理解的关键一点是，测试组合是经过深思熟虑得出的，并由团队的需求驱动——而不是由一些虚假的“最佳实践”指标驱动。

随着项目功能的完成，强调测试类型的整体组合也很重要。某些功能可能需要比 UI 测试更多的单元测试。其他功能可能需要更多的 UI 测试组合和很少的集成测试。良好的测试覆盖率意味着不断讨论手头的工作需要什么类型的测试，并了解其他地方已经涵盖的内容。

适用于 QA 和开发团队的现代测试用例管理软件

一个实际的例子

现在舞台已经搭建好了，让我们来看一个实际的例子，在本例中，这个例子取自我几年前参与的一个现实项目。该项目是一个用于管理产品线配置的系统。这个概念是制造商需要创建一个要构建的特定模型的矩阵，以及这些特定模型中的各种配置。

在此示例中，我将使用一系列多种冰箱型号，每种型号都有各种选项和配置。需要从存储加载矩阵，作为产品所有者输入的一部分运行各种计算，然后将结果保存回存储。

UI 的粗略示例可能类似于 Excel 电子表格：

产品管理 UI 示例

应用程序的关键业务规则可能包括对配置选择进行总计，以确保小计与总体“生产总单位数”相匹配，并在小计不匹配（太多或太少）时以红色突出显示单元格。其他关键业务规则可能包括确保只有授权用户才能加载或保存矩阵。

考虑到所有这些，实际的发行版可能看起来像这样：

单元测试（仅显示一种模型）

A 型 共 100 件

•  标准制冰机 67，真棒 33，小计 == 100 无错误（内边界）

•  标准制冰机 68，真棒 33，小计 == 101 错误（外边界）

•  标准制冰机 67，真棒 34，小计 == 101 错误（外边界）

•  标准抽屉 80 个，豪华抽屉 20 个，小计 == 100 无错误（内边界）

•  标准抽屉 81 个，豪华抽屉 20 个，小计 == 101 错误（外边界）

•  标准抽屉 80 个，豪华抽屉 21 个，小计 == 101 错误（外边界）

•  标准门托盘 35，奖励门托盘 65，小计 == 100 无错误（内边界）

•  标准门托盘 36，奖励门托盘 65，小计 == 101 错误（外边界） 

•  标准门托盘 35，奖励门托盘 66，小计 == 101 错误（外边界）

• 室内屏分配置，90块

• Wifi 单位 80，无 WiFi 10，小计 == 90 无错误（内部边界）

• Wifi 设备 81，无 WiFi 10，小计 == 91 错误（外边界）

• Wifi 单位 80，无 WiFi 11，小计 == 91 错误（外边界）

• USB 70，无 USB 20，小计 == 90 无错误（内部边界）

• USB 71，无 USB 20，小计 == 91 错误（外边界）

• USB 70，无 USB 21，小计 == 91 错误（外边界）

• 屏幕 90 单位，无屏幕 10 单位，小计 == 100 无错误（内边界）

• 室内屏 90 台，无屏 11 台，小计 == 101 错误（外边界）

• 室内屏 91 个，无屏 10 台，小计 == 101 错误（外边界）

集成测试

测试运行设置加载具有有效值的基线网格，然后通过以授权和未经授权的用户身份调用 Web 服务来执行测试。包括基本的 CRUD 操作（创建、检索、更新、删除）。

基本创建测试

• 以未经授权的用户身份调用“保存”服务，Web 服务返回预期的 HTTP 错误代码（例如 HTTP 403）

• 以授权用户身份调用“保存”服务调用，检查数据库并验证更新的 JSON 确实已保存

基本检索测试

• 以未经授权的用户身份调用“加载”服务，Web 服务返回预期的 HTTP 错误代码（例如 HTTP 403）

• 以授权用户身份调用“load”服务，Web 服务根据基线数据集返回预期的 JSON

基本更新测试，使用带有一些更新值的基线数据集

• 以未经授权的用户身份调用“保存”或“更新”服务，Web 服务返回预期的 HTTP 错误代码（例如 HTTP 403）

• 以授权用户身份调用“保存”或“更新”服务调用，检查数据库并验证更新的 JSON 确实已保存

基本删除测试

• 以未经授权的用户身份调用“删除”服务，Web 服务返回预期的 HTTP 错误代码（例如 HTTP 403）

• 以授权用户身份调用“删除”服务调用，检查数据库以确保矩阵/配置已正确删除

用户界面测试

检查主要操作，例如：

• 以授权用户身份登录，确保默认数据加载

• 编辑一个单元格，保存网格，检查数据库以确保数据已正确更新

最后的想法

坦率地说，我的测试清单很粗略。我不得不使用一个有些人为的示例，并且我遗漏了很多测试用例，我可能会根据与团队的讨论考虑自动化。我知道有些读者可能对特定的组合有异议，这没关系 - 只要您对您希望看到的测试覆盖范围形成自己的想法！

重点是，使用这些示例作为评估您如何混合自己的自动化测试的起点。努力将适当的测试推向适当的测试风格，并且无论如何，集中精力保持所有测试的可维护性和高价值！