想看更多内容请移步专栏

转载：【1+X】软件测试技术 - Web 测试 - 蓝桥云课 (lanqiao.cn)

Web 测试

知识点

• 页面内容的测试
• 功能测试
• 性能测试
• 安全性测试
• 图形用户界面测试
• 配置和兼容性测试
• 数据库测试
• 接口测试

简介

Web 测试是软件测试的一部分，是针对 Web 应用的一类测试，本书前面章节都是软件测试基本知识的介绍，而这一节 Web 测试则是印证之前所学内容的极佳方式。

Web 网页是由文字、图形、声音、视频和超链接等组成的文档页面。网络客户端用户通过浏览器中的操作，搜索浏览所需要的信息资源，服务器后台主要是用于对网站前台的信息管理，如文字、图片、影音和其他日常使用文件的发布、更新、删除等操作，同时也包括对网站数据库的管理及网站的各种配置。

由于 Web 具有分布、异构、并发和平台无关的特性，因此它的测试要比普通程序复杂的多。不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适，还需要从最终用户的角度进行安全性和可用性测试。由于 Web 应用与用户直接相关，又通常需要承受长时间的大量操作，因此 Web 项目的功能和性能也都必须经过可靠的验证。

本章主要从以下几个方面来介绍 Web 网站测试：

• 页面内容测试
• 功能测试
• 性能测试
• 图形用户界面测试
• 配置和兼容性测试
• 安全性测试
• 数据库测试
• 接口测试

实际上，Web 网页各种各样，读者可以针对具体情况选用有针对性的测试方法和技术。

页面内容的测试

页面内容测试是用来检测 Web 应用系统页面文本的正确性、准确性和相关性。

信息的正确性指信息必须是真实可靠的，不能是胡乱编造的。一条不实的新闻报道或虚假的广告宣传可能会引起不良的社会影响，甚至会让公司陷入麻烦之中；再比如，在商品价格列表中，错误的价格可能引起财务问题甚至导致法律纠纷；网页上一些过期的信息也需要及时核查，以免影响用户的信任感。

信息的准确性是指网页文字表述要准确，不能有语法或拼写错误。在 Web 应用系统开发的过程中，可能是开发人员先开发出功能，然后才对这个功能进行描述，而开发人员常常不是特别注重文字表达，有时他们对文字的改动只是为了页面布局的美观，所以文字内容可能会让人产生误解，因此测试人员需要检查页面内容的文字表达是否恰当。

如果有明确的预期结果，通常可以使用自动化测试工具来测试页面内容，比如 QTP，它可以把脚本执行的实际结果和预期结果作自动对比。最简单的也可以使用文字处理软件来进行测试，例如使用 Microsoft Word 的“拼音与语法检查”功能。但仅仅利用软件进行自动测试还是不够的，还需要人工来测试文本内容。

信息的相关性是指能否在当前页面找到与当前浏览信息相关的信息列表入口，也就是一般 Web 站点中所谓的“相关文章列表”。测试人员需要确定页面中是否列出了相关内容的站点链接。

另外，大多数浏览器都支持文字标签的显示，借助文字标签，用户可以很容易的了解图片的语义信息。比如当用户把鼠标移动到网页的某些图片上时，可能会立即弹出关于该图片的说明信息。所以进行页面内容测试时，还需检查文字标签能否正确地显示，显示结果是否和图片的内容一致。

功能测试

功能测试是 Web 测试的重点，主要是检验 Web 站点的功能能不能用，测试 Web 站点的功能是否符合需求说明书的各项要求，功能测试主要依据《需求规格说明书》和《详细设计说明书》，采用前面章节学过的黑盒测试方法来进行测试。每一个独立的功能模块都需要设计相应的测试用例进行测试。

Web 功能测试主要从以下几个方面开展：链接、表单、Cookie、设计语言。

链接测试

页面之间的超链接是 Web 应用系统最主要的一个特征，链接可能是与文字或图片拴在一起的，也可能是带有下划线的文字。一般鼠标指针经过任何类型的超链接时都会发生变化，比如变成手形指针。链接是用户从一个页面跳转到另一个页面的主要手段。

