什么是GUI测试

用户界面（UI）测试初学者指南

本指南介绍了有关GUI测试的关键问题：它是什么？它为什么如此重要？什么是主要的GUI测试类型和技术？阅读此综合指南以发现这些问题的答案，并学习如何创建GUI测试计划并编写GUI测试用例。

什么是GUI测试？

如果智慧的开始是术语的定义，那么对GUI测试的理解必须从术语 GUI 的定义开始  。这是 图形用户界面 的缩写  ，或用户可见的应用程序的一部分。GUI可能包含诸如菜单，按钮，文本框和图像等元素。第一批成功的图形用户界面之一是Apple Macintosh，它通过文件夹，日历，垃圾桶和计算器来推广用户“桌面”的概念。

早期的GUI：1984年发布的Apple Macintosh。

图片来源：   folklore.org CC许可

在当今的GUI测试环境中，“简单计算器应用程序”不再局限于计算机的桌面。它可能是在所有主要移动平台上可用的移动应用程序。或者，它可能是所有主流浏览器都必须支持的云应用程序。测试人员必须执行跨浏览器和跨平台测试来识别缺陷并确保应用程序满足所有要求。

因此，GUI测试是指测试用户可见的应用程序的功能。在计算器应用程序的示例中，这将包括验证应用程序是否正确响应诸如单击数字和功能按钮等事件。GUI测试还会确认外观元素（如字体和图像）符合设计规范。

UI测试与GUI测试一样吗？

学习软件测试的一个挑战是行业中有许多术语，这些术语通常意义重叠或使用不一致。

例如，  用户界面（UI）测试  类似于GUI测试，并且这两个术语通常被视为同义词。但是，UI是一个更广泛的概念，可以包括GUI和命令行界面（CLI）。CLI允许用户通过文本命令和响应与计算机系统进行交互。虽然CLI早于图形用户界面，但它们现在仍在使用中，并且通常受系统管理员和开发人员的青睐。GUI测试还会确认外观元素（如字体和颜色）符合设计规范。

小费

要访问Windows PC上的命令行，请启动命令提示符桌面应用程序。在Mac上，打开终端应用程序

虽然测试术语没有普遍接受的定义，但是他们的Certified Tester Foundation Level Syllabus中的国际软件测试认证委员会（ISTQB）是一个很好的来源   。

GUI测试在软件开发生命周期中的位置在哪里？

要了解GUI测试在开发生命周期中的角色，考虑 测试级别 和   测试类型 是有帮助的  。

测试级别

测试级别会告诉您何时在开发生命周期中进行测试。每个级别对应于开发生命周期的一个阶段。ISTQB测试级别是组件测试（也称为单元测试），集成测试，系统测试和验收测试。

软件开发的V模型确定了每个开发阶段的测试任务。

组件测试

组件测试检查单个代码单元。组件测试通常被称为  单元测试，但也可能被称为  模块  测试或  程序测试。开发人员编写并执行单元测试，以便在开发过程中尽早发现并修复其代码中的缺陷。这在敏捷开发环境中非常重要，因为短版本周期需要快速的测试反馈。单元测试是白盒测试，因为它们是用被检查代码的知识编写的。

集成测试

集成测试结合了各个单元并测试它们的交互。一种常见的集成测试类型是  接口/ API测试。应用程序编程接口（API）是两组代码用于相互通信的一组规则。接口/ API测试验证了这种交互。由于API规则在任何给定的应用程序中都非常稳定，因此API测试是自动化的理想选择。Interface / API测试也是  白盒测试，  因为它们需要知道被检查的代码。

系统测试

系统测试验证一个完整的集成系统按设计运行。由于不需要知道底层代码，所以这是   黑盒测试 。系统测试是GUI测试发生的级别。

验收测试

验收测试通常由最终用户或其代理人（例如产品所有者）执行。用户验收测试（UAT）的目标是确保应用程序解决客户的需求。

测试类型

测试类型告诉你正在测试什么。以下是ITSQB定义的测试类型。

功能测试

