为设备测试带来理性和秩序

Aaron Gustafson

0/5 (0投票)

2015年7月10日

CPOL

12分钟阅读

8400

在面对网络连接设备数量的疯狂增长以及网站将走向何方的未知情况时，退一步思考什么才是重要的，是很有价值的。

似乎每隔一天，公众就会获得一种新的访问网络的方式。有时是一款新浏览器。有时是一款新智能手机。或者一款平板电脑。或者一款电子阅读器。或者一台视频游戏机。或者一款智能手表。或者一台电视。或者一款头戴式显示器。或者一辆汽车。或者一台冰箱。

我曾经参与过一个项目，客户提供了一份电子表格，详细列出了在两天内访问过该m点网站登录页面的1400种不同的用户代理。

作为进一步的证据，可以参考Jason Samuels在这篇博文中令人开眼界的内容，他来自一个非营利组织——美国家庭关系委员会。

2008年，“移动”设备的访问量仅占其流量的0.1%左右。到2014年，这一数字飙升至14.4%。
2008年，他们检测到了71种不同的屏幕分辨率，这已经很多了。然而，到2014年，他们每季度都能看到1000种独特的屏幕分辨率（其中200多种每季度记录到10次以上的访问）。

最后这个统计数据每次读到我都会感到震惊。你无法为200种不同的屏幕进行设计，更不用说1000种了。这是徒劳的。更不要想尝试在这么多设备上进行测试。

尽管如此，我们仍然在设计网站，这些网站能够（并将继续）被用于任何地方。我们需要进行彻底的测试，因为我们无法对访问我们内容的浏览器和设备进行任何假设。

测试可能很乏味、耗时且成本高昂。肯定有办法让它变得更容易。确实有：与其纠结于创建一个在每种浏览器上几乎都相同的体验，不如我们更聪明地构建事物，并将体验视为一个连续体。

我们可以构建既足够灵活，能在低带宽网络上运行于低功耗设备上，又足够智能，能在有机会时利用高级功能和传感器。

什么？！我们真的能两全其美吗？是的。是的，我们可以。

从坚实的基础开始

在面对网络连接设备数量的疯狂增长以及网站将走向何方的未知情况时，退一步思考什么才是重要的，是很有价值的。我们需要问自己两个简单的问题：

这个页面、这个表单、这个界面的目的是什么？
实现这个目标最简单的方法是什么？

然后我们需要先构建这个。通常我们说的是文本、一些基本的HTML、指向其他页面的实际链接，以及提交到某个后端处理的表单。这是我们的最小可行产品，它可以在任何地方工作。

然后，我们可以寻找增强体验的机会，同时将功能核心保持在体验的中心。

我们可以使用CSS为页面添加视觉层次结构，提供一些视觉趣味，并调整布局以在各种屏幕尺寸上创建良好的阅读体验。我们应该从我们能想象到的最窄的屏幕尺寸开始，并让内容指导我们的断点决策。

我们将使用JavaScript为用户提供实时反馈。我们将劫持表单和链接以延迟加载额外内容或避免完全页面刷新。甚至，我们可以接管整个页面并将其转换为单页应用。

但我们绝不应牺牲功能核心。

这种为网络设计的方法称为渐进增强，它是应对旧浏览器和设备激增这一组合拳的头号工具。

交付时要保守

渐进增强之所以在应对如此庞杂的设备和浏览器时如此有用，是因为核心体验始终可用。没有任何东西可以阻止我们的用户访问它，即使是在糟糕的WAP浏览器、文本浏览器如Lynx，甚至是一些并非遥远的未来但只将网络视为文本的智能设备上。

为了确保我们不会意外地向功能较弱的浏览器（如这些）提供高级功能，我们只需要智能地加载CSS和JavaScript等内容。

一些基本的CSS—例如排版、颜色等—几乎任何人都可以使用，所以我们可以将所有这些内容放在一个CSS文件中（例如basic.css），并使用标准的link标签包含它。然后，我们可以将所有布局规则和其他高级CSS放入一个单独的CSS文件中（例如advanced.css），并使用相关的媒体查询来链接它。

<link rel="stylesheet" href="default.css" media="all">
<link rel="stylesheet" href="advanced.css" media="only screen">

任何不理解媒体查询的浏览器将完全忽略第二个CSS文件，只接收线性、移动视图。简单易行，IE8也能获得移动布局（这是不太可能让你头疼的基线支持级别）。

你甚至可以更进一步，在advanced.css中使用@supports块，将某些规则集限制为仅支持特定CSS功能的浏览器。

当然，CSS支持问题与JavaScript相比微不足道，所以有时最好不要将某些基于JavaScript的功能提供给无法处理的浏览器。这就是功能（和对象）检测变得非常有用的地方。

if ( 'querySelector' in document ) {
    // We can use querySelector!
}

你还可以使用反向条件注释来阻止旧版本的IE获取JavaScript（这意味着你甚至不需要担心在那里调试JavaScript）。这是一个例子，它隐藏了main.js在IE8及以下版本中的可用性，但使其在IE9及以上版本以及所有其他非IE浏览器中可用。

<!--[if gt IE 8]><!-->
    <script src="main.js"></script>
<!--<![endif]-->

通过对浏览器交付的内容持保守态度，我们确保了最大程度的支持，但仍然可以针对更高级的浏览器进行优化。这使得测试变得容易得多，因为我们知道旧浏览器可以使用基本功能，而且我们不会在不确定是否可用时使用JavaScript功能。

