[译]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/