web测试方法

一、Web测试方法

本文属于转载

 　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

 

　　本文将 web 测试分为 6 个部分：

 

　　1.  功能测试

 

　　2.  性能测试（包括负载/压力测试）

 

　　3.  用户界面测试

 

　　4.  兼容性测试

 

　　5.  安全测试

 

　　6.  接口测试

 

　　本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

 

　　1 功能测试

 

　　1.1 链接测试

 

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

 

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

 

　　采取措施：采用自动检测网站链接的软件来进行。

 

　　推荐软件：

 

　　Xenu Link Sleuth 免费 绿色免安装软件

 

　　HTML Link Validator 共享（30天试用）

 

　　1.2 表单测试

 

　　当用户通过表单提交信息的时候，都希望表单能正常工作。

 

　　如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

 

　　当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

 

　　1.3 数据校验

 

　　如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

 

　　在测试表单时，该项测试和表单测试可能会有一些重复。

 

　　1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。

 

　　1.4 cookies测试

 

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

 

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。

 

　　采取措施：

 

　　1 采用黑盒测试：采用上面提到的方法进行测试

 

　　2 采用查看cookies的软件进行（初步的想法）

 

　　可以选择采用的软件

 

　　IECookiesView v1.50

 

　　Cookies Manager v1.1

 

 

 

1.5 数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

 

　　在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

 

　　采取措施：暂时没有更好的测试方法

 

　　考虑结合到1.2和1.3的测试中

 

　　1.6 应用程序特定的功能需求

 

　　最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。

 

　　采取措施：深刻理解需求说明文档

 

　　1.7 设计语言测试

 

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。

 

　　暂时没有方法测试，可以多参考一点讨论组内的更新信息

 

　　2 性能测试

 

　　2.1 连接速度测试

 

　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

 

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

 

　　2.2 负载测试

 

　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

 

　　2.3 压力测试

 

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

 

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

 

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

 

　　负载/压力测试应该关注什么

 

　　测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

 

　　瞬间访问高峰

 

　　如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

 

　　每个用户传送大量数据

 

　　网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

 

　　长时间的使用

 

　　如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。

 

　　采取措施：采用测试工具WAS、ACT协助进行测试

 

 

3 用户界面测试

　　3.1 导航测试

 

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？

 

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

 

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

 

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

 

　　3.2 图形测试

 

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

 

　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

 

　　（2）验证所有页面字体的风格是否一致。

 

　　（3）背景颜色应该与字体颜色和前景颜色相搭配。

 

　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下

 

　　（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

 

　　通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

 

　　3.3内容测试

 

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

 

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

 

　　对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

 

　　3.4 表格测试

 

　　需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?

 

　　3.5 整体界面测试

 

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？

 

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

 

　　对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

 

　　采取措施：手动测试，参与人员最好有外部人员

 

 

4 兼容性测试

 

　　4.1 平台测试

 

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

 

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

 

　　4.2 浏览器测试

 

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

 

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

 

　　4.3 分辨率测试

 

　　页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

 

　　4.4 Modem/连接速率

 

　　是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

 

　　4.5 打印机

 

　　用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

 

　　4.6 组合测试

 

　　最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

 

　　采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵

 

　　5 安全测试

 

　　即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。

 

　　5.1 目录设置

 

　　Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

 

　　5.2 SSL

 

　　很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

 

　　5.3 登录

 

　　有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面？

 

　　Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

 

　　5.4 日志文件

 

　　在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

 

　　5.5 脚本语言

 

　　脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

 

 

6 接口测试

 

　　在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。

 

　　6.1服务器接口

 

　　第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

 

　　这种测试可以归到功能测试中的表单测试和数据校验测试中

 

　　6.2 外部接口

 

　　有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

 

　　这种情况在远程抄表中可能会体现到

 

　　6.3 错误处理

 

　　最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。

 

　　采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。

 

　　7 结论

 

　  无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

 

 

软件测试中有关界面测试经验总结  

作者：未知   来源：51testing  发布时间：2007-04-05    

 1.应验证界面显示内容的完整性：

 

　　a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

 

　　b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常;

 

　　2.应验证界面显示内容的一致性：

 

　　a) 如有多个系统展现同一数据源时，应保证其一致性;

 

　　3.应验证界面显示内容的准确性：

 

　　a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

 

　　4.应验证界面显示内容的友好性：

 