链接测试必须在整个应用系统的所有页面开发完成之后再进行，在测试时，每一个链接都要检查，确保它跳转到正确的目的地，并在正确的窗口中打开。总体来说，链接测试需要验证以下 3 个方面的问题：

• 首先，测试所有链接是否按指示的那样确实链接到了正确的页面上。如果链接打开的是电子邮件信息，也要对此功能进行测试，比如填写具体内容并发送，而且要确保能够得到收件人的回应。
• 其次，测试所链接的页面是否存在。实际上，好多不规范的小型站点，其内部链接很多都是死链接，这常常让浏览者感觉很不友好，甚至非常愤怒。
• 最后，测试 Web 应用系统是否有孤立的页面。所谓孤立的页面是指没有链接指向该页面，孤零零存在，只有知道正确的 URL 地址才能访问的页面。

链接测试可以使用工具自动进行。因为一般的门户网站，一个页面可能会有成千上万个链接，如果一个一个的手动点击效率就太低了，现在已经有许多工具可以采用。有一款简单好用的软件可以推荐：Xenu Link Sleuth，它的主界面如下图所示，它是一款免费、绿色、免安装的软件，它能快速查出一个页面中的死链接，而且可以检查多级链接（但一定要记得设置扫描级别，不然它会像爬虫一样扫描上百层的链接，这样可能会导致网络瘫痪。）

注意，页面链接测试和界面测试中的链接测试不同，页面链接测试更注重是否有链接、链接的页面是否正确；界面测试中更注重测试链接的方式和位置以及显示。

表单测试

表单指网页中用于输入和选择信息的文本框、列表框和其他域。单通常包含的元素有：文本框、密码框、列表框、复选框、单选框、下拉列表、提交按钮、复位按钮等。如下图就是一个典型的注册表单，当用户在 Web 应用系统上向服务器提交信息时就需要使用表单操作，例如：用户注册、登录、信息更新等。

表单是 Web 页面里最容易出问题的地方之一。在《易用性测试》中详解介绍了这些控件的易用性测试清单。除此之外，针对这些控件设计功能测试用例，相信大家也都有一箩筐的方法，如：边界值、等价类划分、正交法、判定表法等等。但由这些元素组成的表单在进行功能测试时都应该重点考虑哪些方面呢？概括来说，表单测试主要考虑以下几个方面的测试内容：

• 应当模拟用户提交表单，验证表单功能是否正确。如使用表单进行在线注册，要确保注册按钮能正常工作，注册完成后可以返回注册成功的消息。
• 要验证服务器能否正确保存所提交数据，而且后台运行的程序能正确解释和使用这些信息。
• 要验证数据的正确性和异常情况的处理能力等。在测试表单时会涉及数据校验问题。比如省份的字段可以用一个有效列表来进行校验。需要保证列表完整而且程序正确调用了该列表，例如在列表中添加一个测试值，要确定系统能够接受这个测试值。
• 提交数据、处理数据等操作，如果有固定操作流程可以考虑使用自动化测试，比如 QTP、Selenium 等工具都可以。编写可重复使用的脚本代码，这样就可以在回归测试时使用，以减轻测试人员的工作量。

Cookie 测试

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

有人认为网站利用 Cookie 可能存在侵犯用户隐私的问题，但由于 Cookie 对用户个人信息的利用多数作为统计数据之用，不一定造成用户的直接损失，因此现在对于 Cookie 与用户隐私权的问题并没有相关法律约束，很多网站仍然在利用 Cookie 跟踪用户行为。有些程序甚至要求用户必须开启 Cookie 才能正常使用，通常浏览器用户可以自行选择是否删除 Cookie。

如果 Web 应用系统使用了 Cookie，测试人员就必须检查 Cookie 是否能正常工作。Cookie 测试内容可包括：

