测试Web Application之三：进攻

     在“测试Web Application之二：准备作战”一文中，我给出了一些计划测试一个web application的建议。在这关于web application测试系列的最后一篇中。我将提出测试web application的艺术，包括一些关于简化面前任务的工具和技巧的想法。

1. 从由后向前测试，而不是由前向后

    许多测试人员集中通过浏览器来测试一个web application。然而，这会导致花格外的时间来测试浏览器，而不是web application本身。当然，你仍然需要在浏览器中测试，但是不要让它变成你测试的焦点。在执行负载和性能测试的时候，这是特别重要的。如果你的web application象大多数一样，你将有一个连接着一个或多个应用服务器的web服务器，那些应用服务器也连接着一个数据库。因此，性能和负载的变慢可能会出现在web服务器，应用服务器或数据库服务器上。

2. 编写脚本是有好处的

    不通过浏览器测试不同后台服务器的最好方法之一是使用脚本。我喜欢的用于测试web服务器的脚本语言是Perl，因为它容易学习，容易使用，并且有一组很好的特别为这个目的设计的（LWP或Win32::Internet library，取决于你的平台）web服务器库文件。他们让你：解析HTML文件；提供客户端请求并且处理服务器响应；创建，解析并解释URL。你应该可以使用JavaScript，VBScript，或PerlScript来测试应用服务器和数据库（例如，通过在脚本中嵌入SQL语句）。

3. 使用基于风险的测试

    这仍然是今天测试人员可用的最好的技术之一。在项目的初期，测试团队应该定时地聚在一起以生成“排名前10的风险列表”，它列出了测试（明确）和项目（总体）中所有的风险。然后，当项目进行时，定时的开会并更新这个列表。利用这个列表来帮助达到你测试的目标。对于每个已验证的风险，计划一些方法以减少或最小化如果风险出现所带来的影响。许多可能的解决方案将影响你的测试策略。那是可以的－这时你需要拥抱变换以最小化你失败的风险。当新的问题突然出现时，你将不得不改变你的计划和策略以有效地处理它们。因此不要锁住到"隧道幻想"中，在那里你只会盲目地遵从原始的测试策略并向上天（和你的开发团队）发誓它是*唯一*能起作用的策略。贯穿项目的始末风险会发生变化，因此为了处理它们，你的策略也必须变更。

4. 记住UI和可用性不是一样的

    仅仅因为你的web application看上去不错，并不意味着它是可用的（或它展示出良好的可用性）。现实是大多数网站和web application边际的展示出低劣的可用性。许多 web application的UI设计人员来自图形设计或桌面出版 背景。这对于以文字基础的网站很有用－想想Internet原本设计的目的是什么，但是web application需要更多的集中在人机界面设计上。

在考虑可用性时，5个需要记住的关键区域是移动，察觉，语言，内存和思考。

可以应用于以上每个区域的三个系统属性包括：

数量－能够记得，察觉到多少项目

距离－用户必须在项目之间移动鼠标，为了察觉项目要在项目之间移动他们的眼睛多少距离，等等。

结构－在项目之间鼠标移动的结构，为察觉项目要在项目之间眼睛移动的结构是否一致，等等。

需要测试的一些项目：

眼睛追踪的距离：为了记下所有相关的信息，你的眼睛必须交叉和向下移动多远？

鼠标追踪的距离：为了完成任务，用户必须要移动鼠标光标多远，包括基本的导航，例如浏览器中的“Back”回到一个页面 。

颜色的组合，特别是背景和图像。

便于导航和定位：你能怎样轻松地说出你在网站上的位置或者用户必须回忆吗，你总是可以回到“首页”吗，你可以从每个页面中“退出”吗，你可以轻松地返回到上一个页面吗？例如搜索结果。

数据的组织：例如按字母排序的列表，按数字排序的列表，最频繁使用项目和/或最近使用项目的列表

在线帮助：有没有在线帮助？是否正确？

    这些仅仅是少数一些关于测试web application的心得。我希望当你和你的团队工作以使你们的应用程序发布时它们可以节约你们一些时间和许多担忧。然而，这些技巧不能代替经验。你在这一领域做的工作越多，你将能积聚更多的经验，你也将会越轻松地计划和执行测试web application。
 

原文转自：http://www.ltesting.net