PDF使用自动化测试查找可用性错误
自动化可用性测试可以成为人工测试的宝贵补充。
Julian Harty，eBay
理想情况下，所有软件都应该易于使用，并可供广泛的人群访问；然而，即使是看起来现代且直观的软件，也常常达不到最基本的可用性和可访问性目标。为什么会这样呢？一个原因是，有时我们的设计看起来很吸引人，因此我们跳过了测试其可用性和可访问性的步骤——所有这些都是为了追求速度、降低成本和竞争优势。
即使是来自互联网公司的大型应用程序，也为某些用户群体带来了根本性的障碍，而小型网站也好不到哪里去。因此，我们需要方法来帮助我们高效且有效地发现这些可用性和可访问性问题。
可用性和可访问性是衡量软件质量的两种方式。本文介绍了自动化测试如何在基于Web的应用程序中帮助识别问题和局限性，修复这些问题可以使软件更易于使用和/或访问。这项工作是对其他人性化可用性测试的补充，而不是取代。无论人工测试多么有价值，有效的自动化都能够通过扩展其范围和幅度来增加整体测试的价值。对大量网页进行最少人工干预的自动化测试在人员方面是不可行的。相反，人们能够发现许多难以编程计算机来检测的问题。
许多组织根本不做任何可用性或可访问性测试；通常，它被认为太昂贵、太专业，或者是在测试完所有“功能”（由于时间和其他资源限制，这种情况很少完成）之后才需要解决的事情。对于这些组织来说，良好的测试自动化可以在几个方面提供帮助。自动化测试可以通过提供关于正在编写的软件的信息来指导和告知软件开发过程。这种测试有助于软件的创建者快速修复问题（因为他们有快速、可见的反馈）并更有信心地进行实验。它还可以通过快速且一致地评估每个版本，来帮助识别各种内部版本中的潜在问题。
一些可用性专家发现将自动化测试纳入他们的工作是陌生的、不舒服的，甚至是不必要的。有些人可能已经在使用静态分析工具，如Hera和Bobby，来检查是否符合WCAG（Web 内容可访问性指南；）和Section 508，但尚未开始使用动态测试自动化工具。结果，他们捕获了一些问题，但错过了其他问题（本文后面给出的几个例子就是这种情况）。
本文的一个目的是鼓励读者简单地尝试应用一些自动化测试，看看它们是否有助于发现可能值得修复的问题。
为什么可用性和可访问性测试如此困难？
很明显，今天的公司在可用性和可访问性测试方面做得不够，部分原因是这可能很难完成。以下是几个原因。
当用户的需求与我们不同时，通常很难理解用户在与软件交互时的挫败感。例如，如果我是一个20多岁、视力和行动能力良好的人，一个极其详细的多层用户界面可能非常适合我。但是，能力不同的用户呢？他们会觉得沮丧，甚至可能无法使用吗？找到适应各种用户的方法是具有挑战性的，特别是对于那些在接受来自盲人用户和运动障碍人士等群体的免费帮助方面存在问题的公司。尽管拒绝这种帮助可能看起来不合逻辑，但准备工作、运输、调整办公环境以适应访客等后勤工作可能会让那些已经有很多时间有限和资源有限的需求的人感到沮丧。
有各种各样的设备连接用户和应用程序之间的差距——从鼠标和键盘，到屏幕阅读器，再到为严重障碍人士调整用户界面的专用设备。除非我们有过使用这些工具的经验，否则很难想象它们在实践中是如何工作的，以及它们如何影响用户使用我们应用程序的体验。此外，UI工具的开发者很少提供功能接口来支持测试自动化或屏幕阅读器——这使得两者都难以实现。
在我看来，可用性测试本身并不难，但当它需要人工观察使用正在评估的软件的人时，它往往耗时且难以扩展。此外，由于软件开发人员似乎觉得这项工作琐碎或无关紧要，他们可能会在第一个障碍上失败：决定测试工作是否值得投资。
测试自动化的困难
除了可用性和可访问性测试中的基本挑战之外，开发良好的自动化测试框架也存在挑战。尽管存在一些有趣的学术研究专注于自动化测试，但作为一个行业，我们发现很难将学术工作转化为实际价值。来自学术界的知识和工具的共享受到限制，因为公司首先需要付费才能访问许多论文，然后将这些论文的正式结构转化为对他们有意义的东西。这些解决方案还必须解决问题“这能解决我今天的一些直接问题吗？”中隐含的期望。使事情复杂化的是，商业自动化测试工具提供商倾向于保护他们的测试和方法，因为他们认为这具有竞争优势。
许多测试自动化框架没有被定期使用，从从业者的意义上来说，他们实际上一次又一次地运行自动化测试。此外，根据我的经验，许多框架甚至没有被他们的作者使用。它们被编写一次——也许是为了让作者从他们的经理那里获得良好的绩效评估，而不是为他们的项目提供实际价值——然后就废弃不用了，因为没有人看到这项工作的价值或愿意支持它。长期测试自动化往往会遭受脆弱性、可维护性差和软件工程实践不足的困扰。良好的测试自动化就像良好的软件开发一样，需要类似的技能、实践和热情来创建和维护它。
测试自动化的另一个困难是找到那些“困扰”人们到值得修复程度的错误，而不是那些将被忽略的错误，因为用户不太可能遇到它们，或者因为开发人员看不到修复它们的价值。
另一个挑战是将所有各种Web浏览器与测试自动化软件集成。每个浏览器都是不同的，需要特殊的代码才能与自动化测试一起使用。这段代码可能相当复杂且难以编写。开发人员已经启动了各种仅使用单个浏览器的项目，但发现尝试将其工作扩展到其他浏览器的开销比他们准备的要复杂和耗时得多。
最后，许多测试自动化工具仍然需要用户具备技术和编程技能（例如，Java、Maven、JUnit、IDE等）才能编写测试。对于开源项目，最初的学习曲线可能太陡峭，无法在您的计算机上运行该软件。一些公司试图简化测试自动化，以便没有编程背景的人也可以编写测试，但这些尝试往往弊大于利。
自动化测试的例子
2009年，我帮助测试了Google的几个全球软件应用程序。它们是使用GWT（Google Web Toolkit）构建的，这是一个非常强大的开发框架，允许开发人员创建跨浏览器Web应用程序，并向开发人员隐藏许多复杂性。由此产生的应用程序看起来时尚而现代，每个应用程序都有数百万用户。
开发团队估计GWT在将他们的应用程序投入生产方面节省了数人年的工作。然而，团队使用GWT的方式导致了一些副作用，最终导致了可用性和可访问性问题，例如键盘导航中断和对屏幕阅读器的支持不佳。我们发现其他使用其他框架和方法的应用程序也存在类似的问题，这表明这些问题可能在整个行业中普遍存在。
我的主要目标是确定我们是否可以创建自动化测试，以帮助识别可能影响用户群体使用质量的潜在问题，特别是在软件的动态使用方面。正如本文前面提到的，一些标准（例如，Section 508）和指南（例如，WCAG）旨在帮助解决可访问性的基本问题，并且有大量的软件工具可用于测试Section 508和WCAG的合规性。然而，似乎没有一个专注于应用程序的使用质量。
此外，我的工作需要提供积极的投资回报率（ROI），以及实用和有用。
测试键盘导航
可用性和可访问性测试的一个方面是键盘输入和导航（而不是依赖鼠标或触摸屏）。我决定专注于寻找使用自动化软件工具测试键盘导航的方法。这项工作始于一个简单但有效的启发式方法：当我们通过用户界面进行选项卡切换时，我们最终应该返回到我们开始的地方——通常是Web浏览器中的地址栏或具有初始焦点的输入字段（例如，Google Web搜索的搜索框）。
最初的测试包含大约50行Java代码。它通过将每个访问元素的背景设置为橙色，提供了导航的高度可见指示；每个元素还被分配了一个升序数字，表示到达该点所需的选项卡数。图1中的屏幕截图显示了浏览Google搜索结果的示例。选项卡顺序首先浏览主要的搜索结果；接下来，它选项卡浏览右侧的广告，然后是左侧的列；最后一个元素是“高级搜索”链接，大约在130个选项卡之后到达！代码跟踪选项卡的数量，如果它们超过指定的值，则测试失败；这可以防止测试无限期地运行。
此测试帮助突出了几个关键问题，例如黑洞，即“吞噬”所有击键的Web元素。它还帮助识别通过选项卡切换页面无法到达的Web元素。我们的成功是通过修复的错误百分比以及导航用户界面所需的击键次数减少来衡量的。
几个GWT框架包括自定义元素，例如按钮。开发人员可以将JavaScript处理程序附加到这些元素，以处理特定的击键。我们发现了一个严重的错误，即JavaScript错误地丢弃了所有其他击键（除了它旨在处理的特定击键）。这意味着一旦用户导航到该按钮，他或她就无法使用键盘离开（即，选项卡字符被静默丢弃）。
我们在自动化测试中使用了一个启发式方法，假设如果用户按下Tab键足够多次，用户最终应该返回到他或她在用户界面中开始的位置。该测试包括一个“最大选项卡数”参数。我们将其设置为Web页面上Web元素数量的三倍，以平衡确保我们不会在到达合法页面的末尾之前“用完”选项卡，以及如果我们不限制击键次数，测试会永远持续下去。如果测试未能返回到初始元素，则测试失败。此测试能够检测到由错误的JavaScript引起的黑洞。该问题最终通过更改底层自定义GWT框架中的代码得到修复。
我们发现的第二个问题是使用键盘无法到达的“新消息”按钮。这对于开发团队来说很尴尬，因为他们为自己开发了针对他们的新颖应用程序的“高级用户”界面而感到自豪。测试的一个方面是，它将访问的每个Web元素的背景颜色设置为橙色。我们能够通过交互式观看测试运行并看到“新消息”按钮从未突出显示来发现问题。我们能够通过查看测试自动化代码保存的屏幕截图（它保存了页面图像和DOM（文档对象模型），以便我们可以可视化底层HTML内容）来发现类似的问题。
第三个问题更隐蔽，最初更难检测。GWT在Web页面中使用一个隐藏的IFRAME来存储用户访问的Web页面的历史记录（因此用户可以使用浏览器导航控件，如“后退”）。然而，我们发现，初始选项卡字符之一被定向到隐藏的IFRAME。这使用户感到困惑，因为光标消失了，而且也很烦人，因为他们必须按下一个额外的选项卡字符才能到达他们想要在用户界面中到达的位置。一旦问题被发现，修复就很简单：向隐藏的IFRAME添加一个TABINDEX=“-1”属性。
我们考虑的下一个启发式方法是，向前（Tab）和向后（Shift+Tab）击键的选项卡数之和应该相同。测试的第一部分使用了与初始启发式方法相同的代码，其中为每个访问的元素递增发出的选项卡计数。一旦测试到达最初选择的元素，它就开始生成Shift+Tab键盘组合，这导致导航反向进行。同样，Shift+Tab击键的次数也被计数。每次访问元素时，在该元素的标题属性中设置的值都会添加到计数器的当前值中。对于访问的每个元素，选项卡顺序的总和应该相同。如果不是，则用户界面中存在滞后环路，表明存在潜在的值得调查的问题。图2和图3显示了每个访问元素的选项卡计数。我们可以看到，给定Web元素的每对值加起来都为9（例如，按钮B的计数为：4 + 5 = 9；按钮A的计数为：6 + 3 = 9，等等）。因此，此测试通过。[注意：这些图不包括浏览器地址栏等所需的额外选项卡。]
最后的启发式方法是，导航流程应与规则模式匹配，例如向下输入字段的逻辑列，然后向右和向上到下一列的顶部。图4显示了两个典型的流程。
在这里，我们可以通过获取Web页面上每个元素的（x，y）位置来检测是否遵循了预期的模式。该模式可以是显式的（如果我们知道我们想要或期望什么）或隐式的（例如，基于相似Web页面的行为方式）。可以使用容差来允许对齐中的细微变化（我们认为这些变化是可以接受的）。
我们的自动化测试依赖于WebDriver，现在它是开源Selenium测试自动化项目的一部分，被称为Selenium 2.0。WebDriver旨在像人一样与给定的Web浏览器交互；例如，击键和鼠标单击是在操作系统级别生成的，而不是在Web浏览器中合成的。我们将其描述为生成本机事件。有时，由于特定操作系统或Web浏览器的技术限制，WebDriver无法生成本机事件，并且必须通过使用替代输入方法进行补偿。但是，对于键盘导航测试，生成本机事件对于建立测试的保真度至关重要。
WebDriver适用于大多数流行的桌面Web浏览器，例如Firefox、Internet Explorer、Opera等，甚至包括Android、iPhone和BlackBerry设备上的Web浏览器。这种广泛的覆盖范围意味着我们可以在最流行的浏览器上运行我们的测试，这有助于提高测试的实用性。
查找布局问题
布局问题是一个可能对用户对应用程序的感知产生不利影响的领域，并且可能通过分散或挫败用户的注意力而间接降低其可用性。有许多类问题可能导致不良布局，包括特定Web浏览器中的怪癖、开发人员和设计师犯的错误以及不良的工具和库。将应用程序从英语本地化为德语等文本通常更大量的语言是某些布局问题的可靠触发器。许多这些问题一直难以自动检测，传统上我们一直依赖人工来发现和报告它们。
这种情况在2009年发生了变化，当时我遇到了Michael Tamm，他创建了一种创新的方法，可以自动且简单地检测几种类型的布局错误。例如，他的一个测试以编程方式将页面上的文本颜色切换为白色，然后再切换为黑色，并在两种情况下都截取屏幕截图。生成两个图像之间的差异，这有助于识别页面上的文本。然后，各种算法检测Web页面上的水平和垂直边缘，这些边缘通常代表文本框和输入字段等元素。然后，文本的差异有效地叠加在边缘模式上，以查看文本是否与边缘相遇，甚至重叠。如果是这样，则存在潜在的可用性问题，值得进一步调查。这些测试捕获并注释屏幕截图；这允许某人快速查看潜在问题，并确定它们是否严重。
对于用WebDriver编写的现有测试，通过添加几行源代码即可启用布局测试。对于新的自动化测试，在运行测试之前，需要编写一些代码来导航到要测试的Web页面。（有关更多信息，请参见此处，包括Tamm解释其工作的视频、示例代码等。）
展望未来
我们迄今为止的工作是有用的，我希望继续实施测试自动化以支持与Web应用程序的动态方面相关的其他启发式方法。WebDriver包括对触摸事件的支持以及对流行的移动电话平台（如iPhone、Android和Blackberry）上的测试的支持。WebDriver可能需要进行一些额外的工作来支持跨各种移动平台的测试矩阵，尤其是在它们经常更新的情况下。
我们还在考虑编写测试以在Web浏览器中交互式运行；2009年，一位同事为Google的Chrome浏览器创建了一个概念验证。这项工作将减轻运行测试的技术知识负担。最后一个感兴趣的领域是为WAI-ARIA（Web 可访问性倡议 - 无障碍富互联网应用程序； ）和此处描述的测试添加测试。
我们通过开源工作积极鼓励知识和工具的共享，欢迎其他人贡献其他测试和示例。
结论
自动化测试可以帮助捕获多种类型的问题，尤其是在组合使用多种技术和方法时。最好记住这一点，以便我们知道这些自动化测试在我们整体测试方法中的位置。
关于我们在Google网站上进行的自动化测试，编写的代码量的投资回报率证明了这项工作的合理性。运行测试发现了在几个前沿Google属性和工具中修复的错误。保守地说，由于使用此测试自动化发现和修复的问题，数百万Web请求的页面权重已降低。对于那些需要或喜欢使用键盘导航的人来说，键盘导航也得到了改进。
测试自动化是不完善且有限的，但它可以有效地捕获各种会绊倒您某些用户的问题。这项工作是对其他形式测试的补充，有助于快速、经济高效且可靠地告知项目团队和可用性专家潜在问题。
问
致谢
感谢Google允许原始工作开源，感谢eBay支持正在进行的工作，感谢Jonas Klink的贡献，并感谢为本文做出贡献并提供想法的各位人士。如果您有兴趣为该项目做出贡献，请联系作者：[email protected]。
延伸阅读
Steve Krug的作品是对自动化测试的极佳补充。他撰写了两本关于该主题的书籍：《火箭手术变得简单》（http://www.sensible.com/rocketsurgery/index.html）和《别让我思考》，其中关于用户测试的三个章节可从http://www.sensible.com/secondedition/index.html免费下载。
喜欢它，讨厌它？请告诉我们
Julian Harty是eBay的资深测试员，他在那里致力于提高组织内测试的效率和效力。他热衷于寻找使技术为用户工作的方法，而不是迫使用户适应（糟糕的）技术。他的许多资料都可以在网上找到。他是一位经常发言的人，并撰写关于技术、软件测试、移动、可访问性等一系列主题的文章。
版权归作者所有。
最初发表于 Queue 第 9 卷，第 1 期—
在 数字图书馆中评论本文
更多相关文章
Vinnie Donati - 驱动组织可访问性
在本文中，我们将探讨微软如何在整个组织中驱动可访问性，并仔细研究促进包容性文化的基本框架和实践。通过检查诸如意识建设、战略发展、可访问性成熟度建模等方面，我们旨在为开始其可访问性之旅的组织提供指南。其理念是分享我们所学到的知识，希望您可以采纳它，对其进行调整以适应您公司的目标，并以不仅仅是打勾活动的方式，而是真正融入您的文化的方式来培养可访问性。
Shahtab Wahid - 设计系统是可访问性交付工具
设计系统是为消费者（设计师和开发人员）构建的基础设施，他们正在开发应用程序。一个成功的系统允许组织中的消费者快速扩展跨应用程序的设计和开发，提高生产力并建立一致性。然而，许多消费者没有准备好为可访问性构建。组织能否使应用程序的可访问性支持构建具有可扩展性、生产力和一致性？本文探讨了设计系统如何成为支持可访问性的重要工具。
Juanami Spencer - 移动应用程序的可访问性考虑
在创建移动应用程序时，考虑可访问性至关重要，以确保尽可能广泛的受众可以使用和享受它们。与桌面体验相比，移动可访问性具有独特的考虑因素，但它为那些在日常活动中依赖移动设备的用户提供了巨大的价值。通过牢记这些考虑因素，移动产品开发团队可以更好地支持和改善所有用户的生活。本文探讨了移动应用程序的一些关键可访问性考虑因素，并重点介绍了 Bloomberg Connects 应用程序如何在产品和流程中支持可访问性。
Chris Fleizach, Jeffrey P. Bigham - 系统级可访问性
本文通过我们使iPhone能够使用VoiceOver屏幕阅读器以非视觉方式使用的工作来说明系统级可访问性。我们重新构想了非视觉使用的触摸屏输入，引入了适用于屏幕阅读器控制的新手势，并且为了输出，我们添加了对合成语音和可刷新的盲文显示器（输出触觉盲文字符的硬件设备）的支持。我们添加了应用程序可以采用的新可访问性API，并使我们的用户界面框架默认包含它们。最后，我们添加了一个可访问性服务，以桥接这些新的输入和输出与应用程序之间的联系。
© 保留所有权利。