程序测试规范(6)

　　流控制和状态测试。在用户填写完表单中的字段并按下按钮后，逻辑是否会到达期望的进程?下一次显示同一页面时，其中的值是否正确?有时页面第一次显示了正确的值，而以后不再显示;或者情况相反。

　　配置测试。在可行的情况下，会用尽可能多的“受支持服务器”和客户程序配置对应用程序进行测试。

　　负载测试。在将页面或 Web 应用程序作为整体进行测试之前，应首先在组件级别进行负载和性能测试，以确保应用程序的每一部分能够在适当的指标下运行。这种隔离测试使测试小组能够更迅速地发现使用特定技术的问题。如果一个执行数据库查询功能的小脚本太慢，进行组件级别的测试比进行整个页面或应用程序测试更容易发现它。

　　回归测试。开发部门修复了代码中的错误后，我们会重新进行测试，以检查错误是否被修复并确保所做的修复不会引起其它问题。

　　二、按窗体位置分类：

　　左侧导航窗格：

　　是否能够在左侧的导航窗格中来回移动，该窗格显示是否正确?

　　是否能够在大于屏幕的区域内滚动?

　　是否能够选择不同的新闻组，文章列表是否显示在右上窗格中?

　　是否能够调整左侧导航窗格以及右上和右下窗格的大小?

　　右上窗格：

　　右上窗格是否正确地显示文章，是否保持了每篇文章的连载状况?

　　是否可以遍历连载文章?

　　读过一篇文章后，它是否被标记为红色?

　　如果文章列表大于一个页面，是否能够遍历右上窗格中的各个页面?

　　右下窗格：

　　是否可以选择一篇文章并显示在该页面的右下窗格中?

　　是否能够发布新消息，回复组，回复个人或转发文章?

　　在回复个人或转发消息时，默认的邮件客户程序是否启动并显示新消息?

　　是否能够伴随文章发送附件?

　　是否可以查看附件?

　　工具栏：

　　验证工具栏适合其所在的页面并能够根据浏览器窗口调整大小。

　　验证本地菜单能够正常运行。

　　验证本地菜单中的链接。

　　验证全局菜单能够正常运行。

　　验证全局菜单中的链接。

　　验证工具栏上的所有图形。

　　验证工具栏框架大小不可调整。

　　界面测试

　　站点地图和导航条

　　确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击一大堆页面。另外新用户在网站中可能会迷失方向。站点地图和/或导航条可以引导用户进行浏览。需要验证站点地图是否正确。确认地图上的链接是否确实存。地图有没有包括站点上的所有链接。是否每个页面都有导航条? 导航条是否一致? 每个页面的链接是否正常? 导航条是否直观?

　　内容

　　测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。 最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

　　颜色/背景

　　由于 web 日益流行，很多人把它看作图形设计作品。不幸的是，有些开发人员对新的背景颜色更感兴趣，以至于忽略了这种背景颜色是否易于浏览。典型的站点是在紫色图片的背景上显示黄色的文本(如果你没有见过这样的站点，请浏览一下 GeoCities 或 AOL 上的个人主页，有不少这样的)。这种页面显得"非常高贵"，但是看起来很费劲。通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

　　图片

　　无论作为屏幕的聚焦点或作为指引的小图标，一张图片都胜过千言万语。有时，告诉用户一个东西的最好办法就是将它展示给用户。但是，带宽对客户端或服务器来说都是非常宝贵的，所以要注意节约使用内存。是否所有的图片对所在的页面都是有价值的，或者它们只是浪费带宽? 使用其它的文件格式(.GIF, .JPG) 是否能使图片的大小减小到 30k 以下? 通常来说，不要将大图片放在首页上，因为这样可能会使用户放弃下载首页。如果用户可以很快看到首页，他可能会浏览站点，否则可能放弃。

原文转自：http://www.uml.org.cn/Test/200706154.asp