[译]36 Days of Web Testing(一)

【前言】最近负责的一次迭代发布中，一个小需求涉及前端JS改动，在测试这个需求的过程中忽略了浏览器兼容性测试，导致了一个线上bug。恶补下web测试，《36Days of web testing》是之前看到有人推荐的，翻了翻，觉得挺不错的，决定利用业余时间把它翻译完，希望自己能坚持住，保证每周更新。

Day1: Cross Browser - 跨浏览器兼容性测试

为什么要做有浏览器兼容性测试？

如今，市面上的浏览器种类越来越多（尤其是在平板和移动设备上），这就意味着你所测试的站点需要在这些你声称支持浏览器上都能很好的工作。

同时，主流浏览器（IE,Firefox,Chrome,Opera,Safari）版本更新更加频繁，终端用户甚至不会感知这些浏览器版本的升级。

这两点就导致了对于日益增多的浏览器做兼容性测试显示十分必要，但也使得这种兼容性测试变得十分耗时。

通过全覆盖的测试，你就可以明确的知道你的站点支持哪些浏览器，哪些有兼容性问题。一个最简单的减少浏览器兼容性测试的办法，就是停止对老版本浏览器的支持。这个策略对一些公司是适用的，但并不适用所用的公司。

停止对老版本浏览器的支持，并不意味这你的产品在这些老版本上就没有bug, 这仅仅是你可以忽略那些老版本上的潜在问题，把精力放在那些当前支持的浏览器版本上。

浏览器兼容性测试应该如何来做？

分散风险

一个途径就是在多浏览器环境中执行日常的测试工作。

举个例子来讲，你要测试这样一个web应用：用户登入，生成报表，发送报表，退出系统。这个应用还包含一个管理功能，管理员或经理登入后可查看哪些人做了哪些改动。

为了覆盖更多的浏览器，你可以用一种浏览器来测试登入功能，在另一个浏览器中测试“发送报表”的功能，用第三种浏览器测试“审计变动”的功能。

这是一个有效的方法，在日常的功能测试的过程中，同时覆盖多浏览器兼容性测试。上面这个例子还是存在一些问题的，比如讲，如果“审计变动”这个功能在第一种，或第二种浏览器里是有问题，那么就会发现不了。这种方法节省下来的时间，可以让你在做兼容性测试策略时，更有侧重。

让其他人来帮你做测试

对于一些明显的页面兼容性问题，有一些在线工具可以帮着你检查，例如Browser Shots,它可以将你的页面载入到它所支持的浏览器中(它支持浏览器种类和版本很丰富),然后截屏,你可以查看在这些浏览器下的载入情况了.

这是一个很棒的工具,但那些需要登入验证的应用,或则你的应用中包含的页面太多 ,这个工具就显得有点力不从心了.

和标准进行比对

你可以对你的站点进行HTML语法标准检查，如果通过了，在多浏览器兼容性上，你可以更有自信一点了，但即使通过了，还是总有一些浏览器（比如万恶的360）渲染你的页面是会有兼容性问题。

W3.org提供一个很好的标准检平台。

自动化

Web UI的测试可以通过webdriver这个工具来实现自动化，可以使用selenium Grid来讲自动化脚本在多浏览器上运行。

前提是你得有Web UI自动化的投入。Web UI自动化可以发现一些功能上的问题，但对于多浏览器页面布局方面的差异，通过它是很难发现的。

Fight Layout Bugs

你可以写一些自动化脚本来检查页面在不同浏览器下渲染效果。Fighting Layout bugs是一个开源的工具，可以用来检查页面布局方面的bug

手工测试

你可以手工测试所有的浏览器版本，为了避免混淆，你可以将不同的浏览器安装在不同的虚拟机上（uedde的确这这样做的），当有其他人需要用是，可以直接克隆这些虚拟机，或则直接访问这些虚拟机。但这太耗时，费力了，但还是有必要做一次这样的多浏览器手工测试的。

分类

你可以依据内核来划分浏览器。

chrome & safari使用的是webkit内核，Firefox则是Gecko, IE系列的是Trident内核，Opera使用Presto内核。最新的Opera好像也开始使用webkit内核了。

这样你就可以认为，如果在chrome上没有问题，那么“理应”在safari也应该没问题。

模拟

市面上有一些工具可以模拟不同的浏览器，有一些浏览器也附带了工具来兼容老版本。但使用这些工具是要谨慎，这样的模拟并不一定准确。慎重。

outsource selenium

