测试推动 Web 持续发展

由于不同浏览器的 HTML5 引擎在品质和正确性方面仍然存在巨大差异，因此我们将继续为 W3C 正在开发的测试套件做出自己的贡献，以进一步实现 Web 平台互操作性和相同标记的目标。我们一共向其提交了 7573 项测试，您也可以在 IE 测试中心查看这些测试。随着各种浏览器相继改善对相同标记的支持，我们最终将获得一致的效果，共同实现对 HTML5 许下的承诺。

本篇博文的标题参考了 Adobe 于 6 月 15 日和 16 日在其旧金山总部举办的周末活动。在这次活动中，数十位志愿者向来自 Adobe、Google、Mozilla、Apple、HP 和 Microsoft 的 W3C 专家和成员悉心讨教，认真学习如何进行 Web 标准测试、如何编写 CSS 和 SVG 测试、如何创建优秀的 bug 报告，并详细了解用于管理测试套件的工具。

活动后来进入了“编程马拉松”测试环节，大家一边享用免费的食品和饮料，一边写了一整天的测试程序。志愿者们花了周六大部分时间编写了一些针对 CSS OM、[Transforms]（变换）、[Backgrounds & Borders]（背景和边框）、[Exclusions]（环绕）、SVG 和其他模块的新测试用例，其中的佼佼者最后还获得了若干奖项的提名。

测试 Web 标准

Adobe 的 Alan Stearns 向活动参与者们介绍了 W3C 测试的一般原则以及测试在推动规范发展的过程中扮演的角色。特别地，针对指定的规范建立浏览器的单项通过率并不是 W3C 测试套件的目标。为了使规范成为 W3C 建议，工作组必须证明规范是可实施的。在实践上，这意味着：

  • 针对规范中的每个要求（称为“标准化声明”）创建测试用例
  • 验证至少有两个单独的实施通过了每个测试

请注意“至少两个浏览器必须通过整个测试套件”和“至少两个浏览器必须通过测试套件中的每个测试”之间的区别。浏览器测试人员通常将该句子描述为“测试该规范”。

然而，该测试过程的一个重要副作用就是建立可据其开发和测试所有浏览器的通用交互基准。测试套件有助于跨所有浏览器找到 bug，而且有时能识别规范中的问题。

编写 CSS 和 SVG 测试

有三种类型的测试：

W3C 的 Doug Schepers 仔细讲解了 SVG 测试，同时 Adobe 的 Rebecca Hauck 和 Jacob Goldstein 提供了测试编写教程。CSS 工作组联席主席 Peter Linss 深入介绍了 CSS 测试框架，包括测试套件构建系统和管理工具（如 Shepherd）。

创建优秀的 Bug 报告

Mozilla 的 Elika Etemad 为活动参与者给出了关于如何创建优秀的浏览器 bug 报告的建议：

  • 问题是特定的、可复现的
  • 识别版本和平台
  • 已寻找了重复之处
  • 包含重现问题的步骤
  • 描述预期和实际结果
  • 如果可能，已简化问题，即已从问题页面删除重现问题所不需要的所有 HTML、JavaScript 和 CSS 部分，而且剩余部分已附加到 bug。

构建测试套件

构建测试套件需要大笔投资。CSS2.1 需要较长时间才能达到“推荐”阶段的原因之一，就是规范的规模以及所需测试的基本要求数量过于庞大。该测试套件的最新版本包含 9422 个测试。

Microsoft 贡献了这些测试中的 7000 多个，而且我们正在继续针对其他标准规范贡献更多测试。

在 IE10 中，我们已经增加了对跨 CSS、HTML、SVG 和 DOM 的众多新标准功能的支持。我们已在我们的 IE 测试中心发布了一些针对这些新功能的测试用例。我们将继续提交更多测试用例，尤其是针对 IE10 Release Preview 中近期无前缀的那些功能。

您如何贡献自己的力量

我们都为自己身为改进 Web 互操作性的团体的一员而感到由衷自豪。如果您致力于推动 Web 发展，同时也会有助于互操作性迈上新台阶。您可以了解如何贡献测试，或者查看现有测试。有关详细信息，请参阅 CSS WG wiki 以及本次活动的相关网页。

将来举办活动时，我们会及时通知您。

—Sylvain Galineau，Internet Explorer 项目经理；以及
—John Jansen，Internet Explorer 测试主管

  • Last updated on