1.2 关于虫子的故事 在熟悉了公司的结构、开发流程，参与了部门例会之后，小白要开始从事具体的软件测试工作了，对于他来说，这一领域陌生而令人兴奋。
在刚上班的一周内，小白不断地听到周围的测试工程师高兴得喊道：“又发现Bug了！”，看着他们那兴奋的样子，小白也有点跃跃欲试，想赶紧在捉虫的战场上大展身手。那么，什么是Bug呢，它为什么这么重要，发现Bug为什么这样兴奋？
1.2.1 虫子的来世今生
在本章的序幕部分，我们已经了解了很多由于软件代码的问题使得事情失败的案例了。它们有的后果真的很严重，甚至能够造成对生命的威胁。这肯定不是软件设计者和开发者想要达到的目标，因此，出现这样的情况可以说是软件的错误。
细细的分起来，软件的错误有如下几个词语来描述：
缺陷、偏差、错误、问题、事故、异常。在这一堆词语当中，除了偏差之外，其他的词语所造成的后果给人的感觉都相当严重。所谓偏差，就是软件在使用过程中，和软件设计说明（product specification）所不一致的行为。
那么为什么将这样的软件问题称为Bug呢？这里面还有一个故事。
【史上第一个软件Bug】
该词的原意是“臭虫”或“虫子”。1947年9月9日，正值计算机刚刚被发明的时候，哈佛大学的某个计算机实验室正在做实验。由于当时的原始计算机由很 多庞大且昂贵的真空管组成，运行时会产生光和热，在下午15点45分的时候，一个飞蛾（英文是Moth）钻入了真空管内，导致整个计算机无法工作。当把这 只小虫子从真空管中取出后，计算机又恢复正常。后来，虫子的泛称Bug这个名词就沿用下来，而那个被拍死的飞蛾也成为了历史上发现的第一个Bug。
【Bug渗透到日常生活中】
一般来说，拥有一定知识产权的产品的错误都能称之为Bug。这方面有一个我们比较熟悉的例子就是电影。影迷们经常议论某热门电影中出现了所谓的“穿帮” 镜头，比如在描述古代武侠的影片中天空掠过一架飞机，主角刚才是右脸有伤痕，过一会变成左脸等。这样的镜头也可以说是Bug，甚至还有专门的网站来记录这 些影迷的细心发现，比如http://www.chinabug.net。
1.2.2 软件Bug的5个要素
前文笼统解释了软件Bug是软件的错误或者偏差。那么在具体的工作中，小白如何判断软件的行为是Bug呢？说来简单，根据软件设计阶段形成的功能说明 书，英文为Specification Document，一般简称Spec。对于具体的判断标准，经理介绍了如下5个要素：
软件没有实现说明书中所列出的功能。
软件出现了说明书中提到不应出现的事情。
软件实现了说明书中没有提到的功能。
软件没有实现说明书中没有提到但应该实现的功能。
软件非常难于学习、使用，运转速度很慢，用户认为无法达到预期。
为了充分理解上述5个要素，小白自己打开了Windows系统中最简单的一款软件Notepad，也就是我们平时“不屑于”用到的记事本程序，开始了自己的思考。
1．软件没有实现说明书中所列出的功能
对于“软件没有实现说明书中所列出的功能是Bug”这一点是比较好理解的。如果打开记事本软件，却无法在其中输入汉字，或者输入了文本，无法保存成文件，那么肯定是一个很重要的Bug。
2．软件出现了说明书中提到不应出现的事情
对于第2点，“软件出现了说明书中提到不应出现的事情也是Bug”，这一点和小白的性能测试工作有相对更紧密的关系。小白要测试的是公司的网站，它要求用户在浏览网站时显示页面尽可能地快，如果超出5秒钟则认为是不可接受的。这个“超出5秒钟”就是说明书中提到不应该出现的事情，实际出现后肯定是一个Bug，需要开发人员找出哪里耗费了页面显示时间。
在记事本程序中，如果程序保存文件时出现了程序崩溃（Crash）现象，即属于此类。
3．软件实现了说明书中没有提到的功能 软件实现了说明书中没有提到的功能也是Bug这一点可能有点难于理解。一个软件，功能难道不是越多越强大吗？其实不尽然，实现额外的功能有如下几个缺点，如表1-3所示。
表1-3 软件实现说明书中未提到功能所带来的问题
| 缺 点 | 说 明 |
| 代码量增大 | 由于代码可能相互影响，因此这部分额外 的功能可能对其他功能的实现造成影响， 带入新的Bug |
| 增加额外的开发、测试时间 | 在软件项目时间固定的情况下，导致投入 到其他必备功能的开发测试时间减少， 可能影响它们的完成质量 |
| 增加了成本， 与软件的宣传不完全符合 | 虽然用户对于增加功能一般不会有意见， 但可能影响了公司的销售策略和市场定位 |
4．软件没有实现说明书中没有提到但应该实现的功能
小白一般是将网上找到的有用文档保存在随身携带的U盘中。这一次，他在测试记事本程序的时候，同样打算将文件保存在 U盘上，可是由于连日来的文档太多了，优盘已经没有空间，记事本提示无法保存，同时系统托盘有提示说磁盘空间已满。在这种情况下记事本的行为，就属于实现 了说明书中没有提到却应该实现的功能（在磁盘满的情况下，给用户以提示）。如果没有提示，不符合绝大部分用户的使用习惯，也是一个Bug。
5．软件难于使用、性能差
软件是拿来用的，再好的界面使用不方便也不会产生多大效果。一个网站如果半天都打不开，很难想象还会有多少用户会访问它。因此这样的问题也是Bug，而且对于性能测试来说，这一个规则很重要。
1.2.3 发现虫子的危害
既然软件Bug对产品造成了这么多的影响，那么发现它就显得非常重要了。业内人士都认为，在软件生命周期内的不同阶段发现Bug，所节省的成本是不同的，如图1-5所示。
图1-5 软件生命周期内各阶段发现与改正Bug所需成本示意图
从图中可以看出，在产品设计阶段发现Bug要比在产品维护阶段发现好得多，这是很好理解的。
在需求分析阶段，对于用户需求的理解停留在需求文档中，对其中理解不正确的部分只需要修改文档即可以，基本不会产生什么成本。
在软件设计阶段，发现的Bug很多都是设计思想的缺陷。由于尚未开始编码，这样的Bug一般需要进行深入的讨论最终获得一种正确的结论，因此改正成本也不高。
在软件编码阶段和测试阶段，代码通过开发人员和测试人员的努力在进行不断的完善，有关Bug的成本主要花费在项目内部的沟通与时间成本方面。
但是一旦产品发布，在软件维护阶段发现的Bug，其修改成本会非常高昂：一是因为软件成为了系统，与开发阶段重点检 查各模块功能相比更为复杂，寻找代码上的产生Bug根源更加困难。特别是，如果前期工作没有做好的话，甚至软件产品的结构都需要进行大修改；二是因为牵扯 的部门明显增加，比如客户服务部门、产品部署部门、销售部门等都要参与，导致公司内部、公司与客户之间的沟通成本急剧增加；第三点则是影响产品质量与公司 的信誉、未来产品的销售。
【千年虫的问题】
在前几年，有一个著名的虫子把业内搅得不可开交，那就是千年虫问题，也叫做2000年问题。它是指在某些使用了计算 机程序的智能系统（比如一般的计算机系统以及自动控制芯片等）中，由于其中的年份沿用早期的设计，只使用2位十进制数来表示，比如用80代表1980年， 因此当系统进行（或者涉及到）跨世纪的日期处理运算（比如计算1980年到2080年之间的日期）时，就会出现错误的结果，从而引发各种各样的系统功能紊 乱甚至系统崩溃。
从千年虫的实际例子中也可以看出，不考虑硬件上的限制，如果当初在设计日期表示格式的时候能够想得更长远一些，就完 全可以避免这个虫子的发作，从而节省一大笔修改更新软件等的费用（据未经证实的来自美国国际资料公司调查报告表明，光是1995年到1998年，全球捉" 千年虫"的开销就已经达到惊人的1840亿美元）。
1.3 软件测试的定义与分类 前文花费了不少文字来讲述Bug的定义、危害和判断原则，本节将在更广的范围内介绍软件测试的定义与分类。
1.3.1 软件测试的定义
软件测试就是利用一定的方法对软件的质量或者使用性进行判断和评估的过程。这一定义获得了较广泛的认同。
1.3.2 软件测试工程师的工作内容
软件测试是由软件测试工程师来完成的，他们的主要工作内容则是：
寻找软件中的Bug，并且是越早发现越好（原因见1.2节）。
确认Bug的可重复性（Repro）以及Bug产生的步骤。
确认Bug是否被解决（Fixed）。
测试方法、测试计划、测试平台、测试代码、测试用例、测试文档、测试报告的确定、编写和执行。
对于小白这样刚入职的新人来说，主要工作就是前3项以及测试用例的编写了。在1.4节将讲述测试用例的知识。
1.3.3 软件测试的分类
软件测试可以有很多种分类，常见的有如下一些：
黑盒测试（Black box testing）；
白盒测试（White box testing）；
功能性测试（Functional testing）；
兼容性测试（Compatibility testing）；
性能测试（Performance testing）；
安全测试（Security testing）；
压力测试（Stress testing）。
虽然看起来很多很复杂，但是目前，小白所要做的工作就是先熟悉这些名词，这样在阅读众多的技术文档时，了解这些名词属于软件测试的范畴就可以了。
对于软件测试的两个核心，则有必要在第1章详细的介绍。这两个核心分别是测试用例和测试工程师，分别代表了软件测试的两个方面：工具和人。
（未完待续）
相关链接：
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)