关于:SEO
关于:Google
2007/06/19 20:29 | by 不要像以前那样在运行中做出修改（如果你曾经用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的愿景变成现实并提升互联网的价值。