功能测试将应用程序与其功能规格进行比较，以确保应用程序执行应有的功能。对于计算器应用程序，功能测试将确保所有数学运算正常工作，并且内存和调用按钮可以正确保存和返回数据。功能测试回答了诸如“零错误处理是否正确工作？”GUI测试是功能测试的一个例子。

非功能测试

非功能测试测试系统的工作情况，而不是其特定的功能。非功能测试考虑了可用性，响应性和可伸缩性等要素。这种类型的测试回答了诸如“使用这个应用程序进行分区有多容易？”和“这个应用程序在不同大小的屏幕上看起来是否正确？”。测试GUI的可用性是非功能测试的一个例子。

结构测试

结构测试是一种白盒方法。它验证系统的所有组件都被适当的测试覆盖。如果发现覆盖差距，则可以设计额外的测试以确保每个组件都得到正确测试。

回归测试

回归测试包括在代码更改后重新运行先前成功的测试，以确认没有引入额外的缺陷（回归）。回归测试是自动化的理想之选，因为它们经常重复。

端到端测试

端到端测试验证系统的工作流程。例如，采购应用程序的端对端测试将确保用户可以搜索项目，将其添加到购物车，输入付款和运送详情，并完成购买。

为什么GUI测试很重要？

在软件开发中，  质量  被定义为提供具有功能和易用性的应用程序，以满足客户的需求，并且尽可能没有缺陷。

有人说，“你不能把质量检验到产品中。质量在那里，或者不在它被检查的时候。“这个报价是关于测试完成的产品，如汽车，但是这个原则也适用于软件开发。

为了提高质量，开发团队从一开始就试图将其融入到他们的项目中。这样做的一种方法是在软件开发生命周期中提前进行测试，这种方法也称为Shift Left测试。

左移测试

在开发过程中执行单元和接口/ API测试会在软件开发生命周期的早期阶段转移整体测试工作。

开发团队并没有在应用程序完成后等待系统测试，而是增加了在单元和接口测试中花费的时间和资源。在开发过程中及早发现错误可降低解决这些问题的成本。此外，单元和接口/ API测试非常适合自动化：单元测试可以由开发人员在编写时创建，而API往往非常稳定，因此比GUI测试需要更少的维护。

强调Shift Shift测试，似乎GUI测试并不重要。毕竟，手动GUI测试可能需要耗费大量资源。对于GUI来说，测试自动化更具挑战性：由于用户界面可能会经常更改，因此以前的自动GUI测试可能会中断，需要花费大量精力来维护它们。

但单元和界面测试无法评估系统的所有领域，特别是工作流和可用性的关键方面。特别是，这些测试只能验证存在的代码。他们无法评估可能缺失的功能，或者应用程序的可视元素和易用性问题。这是GUI测试的价值，它是从用户而不是开发人员的角度来执行的。通过从用户角度分析应用程序，GUI测试可以向项目团队提供他们需要的信息，以决定应用程序是否已准备好部署。

什么是主要的GUI测试技术？

如上所述，测试级别描述何时测试，测试类型描述测试内容。  测试技术   描述了如何测试目标应用程序，也称为“待测应用程序”或AUT。本节介绍三种主要的GUI测试技术：脚本测试，探索性测试和用户体验测试。

测试自动化可以支持脚本和探索性测试。

脚本测试

在脚本测试中，软件测试人员设计并执行预先规划的脚本以发现缺陷并验证应用程序是否执行其应该执行的操作。例如，脚本可能会指导测试人员完成在线购物网站上的特定订单处理过程。该脚本定义了测试人员在每个屏幕上所做的条目以及每个条目的预期结果。测试人员分析结果并报告发现团队发现的任何缺陷。脚本化测试可以手动执行或由测试自动化支持。

脚本化测试的好处

由于脚本化测试是预先计划好的并且具有实际产出 - 测试脚本和测试报告 - 脚本化测试为产品经理和客户确信应用程序经过严格测试。通过在开发过程的早期创建测试脚本，团队可以在将代码写入代码之前发现缺失的需求或设计缺陷。虽然测试脚本必须由熟悉系统的更有经验的测试人员创建，但经验不足或知识渊博的测试人员可以执行实际测试。最后，测试脚本可以在未来用于回归测试，并且可以自动化以获得更高的效率。

