1.2 互联网测试与传统软件测试的区别

在过去的20多年中，计算机产业经历了几次重大的发展，相应地，软件测试理论、方法、技术，以及工具也在不断地发展。在互联网诞生并高速发展的同时，由于互联网具有许多有别于传统软件的特点，传统的软件测试并不适用于互联网应用，因此，众多软件工程专家及软件测试专家们提出了许多新的软件测试理论和方法，以便更好地进行互联网测试，新的测试技术和工具也不断地进入人们的视线。

1.2.1 软件开发和测试的三次进化

从20世纪70年代微型计算机诞生开始，软件开发和测试经历了三次进化：桌面应用软件、客户端/服务器应用软件、互联网应用软件，三者在经历了长时间地平行发展后，已经出现逐渐统一的趋势。下面简单介绍一下这三次进化。

桌面应用软件的开发和测试

桌面应用软件的开发和测试始于20世纪80年代。那个时候虽然已经存在网络，但是由于网速非常慢，因此极少有桌面应用软件与网络信息资源连接。桌面应用软件采用事件驱动架构，应用程序从逻辑上分开管理窗口和菜单事件。应用程序命令操作系统打开一个窗口、初始化一个下拉菜单，然后等待操作系统将用户“选择了菜单命令”或“移动了窗口”等情况通知应用程序。在本地，当操作系统“发出一个事件”时，应用程序对此作出响应。从本质上来说，桌面应用软件是过程性的，它遵从一种简单的单一途径，即从开始初始化一直到完成最后的单一目标。

使用事件驱动架构建立的桌面应用软件，与目前面向对象的软件相比，开发和测试都要容易得多。但是，事件驱动设计模式仍然是软件开发与测试的第一次重要进化，从这个时候起，软件开发与测试开始向自动化的方向发展。桌面应用软件的开发自动化注重编码和建立软件所需的时间，通过桌面应用程序框架为软件开发人员编码提供了一种快捷的方法。而桌面应用软件的测试自动化，则主要为了节省用于测试一个桌面系统功能所需的时间，通过测试工具链接到应用程序中并尝试每个命令，就如同用户访问菜单和窗口命令一样。

另外值得一提的是，也是从桌面应用软件的生命周期开始，第一次真正出现了单元测试。桌面应用软件生命周期大致如下：

● 用一个Feature List来说明程序。

● 编写应用程序。

● 对应用程序进行单元测试。

● 修改在单元测试中发现的问题。

● QA工程师对应用程序进行测试。

● 开发人员修改QA工程师测试发现的问题。

● QA工程师进行回归测试。

● 回归测试通过后交付外部Beta测试人员，对应用程序进行测试。

● 修改Beta测试发现的问题。

● 将应用程序交付给客户。

● 进入维护阶段，开发新功能以及修复客户使用中反馈的缺陷，推出新版本。

仔细看看以上的软件生命周期，实际上，到目前为止，很多的软件企业依然在使用这个经典的软件生命周期。这个软件生命周期最大的问题在于，它太过于严格，以致于不允许采用较短的版本周期，一般新版本推出的时间至少是在6个月之后，即使很小的维护版本（例如，重大缺陷的Hot Fix），也只能从6个月缩短到几个星期。关于这一点，可以参考一下微软的产品发行速度，便很容易理解。在早期用户对软件需求普遍较低的年代，这个问题并没有暴露出来，但随着用户对软件的要求越来越高，这个问题所带来的弊端也越来越明显。

客户端/服务器应用软件的开发和测试

客户端/服务器应用软件的最初目的，是将表示逻辑和业务逻辑分离。在一个理想的系统设计中，客户端负责表示用户的界面，并显示一系列结果信息；客户端处理功能，而服务器则对数据作出响应。不过实际中很少能有这么明确的分工。由于客户端/服务器应用软件具有的集中特性，因此使得系统的维护、部署和开发更为方便快捷，成为软件开发和测试的第二次进化。

在客户端/服务器应用软件中，需要明确地定义协议，从而使所有客户端都使用相同的协议来与服务器进行通信。这简化了代码重用和远程数据源中提供的信息，并为智能客户功能提供了可能性。相应地，开发框架也被扩展成为客户端和服务器端两种框架。客户端框架不但提供了与桌面应用程序框架相同的功能，而且还提供了与服务器通信所需的命令代码，以及从服务器接收并自动更新客户端的代码；服务器端框架提供了从多个客户端接收并处理请求的代码，以及为了数据持久化而与数据库或远程信息提供商连接的代码等功能；同时，这些框架要能够处理有状态的事务和间断的网络连接。

刚才说过，桌面应用软件从本质上来说是过程性的，那么客户端/服务器应用软件从本质上来说，是事务性的，而且需要与用户通过几次交互才能完成一个单独的请求。对于客户端/服务器应用软件的测试来说，它需要比桌面应用软件的测试做更多的工作，这主要包括以下几个方面：