如果你没有条件搭建selenium grid测试环境，你可以尝试着使用Sauce Labs 和 testingbot 这样的服务。

多浏览器的支持我们心中永远的痛，特别是如今浏览器更新如此频繁的状况下。哎~ 你可以选择上面的适合你的方法。

PS：有些浏览器有兼容模式，可以通过兼容模式来模拟老版本。有些浏览器，如chrome,提供了开发者工具可以帮着定位问题。

有用的链接：

Compatibility Mode page on Wikipedia - http://en.wikipedia.org/wiki/Compatibility_mode_%28software%29

Sauce Labs - http://saucelabs.com/

Testing Bot - http://testingbot.com/

Browsers and Rendering Engines - http://en.wikipedia.org/wiki/Web_browser_engine

Selenium Grid - http://selenium-grid.seleniumhq.org/

Day2: Web Accessibility - 页面可访问性测试

【题外话】对于web accessibility testing之前都没听过，但曾听说过“淘宝无障碍”。wikipedia上对于web accessibility的定义是：站点要具备包容性，正常人能使用，残障人士也能无障碍的访问。当网页合理的设计，编辑，就可以保证所有的人都可以平等的访问你的站点，获取信息，进行操作。如，盲人可以通过读屏软件访问你的站点，红绿色盲也可以辨别出页面上的超链接等。

Why ? 为什么要做

很少有公司会十分重视他们的网页对于特殊人群可访问性问题，但如今互联网早已渗入我们的日常生活，让残障人群能融入到这个虚拟的世界，而不是将他们排斥在外，就显得十分重要。

一方面讲，可访问测试十分简单，另一方面看，又很难。

一个站点的可访问性可以通过W3C制定出来的国际合规标准来进行判定，这个指南给出了A，AA，AAA三个等级。

How? 怎么来做

市面上有很多工具可以帮着你检查你的站点是否符合合规标准，这些自动化工具可以很快的给出结果来。这是最简单的方法，分分钟就可以给你结果，但这些结果往往又不是很全面。

让我们来看一个简单的例子：你的页面包含有一张图片。图片的 alt 属性可能为空。

当用户因为网速太慢无法查看图片，或则使用屏幕阅读器时，alt属性就显得十分重要了，它可以为图像提供替代的文本信息，使用屏幕阅读器的残障人士可以听到关于这个图像的文本信息。

如果alt属性为空，自动化检查工具就会报错，这是很容易修复的。填上alt属性值，重新跑一遍，就可以通过了。

然而，当你的图像是一个红苹果，而你输入的文本信息是“可爱的泰迪熊”，就可访问性而言，图像的alt属性告诉使用屏幕阅读器的用户，这个图像真实的是什么。所以“可爱的泰迪熊”这样的文本信息对他们是没有帮组的，实际上起到的作用恰恰相反，误导了用户。这种情况，自动化的检查工具是检查不出来的。

页面流，页面的逻辑对于盲人用户，或没有背景知识的用户，是不是很明了，这一点，自动化检查工具也是无法帮着检查出来的。

就我的经验而言，让真正使用可访问站点的人来测试站点的可访问性比正常人更有效。因此，可以考虑将站点的可访问性测试外包给那些专业的可访问性测试公司或慈善组织。我曾通过自动化工具来检查一个站点，检查的结果是符合AA规范标准的，但当我将它交给可访问性测试专家测试时，我惊呆了，就可访问而言，基本等于不可用。它是符合规范的，但用起来很不方便，也很不爽。

优秀的可访问性测试需要人的判断和思考，而不是简单的自动化。需要不断的尝试，需要来自目标用户的反馈。

毋庸置疑，在线工具擅于发现那些明显的错误和规范性问题，而且这些工具也在不断优化，变得更强大。

如果你的站点在开发时，根本没考虑可访性，那么当用这些工具扫描你的站点，你会惊讶的发现，你的站点在可访问性方面是多么的差。

无论你是否在意你的站点是否符合可访问性规范，做一下可访问性检查往往会发现Html中一些明显的问题，并能给你下一步的测试工作提供一个方向。

如果你的公司毫不在乎自己的站点来个A标准都达不到，这时候，作为一个优秀的测试工程师，你就要问一个为什么不了。

小建议：

最简单的方法来检查你的站点是否符合W3C标准的方法就是，安装一个firefor插件，然后打开网页，进行一个快速的扫描。

有用的链接：

Firefox accessibility extension - https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/