　　a) 对统计的数据应按用户习惯进行分类、排序。

 

　　b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;

 

　　c) 界面内容更新后系统应提供刷新功能。

 

　　d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

 

　　5.应验证界面提示信息的指导性：

 

　　a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

 

　　b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

 

　　c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。

 

　　d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

 

　　6.应验证界面显示内容的合理性：

 

　　a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

 

　　b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

 

　　c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

 

　　7.界面测试时，应考虑用户使用的方便性：

 

　　a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

 

8.界面测试时，应考虑界面显示及处理的正确性：

 

　　a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。

 

　　b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复;

 

　　c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。

 

　　d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。

 

　　e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变;

 

　　9.界面测试时，应考虑数据显示的规范性：

 

　　a) 确保数据精度显示的统一：如单价0元，应显示为0.00元;

 

　　b) 确保时间及日期显示格式的统一;

 

　　c) 确保相同含义属性/字段名的统一;

 

　　d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。

 

二、UI测试常见BUG汇总

适用于新手

 

　　录入界面

 

　　1.1 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）

 

　　1.2 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）

 

　　1.3 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息

 

　　（1） 长度校验

 

　　（2） 数字、字母、日期等等的校验

 

　　（3） 范围的校验

 

　　1.4 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示

 

　　1.5 下拉框不选值的时候应该提供默认值

 

　　1.6 相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）

 

　　1.7 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）

 

　　1.8 日期参照应该既能输入，又能从文本框选择

 

　　界面格式

 

　　2.1 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性

 

　　2.2 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性

 

　　2.3 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致

 

　　2.4 不同界面显示相同字段的一致性（如列表界面和编辑界面）

 

　　2.5 界面按钮显示要求（查询、新增、删除顺序）

 

　　2.6 列表的顺序排列应该统一（按照某些特定条件排序）

 

　　2.7 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定

 

　　2.8 所有弹出窗口居中显示或者最大化显示

 

　　2.9 信息列表中如果某个字段显示过长用“…”或者分行显示

 

　　2.10 人员、时间的缺省值一般取当前登录人员和时间

 

　　2.11 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”

 

　　功能问题

 

　　3.1 按钮功能的实现（如返回按钮能否返回）

 

　　3.2 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示

 

　　3.3 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）

 

　　3.4 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮

 

　　3.5 没有选择记录点击删除/修改按钮要提示“请先选择记录”

 

　　3.6 选择记录后点击删除按钮要提示“确实要删除吗？”

 

　　3.7 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容

 

　　3.8 界面只读的时候（查询、统计、导入）等，应该不能编辑

 

　　查询问题

 

　　4.1 查询条件缺少一些可以查询的字段

 

　　4.2 有些查询条件需要支持模糊查询

 

　　4.3 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）

 

　　4.4 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一

 

　　4.5 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）

 

　　4.6 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么

 

　　4.7 对于范围的查询采用全闭的形式（如 [2006-1-1,2006-12-30]）

三、界面测试经验总结  

 

1．应验证界面显示内容的完整性：  

 

a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

 

b) 所有有数据展现的界面（如统计、查询、编辑录入、打印预览、打印等），必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常；

 

 

 

2．应验证界面显示内容的一致性：

 

a) 如有多个系统展现同一数据源时，应保证其一致性；

 

 

 

3．应验证界面显示内容的准确性：

 

a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

 

 

 

4．应验证界面显示内容的友好性：

 

a) 对统计的数据应按用户习惯进行分类、排序。

 

b) 某些重要信息在输入、修改、删除时应有“确认”提示信息；

 

c) 界面内容更新后系统应提供刷新功能。

 

d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面；

 

 

 

5．应验证界面提示信息的指导性：

 

a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

 

b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

 

c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述；当输入数据不符合规则时应提示用户是否继续。

 

d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存（如果用户没有主动保存的情况下）；

 

 

 

6．应验证界面显示内容的合理性：

 

a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

 

b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

 

c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确；

 

 

 

7．界面测试时，应考虑用户使用的方便性：

 

a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

 

 

 

8．界面测试时，应考虑界面显示及处理的正确性：

 

a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。

 

b) 应验证各种对象访问方法（Tab 健、鼠标移动和快捷键）是否可正常使用，并且在一个激活界面中快捷键无重复；

 

c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。

 

d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。

 

e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变；

 

 

 