● 由于客户端/服务器应用软件在网络环境下运行，因此测试不仅需要检验应用程序的功能，还需要测试应用程序为何处理缓慢或者为何会出现拒绝服务等等，即测试应用程序的性能。

● 客户端/服务器应用软件开始出现明显的层次结构，对于不同的层需要采用不同的测试方法，同时还要测试不同层之间的兼容性，例如服务器端程序版本升级后，新版本的服务器端程序能否兼容旧版本的客户端程序，因为并不是所有用户都会乐于升级客户端程序；不同版本的客户端程序之间是否能正常协同工作也是一个需要考虑的问题。

● 由于软件运行在网络环境下，因此安全性测试也是值得考虑的一个问题，包括通信协议的保密性、服务器的防攻击能力、权限体系是否存在漏洞等等。

● 客户端可能部署在不同的操作系统上，并且可能使用不同的字符集，这可能会导致一些问题，需要有针对性的测试。

● 数据通过网络传输并保存在远程数据源中，因此需要测试在使用过程中网络突然出现中断后，各处的数据是否仍然保持一致。

● 与桌面应用软件相比，客户端/服务器应用软件与用户的交互更多，这带来了更多的分支流程与异常流程，使得测试用例的数量大大地上升。

这些对QA工程师来说是一个很大的挑战，它意味着QA工程师需要将自己的工作效率提升数倍以完成更多的工作，并且还需要提升自己的能力，来完成包括性能测试、安全性测试在内的新兴的测试。

不过，与桌面应用软件生命周期相比，客户端/服务器应用软件生命周期并没有明显的变化，版本的更新速度仍然越来越难以满足用户的需要。并且用户通常因为“懒”而不去升级客户端，使得新版本软件不得不兼容各种旧版本的软件，随着旧版本数量的增多，开发和测试工作的难度呈指数上升，以致于到某个时候不得不进行客户端强制升级，这对于用户来说显然是不够友好的。

互联网应用软件的开发和测试

互联网应用软件带来了软件开发和测试的第三次进化，它在以下领域进行了扩展：

● 互联网应用软件意味着无状态。HTTP的设计就是无状态的。来自互联网应用软件的每个请求都是原子的，并且与以前的请求没有关联。而这对于系统的体系结构和数据中心是非常有好处的。

● 互联网应用软件是与平台无关的，可以在任何操作系统上开发，只要能够实现命令协议和服务器网络连接即可。

● 互联网应用软件只需要客户端提供显示功能以及执行简单脚本的能力，这点浏览器通常足以胜任，这样避免了兼容大量老版本客户端的烦恼。

● 互联网应用软件相比客户端/服务器应用软件更为集中，因此维护和部署更为简单快速。

● 由于互联网应用软件的出现，SaaS（软件即服务）成为现实，用户可以根据需要租用软件，而非一次性买下软件。

互联网应用软件对软件生命周期产生了深远的影响，形成了互联网应用软件生命周期，大致如下：

● 以网站站点物理模型来说明程序。

● 编写软件。

● 对应用程序进行单元测试。

● 修改在单元测试中发现的问题。

● 内部人员对应用程序进行测试。

● 修改测试中发现的问题。

● 将软件发布到互联网上。

● 为已经在提供服务的软件快速修复缺陷。

后面还会提到，在测试驱动开发（TDD）理论中，上面的第二步和第三步还要互换一下位置，即先编写测试，再开发应用程序代码，这听上去很有意思。

现在比较一下互联网应用软件生命周期和桌面应用软件生命周期，从中能发现什么？最显著的区别是互联网应用软件生命周期更简单，经过的步骤更少，因此互联网应用软件能解决传统软件版本更新速度慢的问题，非常快速地响应用户的需求，第一时间推出新版本的软件。对于互联网软件公司来说，新产品从最初开发到上线运营一般只需要2到3个月的时间，有些甚至只用三周的时间；产品大的版本更新的速度大约为一周到一个月；而小的维护版本（快速修复用户反馈的缺陷、个别功能的修改等等）更是可以达到每周两次常规更新。这样的版本更新速度对于传统软件是不敢想象的。

互联网应用软件生命周期简化了传统的软件生命周期，省去了其中的一些步骤；同时，互联网应用软件又具有许多传统软件所不具备的特点；那么相应地，必然要采用新的测试技术与方法，才能有效保证互联网应用软件的质量。接下来就来看看互联网应用软件的测试具有哪些特点。

1.2.2 互联网应用软件测试的特点