脚本化的测试挑战

脚本化测试需要大量的前期规划，这可能会导致时间压力，尤其是在敏捷开发环境中。测试脚本必须在AUT更改时更新。更重要的是，研究表明测试脚本的严格结构可能会导致测试人员错过   探索性测试未发现的缺陷 ，或者开发测试用例并手动执行测试用例所需的时间并不能   提供   数量和与探索性测试相关的缺陷的严重性。阅读更多关于   脚本与探索性测试中 缺陷检测率的信息 。

探索性测试

探索性测试人员不是遵循预先编写的测试脚本，而是利用他们的知识和经验来了解AUT，设计测试，然后立即执行测试。分析结果后，测试人员可以确定要执行的附加测试和/或向开发人员提供反馈。

虽然探索性测试不使用详细的测试脚本，但仍有预先规划。例如，在  基于会话的探索性测试中，测试人员创建一个称为测试章程的文档   来为计划测试设置目标，并为一段重点探索性测试设置一个时间框架。探索性测试会议记录在会议报告中，并在随后的汇报会上进行审查。

同样，在脚本测试期间，测试人员可能会做出一些决策，包括能够即时创建新测试。出于这个原因，将脚本化测试和探索性测试视为连续统的两端而非极性对立是有帮助的。

脚本和探索性测试都可以是完全手动的，或者可以通过自动化辅助。例如，探索性测试人员可能决定使用测试自动化对一系列数据值进行一系列测试。

探索性测试的好处

随着时间计划和编写测试用例的减少，测试人员有更多时间专注于AUT的实际测试。测试人员如果被挑战使用自己的知识，技能和创造力来识别缺陷并确保符合要求，那么他们可能会比参与其他人编写的脚本的测试人员更容易发现缺陷。

探索性测试挑战

探索性测试要求测试人员深入了解AUT的性能要求以及软件测试技能。由于时间限制和资源可用性的实际情况，试图用探索性测试覆盖整个AUT可能不切实际。探索性测试不像脚本测试那样可重复，这是回归测试的主要缺点。此外，单靠探索性测试可能会让产品经理或客户担心代码不会被覆盖，并且会漏掉缺陷。

用户体验测试

在用户体验测试中，实际最终用户或用户代表评估应用程序的易用性，视觉吸引力和满足其需求的能力。测试结果可能会在用户现场探索应用程序时通过实时观察来收集。这种类型的测试越来越多地使用基于云的平台进行。作为替代方案，项目团队可以进行beta测试，其中完整或近乎完整的应用程序可供其终端用户在其位置进行临时测试，并通过反馈表单收集响应。就其性质而言，用户体验测试是手动和探索性的。

不要混淆用户体验测试（UX）和用户验收测试（UAT）。如前所述，UAT是一个测试级别，用于验证给定应用程序是否符合要求。例如，假设在更新发布到购物网站后不久，该网站收到许多投诉，即客户无法将商品保存到愿望清单。但是，UAT验证了按下“愿望清单”按钮可正确添加项目到愿望清单。那么，怎么了？UX测试可能显示愿望列表按钮未正确放置在屏幕上，导致购物者难以找到。

您可以在需要用户反馈的开发阶段的任何时间进行UX测试。在涉及用户之前，没有必要拥有完整的应用程序。例如，焦点小组可以在开发早期响应应用程序的屏幕模型或虚拟漫游。

用户体验测试的好处

UX测试提供了最终用户的基本视角，因此它可以识别开发人员和测试人员由于熟悉产品而可能无法看到的缺陷。例如，几年前，一家领先的基于网络的电子邮件提供商开发了一种社交分享工具。该工具由成千上万的供应商自己的员工进行beta测试，但在最初发布之前不会由最终用户进行测试。只有在产品投入生产后，供应商才会开始接受最终用户的反馈，由于隐私问题，这种反馈是绝对不利的。早期的用户体验测试可能会揭示出这些问题，并为该提供商节省了数百万美元的开发成本。

