第1章 什么是软件测试
在我国宋代，有一位叫宋慈的法医学家写了一本《洗冤集录》。在书中，他讲述了很多断案的经验，其中有一个用银针验毒的方法至今仍广为流传。比如在很多电视剧中，我们能经常看到皇帝在进膳的时候，由于害怕被人暗害，总要让可怜的太监或者宫女先用银筷子尝上几口饭菜，没有出现问题再正式用餐。这种用银针进行的试验就可以说是一种测试的雏形吧，银针充当了测试工具，而太监或者宫女就是古代的测试工程师。
时光飞逝。随着科技的发展，我们生活周围有了越来越多的产品，它们在出厂销售前都要进行测试，不仅要保证功能完好，还要确保对使用者的伤害在允许范围内。因此在工厂里，逐渐出现了这样一个部门，由它来负责检验产品，被称之为质量检验或者质量保证部。
上个世纪中后期，软件出现了，它作为人们日常生活中天天都会使用的产品，同样也需要质量的保证。有一种误解：软件的质量问题并不那么重要，比如Windows等操作系统，各种桌面的应用软件，像IE浏览器，如果它出现了问题，程序会失去响应甚至严重的系统会蓝屏，那么只需要在任务管理器中将它删掉就可以了，最多重新启动电脑，一般都能够继续使用。这只是一方面，另一方面，有很多非常重要的软件在我们看不见的地方默默地运行着，如果它们出现了问题，影响就很大了。
为了说明软件质量的重要性，这里举一个比较著名的软件质量造成的事故。
1962年，美国的航海家1号（Mariner 1）火箭升空，由于控制火箭的软件出现问题，直接导致火箭升空后因偏离轨道而被迫引爆，造成当时1800万美元的损失。事后查明，是程序员在编写软件代码时，误写了其中一个公式的上标造成轨道计算失误的。
因此，软件公司也需要质量保证部门。我们把该部门的组成人员称为QA工程师，QA即Quality Assurance质量保证的简称。软件是否符合质量是通过测试来验证的，因此他们也被称为软件测试工程师。在本书中您即将遇到的各种行为，绝大多数都将是软件测试工程师在工作中所要实现和完成的。
1.1 软件开发的基本知识
对于每一位进入软件测试行业的新人来讲，公司的入职培训是一个很好的学习机会。
1.1.1 软件开发公司技术部门的基本结构
可将软件测试部门类比于工厂车间的质量保证部门，那么显而易见，如果在工厂中要做好质量控制的工作，必须熟悉本厂生产的产品和流程。换句话来说，作为软件生产的参与者，了解被测试的软件也是非常重要的一件事情。这也正是经理要求小白在短期内尽快熟悉的内容。
【什么是软件】
中国大百科全书中对软件的定义是：软件是计算机系统中的程序和相关文件或文档的总称。软件是从英文Software翻译过来的名词，与硬件（Hardware）相对应。
因此，软件开发公司就是制造这些程序和相关文件或文档的商业机构。一般来说，软件开发公司的技术部门由几个子部门或者角色组成：开发部门、测试部门、部门经理或者项目经理，另外有的公司还有技术支持部门。对应于传统行业，分别相当于生产车间，质量控制部门，部门经理和售后服务部门。如表1-1列出了常见软件开发公司技术部门的不同职责。
表1-1 常见软件开发公司技术部门的角色分类
部 门 | 职 责 |
软件开发部门 | 开发软件：确定软件实现方法， 编写软件程序代码 |
软件测试部门 | 测试软件：确定测试方法，编写自动 测试软件的代码，手工测试软件， 记录并跟踪软件Bug |
技术总监或项目经理 | 在所属或其他部门之间沟通，协调项 目或者开发测试进度，为成员提供各种资源 |
技术支持部门 | 软件开发完成后在客户处部署产品， 并解决与反馈使用中出现的问题 |
Web应用是一种特殊的软件。那么开发Web应用的网站与一般的软件开发公司有什么不同呢？
对于小白所处的商业网站来说，网站程序和相关文件或文档也可以称之为软件，其技术部门的结构也和软件开发公司基本类似，但是各部门日常工作的方式则有所不同。
商业网站每天都要有很多页面的更新，每次更新后当时浏览网站的人立即可以看到；而软件开发公司一般一年或者几年推出一个产品，在产品没有上市的时间内，用户只能使用旧的版本。也就是说网站软件的变化要比软件开发公司频繁，网站软件的开发与用户使用处于同一时间段内。
商业网站以服务器为核心，网站软件主要运行在服务器上；而软件开发公司的产品主要运行在用户的电脑上。
【演唱会与专辑】
商业网站与软件开发公司的运作模式有点类似于歌手开演唱会和发专辑的区别。在演唱会上，歌手与观众的互动性更强，每一个细节的变化也都能被观众捕捉到；而歌手专辑则相当于软件产品的某个版本，是提前制作完成之后再上市销售的。
1.1.2 软件危机
小白在熟悉了技术部门的大致结构，网站与软件开发公司的区别之后，经理开始介绍和软件测试相关的背景知识。软件危机就是产生软件测试这一职业的重要推动力之一。
从20世纪50年代以来，软件的规模越来越大，复杂性也越来越高，另外，在20世纪80年代，伴随着计算机的普及和应用需求的飞速增长，互联网开始蓬勃兴起。现在，现代人的生活已经越来越依赖各种各样的软件，软件不再是大学实验室里科学家的工具，而成为我们生活的一部分。从操作系统，比如每一台个人电脑所安装的Windows XP或者Vista系统，到小小的桌面程序--一个简单的连连看小游戏，再到Google网站上可以编辑的在线文档工具，软件的开发、管理、维护的复杂性和高成本现象也日益突出，在某一段时期，暴露了很多问题。因此在20世纪，有人提出了"软件危机"的说法，来说明这种现象。
【软件复杂性的类比】
其实我们中国人是很容易理解软件复杂性的。一些在人口少的国家不成为问题的问题，放在十几亿人口的环境中，就会产生不大不小的麻烦，比如每年的春运--需要火车票的人是如此之多，而火车的座位是固定数量的；需要回家的人的分布是如此之广，而火车站的位置也是固定的。依此类比，当软件的代码量越来越庞大，要满足的需求越来越广泛时，出现局部的危机是很容易理解的。
1.1.3 软件危机的几个体现
随着软件越来越复杂，质量越来越难于控制，于是出现了所谓“软件危机”。具体而言，软件危机有以下几个体现。
软件需求的增长无法快速得到满足。这一点在前文已经有所讲述。
软件生产成本变高，价格越来越昂贵。软件的代码量增加，所投入的人工成本，也就是软件开发相关人员的成本也会增加，还要增加采用各种新技术的成本等。
软件生产进度难于控制。
软件的用户需求不容易定义。这一点也很重要：目前绝大多数的软件已经不止满足单一的需求，因此用户真正所需要的不一定能够完美地实现。
软件质量不容易保证。这一点也是由软件复杂度的增加而增加。还是举春运的例子，如果火车上人人都有座位，那么每个人的心情都会很好；但如果到处挤满了人，每位旅客回家的心情总会受到影响，从而影响对列车服务的评价。软件质量和用户的评价同样是相关的：经常造成死机、异常退出或者按钮单击后没有反应的软件，很难说是质量好的软件。
软件可维护性变差。软件同样是需要维护的：一方面是对于用户使用过程中的维护，这一功能由客户服务或者技术支持部门来完成；另一方面是对于软件本身代码和文件文档的维护，这一功能由开发部门或者测试部门来完成。随着软件的日益庞大，软件本身经历的修改越来越多，管理维护软件的各种版本变得日益困难。
由于软件危机有这么多的影响和危害，所以促使人们静下心来研究软件开发过程中的规律，这就产生了软件生命周期的概念。
1.1.4 软件生命周期
软件生命周期，英文为Software Lifecycle，就是软件开发、使用和消亡的过程，具体而言，包含软件需求分析、软件设计、软件实现与测试和软件发布、部署与维护这4个过程。
在商业软件开发公司内部，人们往往遵循一定的软件生命周期模型，这样和被开发软件相关的所有人员都按照这个模型的标准或者步骤开展工作，统一行动，有助于提高生产效率，从而减少沟通和实施的成本，获得更大的商业利益。而对于软件生命周期的不同理解和划分，就形成了不同的软件生命周期模型。
1.1.5 常见的软件生命周期模型
目前来讲，主要的软件生命周期模型有如下几种。
Big-Bang：大爆炸模型。
Waterfall：瀑布模型。
Spiral：螺旋模型。
Code and Fix：边做边改模型。
由于本书并不是以软件工程为探讨内容，因此在这里只通过人们过河的类比来简单介绍一下前述这几种软件生命周期模型的特点。
小学课本里有个寓言叫做"小马过河"，小马在过河前遇到了不同的小动物，它们对于河水深度的理解是不同的，会导致小马过河时的不同选择，参见图1-1。假设把待开发的软件产品比喻为小马面前横着的那条小河，那么开发软件的过程也就是过河的过程，那么如何过河就会有不同的结果。
图1-1 小马过河：对河深度的理解影响过河的方法
1.1.6 直接冲过河去的大爆炸模型
大爆炸这个名称来自于天体物理有关宇宙形成方式的一种理论：宇宙是在亿万年前的大爆炸中诞生的。与此类似，软件开发公司把金钱、办公场地和人员全部投入到一个产品的开发当中，经过一段时间，产品出炉，这样的形式就是大爆炸模型。
大爆炸模型的优点就是简单，没有很多的软件设计，对项目的管理也很少，目前不少小公司由于各方面的限制不得已或者不自觉地采用了这样的开发模型。但是它的优点也造成了它的缺点：开发出来的软件质量不可控制。
在这样的模型中，由于没有周密的计划，软件测试往往是在产品即将上市的前夕才开始，在很多公司中甚至没有专职的测试工程师，由开发人员或者其他人员代劳，因此测试人员面对的产品与客户、使用者要面对的产品基本一致。从前文所述可以得知，在这样的阶段发现Bug，返工修改代码的代价是非常大的。
回到过河的比喻中来，大爆炸模型就相当于小马先退后几步，集中精力和能量，然后快速冲过去。这样的结果取决于河的宽度和深度。如果软件非常复杂，很可能过河的小马半途就淹死了，无法到达对岸。
1.1.7 摸着石头过河的边做边改模型
边做边改模型比起大爆炸模型来说进了一步。在开发软件产品的开始阶段，先有一个大概的设计，然后开始编码，测试，发现Bug，修改Bug这样的循环，直到整个产品的轮廓日渐清晰，最终完成产品。用一句俗话来描述，就是"摸着石头过河"的过程：先以河里的一些石头为支点，走入河道，再经过不断的试探和返回得到一条路线，最终到达目的地。
由此可见，边做边改模型中测试的参与要比大爆炸模型中要早得多，而且也重要得多。边做边改模型的优点就是适用于某些中小型项目的快速开发，软件产品的成果也会在最早的阶段显现出来：和在岸边冥思苦想如何过河的人相比，先站在河道里的石头上，总是让人看到更多的希望。
【边做边改模型被较多采用】
这种开发模型被大多数公司所采用，是大多数测试工程师在实际工作中最常遇到的开发模型之一。而且，它和最近几年很流行的敏捷开发也有一定的关系。
1.1.8 制定周密过河计划的瀑布模型
从现在开始，下面的这两个模型就不适合小马了，只有人和外星人才有这样的能力。如图1-2介绍了软件开发的瀑布模型，由于图中的箭头好像瀑布的水流，从上至下，因此得名。
图1-2 瀑布模型示意图
回到过河的例子中来，瀑布模型过河具备如下特点：
过河前，首先花费大部分的时间对河进行详细的勘察，选择合适的下水点，选择合适的过河工具，制定详细的分步骤过河计划。
一旦过河计划制定，将不会大更改，开始过河。在河中完全按照计划进行，无法返回起点。这也是为什么称此模型为瀑布的原因，瀑布是飞流直下三千尺，想从下面返回瀑布的顶端，何其难。
在每步骤即将完成时，都会对这一步骤进行总结，如果进行下一步骤的条件不具备，将停留在原地，等待条件具备。
瀑布模型看起来给人很专业的感觉，所以，对于软件开发人员有比较高的要求。
要对待开发的软件（或者要过的河）有细致、全面、准确的了解。如果理解错误，将导致计划失败，没有返回重来的机会。
职业素质、职业纪律要比较高。软件开发人员要具备坚定执行计划的能力。
这种要求也就产生了瀑布模型的缺点，那就是无法完美适应当今要求快速开发产品，从而占领市场的软件行业现状。因为制定详细的、理解完整的计划很难，聚合很多专业的开发人员有时候也很难，而市场对于软件更新换代的要求期限越来越短。为了适应变化，人们又提出了螺旋模型。
1.1.9 计划赶得上变化的螺旋模型
前文提到，为了适应计划和变化两方面的因素，螺旋模型被提出。螺旋模型的示意如图1-3所示。可以看到，它的确很类似一个螺旋。
图1-3 螺旋模型示意图
与边做边改模型类似，螺旋模型也具有循序渐进的特点，对软件最终实现什么不一定有完全确定的理解，而是摸着石头先下水。但是在选择过河的每一个石头前经过了周密的计划和考虑，从这一点看，又类似瀑布模型。可见，螺旋模型实际上是边做边改模型和瀑布模型的有机结合。螺旋模型有如下4个步骤。
（1）确定项目目标、可用资源、各种实现的方法，项目的各个阶段。
（2）在某个阶段中，确认、解决当前阶段项目进展中出现的风险。
（3）评估各种方法，开发、测试代码，实现当前阶段的目标。
（4）总结当前阶段，计划下阶段的目标和实现方法，重复第（2）步。
在图1-3中螺旋线被两条直线划分成4个部分，分别是上述的4个步骤。在每一步骤中由于被直线切割会有多段曲线，每一段曲线就代表了在不同阶段中所进行的相同某个步骤。
【螺旋模型的优点】
由此可见，螺旋模型是多次计划，边做边改，这样既保证了软件开发任务的清晰，也降低了开始一次计划，因为理解不完整或者市场变化后导致项目失败的可能性。
1.1.10 4种模型的总结
前文讲述了4种软件开发模型，那么在具体项目开发中采取哪一种最好呢？答案是它们各有利弊，需要灵活采用。这几种开发流程的优缺点比较如表1-2所示。
表1-2 4种软件开发流程的优缺点
开发流程分类 | 优 点 | 缺 点 |
大爆炸模型 | 简单，不用学习就会 | 拍脑门的想法，产品质量 无法保证。尽量避免使用 |
边做边改模型 | 快速得到可运行的版本 | 计划有些缺乏，导致版本前 后变化较大。可选择的模型之一 |
瀑布模型 | 计划周密，专业， 按部就班实现 | 相对难于做到快速开发， 以抢占市场。可选择的模型之一 |
螺旋模型 | 计划变化同时考虑 | 可选择的模型之一 |
当然，在几十年的软件开发过程中，人们还提出了很多其他的开发模型，不过，作为测试工程师，我们对这几种主流模型有所了解就可以了。进一步深入的内容并不是本书所讲述的范畴，读者可以参看软件工程的相关书籍。
1.1.11 软件开发的几个阶段
不管采用哪一种开发模型，按照时间顺序，所有的软件开发项目都要经历如下4个阶段。
（1）项目启动阶段：了解客户需求、配置相关资源。
（2）项目设计阶段：明确客户需求，确立软件开发、测试的方法。
（3）项目执行阶段：开发与测试阶段。
（4）项目竣工阶段：软件的上市、后期维护与技术支持。
这一分类很好理解，下面再结合小白的工作场景，进行展开介绍。
（1）项目启动阶段。这一阶段一般技术人员参与较少，主要是市场部门，销售部门，技术总监、项目经理等角色的参与：项目成本是多大，开发人员有多少，测试人员有多少，完成时间在什么时候等。
（2）项目设计阶段。这一阶段主要参与者就是需求分析人员、开发人员、项目经理和小白这样的测试人员了。主要目的是确定软件该如何做，做什么：开发人员利用何种技术开发，测试工程师该如何测试该软件，客户如何使用该软件等。这些问题都要确定，形成各自的开发文档、测试文档和需求文档等。
（3）项目执行阶段。开发、测试以及对其的管理就是执行，这一阶段的参与者是开发人员、测试人员和项目经理。开发人员编写程序代码，进行单元测试；测试人员编写测试代码、测试用例，进行功能测试等多种测试。项目经理控制进度，协调各种资源，与设计人员沟通等。
（4）项目竣工阶段。当项目执行完毕的时候，依然要进行部署、软件光盘生产、客户支持、升级补丁包开发和测试等多项工作。这阶段主要的参与者是项目经理，少量的开发人员和测试人员，售后技术支持人员、客户服务人员等。
1.1.12 软件发布的方式
按照目前的软件发布方式，一般有RTM（Ready To Market，市场发布）、RTW（Ready To Web，在网络上发布）、RTO（Ready To Operation，可以运营）等多种方式。
RTM方式需要在工厂进行光盘的复制生产，用户购买光盘后安装。大部分的操作系统和应用软件采用这种方式的比较多。
RTW方式需要在网络上提供下载链接，一般的软件升级包或者游戏软件采用这种方式的比较多。
RTO方式则很简单，在服务器上部署软件产品，用户购买其中的某项或者多项服务即可，这是大部分网站或者在线游戏采用的方式。
1.1.13 项目管理与甘特图
前面提到软件项目的流程很重要，那么这种流程的控制一般是由项目经理来完成的，他或者她所从事的这个工作叫做项目管理。
小白所在的技术部门一般一周都要开一个例会，在会上，开发部门、测试部门和项目经理都要对上一周各自所做的工作进行一番总结，安排下周将要做的工作。在这样的例会上，同事们经常会查看项目的进度图来进行讲解，他们把这样的进度图称为甘特图（Gantt Chart）。
如图1-4显示的是软件开发过程中常用的项目管理工具Microsoft Office Project软件（在这里是2003版本，最新为2007版本）运行的界面，在其中我们可以清楚地看到软件生命周期中的各个子任务的时间分配，负责人员和项目进度的甘特图。
图1-4 Project 2003中的甘特图
【甘特图的来历】
甘特图的名称由发明者亨利·劳伦斯·甘特（Henry Laurence Gantt，1861-1919）而来。甘特早年从事的是电气工程师的职业，后来转而从事管理业界的咨询。甘特图是他在晚年发明的一种用于显示项目计划和进度的图表。在诞生的初期，甘特图就被誉为20世纪20年代的最重要发明之一，广泛应用于一系列的大工程之中。比如1931年前后修建的美国胡佛水坝（如果你看过2007年的热门电影《变形金刚》，那么对关押威震天的那个水坝应该有印象，它就是胡佛水坝）。在软件开发领域，很多公司也应用甘特图这一工具来进行项目管理，比如著名的微软公司。
（未完待续）