测试，测试，再测试

渐进增强有助于我们在项目进入测试阶段之前避免许多渲染和脚本问题，但最终我们还是需要坐下来仔细测试我们的项目。

为了在开发过程中保持测试的可管理性，最好在一个我们知道具有良好Web标准支持的浏览器中进行测试。这将为我们的工作提供基本的初步检查。一旦我们对工作进行得相当有信心，我们就可以开始在各种浏览器和设备上进行更彻底的测试。

我个人通常会在我的笔记本电脑上安装几个主要浏览器的不同版本。我使用的是Mac，所以我通常会安装几个版本的Chrome、Firefox和Opera。你可以在这里找到这些浏览器的旧版本：

在现代OS X版本上运行旧版Safari几乎是不可能的，所以我通常只本地安装最新版本。

对于在Windows版本上测试上述浏览器，我通常会运行3-5个虚拟机，这些虚拟机运行各种Windows版本，并安装相应的浏览器版本（通常还会安装Chrome、Firefox和Opera）。MS Edge Dev网站提供免费的Windows虚拟机供下载。如果你只是想对微软最新最好的产品进行初步测试，还有Remote.IE服务，它允许你连接到浏览器的虚拟化版本。

如果你在Windows或Linux上开发，你需要访问Mac，或者依赖虚拟化在Mac平台上进行测试。我稍后将讨论虚拟化。

在你对各种桌面浏览器进行了彻底测试后，就可以深入研究设备的世界了。如果你不确定从哪里开始，可以看看你的分析数据；但要有所保留。分析数据可能导致你做出错误的假设。例如，如果你看到Blackberry用户比例很低，这是否是因为你的网站在Blackberry上运行得不好，所以他们不留下来（或者不回来）？要警惕自我实现的预言。

如果你有预算，尽管去购买一些设备供测试使用。你可以使用Adobe的Edge Inspect、Vanamco的Ghostlab或Viljami Salminen的Remote Preview（或以上所有工具的组合）来同步在几台设备上浏览。其中一些工具还允许对设备进行远程检查，以调试CSS和JavaScript。Weinre（Adobe Edge Inspect使用）和Vorlon.js也提供远程检查功能。

如果你足够幸运，附近有开放设备实验室（ODL），你应该去那里运行你的测试。ODL是免费的社区资源，通常由一家网页设计公司或恰好拥有大量设备的个人提供。ODL的某个人应该能够帮助你选择要测试的设备，并向你介绍他们在实验室中可用的测试工具。

如果你附近没有ODL，你也可以在你当地的手机或电子产品商店进行一些游击式测试。只是要确保他们有真实的设备……你无法在假的塑料模型上走远。

如果以上这些都不是你的选择，那么还有虚拟化。你可以下载并安装各种移动浏览器和设备的模拟器。此外，像Browserstack和CrossBrowserTesting这样的服务以象征性的费用提供数百个虚拟桌面和设备。

虚拟化永远无法提供像亲手掌握真实设备一样的体验。性能很少相同，而且你对设备的输入响应没有感觉。我曾经偶然发现了一个Android 2.3的bug，其中生成的内��在设备每次旋转时都会被重新生成和插入。我认为我不会通过模拟器发现这一点。也就是说，模拟器可以帮助你粗略了解你的界面是否工作。

无论你通过何种方式获取测试设备，都要尽量覆盖全面的范围。选择一些低端设备、几款较旧的高端设备、一些最新的旗舰设备，以及各种屏幕尺寸和分辨率。确保你在操作系统方面也有良好的覆盖——最新的iOS和Android版本是必备的，但也要确保你有Windows设备一两台，一些Blackberry选项，以及一些旧的Android和iOS版本。然后，再加入一些奇特的设备，看看你的界面是否能够应对。

重要的是要记住，我们永远无法让每个设备上的每个用户获得完全相同的体验。我们需要接受这一点——体验是一个连续体。只要我们的用户能在我们的网站上完成他们需要做的事情，他们就会得到很好的服务。

加分项：拥抱模式

如果我们真的想让我们自己（和我们的团队）的工作变得轻松，我们应该在构建网站的任何页面之前，考虑构建一个模式库。

将我们的界面分解成离散的、可重复使用的模式（例如，一个标签和一个表单控件、一个选项卡式界面等），可以让我们单独查看并以此方式进行测试。单独测试比试图调试一个有很多活动部件的页面要容易得多。

将我们的模式收集到一个实时、基于Web的模式库中，可以使我们团队中的任何人都能轻松地收集构建给定界面所需的模式，就像在自助餐台上取餐一样。如果我们真的想简化构建和测试过程，我们甚至可以使这些模式可以导入到实时站点中，以保持一切同步。

不要害怕僵尸启示录

面对不断涌现的新设备、外形尺寸和考虑因素，我们很容易放弃并寻找另一条职业道路。发展的步伐如此之快，很难跟上，更不用说感觉自己能掌握事物的走向了。

幸运的是，并非一切都已失去。通过退一步思考什么最重要，拥抱体验作为一个连续体，并有意识地决定如何（以及何时）向浏览器提供某些功能，我们将能够避免大部分问题。

这减轻了测试过程的一些压力（和挫败感），使我们能够更广泛地在各种设备和浏览器上进行测试，这意味着我们将能够为更多的用户提供稳定的体验，无论他们当时使用的是何种技术奇迹。

人人皆赢。