用户体验测试挑战

UX测试需要识别和招募能够准确表示目标用户群的用户测试人员，例如新手，有经验的用户，年轻人，老年人等。虽然不需要有一大群用户，但重要的是覆盖预期的用户角色。招募用户测试人员可能是一个耗时且成本高昂的过程。虽然用户体验测试可能由用户代理（如产品所有者）完成，但他们可能很难将他们的AUT知识放在一边，并充分发挥最终用户的作用。最后，如果UX测试仅限于beta测试，那么在开发周期中发现时间很晚，因为发现和修复缺陷的代价很高。

什么是我的应用程序最好的GUI测试技术？

脚本化测试，探索性测试或用户体验测试：哪种最适合您的情况？所有关于测试的决定都应该通过检测缺陷和确保功能和可用性来设法最大化应用程序的价值。在大多数情况下，实现这一目标需要结合使用测试技术。在测试规划阶段完成最适合您的应用程序和开发环境的特定组合，下一节将对此进行介绍。

如何编写GUI测试计划

GUI测试计划设置测试项目的范围。在编写测试用例之前，有一个测试计划能够识别可用于测试的资源并优先考虑要测试的应用程序区域，这一点很重要。考虑到这些信息，测试团队可以为探索性测试创建测试章程，并为脚本测试测试场景，测试用例和测试脚本。

测试计划定义了关键信息，包括：

• 测试的预期日期
• 所需人员
• 所需资源，如物理硬件，虚拟或基于云的服务器以及自动化软件等工具
• 目标测试环境，例如台式机，移动设备或支持浏览器的网站
• 要测试的AUT的工作流程和事件，以及AUT的视觉设计，可用性和性能。
• 计划的测试技术，包括脚本测试，探索性测试和用户体验测试。
• 测试目标包括确定整体测试成功或失败的标准。

下载免费测试计划模板

测试计划可以是文本文档，也可以使用测试管理工具来开发测试计划并支持分析和报告。有很多这样的工具可用，包括免费的基于服务器和云的工具。在没有正式管理工具的情况下，使用电子表格来跟踪测试进度并不罕见。

请记住，GUI测试计划不是一个完整的系统测试计划，它将测试AUT的其他方面，例如负载测试，安全性以及备份和恢复。

识别要测试的区域

有几种方法可以识别要测试的用户界面区域。如果规范文件可用，这是一个开始的好地方。如果说明文件不可用或不完整，则有用的方法是进行头脑风暴/概念图映射会话以确定要测试的区域。

下面的列表可以帮助你开始头脑风暴会议：

• 视觉设计
• 功能
• 性能
• 安全
• 可用性
• 合规

下面的示例概念图显示了通用应用程序的头脑风暴会话的结果，并包括GUI事件，如添加，编辑，删除，保存和关闭。为了创建概念图，测试人员应用启发式方法：将AUT的知识与一般测试原理相结合。

用于GUI测试的部分概念图

例如，要验证基于云的应用程序的导航，请计划测试，如下所示：

示例区域以测试Web导航

• 与所有常见浏览器兼容
• 当用户点击后退按钮或刷新按钮时，正确运行页面
• 用户使用书签或其浏览器历史记录返回页面后的页面行为
• 用户同时在AUT上打开多个浏览器窗口时的页面行为。

确定基于风险的测试的测试用例的优先级

由于测试资源经常有限，因此优先考虑测试区域可能会有所帮助。  基于风险的测试   使用分析潜在缺陷的相对风险来选择测试的优先级。使用类似于下面的矩阵完成风险分析。在这个矩阵中， 频率   栏描述了用户可能遇到潜在缺陷的  频率，其中包括功能的可见度和使用频率。每个   Impact   列描述缺陷对用户的影响。频率和影响的结合决定了风险水平。

风险评估矩阵

例如，我们假设密码重置过程完全不起作用。一旦用户遇到它，频率是“恒定的”，并且当用户被锁定在应用程序外时，效果是“灾难性的”。因此，测试密码重置过程是至关重要的。如果测试团队确定只有足够的时间来检查关键和高优先级的事件，那么可以通过探索性测试来解决中等事件，而低优先级事件可能根本不会被测试。

