[译]36 Days of Web Testing(五)

Day 23 禁用CSS  Disable CSS

为什么 ?

CSS，层叠样式表，是用来定义web页面布局和显示的机制。通过修改CSS样式，可以改变整个页面的外观。

但是有一些人，因为之前的选择或者其他原因，或选择禁用浏览器的CSS。这样可以使得站点看起来更加简单，最终也有利于屏幕阅读功能访问这些页面。

因此，在css禁用场景下的测试还是很重要的。如果禁用了CSS，你会惊讶的发现站点的流程和顺序都会有改变。

怎么做 ?

我发现的最简单的测试方法就是，用装有web开发工具插件的Firefox来打开你的站点。在扩展插件的菜单中可以选择禁用CSS。站点就会无样式下重新渲染。你也可以使用Firebug或其他功能来做。

建议：

Firebug有个CSS的分页，可以显示站点中使用的CSS样式。如果修改了其中的一些CSS标签，会怎样呢？

链接：

W3C standards and advice for CSS - http://www.w3.org/Style/CSS/
Firebug Firefox Extension - http://getfirebug.com/
Web Developer Add-One - https://addons.mozilla.org/en-us/firefox/addon/web-developer/

 

Day 24 Text Only

为什么 ?

如果能确保站点在纯文本模式下也能正常工作，那就再好不过了。从可访问性角度来看，纯文本模式下的测试是很重要的。从最求简单的角度来看，能在纯文本模式下正常工作，也是一个很好的目标。

但是，很难发现有站点可以在纯文本模式下也能正常工作。

对于提供站点文本访问模式的好处，看法还是不一致的。

怎么做 ?

最简单的来获得网站文本模式的方法就是，启用浏览器的开发者工具。我选择了Firefor的开发者工具栏。

安装上开发者工具以后，你只需要找到选项来开启文本模式。

在开发者工具栏里面：

images > Disable All Images

然后，选择 Disable > Disable JavaScript

接着，选择 CSS > Disable Styles > All Styles

这样访问的站点就是文本模式了。你会发现有一些你需要的功能不可用了，或则一血页面流出现了异常，或则你会发现你真的需要一些视觉图片来使得网页更易于让人理解。

建议：

Firefox的开发者工具栏提供了很多选项按钮，这些会帮着你测试你的站点在一些不支持特定功能的设备上打开会怎样，或需要可访问页面的用户打开会怎样。

链接：

Information on Text Only - http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/textonly.shtml
The Developer Tool Bar extension for Firefox - http://chrispederick.com/work/web-developer/

 

Day 25  禁用 javaScript    Disable JavaScript

Why ?

有很多很好的原因会促使你使用JavaScript  , 但有时候过度使用JavaScript也会导致一些有意思的bugs.

举例来说，在访问你的站点时，并不是所有的浏览器都会启用Javascript的，这会导致你站点的部分功能不可用，或则一些逻辑没有如预想的那样执行。

JavaScript常被用于收集数据，展示信息，执行页面逻辑，以及提交表单或用户数据。如果用户禁用了JavaScript ,这些功能就会丢失。

How ?

最简单的测试方法就是使用开发则工具扩展来禁用浏览器JavaScript, 禁用后访问你的站点，看看会发生什么

Useful Hint

有很多JS的单元测试框架

Useful Links

JSLint - http://www.jslint.com/lint.html
JavaScript information - http://coding.smashingmagazine.com/2011/10/27/lessons-from-a-review-of-javascriptcode

 

Day 26 Flash Free

Why ?

并不是所有的浏览器支持，或则允许Flash功能，因此提供给一个不包含Flash的站点被认为是一个必须的。特别是如今Adobe自己都宣布了将在很多移动平台上停止对Flash的支持。

有新闻价值的就是Ipad就不支持Flash 。也有一些插件和设置可以在浏览器中禁用Flash 。如果你的站点是依赖Flash的，这的确是个坏消息。

HTML5已经在路上，它能提供Flash所擅长的那些功能。

How ?

测试 无Flash的最简单的方法就是下载一个Firfox插件，例如 “Flash Block”,然后启用这个插件，访问你的站点。

下面这个图片就是禁用了Flash的汽车站点。在这个例子中，浏览器禁用了汽车的交互视图，这个站点的核心功能。实际上，人们很少会有理由会徘徊在这个站点。如果你是终端用户，这是你所想要的吗？

我始终简单的认为，即便禁用了Flash , 也不应该影响站点的主要功能。

如果因为一些原因，站点必须使用Flash ,而不是简单的炫耀你的Flash技能，这时候做一名测试同学，你就应该问一问，“我们有没有选错技术”

如果选择了Flash ,那么就有可能失去一部分潜在的市场。