Tips on how best to describe the alt attribute - http://webdesign.about.com/od/beginningtutorials/a/aa122004.htm

The W3 standards on accessibility - http://www.w3.org/standards/webdesign/accessibility

Test Partners accessibility testing  - http://www.testpartners.co.uk/accessibility_testing.htm

再补充两个淘宝的规范：

淘宝信息无障碍设计标准  http://www.taobaotest.com/acc/66

淘宝屋无障碍-网站开发编码规范  http://www.taobaotest.com/acc/68

Day3: Is the HTML valid? 你的HTML符合规范吗

为什么

HTML是一种主要用来描述网页的标记语言。

不合规的HTML可能会导致bug, 页面渲染问题，浏览器兼容性性问题，可访问性也差，所以在做web测试时，可以关注一下HTML是否符合规范。

严格遵守HTML规范可以确保你的站点能经受未来的考验。

有很多站点没有遵循HTML规范，其中不乏一些人气很高的网站。谈到为什么不遵守规范，拿出来的说辞总是：为了页面响应更迅速一点，跨浏览器兼容性的考虑（讽刺的是，HTML5是能够保证跨浏览器一致性），这里就不深究了。

一言以蔽之，利用现有的工具来做一次基本HTML规范性检测，是明智之举。做检查只是个开始，究竟要不要修这个可以讨论。

怎么做

测试时，你可以使用Firefox的FireWeasel插件来验证你的站点是否合规。也有一些在线验证工具可以迅速的给出反馈。这些验证工具可以指出哪一部分HTML违反了规范，应该如何修复。

小建议

鼓励团队中的开发同学装个IDE插件来检查他们写的HTML是否符合规范，这样就可以尽早的发现HTML规范性问题了。

有用的链接

Good post on why you should validate - http://www.stevefenton.co.uk/Content/Blog/Date/201108/Blog/Do-I-Need-To-Validate-My-HTML/?Page=Blog&Date=201108&Blog=Do-I-Need-To-Validate-My-HTML

The W3C validator - http://validator.w3.org/

FireWeasel - https://addons.mozilla.org/en-US/firefox/addon/fireweasel/

Day4: Check for Dead-links  坏链接检查

为什么

几乎所有的站点都存在链接无效的现象，链接无法访问，或则一个内容过期，不再更新，没人维护的页面。原因很简单，要么是你链接指向的页面已经被移除，要么就是没指向正确的地方。也有可能是你指向的页面无法工作了。

为了避免后续花费大量时间来维护这些链接，应该要保持这些链接能得到及时更新，但说起来容易做起来难，特别是在开发那些商业站点时。

坏链接可能会导致其他问题，这一块也是Web测试工程师应该关注的。

怎么来做？

有很多工具可以扫描你的站点，列出一个坏链接的列表，并建议你如何来修复。大多数情况下，简单的移除那些坏链接就可以了，但这么做也有点不好。

下载一个链接检查工具，如 Xenu , 输入你的URL，然后就可以等着看报告了

小建议

将坏链接的检查作为持续集成（CI）的一部分，当自动化测试执行时，你就可以顺带着做坏链接的检查 了。

有用的链接

Xenu Link Checker - http://home.snafu.de/tilman/xenulink.html
W3C Checker - http://validator.w3.org/checklink
Broken Link Checker Tool - http://www.brokenlinkcheck.com/

Day5：One,Two,Many  一个，两个，以及更多

为什么？

除了一些定位很小众的网站，否则你总是希望有多的人来访问你的站点。因此，最好测试一下你的站点在N个用户访问的情况下是否也是能正常工作的。

系统的多用户测试，或压力测试中最让人头疼的是用户使用模型和预期负载的定义。

举个例子，有一些站点平日的访问量很少，只有几十，但周末的时候访问量会增加到好几千。这就增加了使用模型的复杂度。所用的用户每次访问你的站点所做的操作都是一样的吗？

最简单的开始多用户测试/压力测试/性能测试的方法就是使用“一个，两个，或则更多”概念。

我个人比较偏好“一个，两个，或则更多”是因为，这个观念很容易解释，同时，在使用的过程中它也提供了额外的价值。我一直使用这个理论做测试，并将它运用到自动化脚本中。

这个理论是这样的：

首先，在一个用户场景下的测试，主要要确保基本功能能正常工作。

其次，通过两个并发用户访问来检查是否存在死锁问题，以及一些其他的多用户访问问题。你会惊讶的发现居然存在如此多的问题，这种测试很简单，不必花费几个月时间来搭建一套专门的自动化框架来验证这些基本问题。