互联网应用软件测试的特点，其实是由互联网应用软件自身的特点所决定的。归纳起来，互联网应用软件的特点大致包括：生命周期短、性能要求高、需要良好的跨平台性（不同的操作系统、浏览器、字符集等等）、尽量减少网络的影响（网速、路由、丢包等等）、安全性要求高、数据集中存储、异构系统互联互通等特点。相应地，互联网应用软件测试大致具有以下8个特点。

1.高效的单元测试

在互联网应用软件的测试中，单元测试比以往都更为重要。高效的单元测试，指的是用最短的时间使被测单元的质量达到最高。互联网应用软件的一大特点是“短、平、快”。“短”即生命周期短，“平”指的是每次修改的内容少，“快”则是对客户的反馈响应快。在这种情况下，要保证软件的质量仍然处于一个很高的水平，一个有效的办法就是通过单元测试在最短的时间内尽可能多地找出被测单元的缺陷，尽量减少缺陷留到系统测试阶段才被发现的机会，而这能节省后期修复所花的大量的时间。

事实上，在要求保证代码质量的前提下，高效的单元测试甚至能大大提升开发应用程序代码的速度，测试驱动开发（TDD）已经明确地指出了这一点。同时，由于每次修改的内容少，通过高效的单元测试后，基本上剩下的缺陷数量已经被控制在一个很小的范围内，在系统测试阶段，通过有针对性的测试（当然这需要QA工程师丰富的经验）以及自动化回归测试，很快就能找出剩下的缺陷并快速修复，最终快速地发布一个新版本。

另外，单元测试能很容易地重复对代码的测试，这对于重构来说，意味着可以用最短的时间来保证重构后的代码质量是可靠的。

2.自动化功能回归测试

同样是因为互联网应用软件“高频率、小改动”的特性，自动化功能回归测试显得非常重要。由于每次修改的地方只是一小处，因此可以把绝大多数没有修改的地方交给机器去验证，而QA工程师只需要凭借其丰富的经验，对与修改相关的功能点进行重点验证即可。

而在传统的软件测试中，自动化测试更多地是在软件生命周期的后期，软件产品已经基本不再会有改动时进行，这个时候自动化测试主要的好处是减少QA工程师的体力劳动，避免因QA工程师因反复重复的工作产生疲劳感和挫折感，影响到软件的质量，对于缩短软件生命周期的作用并不太大，因此很多时候传统软件测试并不怎么需要自动化测试。

3.性能测试

无论是桌面应用软件还是客户端/服务器应用软件，其对性能的要求远不如互联网应用软件。对于互联网应用软件来说，通过互联网即可以使用意味着一套生产环境下的应用，其最终用户数可能以百万计，千万计，甚至以亿作为单位，最典型的就是电子邮件，早在2004年12月，仅仅雅虎全球邮箱的注册账号数就已经超过了10亿个。

巨大的用户数量对互联网应用软件的性能提出了很高的要求，而性能测试则是发现性能问题从而进行优化来提高系统性能的最有效手段。传统的软件测试可能根本不需要进行性能测试，把项目组成员集中在某个时间一起进行操作，来简单测试一下软件的性能究竟如何也许就能满足需要。而对于互联网应用软件，需要有计划地、分阶段地、严格地进行性能测试与分析，并且一般需要使用各类软件性能测试工具，例如大名鼎鼎的LoadRunner。

4.分层的测试

从体系结构上来说，互联网应用软件可以分为二层结构、三层结构和多层结构等，每一层都有其独有的特点，而测试工作需要根据每一层的特点进行有针对性的测试，而不是仅仅在客户端表现层进行测试，否则很多的问题是无法被测试出来的。

举个简单的例子，有一个CRM（客户关系管理）系统，需求规定客户名称、地址、联系方式等都不允许输入特殊字符（!@#$%^&*/<>\等），因为这可能带来很多的问题，比如引起HTML解析不正确、导致跨站脚本漏洞攻击等，并且这些字段确实不需要输入这些特殊字符；那么在测试的时候，除了在客户端浏览器上需要验证这些字段的输入框确实屏蔽了这些特殊字符，还需要绕开客户端浏览器，通过直接发送HTTP请求的方式（这里假定该系统使用HTTP协议），向服务器提交包含特殊字符的表单，来确认服务器同样已经屏蔽了这些特殊字符，不会将它们保存到数据库中。

在这里我们既对客户端表现层进行了测试，又对服务器端的业务逻辑层进行了测试，之所以这么做，是因为仅仅依赖于客户端表现层是不可靠的，用户可以有许多手段直接跟业务逻辑层打交道，因此需要对业务逻辑层进行测试，而客户端表现层直接影响到软件的用户友好度，对它的测试当然是不可或缺的。而传统的软件测试通常都是基于GUI（图形用户界面）进行测试的，并没有明确地要进行分层的测试。

5.跨平台的测试