• 检查 Cookie 是否按照预定的时间进行保存。
• 检查 Cookie 是否起作用，如果在 Cookie 中保存了注册信息，请确认再次登录时是否还需要再次输入用户名和密码，而且 Cookie 是否已对这些信息加密。如果保存了图片的 cookie 信息，浏览这些图片时是否可以快速查看，不需要再次下载。如果使用 cookie 来统计次数，需要验证次数累计正确。
• 检查 Cookie 保存的有效时间是否起作用。
• 检查刷新对 Cookie 的影响是否符合预期。
• 检查开多个浏览器时 Cookie 的保存情况以及同一个浏览器开多个窗口时 Cookie 的保存情况等。

同样的，Cookie 测试也可以采用工具进行，这里推荐一款工具：IECookiesView，主界面如下图所示。它可以帮助搜寻并显示出计算机中所有的 Cookie 档案的数据，包括是哪一个网站写入 Cookie 的，内容是什么，写入的时间日期及此 Cookie 的有效期限等信息。

设计语言测试

Web 设计语言版本的差异可以引起客户端或服务器端的严重问题。尤其是在分布式环境中开发时，开发人员可能都不在一起，他们可能会使用不同版本的 HTML，那么语言版本的差异性就可能会导致这样的问题。除了 HTML 的版本问题外，不同的脚本语言，例如 Java、JavaScript、ActiveX、VBScript 或 Perl 等也要进行验证。

概括来说，关于设计语言的测试，应该注意以下几个方面：

• 设计语言与浏览器引擎的兼容性。不同的浏览器内核引擎不同，导致不同的开发语言与浏览器的兼容情况也不同，当前主流浏览器的引擎有 Trident、Tasman、Pesto、Gecko、KHTML、WebCore 和 WebKit。
• 脚本语言与平台的兼容性。不同脚本语言与操作系统平台的兼容性也有所不同，测试过程中必须考虑对不同操作系统平台的兼容，即脚本的可移植性。
• 脚本语言的执行时间的差异性。由于不同脚本语言执行的方式不同，所以其执行的时间也不同。
• 嵌入其他语言的能力。如读取客户端的信息就需要使用其他语言来实现，即测试过程中应该考虑当前脚本语言对其他语言的支持程度。
• 脚本语言对数据库的支持程度。考虑系统数据库可能升级的问题，测试时需要考虑脚本语言支持数据库的完善程度。

性能测试

性能测试就是模仿用户对一个系统进行大批量的操作，得出系统各项性能指标，并从中发现系统的性能瓶颈，通过多方协助调优的过程。

性能测试通常关注以下情形：

瞬间访问高峰：比如某电视台的 Web 站点，如果某个收视率极高的电视选秀节目正在直播并进行网上投票，那么在该时段就可能会有上百万甚至上千万的请求。如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布之后的一段时间内能够响应上百万的请求。如果是个购票网站，就应该在购票高峰时段能够响应上亿甚至上十亿的请求。

每个用户传送大量数据：网上购物过程中，一个终端用户可能会一次性购买大量的商品。比如一个大学书店可能会一次性订购 5000 本有关软件测试的课本，系统能处理单个用户的大量数据吗？

长时间的使用：这个是指网站的稳定性。比如一个用于鲜花预定的网站，至少希望它在情人节或母亲节前后一周内能持续稳定运行。

网站的性能测试对于网站的运行非常重要，我们可以通过负载测试、压力测试和连接速度的测试来监控性能的各项指标，具体介绍如下：

负载测试

现在的 Web 服务器需要处理的任务日益复杂，而且承受的网站访问量也迅速增长，服务器的性能显得尤为重要。假如服务访问量过大，用户可能会得到“系统忙”的信息，这会导致用户失去耐心，放弃页面等待，并转向同类其他网站。为了让客户在使用软件系统时感到满意，必须确保系统运行良好，达到高安全、高可靠和高性能。其中，系统是否具有高性能的运行特征，不仅取决于系统本身的设计和程序算法，还取决于系统的运行环境，比如系统架构、硬件配置、网络带宽、支撑软件等。

我们可以通过负载测试来测试不同条件（比如不同的访问量）下服务器的性能表现，找出性能瓶颈所在，从而设计性能改善方案。

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