9．界面测试时，应考虑数据显示的规范性：

 

a) 确保数据精度显示的统一：如单价0元，应显示为0.00元；  

 

b) 确保时间及日期显示格式的统一；

 

c) 确保相同含义属性/字段名的统一；

 

d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。

四、web 测试

1. 不登录系统，直接输入登录后的页面的url是否可以访问

 

2. 不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/download?name=file是否可以下载文件file

 

3. 退出登录后按后退按钮能否访问之前的页面

 

4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位

 

5. 重要信息（如密码，身份证号码，信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息

 

6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面

 

7. url里不可修改的参数是否可以被修改

 

8. 上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行

 

9. 注册用户时是否可以以'--,' or 1=1 --等做为用户名

 

10. 传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（','and 1=1 --,' and 1=0 --,'or 1=0 --）时是否可以正常处理

 

11. 执行新增操作时，在所有的输入框中输入脚本标签（<scrīpt>alert("")</scrīpt>）后能否保存

 

12. 在url中输入下面的地址是否可以下载：http://url/download.jsp?file=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd

 

13. 是否对session的有效期进行处理

 

14. 错误信息中是否含有sql语句、sql错误信息以及Web服务器的绝对路径等

 

15. ID/密码验证方式中，同一个账号在不同的机器上不能同时登录

 

16. ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定

 

17. 新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能）

五、Web下的整体测试

 

随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。

 

B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。

 

首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？

 

如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：

 

l 通用指标（指Web应用服务器、数据库服务器必需测试项）:

 

* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；

 

* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；

 

* Physicsdisk Time : 物理磁盘读写时间情况；

 

l Web服务器指标：

 

* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

 

* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；

 

* Successful Rounds：成功的请求；

 

* Failed Rounds ：失败的请求；

 

* Successful Hits ：成功的点击次数；

 

* Failed Hits ：失败的点击次数；

 

* Hits Per Second ：每秒点击次数；

 

* Successful Hits Per Second ：每秒成功的点击次数；

 

* Failed Hits Per Second ：每秒失败的点击次数；

 

* Attempted Connections ：尝试链接数；

 

l 数据库服务器指标：

 

* User 0 Connections ：用户连接数，也就是数据库的连接数量；

 

* Number of deadlocks：数据库死锁；

 

* Butter Cache hit ：数据库Cache的命中情况；

 

上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持） 的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧，呵呵。在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。

 

上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种，一、性能达不到目标；二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；三、服务器稳定性的问题，比如内存泄漏……。要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的 Purify与Quantify,主要是他对.net 与java ,C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。

 

我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7 秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用 Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库，呵呵。数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。

 

内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常 C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:

 

1、 Array Bounds Read (ABR) ：数组越界读

 

2、 Array Bounds Write (ABW)：数组越界写

 

3、 Beyond stack Read (BSR)：堆栈越界读

 

4、 Free Memory Read(FMR)：空闲内存读

 

5、 Invalid pointer Read(IPR)：非法指针阅读

 

6、 Null Pointer Read(NPR)： 空指针阅读

 

7、 Uninitialized Memory Read(UMR)：未初始化内存读写

 

8、 Memory Leak：内存泄漏

 

注：如果需要更多的信息，可以参见Purify的帮助信息。

 

顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了，呵呵。

 

完成此文，已经是凌晨了，也算是回答了前一段时间提出要进行B/S结构测试又无从下手的朋友的要求，在这里要向大家表达一下歉意，由于工作比较忙，难免对大家的来信有所疏漏，请大家原谅。此文的要求的读者，对测试工具有所了解，希望进入更深测试的同仁，希望我的文章给大家带来帮助,同时也借此文表达一些曾经帮助过我的朋友与同事。

 

注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。

六、WEB测试总结（架构、设计）

　1、总计架构测试

　　1）瘦客户端，业务逻辑规则多数在服务器端执行。如新闻站点、门户网站、信息发布网站等。

 

　　2）胖客户端，安全性要求较高、交互操作频繁、业务逻辑复杂。银行系统、网络游戏、网上办公系统等。

 

　　2、Web架构组成部分是否满足需求

 

　　成本、功能、安全性要求、容量要求、传输实时性。

 

　　3、服务器配置分布是否满足要求

 