传统的软件测试一般只需要在不同的操作系统上进行测试即可，但是对于互联网应用软件的测试来说，由于互联网应用软件要求能够跨越各种平台，无论用户来自哪里，无论用户使用何种操作系统、浏览器，无论客户端的字符集是什么，互联网应用软件都应该能够正常工作，这是需要专门进行测试的。

假设某个互联网应用软件要求支持IE 6、IE 7、Maxthon 1.5、Maxthon 2.0以及Firefox等，这就要求在所有这些浏览器上都进行过完整的测试（虽然Maxthon使用的是IE内核，但在某些情况下仍然会出现支持IE却不支持Maxthon的问题）。同时，不同的操作系统下的测试显然也是必须的，看上去这里的工作量实在是很惊人，使用矩阵是个不错的方法，通过将不同操作系统和浏览器设计成测试矩阵，并分为不支持、部分支持且简单测试、完全支持且中等程度测试，以及完全支持且完全测试几种情况，从而进行相应的测试。

另一个值得一提的问题是字符集，最简单的例子是，台湾的用户通过某个Web Mail系统（通过浏览器收发及阅读电子邮件的系统）向内地的用户发送了一封电子邮件，这封电子邮件显然是BIG 5编码的，那么虽然内地用户默认的编码是GBK，但他应该能看到这封邮件的正确内容，而不是乱码。当然大部分情况下字符集引起的问题很少，但是它仍然会在某些情况下使软件功能变得不正确，这也是需要经过严格测试的。

6.不同网络环境的测试

互联网应用软件的用户可能来自任何地方，因此他们的网络环境可能比较糟糕，例如网速很慢、丢包率很高、存在路由黑洞等。这方面传统软件并不存在很大的问题，虽然客户端/服务器应用软件同样运行在网络环境中，但这通常是在局域网，即使是在广域网上运行（例如大型跨国企业内部使用的软件），网络环境也是比较好的。

在糟糕的网络环境下，往往会产生许多原本没有的问题，例如某个互联网应用软件本身性能很好，内部性能测试的时候完全没有问题，但是在发布到生产环境以后，部分用户会抱怨说软件操作起来很慢，令他们难以忍受，而产生这个问题的原因就在于，抱怨软件操作速度慢的那部分用户，他们的网络环境是比较糟糕的，网速比较慢，下行带宽可能只能达到30KB/s，而该软件的页面普遍比较大，最大的一个页面其大小甚至可以达到1MB，那么计算一下，这个页面在网络上传输所需要花费的时间就达到了34秒多。这个结果很惊人，即使服务器端应用程序能在1秒内就完成所有操作并将结果返回给客户端，用户仍然得等上半分多钟才能看到结果在浏览器上显示，所以用户会抱怨操作速度慢是很正常的。

用户不会去了解操作速度慢的真正原因，对于他们来说，操作速度慢就意味着软件的性能不佳，当他们难以忍受的时候，就会选择其他的软件，这个问题在宽带网络还不是特别发达的中国尤其明显。如果在不同的网络环境下进行过测试，那么这个问题就可以暴露出来，然后针对这个问题，尽可能地减少各个页面的大小。

7.安全性测试

互联网应用软件运行在互联网上，是完全暴露的，因此受到攻击的可能性要远远高于传统软件。不安全的体系结构、糟糕的编码决定、不良的习惯以及简单的错误都会打开安全漏洞。安全性测试是一项很有挑战的工作，同时也是一项非常重要的工作。

一般而言，对于数据保密程度要求非常高的应用，例如银行的一些应用，需要专门从事安全性测试的专业人员来测试这类问题，而这些专业人员本身就是精通各种攻击、解密手段的高手。当然即使应用对安全性的要求达不到银行级别那么高，包括目录设置、SSL、登录、日志文件、脚本语言等在内的一些问题，仍然应该在测试的时候予以特别关注。

8.接口测试

随着互联网应用软件越来越多，对于不同的互联网应用软件互联互通的需求也越来越多。例如一个用户是淘宝网上的一个大卖家，每个月要跟几千个人发生上万笔交易，因为客户、产品、交易的数量太多，他可能会另外使用一个简单的管理软件来管理他的客户、产品、交易等，那么他一定希望淘宝的交易平台能够与管理软件互联互通，使得他能够直接在管理软件中管理他在淘宝上的客户、产品、交易等，甚至能进行一些批量的操作，而不是手工在管理软件中一条一条登记，那样就跟在本子上手写记账差不了多少。

前文提到的阿里巴巴软件互联平台，就是一个允许任何应用接入，并且应用与应用之间能够实现互联互通的开放平台。互联网应用软件要互联互通，一般都是通过接口进行，因此接口测试是互联网应用软件测试的一大特色。在第4章，将会专门来讨论如何进行接口测试。

由于本书主要讨论的内容为网站单元测试，以及网站接口测试，因此对于网站的其他测试，在这里不再作过多的描述。