蔓生的社会关系网络，来自草根阶层的内容创建以及广泛的交互和协作等等，所有这些构成精彩的Web2.0世界。从技术层面来说，Web2.0承诺提供从桌面到富Internet的高性能的快速访问能力，从而带来美妙的网络体验。看看Google Maps，你能够快速的拖拽那些你身边的，所在城市的，所在省的或的卫星地图，因为Ajax能够预测的你的鼠标移动并从服务器端取来你需要的内容。

　　但是许多组织在致力于给客户提供极好的网络体验的同时却或许正在失去对用户网络体验的控制能力。在近十年的早期，公司的IT部门掌控他们自己网站的体验并能够完全控制架构，表现逻辑，业务逻辑和数据表示。然而，2007年以来，控制权却变成分布式的并基于  浏览器构建。在Web2.0时代，一个应用会有上百万种不同的形式。

　　当几年前绝大部分用户都在Windows上使用IE的时候，一切都很简单。一个单一的传输平台导致从应用到产品都不能带来太多的惊奇。由于开发者和用户使用相同的平台，问题会及早出现而不是更多的延迟到用户的使用过程中。然而，总体的网络体验 - 功能的可靠性，界面和性能 - - 是很普通的（但是由于是第一次尝试，所以这个结果并不坏。）。我喜爱评分，所以我用下面的评分报告卡来解释我为什么这么说：

　　以前的网络体验：

　　*可靠性：B+ （绝大多数人用同一个平台很容易去定位问题所在）

　　*界面：C-（不大好）

　　*性能：B（期望值较低，应用也很简单）

　　*总体评价：普通

　　虽然未来的Web2.0体验会十分精彩，但是我们现在正处在一个痛苦的起步阶段。用户在各种各样的操作系统（Windows，Mac，Linux和移动操作系统）中使用各种各样的浏览器（IE，Safari，Firefox，Opera，iPhone，BlackBerry 和其他的）。

　　越来越多的业务逻辑在浏览器中运行。这意味着，对于一个组织来说，将有更多的东西是它所不能够掌控的 - - 广告投放，分析 和内容传输网络（CDN）等这些东西。这是一个复合的世界，但是很多公司却不知道如何去测试除了它们自己的内容以外的任何东西。现在网络体验评分报告卡看起来像下面这样：

　　的网络体验

　　*可靠性： F（“你忘记测试我使用的浏览器和操作系统了！”“Web 服务应该给我提供这个功能的！”）

　　*界面： A-（必须承认的是，相当不错）

　　*性能： C（期望值升高， 但是在很多方面却容易出现问题）

　　*总体评价： 差

　　那么怎么才能提高可靠性和性能的得分，给用户提供一个持续的、好的网络体验并兑现Web2.0的承诺呢？

　　由于我们正在经历一个全新的开发和交付的环境，我们必须更新我们的开发和测试策略。下面是一些建议：

　　1.把用户体验质量放到你的产品目标中。

　　不要像以前那样在运行中做出修改（如果你曾经用Perl写过web应用程序的话，你会理解我说的是什么）。让体验贯穿整个产品开发过程中。请确保你的发布标准中涵盖了可以在开发过程中和之后进行度量的详细的性能和可靠性指标。

　　2.理解（并管理）来自你的客户体验的反馈

　　许多公司理解第三方web服务的概念并使用他们，但是他们仍然只是测试他们自己提供的内容。请关注任何一个影响用户体验的因素，包括第三方的数据和服务。并且请记住：第三方的服务在你的一些客户那运行的很好并不代表全部都是。

　　3.了解你的客户，他们的偏好和使用习惯。

　　他们使用什么浏览器？什么系统？他们是怎么接入互联网的？他们在世界的那个地方？他们的使用习惯是什么样的，(例如，白天，晚上，或者访问应用的时候有一个特别的轨迹)？所有的这些因素都会影响用户体验，所以要确保你的应用总是能够在你的客户那运行的很好。并且仅仅因为第三方的CDN在一个地方工作的好并不能认为它在所有的地方都好。你不能设想你的第三方合作伙伴总是能和你保持一致。

　　4.建立一个涵盖用户所有的浏览器和操作系统的组合，并且包括手机（我计划成为先支持iPhone的人之一）和BlackBerry的浏览器兼容性实验室. 开源的Selenium测试工具是一个用来做自动化的浏览器/操作系统测试的好选择。Selenium Remote Control 让开发人员能够使用自己喜爱的语言来编写测试用例并远程控制浏览器/操作系统的组合。另外一个可以作为Selenium的替代性选择的是Watir，这两个项目在OpenQA.org上发布。Firebug是Web2.0开发人员和QA手中的又一个利器，它是一个Firefox的插件。

　　5.抓屏和录制测试用例实际运行时的影像能够帮你了解问题发生的现象，带来的影响以及分析如何去解决它。只有少数的几个商业化的测试工具具备这个功能，但是它能够在你去分析为什么自动化的测试运行失败的时候给你带来有效的帮助。

　　6.在自动测试和产品化期间记录浏览器内的活动日志。UI中有太多的应用逻辑使得我们不能忽略它。Firebug对Firefox和Safari提供内建的支持。考虑将Firebug Lite用于IE和其他的浏览器吧，想想开发中难跟踪的是从浏览器到持久存储的传输记录，付点钱是物有所值的。

　　7.理解性能和用户感觉性能之间的联系。如果一个用户的浏览器是全屏的，但是只有一部分你当前屏幕下方（需要滚动才能看见的）还没有下载完，用户会感觉你的页面已经下载完了。因此，测试人员不仅要关心HTTP响应时间数据，这个很容易得到，还要捕获独立的javascript函数、Ajax请求，对象（例如，图片和CSS）和HTML事件的信息从而精确的度量用户感觉到的性能。这才是真正影响用户的关键。

　　8.把浏览器加入到你的CI过程中。

　　绝大部分CI的实现都测试服务器端代码，但是他们不关心日益增长的浏览器内的活动。虽然合并浏览器到CI中需要更多的时间和资源，但是它你的测试是和真实的用户体验一致，这才是现在的重点。

　　9.考虑按需（On-demand）测试。

　　在真实的多浏览器/操作系统组合上测试并且捕获数十亿字节的性能数据需要比大多数企业投资的更多的测试基础设施。使用on-demand测试（软件即服务SaaS）让你能够接力别人的测试能力，架构和设施投资。这样你可以在你需要的时候租用一个浏览器实验室。

　　10.随着Web应用的发展重构测试。

　　Ajax改变了Web应用的构建方式，并且使得构建的自动化测试用例和代码结合的更紧密。连接的越紧密学要越多的数据一致性和测试固件。过去的时候，在一个web应用上定义一个自动化测试相当的简单：每一步都是一个用例（Joe Surfer 访问 www.xyz.com 并且点击登录点击等等.）对应一个新的页面。但是在Ajax上，事情变得相当的复杂了，所以我们必须重构测试用例。

　　采用这些策略能够确保你的QA测试是合适的，彻底的且足够敏捷的去跟上复杂的Web2.0应用的发展。好的，干净的，可靠的，高性能的代码能够帮助我们把Web2.0的愿景变成现实并提升互联网的价值。

　　原文地址：http://searchsoftwarequality.techtarget.com/originalContent/0，289142，sid92_gci1260130，00.html