规划回归测试

如前所述，  回归  测试有助于确保新的缺陷尚未引入到以前的代码中。使用诸如Ranorex Studio之类的测试自动化工具可以显着增加可以在测试窗口中完成的回归测试用例的数量。但是，即使在自动化的情况下，为新版本重复以前的所有测试用例也许是不切实际的。下面列出了最重要的回归测试用例。

最重要的回归测试案例是那些：

• 有最高风险
• 提供最大范围的代码
• 根据前几轮测试中发现的每个测试案例的缺陷数，可能会发现最多的缺陷。

为避免浪费时间和精力在尚未准备好进行全面测试的应用程序上，测试计划可能还包括烟雾测试和完整性测试。

烟雾和健康测试

• 烟雾测试  检查应用程序的基本功能。例如，烟雾测试将验证AUT可以启动并且用户可以登录。冒烟测试是  浅，因为它没有深入测试系统的任何一个环节，它也是  广 ，因为它涵盖尽可能多的主要功能成为可能。这个名字来源于开启一块新硬件的做法，看它是否着火。如果没有，可以继续进行其他测试。
• 完整性测试  检查新的或修改过的代码，以确保它不会导致任何重大问题并且符合规范。与浅层  和  宽层 烟雾测试相比  ，健康测试的范围  狭窄  而  深远。

在软件测试人员进行更严格的审查之前，开发人员通常都会进行烟雾和健康测试。

如何编写GUI测试场景

一个  测试场景  是如何应用程序将在现实生活中使用的简短声明，如“用户将能够使用有效的用户名和密码进行登录。”测试场景可以从开发文档，如要求被写入，验收标准和用户故事。在没有这些文件的情况下，可以与开发人员和客户/客户代表协商开发情景。

场景可以指导探索性测试，让测试人员了解要测试的GUI事件，而不会将其限制为特定的过程。场景在敏捷环境中也越来越流行，因为创建一个简短的场景比写出完整的测试案例要快得多。

场景不需要创建GUI测试用例，但有助于指导他们的开发。如果场景用于脚本化测试，那么它们可以作为开发测试用例的基础，如右图所示。

测试场景（如果使用的话）指导测试用例和测试脚本的开发。

例如，上面的“登录”场景可能有GUI事件的测试用例，如下所示：

1. 用户输入有效的用户名和密码
2. 用户输入无效用户名
3. 用户输入有效的用户名但密码无效
4. 用户尝试重置密码
5. 用户尝试将密码从密码字段复制或复制到密码字段
6. 用户按下帮助按钮

如何编写GUI测试用例

要编写一个GUI测试用例，首先描述要测试的GUI事件，例如登录尝试。然后，添加执行测试的条件和过程。最后，确定测试的预期结果和确定测试成功或失败的标准。

是否编写一般或详细的程序取决于以下因素：

• 测试人员的经验水平，包括GUI测试和一般测试的特定应用程序。经验不足的测试人员可能需要更详细的程序。
• 用户界面多久改变一次。如果界面变化频繁，维护详细的程序需要更多的努力。
• 最终用户在浏览应用程序时将拥有多少自由。如果用户有很大的自由度，你可以编写程序来覆盖所有可能的导航路径，或者依靠测试人员预测用户可能采用的随机路径的能力。

如果测试人员只需要一般程序，这些程序就可以出现在测试用例本身中。如果测试人员需要详细的程序，将它们放在单独的测试脚本中可能有助于使测试更易于维护。

在GUI测试案例中包含什么

测试用例中最基本的信息是对要测试的GUI事件的描述，执行测试的条件以及预期结果。为了使测试案例更易于管理，包含附加信息（如链接到需求文档和/或缺陷跟踪系统）会很有帮助。

例如，上面的“有效用户名和密码”测试用例可能包含以下信息：