负载测试的作用是在软件产品投向市场以前，预先分析软件可以承受的并发用户的数量极限和性能极限，以便更好地优化软件。

压力测试

我们不仅要使用户能够正常访问网站，而且要知道系统过载时，需要采取哪些措施，而不是简单地提升系统性能。比如常常有黑客提供错误的数据负载，试图通过发送大量数据包来攻击服务器直到 Web 应用系统崩溃，接着当系统重新启动时获取存取权。出于系统安全考虑，就需要进行压力测试以便于开发人员在程序设计和程序算法上进行限制和采取系统回复措施。

进行压力测试是指通过破坏一个 Web 应用系统，来测试系统的限制和故障恢复能力。也就是测试 Web 应用系统在极端情况下会不会崩溃，在什么情况下会崩溃以及崩溃之后如何处理。页面表单、登录和其他信息传输页面等都是压力测试的区域。

连接速度测试

连接速度就是打开网页的响应速度。用户对 Web 响应的容忍度遵循 3-5-8 原则：用户发出一个请求后，如果在 3 秒之内得到响应，会感觉系统性能十分优秀；5 秒之内得到响应，会感觉还不错；但当请求响应时间超过 8 秒甚至更长的时间之后，用户很有可能会失去耐心，从此不再访问或者不再喜欢访问该网站。另外，有些页面有超时限制，如果响应速度太慢，用户还没来得及浏览内容，就可能需要重新登录了。连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

负载测试、压力测试以及连接速度测试都属于性能测试。性能测试应该安排在预热环境中进行，或者在 Web 系统发布之后，在实际的网络环境中进行测试。因为测试环境中的配置和实际网络环境中的配置通常是有很大区别的。

性能测试需要利用辅助工具对 Web 网站进行模拟测试。例如，组织上万个人同时点击某个站点功能按钮就很不现实。而使用性能工具可以模拟大数据并发，记录页面的响应时间，从而检测整个系统的处理能力。MicroFocus 公司的 LoadRunner 是现在使用非常广泛的一款性能测试工具，它可以编写脚本、运行脚本以及监控测试结果。下图是 LoadRunner 的脚本运行和监控界面。

安全性测试

现在，网上交易、电子支付业务已经深入到人们的生活中，尤其是对于有交互信息的网站及进行电子商务活动的网站。这些站点涉及银行账户、用户资料信息保密等问题，如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感，甚至造成严重后果。所以安全问题就显得越来越重要。

安全测试是检验在系统中已存在的系统安全性、保密性措施是否发挥作用。主要包括以下几个方面的测试：目录设置、SSL、登录、日志文件、脚本语言。

目录设置

Web 安全的第一步就是正确设置目录。每个目录下都应该有 index.html 或 main.html 页面。 日常生活中，很多应用系统都可以通过一些小手段看到本不该出现的数据信息。比如通过某商品的图片属性查看其网络路径，有时候会显示全路径，然后通过复制其上一级路径并打开，可以查看到上级目录中所有图片信息列表。如果测试工程师发现类似的问题，应当及时提出缺陷。

目录安全测试也可以通过工具进行，可以使用 IBM 的 AppScan 工具扫描 Web 系统中存在的目录安全问题，如下图所示。AppScan 是基于 Web 项目的安全测试工具，它可以扫描网站所有 url，自动测试是否存在各种类型的漏洞。AppScan 安装在 Windows 环境上，版本越高，规则库越全，扫描越全面。

SSL

给网站配置 SSL（Security Socket Layer，安全套接字协议层）证书的目的是为了网站更加的安全，可以避免不法分子盗用网站信息。所以，很多企业都开始给网站配置 SSL 证书。然而，配置了 SSL 证书之后，为了保证证书的安全性，就一定要使用测试工具去检测 SSL 证书。

SSL 是由 Netscape 首先发表的网络数据安全传输协议，它利用公开密钥/私有密钥的加密技术，位于 HTTP 层和 TCP 层之间，建立用户和服务器之间的加密通信，用以保障在 Internet 上数据传输的安全。利用数据加密（Encryption）技术，可确保数据在网络上的传输过程中不会被截取及窃听。当浏览器出现了警告消息，点击却进入一个 SSL 站点，而且在地址栏中的 HTTP 变成了 HTTPS 的时候，就是使用了 SSL。

