用户界面(UI)测试初学者指南
本指南介绍了有关GUI测试的关键问题:它是什么?它为什么如此重要?什么是主要的GUI测试类型和技术?阅读此综合指南以发现这些问题的答案,并学习如何创建GUI测试计划并编写GUI测试用例。
什么是GUI测试?
在当今的GUI测试环境中,“简单计算器应用程序”不再局限于计算机的桌面。它可能是在所有主要移动平台上可用的移动应用程序。或者,它可能是所有主流浏览器都必须支持的云应用程序。测试人员必须执行跨浏览器和跨平台测试来识别缺陷并确保应用程序满足所有要求。
因此,GUI测试是指测试用户可见的应用程序的功能。在计算器应用程序的示例中,这将包括验证应用程序是否正确响应诸如单击数字和功能按钮等事件。GUI测试还会确认外观元素(如字体和图像)符合设计规范。
UI测试与GUI测试一样吗?
学习软件测试的一个挑战是行业中有许多术语,这些术语通常意义重叠或使用不一致。
例如, 用户界面(UI)测试 类似于GUI测试,并且这两个术语通常被视为同义词。但是,UI是一个更广泛的概念,可以包括GUI和命令行界面(CLI)。CLI允许用户通过文本命令和响应与计算机系统进行交互。虽然CLI早于图形用户界面,但它们现在仍在使用中,并且通常受系统管理员和开发人员的青睐。GUI测试还会确认外观元素(如字体和颜色)符合设计规范。
小费
GUI测试在软件开发生命周期中的位置在哪里?
测试级别
组件测试
组件测试检查单个代码单元。组件测试通常被称为 单元测试,但也可能被称为 模块 测试或 程序测试。开发人员编写并执行单元测试,以便在开发过程中尽早发现并修复其代码中的缺陷。这在敏捷开发环境中非常重要,因为短版本周期需要快速的测试反馈。单元测试是白盒测试,因为它们是用被检查代码的知识编写的。
集成测试
集成测试结合了各个单元并测试它们的交互。一种常见的集成测试类型是 接口/ API测试。应用程序编程接口(API)是两组代码用于相互通信的一组规则。接口/ API测试验证了这种交互。由于API规则在任何给定的应用程序中都非常稳定,因此API测试是自动化的理想选择。Interface / API测试也是 白盒测试, 因为它们需要知道被检查的代码。
系统测试
验收测试
测试类型
功能测试
非功能测试
结构测试
回归测试
端到端测试
为什么GUI测试很重要?
在软件开发中, 质量 被定义为提供具有功能和易用性的应用程序,以满足客户的需求,并且尽可能没有缺陷。
有人说,“你不能把质量检验到产品中。质量在那里,或者不在它被检查的时候。“这个报价是关于测试完成的产品,如汽车,但是这个原则也适用于软件开发。
为了提高质量,开发团队从一开始就试图将其融入到他们的项目中。这样做的一种方法是在软件开发生命周期中提前进行测试,这种方法也称为Shift Left测试。
开发团队并没有在应用程序完成后等待系统测试,而是增加了在单元和接口测试中花费的时间和资源。在开发过程中及早发现错误可降低解决这些问题的成本。此外,单元和接口/ API测试非常适合自动化:单元测试可以由开发人员在编写时创建,而API往往非常稳定,因此比GUI测试需要更少的维护。
强调Shift Shift测试,似乎GUI测试并不重要。毕竟,手动GUI测试可能需要耗费大量资源。对于GUI来说,测试自动化更具挑战性:由于用户界面可能会经常更改,因此以前的自动GUI测试可能会中断,需要花费大量精力来维护它们。
但单元和界面测试无法评估系统的所有领域,特别是工作流和可用性的关键方面。特别是,这些测试只能验证存在的代码。他们无法评估可能缺失的功能,或者应用程序的可视元素和易用性问题。这是GUI测试的价值,它是从用户而不是开发人员的角度来执行的。通过从用户角度分析应用程序,GUI测试可以向项目团队提供他们需要的信息,以决定应用程序是否已准备好部署。
什么是主要的GUI测试技术?
脚本测试
脚本化测试的好处
脚本化的测试挑战
探索性测试
探索性测试人员不是遵循预先编写的测试脚本,而是利用他们的知识和经验来了解AUT,设计测试,然后立即执行测试。分析结果后,测试人员可以确定要执行的附加测试和/或向开发人员提供反馈。
虽然探索性测试不使用详细的测试脚本,但仍有预先规划。例如,在 基于会话的探索性测试中,测试人员创建一个称为测试章程的文档 来为计划测试设置目标,并为一段重点探索性测试设置一个时间框架。探索性测试会议记录在会议报告中,并在随后的汇报会上进行审查。
同样,在脚本测试期间,测试人员可能会做出一些决策,包括能够即时创建新测试。出于这个原因,将脚本化测试和探索性测试视为连续统的两端而非极性对立是有帮助的。
脚本和探索性测试都可以是完全手动的,或者可以通过自动化辅助。例如,探索性测试人员可能决定使用测试自动化对一系列数据值进行一系列测试。
探索性测试的好处
探索性测试挑战
用户体验测试
在用户体验测试中,实际最终用户或用户代表评估应用程序的易用性,视觉吸引力和满足其需求的能力。测试结果可能会在用户现场探索应用程序时通过实时观察来收集。这种类型的测试越来越多地使用基于云的平台进行。作为替代方案,项目团队可以进行beta测试,其中完整或近乎完整的应用程序可供其终端用户在其位置进行临时测试,并通过反馈表单收集响应。就其性质而言,用户体验测试是手动和探索性的。
不要混淆用户体验测试(UX)和用户验收测试(UAT)。如前所述,UAT是一个测试级别,用于验证给定应用程序是否符合要求。例如,假设在更新发布到购物网站后不久,该网站收到许多投诉,即客户无法将商品保存到愿望清单。但是,UAT验证了按下“愿望清单”按钮可正确添加项目到愿望清单。那么,怎么了?UX测试可能显示愿望列表按钮未正确放置在屏幕上,导致购物者难以找到。
您可以在需要用户反馈的开发阶段的任何时间进行UX测试。在涉及用户之前,没有必要拥有完整的应用程序。例如,焦点小组可以在开发早期响应应用程序的屏幕模型或虚拟漫游。
用户体验测试的好处
用户体验测试挑战
什么是我的应用程序最好的GUI测试技术?
如何编写GUI测试计划
测试计划定义了关键信息,包括:
- 测试的预期日期
- 所需人员
- 所需资源,如物理硬件,虚拟或基于云的服务器以及自动化软件等工具
- 目标测试环境,例如台式机,移动设备或支持浏览器的网站
- 要测试的AUT的工作流程和事件,以及AUT的视觉设计,可用性和性能。
- 计划的测试技术,包括脚本测试,探索性测试和用户体验测试。
- 测试目标包括确定整体测试成功或失败的标准。
识别要测试的区域
有几种方法可以识别要测试的用户界面区域。如果规范文件可用,这是一个开始的好地方。如果说明文件不可用或不完整,则有用的方法是进行头脑风暴/概念图映射会话以确定要测试的区域。
下面的列表可以帮助你开始头脑风暴会议:
- 视觉设计
- 功能
- 性能
- 安全
- 可用性
- 合规
示例区域以测试Web导航
- 与所有常见浏览器兼容
- 当用户点击后退按钮或刷新按钮时,正确运行页面
- 用户使用书签或其浏览器历史记录返回页面后的页面行为
- 用户同时在AUT上打开多个浏览器窗口时的页面行为。
确定基于风险的测试的测试用例的优先级
由于测试资源经常有限,因此优先考虑测试区域可能会有所帮助。 基于风险的测试 使用分析潜在缺陷的相对风险来选择测试的优先级。使用类似于下面的矩阵完成风险分析。在这个矩阵中,频率 栏描述了用户可能遇到潜在缺陷的 频率,其中包括功能的可见度和使用频率。每个 Impact 列描述缺陷对用户的影响。频率和影响的结合决定了风险水平。规划回归测试
如前所述, 回归 测试有助于确保新的缺陷尚未引入到以前的代码中。使用诸如Ranorex Studio之类的测试自动化工具可以显着增加可以在测试窗口中完成的回归测试用例的数量。但是,即使在自动化的情况下,为新版本重复以前的所有测试用例也许是不切实际的。下面列出了最重要的回归测试用例。
最重要的回归测试案例是那些:
- 有最高风险
- 提供最大范围的代码
- 根据前几轮测试中发现的每个测试案例的缺陷数,可能会发现最多的缺陷。
烟雾和健康测试
- 烟雾测试 检查应用程序的基本功能。例如,烟雾测试将验证AUT可以启动并且用户可以登录。冒烟测试是 浅,因为它没有深入测试系统的任何一个环节,它也是 广 ,因为它涵盖尽可能多的主要功能成为可能。这个名字来源于开启一块新硬件的做法,看它是否着火。如果没有,可以继续进行其他测试。
- 完整性测试 检查新的或修改过的代码,以确保它不会导致任何重大问题并且符合规范。与浅层 和 宽层 烟雾测试相比 ,健康测试的范围 狭窄 而 深远。
如何编写GUI测试场景
一个 测试场景 是如何应用程序将在现实生活中使用的简短声明,如“用户将能够使用有效的用户名和密码进行登录。”测试场景可以从开发文档,如要求被写入,验收标准和用户故事。在没有这些文件的情况下,可以与开发人员和客户/客户代表协商开发情景。
场景可以指导探索性测试,让测试人员了解要测试的GUI事件,而不会将其限制为特定的过程。场景在敏捷环境中也越来越流行,因为创建一个简短的场景比写出完整的测试案例要快得多。
场景不需要创建GUI测试用例,但有助于指导他们的开发。如果场景用于脚本化测试,那么它们可以作为开发测试用例的基础,如右图所示。
测试场景(如果使用的话)指导测试用例和测试脚本的开发。
例如,上面的“登录”场景可能有GUI事件的测试用例,如下所示:
- 用户输入有效的用户名和密码
- 用户输入无效用户名
- 用户输入有效的用户名但密码无效
- 用户尝试重置密码
- 用户尝试将密码从密码字段复制或复制到密码字段
- 用户按下帮助按钮
如何编写GUI测试用例
是否编写一般或详细的程序取决于以下因素:
- 测试人员的经验水平,包括GUI测试和一般测试的特定应用程序。经验不足的测试人员可能需要更详细的程序。
- 用户界面多久改变一次。如果界面变化频繁,维护详细的程序需要更多的努力。
- 最终用户在浏览应用程序时将拥有多少自由。如果用户有很大的自由度,你可以编写程序来覆盖所有可能的导航路径,或者依靠测试人员预测用户可能采用的随机路径的能力。
在GUI测试案例中包含什么
测试用例中最基本的信息是对要测试的GUI事件的描述,执行测试的条件以及预期结果。为了使测试案例更易于管理,包含附加信息(如链接到需求文档和/或缺陷跟踪系统)会很有帮助。
例如,上面的“有效用户名和密码”测试用例可能包含以下信息:
测试用例ID | 测试脚本的唯一标识符。 |
标题 | 测试脚本的标题,例如“用户输入有效的用户名和密码,最大长度”。 |
方案/需求ID | 链接到测试场景或需求文档的唯一ID(如果适用)。 |
优先级/风险级别 | 关键,高,中,低。 |
技术 | 脚本化,探索性的UX |
描述 | 测试用例的简要说明,例如“用户尚未登录时,确保用户可以使用任何有效的用户名和密码字符组合(包括特殊字符)登录。确保密码是隐藏的,除非用户选择使其可见 |
数据源* | 外部电子表格或包含用户名和密码组合的数据库进行测试 |
程序* | 执行测试时测试人员要遵循的步骤列表 |
预期结果* | 成功,出现应用程序主窗口 |
实际结果* | 测试完成后由测试者完成 |
状态 | 测试用例的通过/失败/阻塞状态。 |
缺陷交叉引用* | 如果发现缺陷,请在此输入缺陷跟踪系统中的代码,以将测试案例与缺陷相连接。 |
*如果您选择编写测试脚本,则此信息将显示在测试脚本中,而不是测试用例中。 见下文
编写GUI测试用例的最佳实践
在测试用例设计中应用“最佳实践”可以帮助提高测试质量。以下是让您的GUI测试案例更易于维护和执行的建议。
将测试数据与测试用例分开
保持测试案例模块化
写出正面和负面的测试用例
一定要写正面测试和负面测试用例。正面的测试用例验证用户输入有效数据时AUT的行为。否定的测试用例验证AUT对无效数据的响应。例如,基于云的购物应用程序可能具有以下测试用例:
- 肯定的测试案例:在付款栏中输入有效的信用卡。如果AUT接受有效的付款方式,则测试成功。
- 否定测试用例:在付款字段中输入无效的信用卡。如果AUT给出指定的错误消息,则测试成功。
使用测试启发式
为测试用例创建数据时,使用测试启发式是很有用的。例如,为数据字段中的最大值和最小值创建测试数据。或者,在针对数据库测试查询时,对返回零行,一行或多行的查询进行测试。有关测试启发式技术的更多示例,请参阅 敏捷测试专家Elisabeth Hendrickson 的 测试启发式备忘单。
如何编写GUI测试脚本
测试脚本ID | 测试脚本的唯一标识符。 |
标题 | 测试脚本的标题,例如“用户输入有效的用户名和密码,最大长度”。 |
测试用例ID | 指向测试用例的唯一ID的链接。 |
测试设置 | 对测试环境的要求; 可以单独存储在测试数据电子表格中。 |
数据 | 要么是测试者输入的文字值; 或指向包含用户名和密码组合的外部电子表格或数据库的链接以进行测试。 |
程序 | 测试仪的分步说明,例如以下示例:
|
实际结果 | 测试完成后由测试者完成。 |
状态 | 测试脚本的通过/失败/阻塞状态。 |
缺陷交叉引用* | 如果发现缺陷,请在此输入缺陷跟踪系统中的代码,以将测试案例与缺陷相连接。 |
创建足够的测试脚本来验证用户将通过AUT的最常用路径。
来源:CSDN
作者:renshuaicsdn
链接:https://blog.csdn.net/renshuaicsdn/article/details/80661702