接着，在多用户场景下测试。多用户，这个根据你的实际需要来调整，可以是十个，二十个，甚至百万级的。

为什么，一开始从一个低量级下测试，然后才开始在一个大数量下测试呢？我遇到过一些例子：一些耗费昂贵设备，测试脚本的压力测试，结果发现仅仅是产品不支持两个用户同时登入。

怎么来做呢？

为了得到快速的反馈，一般“一个”、“两个”的场景我都是通过手工测试来验证的，也会借助一些自动化工具，如selenium来辅助测试，甚至会忽略UI，直接验证web service层的功能。

大负载的测试有许多选择，这里我就不多讲了。我个人比较偏好使用jmeter, 这是一个免费的工具，上手也快，容易扩展。你也可以采用其他一些工具，免费的，收费的，本地安装的，或则服务方式的。

无论采用何种方式来测试，但别忘了你的目标是什么。如果不能专注于你的目标，不断尝试各种不同的工具，你会发现性能测试和压力测试会变得十分复杂，笨重，成本也很大。

小建议：

先了解一下那些免费的工具，或则下载个试用版玩玩，然后再决定是否需要购买。工具的质量和适用性很重要。

有用的链接：

A list of testing tools - https://en.wikipedia.org/wiki/Load_testing/
jMeter -  http://jmeter.apache.org/

Day6: 多分页和多窗口

Why?

在多个分页或多个窗口打开你的网页，会发现一些有趣的安全性bugs, 数据刷新问题，或则多个cookie的混乱。

一个经常忽略的测试点就是：在同一Session下，在多个分页，多个浏览器窗口打开页面。这是为了检查应用对于同一用户（或不同用户）在同样session token场景下，在不同分页/窗口的处理。

很多站点是使用cookie来存储Session IDs和其他一些数据的，因此很有可能会发现一些错乱数据，seesions或安全访问的问题。这些错误信息显示，安全漏洞，或功能没有人预期地那样，这些都会很明显的。

How?

这里有个简单的发现安全缺陷的例子。

打开Firefox, 在一个分页里登入你的系统。在一个新分页中打开同样的页面，这两个分页被认为在同一个Session中。在第二个分页中，点击“退出”，然后第一个分页中，做一些其他操作。看看，是直接退出了，还是让你做这些操作。大多数情况下，会让你退出的。

在很多情况下，可能会存在同一浏览器下登入两个不同账户，导致不同分页下数据交叉。

看一个真实的案例。

我在分页1下以Rob的身份登入网上银行，在分页2下以Dave的身份再次登入。接着，回到分页1，点击页面上的链接，我看到了Dave的信息，而Dave看到了我的信息。这是因为混乱的session数据存储在同一个cookie文件中，这两个分页共享的同一cookie文件。

不单单是身份验证的问题。

在不同的分页中，分别往购物车中添加商品，检查一下购物车里的商品是否和你已添加的一致。

在不同的浏览器中，是不是以不同的Seesion登入的？

是不是通过在不同分页中操作，来绕过前端验证和限制？

多个分页测试最好的方法就是：在多个分页中打开你的应用，检查在一个分页中改动，是否会影响另个。在这个过程中，要关注：数据，状态，操作因为糟糕的cookie管理，seeson管理而出现问题。

有一些工具可以帮着检查请求、响应的内容。Burpsuite安全工具特别有用，如果你想做session劫持的话。Firecookie是一个FireFox插件，可以显示有哪些cookies和cooke的内容。

小建议

有些支持多分页的浏览器，可以打开多个分页，然后将一个分页拖拽出当前窗口，成为一个新的窗口，这两个窗口是在同一session下的。在测试的过程中，可以通过”Ctrl”+”tab”键来切换检查这两个分页的内容。

但需要注意的是，并不是所有的浏览器都认为这个新出来的窗口，在同一个Session下的。

其他有用的链接

A list of testing tools - https://en.wikipedia.org/wiki/Load_testing/
jMeter - http://jmeter.apache.org/
Good site about cookies and sessions - http://www.allaboutcookies.org/cookies/session-cookies-used-for.html/
Session Hijacking - http://en.wikipedia.org/wiki/Session_hijacking
Security implications of cookies - http://it.toolbox.com/blogs/securitymonkey/successful-hacking-with-xsscookies-session-ids-11098
Burpsuite - http://portswigger.net/burp/
Firecookie - https://addons.mozilla.org/en-us/firefox/addon/firecookie/