如果开发部门使用了 SSL，测试人员需要确定是否有相应的替代页面。当用户进入或离开安全站点的时候，请确认有相应的提示信息，以及是否有连接时间限制？超出限制时间后出现什么情况？一般情况下，SSL 在线检测需要检测 SSL 证书的对称加密和非对称加密。

SSL 的测试首选的测试工具是 TestSSL.sh，它涵盖了 TLS（Transport Layer Security，安全传输层协议）和 SSL 评估所有测试的所需操作，并会进行定期更新。

登录

有些站点需要用户进行登录，以验证他们的身份，同时要阻止非法用户登录。测试人员需要验证系统能够阻止非法的用户名/口令进行登录，而同时能够允许有效的登录通过。登录的主要测试内容有：

• 测试用户名和输入密码是否有大小写区别。
• 测试有效和无效的用户名和密码进行登录。
• 测试用户登录是否有次数限制，如果允许登录失败的次数为 3，在第 3 次登录的时候输入正确的用户名和口令，测试是否都能通过验证。
• 测试系统是否限制从某些 IP 地址登录情况。
• 测试口令选择是否有规则限制。
• 测试哪些网页可以不进行登录而直接浏览。
• 测试 Web 应用系统是否有超时的限制，也就是说，用户登录后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登录才能正常使用。

日志文件

为了保证 Web 应用系统的安全性，日志文件至关重要。虽然额外的日志记录可能会导致软件程序的执行速度下降，但如果有详细的日志记录就可以帮助我们更迅速地诊断问题，加快我们对故障的响应，并且往往可以减少一些隐藏得非常深的错误。在后台，要注意验证服务器日志工作是否正常，需要测试相关信息是否都写进了日志文件、是否可追踪。

概括来说，日志文件的主要测试内容有：

• 日志是否记录了所有的事务处理，在每个事务处理时，CPU 的占用率是否很高，是否有例外的进程占用；
• 是否记录失败的注册企图；
• 是否在每次事务完成的时候都进行保存；
• 是否记录 IP 地址；
• 是否记录用户名等。

脚本语言

脚本语言是常见的安全隐患。每种语言的细节都有所不同，有些脚本允许访问根目录，其它脚本语言只允许访问邮件服务器。但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己，找出站点使用了哪些脚本语言，并研究该语言的缺陷。因此，脚本语言安全性在测试过程中也必须被考虑到。

以上是常见的安全测试的内容。常用的安全测试方法有：认证与授权、session 和 cookies、文件上传漏洞、缓存溢出漏洞、SQL 注入漏洞、XSS 跨站脚本攻击、DDos 分布式拒绝服务攻击等内容。不同的安全测试方法有不同的测试工具，实在是太多啦。这同性能测试一样，也是一门比较深刻的课题，读者可以拓展学习，也可以以此作为未来职业规划的一个研究方向。当然，实际工作中如果需要高级的安全测试，也可以外包给专业安全公司去执行测试。

图形用户界面（GUI）测试

一般使用过计算机的人都有使用浏览器浏览网页的经历，对不懂技术的用户来说界面非常重要，你应该不希望看到一篇到处是黑体字的文章，也不希望整个页面充满图片却没有任何文字标签说明。测试人员应该通过测试让 Web 站点看起来更专业一些。

用户界面测试主要包括以下几个方面的内容：

站点地图和导航

新用户在网站中可能会迷失方向，站点地图和导航（Navigation）可以引导用户进行浏览。站点地图和导航为访问者提供一定的途径，使其可以方便地访问所需内容。网站导航表现为网站的栏目菜单设置、辅助菜单、在线帮助等形式。

Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。关于导航测试，笔者总结了一些测试标准，见下表所示。

使用说明

一般要确保网页具有使用说明，因为即使非常简单的网站，也很可能有用户在某些方面需要证实一下。测试人员需要测试说明文档，来验证文字是否合理、是否正确。可以根据说明进行操作，确认出现错误的结果。