Useful Hint

如果此时你使用Firefox的插件来禁用Flash , 这时候如果要访问你喜欢的站点，记得修改一下设置。因为这个插件同时会禁用掉 Silverlight , 微软的多媒体框架。

Useful Links

Flash Block - https://addons.mozilla.org/en-US/firefox/addon/flashblock/
Flash and why you shouldn’t use it - http://dynamicwebs.com.au/weblog/?p=33
Flash 99% Bad - http://www.useit.com/alertbox/20001029.html
When and where to use Flash - http://www.businessknowhow.com/internet/flash.htm

 

Day 27 用户接受测试（UAT，User Acceptance Testing)

Why ?

依据我的个人经验，大多数人（包括，开发、测试、产品经理）在做产品时，总会设想使用者是很Power的。我之所以这么认为，是因为在我以往接触的这些人中，他们往往都很擅长电脑技术，拥有这领域的专业知识，他们和项目息息相关，对项目和产品有自己的见解。

他们是电脑专家，对自己的产品有着很深的见解。这就意味着他们不是“Greenfield“用户。他们可能对自己的产品应该做成什么样，为什么这样做，有着自己固执的看法。毕竟，是他们编写了这个产品，测试这个产品，推广这个产品，支持维护这个产品的人。

“Greenfield”用户是指那些第一次访问你站点的用户，他们不懂技术，也不了解设计方面的知识，来访问你的站点仅仅是为了完成一些目标（比如，解决一些问题）

有些时候，作为一名测试工程师，我们忽略了产品的最终使用者，自以为是的认为用户在访问站点时，拥有和我们差不多的技能。这是很危险的。

How ?

获取用户反馈最简单的办法就是找一个开发团队之外的人来执行一些用户验收程序。验收可大可小，小到这个页面看起来不舒服，都可以提，但这样的验证频次在开发的过程中越频繁越好。敏捷开发部分采用了用户验收测试的方式，意识到用户的存在，频繁的更新发布。

但像瀑布模型，V模型或其他一些生命周期较长的软件开发模式，应该更频繁的用户验收测试来收益。

用户验收，ISTQB是这样定义的：

验收测试是对用户，或最终系统使用者负责的一种测试。其他利益相关者也可参与。验收测试的目的就是建立对系统，系统的某一部分，或特定的非功能特定的自信。发现bug并不是验收测试的主要关注点。

对于这样的定义存在很大争议，这次就先不在这里讨论了。我认为我们应该从这里面看到一些不同点，我认为用户验收测试可以在项目任一阶段来执行。

我认为这应该是开发团队的责任（有助于你交付正确的产品），我认为应该鼓励发现bug（要看对bug的分类了，是enhancement,defect,fault,missing copliance ,suability ,performance）。这些反馈可以反映产品是不是用户想要的，如用户预期的。为什么要等到产品要发布了才做验收测试呢？

倾听来自用户的声音对你的成功至关重要，得到用户的反馈越早越好。

Useful Hint

每隔几周，或几个月做一次用户验收测试是一个正确的策略。尽快的把产品放到用户面前，频繁倾听用户的声音。尽快听到用户反馈，并将反馈后的改动包含在下一次的发布中

Useful Links

ISTQB online - http://istqb.org/display/ISTQB/Home

 

Day 28 移动设备友好网站   Mobile Friendly ?

Why ?

如今有很多关于移动设备使用情况的统计数据。

无论你相信哪种统计信息（试着搜索一下“移动设备使用数据”），都很清晰的表明对于很多企业来说，移动是一直值得拥抱的未来。

作为一名测试同学，应该尝试着在各种移动设备上访问你的站点，看是否能正常工作。也许你的公司认为mobile并不是一个需要支持的平台，但长远开来mobile越来越流行，这是不争的事实。

How ?

如果你自己就有移动设备，可以访问下你的站点，看是否正常工作。也有很多移动模拟器可以用来测试你的站点。

在不同的操作系统上（mobile 和平板）上测试，把在各个系统的测试结果分别记录下来。

试试右击，页面更新，多个分页和数据选择（下拉，单选按钮）。这些地方我曾发现过问题，但各个产品在不同的场景下操作，需要根据自己的情况决定测试哪些。

Useful Hint

如果你在移动设备上测试需要一些数据，不要总是傻不拉几的每次都手动输入。可以把需要的数据以SMS或Email的形式发送到你的手机上，下面就可以在手机上Copy, 粘贴了。

如果你使用的是智能机，可以使用Evernote 或Dropbox进行数据同步。

Useful Links

