[译]36 Days of Web Testing(六)

Day 30 Test in situ  真实场景下的测试

为什么？

我十分推崇现场测试，简单讲就是要在你的站点或应用真实使用的场景下进行测试。但随着人口增长，对于“真实场景”的定义变得愈发困难，因为人们可能在各种场景下使用产品。

如果你正在测试一个公共报亭软件，在拥挤，嘈杂，光线刺眼的公共环境，是否可以如预期的工作？在测试环境可能正常工作，但在户外街道上测试，和在测试环境的结果一样吗？你的移动APP在公交站点，深夜，下雨的时候都可以正常工作吗？

怎么做？

试着定义一些常见的“真实场景”，并在这些场景下测试。设计一系列场景是一个好主意。在这些场景中用户会发现自己真实使用的情景，例如“忙碌的办公室”，“吵闹繁忙的火车站”，“安静的房间”等。这些场景会帮助你理解在什么样的情况下，以及为什么使用你的产品。

我测试呼叫中心软件，没有比拜访一些最终用户（呼叫中心代理），看看他们是如何使用这些应用的更来得直接了。这可能会改变你对产品一些元素的看法。

我有一个朋友，他从事很酷的航海导航工具测试。如果可能，他会在海中的船上进行测试，没有什么可以替代这样的真实场景。

另一个朋友测试医疗设备，在模拟操作阶段发现设备导致噪声很大，血花飞溅。这样的体现，让他回到办公室后对整个产品有个全新的认识。

建议：

这样的角色扮演不单单设计专家，功能专家来做。这同样是一个很棒的主意，可以有助于产生一些测试点子。

链接：

In Situ on Wikipedia - http://en.wikipedia.org/wiki/In_situ
Blatant self-promotion link to Social Tester site - http://thesocialtester.co.uk/theres-method-in-the-madness/

 

Day 31  Print it out 打印出来

为什么？

如果你的站点有表单，应用提供其他使用者一些数据，例如收据，可访问的代码，确认码等，那么最好将打印这些数据作为你测试的一部分。

终端用户是会打印收据这些数据的，如果你发现你优雅的功能站点打印出来是如此槽糕，这将搞坏用户体验。

举个例子，当我收到了一个会议邀请的电子邀请函，我一般都会打印出来作为报销凭证的，如果惊讶的发现打印出来的格式很糟糕

怎么做？

点击打印，然后检查打印出来的。

建议：

大多数浏览器都提供了打印预览功能，通过打印预览就可以看出效果了，不必浪费纸了。

链接：

Insights in to how to make a print ready CSS - http://answers.oreilly.com/topic/1018-how-to-make-a-web-formprint- ready-with-css/

 

Day 32 Too many extensions  太多的扩展

为什么？

很多现代浏览器允许你添加附件组件、扩展，或插件，这些都可以增加浏览器的功能，允许你在浏览器中执行一些操作。

对一个测试而言，Firefox的主要扩展可能就是Firebug,通过Firebug可以查看客户端和服务器的网络交互，可以做一些很酷的页面检查，以及其他一些事情。

对于主浏览器，有成千上万中不同的扩展，我之前已经讨论过很多类似的扩展应用了。

然而，在测试的过程中，你所安装的这些应用也会和产品进行交互，扩展本身的问题可能导致你花费大量时间来调查一个对用户并不是十分重要的bug

怎么做？

我最近就遇到过一个问题，我的一个扩展将一段Javascript脚本给禁用掉了，虽然并没有配置禁用JavaScript脚本。

这个bug在其他浏览器上都无法重现。通过分析所有执行过的代码我们得出的结论是，这可能是Firefox的扩展引起的问题。我在另一个虚拟机上安装了同样版本的Firefox，但是没有安装扩展，结果是正常的，所以原因找到了。

因为我安装有20+的扩展来协助我测试，所以我每次移除两个扩展，以此来定位导致问题的扩展究竟是哪个。

当我移除掉最后两个扩展时，问题解决了。接着，我又以相反的顺序将那些移除的扩展安装起来，结果当安装完前两个扩展时，问题又出现了。我定位到了导致问题的扩展，并做了一番探究。这是这个扩展的已知问题，因为扩展本身也是JavaScript实现的。

扩展很强大，但也有可能会妨碍正常功能。

建议：

准备一个测试机（虚拟机，或实体机都可以），安装绝对干净的（没有扩展，或不必要的插件）的浏览器，如果你发现了很诡异的问题，这时候可以在两套环境下比较一下，看是不是浏览器扩展引起的问题。

链接：

How to manage add-ons across multiple machines - http://lifehacker.com/272113/sync-your-firefoxextensions-and-profiles-across-computers

 

Day 33 Refresh during page loads  在页面载入的过程中刷新

为什么？