　　Web服务器、应用服务器、数据库服务器可以分布在不同物理机器上也可以分布相同的物理机器上，一般优先考虑独立数据库服务器，Web服务器、应用服务器可以在相同的机器上。

 

　　4、客户端设计测试

 

　　1）功能设置测试：信息服务、办公自动化、Internet支持；

 

　　2）信息组织结构测试：线性结构、分层结构、非线性结构；

 

　　3）页面设计测试：

 

　　a) 页面一致性测试

 

　　b) 用户界面友好性及导航直观性测试；、

 

　　c) 是否适合多种浏览器；

 

　　d) 页文件的命名；

 

　　e) 页面布局技术。

 

　　5、服务器端设计测试

 

　　1）容量规划测试：点击率、延迟和流量、服务器资源；

 

　　2）系统安全测试：

 

　　a) 常识性安全策略，取消不必要的协议、控制写权限、取消服务器目录浏览属性、记录日志等；

 

　　b) 使用加密技术；

 

　　c) 构造防火墙，网络级、应用级、电路级；

 

　　d) 构建网络防毒体系。

 

　　3）数据库设计测试。

 

　　6、Web开发测试

 

　　1）源代码分析，主要是使用检查工具来完成；

 

　　2）链接测试，主要借助工具来完成；

 

　　3）框架测试：

 

　　a) 自动调整窗口大小；

 

　　b) 是否提供滚动条；

 

　　c) 打开新页面是否正常。

 

　　4）表格测试，随窗体变化自动调整大小；

 

　　5）图形测试：

 

　　a) 颜色饱和度及对比度；

 

　　b) 链接标识；

 

　　c) 图形显示是否正确。

 

　　7、与一般应用软件相比，Web测试有以下区别：

 

　　第一、Web测试的侧重点是性能、安全、易用性、兼容

 

　　第二、测试工具有所不同，如链接测试、表单测试、界面测试

 

　　8、功能测试

 

　　1）客户端的选择，优先测试流行的客户客户端；

 

　　2）客户端浏览器的配置

 

　　3）客户端的显示设置

 

　　4）内容测试

 

　　9、链接测试

 

　　1）该链接将用户带到它所说明的地方

 

　　2）被链接的页面是存在的

 

　　3）保证没有孤立页面

 

　　工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

 

　10、链接测试工具的优势：

 

　　1）简单易用

 

　　2）在实现上采用多线程技术，检查速度特别快；

 

　　3）对断开的链接可以再次测试，可以避免误判；

 

　　4）没有检查链接的数量限制，只受系统资源的约束；

 

　　5）可以分析Web应用的结构；

 

　　6）检查结果可以分类查看，自动生成HTML格式的报告；

 

　　11、Web应用链接主要测试点如下

 

　　1）测试内部链接和外部链接中成功和失败的链接点，以及应用中不被其他链接调用的页面；

 

　　2）测试链接中新网页、老网页、慢网页以及丢失的图象标题标签和属性标签等；

 

　　3）分析Web应用的结构是否合理，包括显示和某个URL相关的链接以及按照标题、描述、作者、大小、最后修改时间、类型为URL链接分类等。

 

　　12、易用性测试

 

　　易用性测试要考虑以下几个方面：

 

　　1）用户的计算机使用经验；

 

　　2）用户对浏览器以及Web的使用经验；

 

　　3）用户的业务专业知识。

 

　　13、Web系统的易用性测试分为三个方面：

 

　　1）界面测试

 

　　2）辅助功能测试

 

　　3）图形测试

 

　　● 界面测试要考虑以下几个问题

 

　　A．WEB应用系统的最终用户群是谁？

 

　　B．WEB应用界面的设计策略是什么？

 

　　C．页面中各元素布局的协调性

 

　　a) 各元素位置的协调性

 

　　b) 各元素颜色的协调性

 

　　c) 各元素大小比例的协调性

 

　　D．不同页面风格的统一性

 

　　E．用户在界面中操作的便利性

 

　　F．界面动态操作测试

 

　　a) 屏幕分辩率设置的影响

 

　　b) 浏览窗口最大化/最小化的影响

 

　　c) 选定目标元素的置中与缩放

 

　　● 辅助功能测试

 

　　A．使用说明，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容

 

　　B．导航功能

 

　　C．站点地图

 

　　D．帮助，这个没有多大意义，WEB网页按F1弹出来的页面都是IE的帮助页面，除非有特定的帮助说明内容。