测试用例ID	测试脚本的唯一标识符。
标题	测试脚本的标题，例如“用户输入有效的用户名和密码，最大长度”。
方案/需求ID	链接到测试场景或需求文档的唯一ID（如果适用）。
优先级/风险级别	关键，高，中，低。
技术	脚本化，探索性的UX
描述	测试用例的简要说明，例如“用户尚未登录时，确保用户可以使用任何有效的用户名和密码字符组合（包括特殊字符）登录。确保密码是隐藏的，除非用户选择使其可见
数据源*	外部电子表格或包含用户名和密码组合的数据库进行测试
程序*	执行测试时测试人员要遵循的步骤列表
预期结果*	成功，出现应用程序主窗口
实际结果*	测试完成后由测试者完成
状态	测试用例的通过/失败/阻塞状态。
缺陷交叉引用*	如果发现缺陷，请在此输入缺陷跟踪系统中的代码，以将测试案例与缺陷相连接。

*如果您选择编写测试脚本，则此信息将显示在测试脚本中，而不是测试用例中。 见下文

下载免费测试计划模板

编写GUI测试用例的最佳实践

在测试用例设计中应用“最佳实践”可以帮助提高测试质量。以下是让您的GUI测试案例更易于维护和执行的建议。

将测试数据与测试用例分开

将测试数据与测试用例分开将使它们更易于维护。例如，“有效的用户名和密码”测试用例不应包含实际的用户名和密码数据值。相反，这些数据值应保存在电子表格或数据库中 - 无论是手动还是借助测试自动化软件执行GUI测试。同样，从测试用例中分离有关环境的信息也是一个好主意。如果团队决定在新平台上进行测试，则无需更改测试用例本身。

保持测试案例模块化

尽可能保持测试用例的模块化，以便它们可以按任意顺序执行。这更接近地模仿实际的用户体验，因为用户并不总是按照开发人员期望的顺序浏览应用程序。在基于云计算的购物应用程序中，不要写一个大的测试用例来购买商品。相反，可以为事件创建单独的测试用例，例如搜索项目，将项目添加到购物车，从购物车删除项目以及更新购物车中的项目数量。这样可以更轻松地测试事件组合，例如用户在将几件商品添加到购物车后返回搜索功能，而不是直接结账。

写出正面和负面的测试用例

一定要写正面测试和负面测试用例。正面的测试用例验证用户输入有效数据时AUT的行为。否定的测试用例验证AUT对无效数据的响应。例如，基于云的购物应用程序可能具有以下测试用例：

• 肯定的测试案例：在付款栏中输入有效的信用卡。如果AUT接受有效的付款方式，则测试成功。
• 否定测试用例：在付款字段中输入无效的信用卡。如果AUT给出指定的错误消息，则测试成功。

使用测试启发式

为测试用例创建数据时，使用测试启发式是很有用的。例如，为数据字段中的最大值和最小值创建测试数据。或者，在针对数据库测试查询时，对返回零行，一行或多行的查询进行测试。有关测试启发式技术的更多示例，请参阅 敏捷测试专家Elisabeth Hendrickson 的  测试启发式备忘单。

如何编写GUI测试脚本

测试脚本为测试人员提供了一个明确定义的过程。测试脚本可能包含以下信息：

测试脚本ID	测试脚本的唯一标识符。
标题	测试脚本的标题，例如“用户输入有效的用户名和密码，最大长度”。
测试用例ID	指向测试用例的唯一ID的链接。
测试设置	对测试环境的要求; 可以单独存储在测试数据电子表格中。
数据	要么是测试者输入的文字值; 或指向包含用户名和密码组合的外部电子表格或数据库的链接以进行测试。
程序	测试仪的分步说明，例如以下示例： 启动AUT。出现登录屏幕。 点击用户名字段。 从电子表格中输入第一个用户名。 从电子表格输入密码。 点击登录按钮。
实际结果	测试完成后由测试者完成。
状态	测试脚本的通过/失败/阻塞状态。
缺陷交叉引用*	如果发现缺陷，请在此输入缺陷跟踪系统中的代码，以将测试案例与缺陷相连接。

创建足够的测试脚本来验证用户将通过AUT的最常用路径。