背景颜色

要验证背景颜色是否合理，是否符合用户需求。很多人把 Web 看作是图形设计作品，常常忽略了页面背景颜色是否易于浏览。比如，在紫色图片的背景上显示黄色的文本，这种页面显得“过于高贵”，而且看起来很费劲。通常来说，使用少许或尽量不使用背景是个不错的选择，如果想用背景色，最好使用单色，和导航条一起放在页面的左边。背景色要与字体颜色和前景色相搭配。

图片

有时，告诉用户一个东西的最好办法就是将它用图片的形式展示给用户。无论作为屏幕的聚焦点或作为指引的小图标，一张图片能胜过千言万语。适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。但由于宽带对客户端或服务器来说非常宝贵，所以要注意节约使用内存，不要将大图片放在首页上，否则会使用户放弃下载首页；而且当网页无法载入图片时，一般会在其位置上显示错误提示信息或者图片的 Alt 属性，这会影响用户的使用。

每张图片都要确保有明确的用途，对所在的页面都要有价值，能清楚地说明某件事情，不然它们的存在只是在浪费带宽。图片或动画不要胡乱地堆在一起，以免浪费传输时间。

Web 应用系统的图片尺寸要尽量地小，一般采用 JPG 或 GIF 压缩，最好能使图片的大小减小到 39k 以下。

表格

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

文字回绕

需要验证文字回绕是否正确。如果说明文字指向右边的图片，应该确保图片出现在右边，不要因为使用图片而使窗口和段落排列古怪或者出现孤行。验证所有页面字体的风格是否一致，过多地使用粗斜体、大号字体和下划线会令人感到不舒服，甚至降低用户的阅读兴趣。

整体界面

整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。这部分内容详见上一节《易用性测试》。

配置和兼容性测试

配置测试是指使用各种硬件来测试软件运行的过程。基于标准 Windows 的 PC 机有很多配置的可能性，比如：PC 机、模块化部件、外部设备、接口、可选项和内存、设备驱动程序等。

兼容性测试是指检查软件之间是否能够正确地交互和共享信息。例如，图片在不同的浏览器上的显示是否正确，HTML 语言的解释上也有细微的差异，这些差异可能导致应用程序的错误。

配置和兼容性测试主要考虑：浏览器兼容性、操作系统兼容性、打印机兼容性以及组合测试。

操作系统兼容测试

市场上有很多不同的操作系统类型，最常见的有 Windows、Unix、Macintosh、Linux 等。Web 应用系统的最终用户究竟使用哪一种操作系统，取决于系统的配置。这样，就可能会发生兼容性问题，同一个应用在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在 Web 系统发布之前，需要在各种操作系统下对 Web 系统进行兼容性测试。迪斯尼“狮子王”游戏就是操作系统兼容性缺陷导致的不良后果。

浏览器兼容测试

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

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

打印机兼容测试

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

组合测试

最后需要进行组合测试。600x800 的分辨率在 Mac 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 NetScape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 Web 站点，测试可能会轻松一些。有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持那些已设置的系统。如果公司指定使用某个类型的浏览器，那么只需要在该浏览器上进行测试。但是，理想的情况是，系统能在所有机器上运行，不然会限制将来的发展和变动。

浏览器环境和测试平台的兼容性测试组合矩阵如下表所示。在不同的平台和浏览器组合中执行相同的测试用例，在执行后核对结果并将是否兼容性填入表格中。

数据库测试

现有的软件系统，尤其是业务应用系统，后台都连接着一个数据库。数据库测试是 Web 网站测试的一个基本组成部分。网站把相关的数据和信息存储在数据库中，从而提高搜索效率，测试人员要真正了解后台数据库的内部结构和设计概念，制定详细的数据库测试计划，至少能在程序的某个流程点上并发地查询数据库。数据库的设计是否合理和完善，SQL 语句编写是否正确高效，都直接影响了一个软件系统的功能正确性和性能表现。