如果你测试的应用或站点存在特定的状态，或则事务更新，举例来讲，当你点击一个按钮，然后尝试刷新页面时，这时候会进入不同的状态。

你会惊讶的发现在这个地方存在很多潜在的问题。当一个页面在载入，或发送、接收新数据时，刷新操作也会可能会获取老的状态数据。这时候通过刷新获取到的数据可能不是最新的数据。

怎么做？

在执行一些操作（如提交表单）的同时，点击“刷新”按钮。依据这个模块的响应速度有多快，你可能会发现一些关于状态、数据、或则用户活动的问题。

Ps: 曾发现过，在提现时，输入短信校验码后，在提现成功页面，按F5刷新，会出现重复提现的问题。

建议：

找出你所使用的操作系统的快捷键，这样便可以更迅速的刷新

链接：

Windows shortcut keys - http://support.microsoft.com/kb/126449
MAC shortcut keys - http://support.apple.com/kb/HT1343
Linux shortcut keys - http://linux.about.com/od/linux101/l/blnewbie5_1.htm

 

Day 34  Check for SEO 搜索引擎优化

为什么 ？

在如今这个社交意识愈发强烈的社会，我们需要通过点击来进行销售和获取市场份额。获取点击并不是单单提供正确的内容，还得市场要知晓你的运营活动。这当然也包括，创建一个搜索引擎优化的网站，或设计。

“搜索引擎优化(SEO)是指通过一些‘自然的’，‘非付费的’，或算法的方式来提高网站在搜索引擎结果中的可见度”

基于上述考虑，我们就要做一些研究，看看究竟改做些什么，哪些不能做才能是有利于SEO(搜索引擎优化)。

市面上存在一些有用的指导，有一些好不帮助，还有一些帮助甚微。对于最佳方式提升SEO的，也有一些不同意见，甚至认为SEO究竟是否重要都有不同的意见。

站点的SEO另一个经常被忽视的作用就是，SEO的同时有利于站点的可访问性。看看下面一个有意思的对比：

http://www.slideshare.net/ConeTrees/seo-through-accessibility

怎么做？

我已经在下面列出了一些有用的链接，但是还是最好订阅一个内容靠谱的网站，保持与这个快速变化的领域时刻同步。

小建议

有很多浏览器插件提供SEO检测功能。

有用的链接

Marketing and Sales look at SEO -
http://www.promotionworld.com/articles/se/articles/Internet_Marketing_Strategy/SEO/071007EssentialGuide.html
SEO through accessibility - http://www.slideshare.net/ConeTrees/seo-through-accessibility
SEO at Wikipedia - http://en.wikipedia.org/wiki/SEO

 

Day 35 Five second test  五秒测试

为什么？

当人们访问你的站点时，通常会很快对这个站点做出一个判断，也就是第一印象，接下来去哪，他们是否喜欢这个设计（或内容）。

有个很棒的服务叫做“五秒测试”（http://fivesecondtest.com/），提供这个服务的网站上有一些用户和测试人员，他们会访问你的站点，回答一些关于你的网站的问题，并给你一些反馈。

这可以帮助你发现当用户访问你的站点时，他们的注意力会更关注那些内容。

“在仅仅5秒的访问时间后，看看一个人对于你的设计究竟能回忆起什么，这可以确认你的信息是否有效的传递给用户。” – From Five Second Test Website

怎么做？

只需注册一下，上传你网站的线框图，或则mocks，接着等待反馈

建议：

尽早获得用户的反馈可以第一时间确保你专注在做正确的应用。经常看到，像这种有用的测试做的太晚，一直于最后代码的变更已经很难了，或则说太多时间投入到一个很烂的设计中。

链接：

Five Second Test - http://fivesecondtest.com/
24 Usability Tools - http://www.usefulusability.com/24-usability-testing-tools/

 

Day36  Throttle It 限流

为什么？

在测试应用时，测试环境的网络链接是很快的，这就意味着我们的产品是在很好的网络连接和网速的情况下测试的。

但终端用户并不是都能通过很快的网络连接来访问我们的站点的。

不要设想你的用户的网络环境是很流畅的，这一点很重要。要面对冷酷的现实。过度的设想会导致设计和实现不能满足用户，或则现场的场景。

怎么办？

市场上有很多工具，但我发现Charles Proxy是最有效的限流工具。

在Charles Proxy的界面上，有个很明显的“节流阀”按钮。允许你限制连接的网络速度，就像用户的网速一样。

介绍怎样限制网站的网速：

http://www.charlesproxy.com/documentation/proxying/throttling/

通过使用Charles Proxy可以测试不同网络连接速度下，和网站交互或连接时的反应。

Useful Hint

在产品说明书中通常会有需要的最小配置，可以从最小配置开始测试。

Useful Links

Charles Proxy - http://www.charlesproxy.com/