A monster list of emulators - http://www.mobilexweb.com/emulators
Micro emulator - http://www.microemu.org/
Android Emulator - http://developer.android.com/guide/developing/tools/emulator.html
Nokia Toolkit - http://www.developer.nokia.com/info/sw.nokia.com/id/d57da811-c7cf-48c8-995ffeb3bea36d11/
Nokia_Mobile_Internet_Toolkit_4.1.html
Opera Mobile Emulator - http://www.opera.com/developer/tools/mobile/
Windows Mobile Emulators - http://msdn.microsoft.com/en-us/windowsmobile/bb250560.aspx
iPhone Emulator - http://www.marketcircle.com/iphoney/
Evernote - www.evernote.com

 

Day 29  Race conditions with selenium

为什么？

Selenium是UI自动化的利器，但它还有一些其他的，被大家忽视的用处。条件竞争就是其中之一的用处。

例如，Selenium IDE允许你以超过正常人为速度，来输入数据，点击按钮，以及访问一个站点。有时候，以很快的速度来走一个流程，访问一个站点可能会改变事件的顺序，改变消息，或则是其处在一个不该触发的状态上。这就是条件竞争。

使用Selenium UI测试，很容易就能发现竞争危害。我曾通过Selenium重现过之前正常UI测试无法每次都发现的问题。

怎么做？

使用Selenium脚本以较快速度回放之前录制的一系列页面操作。

举例来说，你正在填写一个表单，对于问题三选择了“Yes”，这时候在表单末尾出现了另外两个必填的问题。在这种场景下，就存在一种潜在的竞争危害。这两个问题可能是等一个很快的页面重载后出现的（或则其他实现方式）。

如果你以正常的速度填写表单，选择了“Yes”,接着看到了两个问题的展示，如果不填写这两个问题，你就会收到提示信息，告诉你这两个问题是必填的。

但是，如果你录制了表单填写过程，并通过Selenium以很快的速度回放，你就可能选择了“Yes”,并在页面重载前，按下一步。

这就意味着你可以提交一个在技术上不合法的表单（因为另外两个问题是必填项目）。

过去几年我在真实系统中发现过这样的Bug.这样的问题通过自己手动点击是不能重现的，但通过Selenium每次都能重现。

关于这个问题存在一定争议，因为终端用户并不会看到这种类型的bug,因为他们不会以这样的速度来操作，但竞争条件可以暴露出一些代码底层的问题，或则处理流程的错误。这样的讨论还是有必要的。

每个团队对待这样的bug都是不一样的。有一些自动化框架使用“思考时间”来模拟真实用户的响应时间。这对于常规的自动化是有效的，但如果你专门为了寻找这种竞争条件的话，那么快速UI自动化可以帮助你。

有一些用户的操作速度比其他人快，在操作速度的判断上需要做一些自己的判断，但竞争条件是会在任何速度下发生的，只是使用Selenium可以帮助更容易的，更多的发现这种现象。

建议：

掌握了Selenium IDE意味着你可以更快速地编辑，和执行它。

链接：

Race Conditions (Wikipedia) - http://en.wikipedia.org/wiki/Race_condition
Selenium - http://seleniumhq.org/

 

Day 30 Blink testing

为什么？

关于“闪烁测试”，我本想写下和James Bach不一样的介绍，但实际上他的描述已经很到位了。因此，这里直接引述他的定义：

所谓的闪烁测试，就是把你置身于数据的海洋里 - 有太多数据，以至于一时无法理解消化。接着你理解了这些数据时，但你都不知道自己是怎么就想通了的。但是你真的理解了，但你自己并没有意识到该怎么理解

- James Batch   http://www.satisfice.com/blog/archives/33

怎么做？

举个例子，你可以很从容的填写一个表单（用Selenium或屏幕抓取软件记录下来），完成上面的每一个字段，然后回放脚本，或视频。你可能会发现一些布局问题，标签的不一致，页面的错误，或则其他一些之前没注意到的问题。

你可以把点击按钮产生值的过程录制下来（就像JB博客中的那段视频一样http://www.satisfice.com/blog/archives/33，或则将一个探索式测试的测程录制下来），然后以很快的速度回放，你可能会发现一些第一次漏掉的问题。

当你看到页面，或则数据闪烁的时候，你会开始观察到一些不同之处，而这些在之前的常规测试中并不是很明显。Selenium 是一个很棒的工具，其他一些屏幕记录工具，或则自动化工具可以提供帮助。

建议：

在测试音频时，以两倍速度播放音频，可以有效的发现一有意思的元素，在正常速度下是不会注意到的。

链接：

James Bach’s article on Blink Testing - http://www.satisfice.com/blog/archives/33
Screen recording for your browser - http://www.screenr.com/
Desktop screen reading software - http://camstudio.org/