数据库测试的主要因素有：数据完整性、数据有效性和数据操作和更新。

数据的完整性：测试的重点是检测数据损坏程度。开始时，损坏的数据很少，但随着时间的推移和数据处理次数的增多，问题会越来越严重。设定适当的检查点可以减轻数据损坏的程度。比如，检查事务日志以便及时掌握数据库的变化情况。

数据的有效性：数据有效性能确保信息的正确性，使得前台用户和数据库之间传送的数据是准确的。在工作流上的变化点上检测数据库，跟踪其变化，判断其正确性。

数据操作和更新：根据数据库的特性，数据库管理员可以对数据进行各种不受限制的管理操作。具体包括：增加记录、删除记录、更新某些特定的字段。

当多个用户同时访问数据库处理同一个问题或者并发查询时，要确保数据库操作能够有足够的空间处理全部数据，当超出空间和内存容量时能够启动系统扩展部分。围绕上述的测试因素和测试的相关问题，就可以设计具体的数据库测试用例。

对数据库相关方面的测试需要注意以下方面。

数据库设计的测试

不合理的数据库设计可能导致功能实现上的一些问题，例如，一个人员管理模块表的设计，从人员出生日期可以算出年龄，那么界面上就没有必要同时出现两个字段要求编辑输入，如果年龄字段没有其他地方需要引用，则可以把这个字段省略掉，年龄界面显示可以通过出生日期计算出来。但是，如果在其他地方需要频繁使用或查询这个字段的内容，则不应该省略，为了性能考虑保持适当的冗余。这些都是测试人员在测试数据库的设计是否合理时需要考虑到的问题。

糟糕的表结构设计还可能会导致很差的性能表现。例如没有合理地设置主键和索引则可能导致查询速度大大降低。没有合理地选择数据类型也可能导致排序性能降低。

数据库设计的检查和测试需要测试人员了解逻辑设计文档和数据库设计方面的知识。另外还应该注意检查设计文档与实际数据库结构之间的差异，有没有及时同步；数据库中是否存在冗余的对象，是否可能造成程序员的误用；开发库的数据结构与测试库的数据结构是否一致。

SQL 代码规范性测试

SQL 语句、存储过程、函数、视图等语句的编写是否规范可能对查询性能、可维护性等产生一定的影响。测试人员可适当利用一些工具来帮助检查 SQL 代码的规范性。例如，SQL Best Practies Analyzer，简称 SQL BPA，如下图所示。是微软提供的用于检查 SQL Server 数据库是否符合某些最佳实践的免费工具，目的在于提高数据库性能和效率。

SQL 语句效率测试

SQL 的执行效率是影响系统整体性能的关键因素之一，尤其是在数据量比较大的情况下。SQL 的编写方法不同，数据库的执行计划就会有所差别，执行的效率也不一样。因此需要进行效率测试，分析 SQL 代码的执行效率瓶颈。

可借助一些工具来分析 SQL 语句的执行效率，如果使用的是 SQL Server 数据库，可借助 SQL Server 自带的事件探查器和查询分析器。在 SQL 查询分析器中还能查看 SQL 语句的执行计划，分析 SQL 语句的执行过程以及每一部分的成本。其他类型的数据库也有类似的分析工具。LECCO SQLExpert 是一款可以自动分析 SQL 语句的执行效率并提出改进建议的 SQL 语句写法的工具，同时比较语句之间的执行时间差异。

SQL 数据库兼容性测试

在那些需要支持多种类型数据库产品的软件系统中，可能要进行 SQL 的兼容性测试。虽然很多数据库厂商都声称支持标准 SQL，但是不同的数据库类型之间在实现上还是存在很多差异。例如 SQL Server 和 Oracle 之间就存在很多差异。有很多函数是 SQL Server 和 Oracle 都有的，但是实现的功能有所区别。有些函数实现了相同的功能，但是函数名称和参数不一致。

SQL 数据库兼容性可以与 SQL 标准规范进行比较、对不同的数据库自动执行 SQL 语句，根据结果判断是否兼容，SQL 数据库兼容性的测试主要有以下两种方法。

第 1 种方法主要是对软件系统中执行的所有 SQL 语句进行审查，看是否只能在指定的数据库执行，而不能兼容其他类型的数据库，审查主要是将 SQL 语句与标准的 SQL-92 或 SQL-99 规范进行对比。

第 2 种方法是对不同的数据库自动执行 SQL 语句，根据结果判断是否兼容。这种方法是把 SQL 语句在需要兼容的数据库上逐一执行，根据返回结果判断是否兼容 SQL 语句。

接口测试

在很多情况下，Web 站点不是孤立的。Web 站点可能会与外部服务器通讯、请求数据、验证数据或提交订单。软件的功能往往不是某个单独的模块来实现的，而是由模块跟模块之间协作共同实现某个功能，这种模块间的交互就是通过接口来实现的。除了模块与模块之间，前端和后端之间的交互也是通过接口来实现的，前端负责“貌美如花”，后端负责“糊口养家”。

所谓的接口测试是组件间接口的一种测试，主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是检查数据的交换、传递和控制管理过程，以及系统间的相互依赖关系等。我们对接口的操作最终会发送到数据库，也就是会对数据库进行一些增、删、改、查的操作。

接口测试其实是功能测试的一种，只不过我们采用测试接口的方式进行。接口测试可以发现一些页面操作发现不了的问题，它的优势在于，当页面还未开发完成的时候，就可以提前介入进行接口测试，它弥补了界面操作测试的遗漏点。接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显。由于它的特殊性，所以这里把它单列出来介绍。

接口测试最容易被测试人员忽略的地方就是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？系统能否正确处理这些错误？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，可以由客户代表致电用户进行订单确认。采取的措施是：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。

接口测试可以根据开发人员提供的接口文档为依据来执行测试，接口文档中需要包括一些参数，如：URL、接口说明、请求方式、入参、出参、请求和返回的样例，以及状态码说明等内容。对于这些概念的解释，读者在做接口测试之前需要提前了解。

接口测试需要结合工具进行，可以进行接口测试的工具很多，浏览器方面的推荐 Firefox 的 Firebug 和 Chrome 自带的开发者工具，快捷键都是 F12，如：

• Poster：火狐浏览器自带接口测试工具，在插件中安装即可，界面简单明了，容易上手。
• Postman：谷歌浏览器的扩展工具，在谷歌商店中选中安装，界面同 Poster 差别不大，界面简洁。

工具方面，可以推荐的有 LoadRunner、Jmeter、HttpClient 和 SoapUI 以及 Fiddle。

值得注意的是，接口测试应该以保证系统的正确和稳定为核心、以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本，关注持续集成是接口测试的灵魂，否则接口测试带来的工作量会成指数增长。接口的持续集成可以采取：Jmeter+Jenkins+Ant 的组合进行，感兴趣的读者可以自行研究。

小结

本章讲述了 Web 测试的几个方面：页面内容测试、功能测试、性能测试、安全性测试、图形用户界面测试、配置和兼容性测试、数据库测试、接口测试。在面试中也常常会遇到一个测试题：给你一个网站你如何开展测试？

我们可以结合前面几个章节中学过的软件测试的流程以及本章所讲述的知识点来回答这个问题：

本章讲解了 Web 网站的各方面测试内容，这里的每一个测试内容都是一个独立的软件测试课题，是一个明确的软件测试发展方向，读者可以在本文的基础上对自己感兴趣的领域深入研究，成为该领域的专家。很难要求一个测试人员对这些全部都要擅长，这通常会由团队合作完成，但我们必须对 Web 测试的全貌予以了解，有利于个人的职业发展。

无论你在测试 Internet、Intranet 或者 Extranet 应用程序，Web 测试相对于其他测试来说都是更具有挑战性的工作。针对 Web 的测试方法应该尽量覆盖 Web 网站的各个方面，在继承传统测试技术的基础上还要结合 Web 应用的特点。

另外要做好 Web 测试，测试人员需要具备一定的网络知识：如网络架构、网络协议、session、cookie、请求和响应状态码等内容。