第一部分

软件测试综述
竞争对手的程序死掉叫“崩溃”，自己的程序死掉叫“不良反应”（idiosyncrasy）。通常，崩溃之后会显示“ID 02”这样的信息。“ID”是idiosyncrasy 的缩写，后面的数字表示产品应测试的月份数。
—盖伊·川崎（Guy Kawasaki），
《麦金塔风范》（The Macintosh Way）
我喜欢最后期限。我特别喜欢它们飞驰而过时的呼啸声。
—道格拉斯·亚当斯（Douglas Adams），
《银河系漫游指南》
（The Hitch Hiker抯 Guide to the Galaxy）作者

第1章

软件测试的背景
1947年，计算机还是由机械式继电器和真空管驱动的有房间那么大的机器。体现当时技术水平的MarkⅡ，是由哈佛大学制造的一个庞然大物。当技术人员正在进行整机运行时，它突然停止了工作。他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。
计算机的缺陷发生了。虽然最后该缺陷被消除了，但我们从此认识了它。
欢迎阅读第1章，本章讲述软件缺陷和软件测试的历史。
本章重点包括：

软件缺陷如何影响我们的生活
软件缺陷是什么，为什么会出现
软件测试员是谁，他们在做什么

1.1　臭名昭著的软件错误用例研究

人们常常不把软件当回事，没有真正意识到它已经深入渗透到我们的日常生活中。回到1947年，Mark Ⅱ计算机需要大批程序员定期维护，普通人谁会想到有一天在家里能够拥有自己的计算机呢？现在食品包装盒上都带有免费赠送的软件光盘，小孩子视频游戏中的软件比太空船上的还多。那些以前新奇的小玩意，例如寻呼机和手机，都已经变得平平常常了。现在许多人如果一天不上网查看电子邮件，简直就没法过下去。我们已经离不开24小时包裹投递服务、长途电话服务和最先进的医疗服务了。
软件无处不在。然而，软件是人写的—所以不完美，下面会用实例来证明。

1.1.1　迪士尼的狮子王（1994～1995年）

1994年秋天，迪士尼公司发布了第一个面向儿童的多媒体光盘游戏—狮子王动画故事书（The Lion King Animated Storybook）。尽管已经有许多其他公司在儿童游戏市场上运作多年，但是这次是迪士尼公司首次进军这个市场，所以进行了大量促销宣传。结果，销售额非常可观，该游戏成为孩子们那年节假日的必买游戏。然而后来却飞来横祸。12月26日，圣诞节的后一天，迪士尼公司的客户支持电话开始响个不停。很快，电话支持技术员们就淹没在来自于愤怒的家长并伴随着玩不成游戏的孩子们哭叫的电话之中。报纸和电视新闻进行了大量的报道。
后来证实，迪士尼公司未能对市面上投入使用的许多不同类型的PC机型进行广泛的测试。软件在极少数系统中工作正常—例如在迪士尼程序员用来开发游戏的系统中—但在大多数公众使用的系统中却不能运行。

1.1.2　英特尔奔腾浮点除法缺陷（1994年）

在计算机的“计算器”程序中输入以下算式：
(4195835/3145727)×3145727-4195835
如果答案是0，就说明计算机没问题。如果得出别的结果，就表示计算机使用的是带有浮点除法软件缺陷的老式英特尔奔腾处理器—这个软件缺陷被烧录在一个计算机芯片中，并在制作过程中反复生产。
1994年10月30日，弗吉尼亚州Lynchburg学院的Thomas R. Nicely博士在他的一个实验中用奔腾PC解决一个除法问题时，记录了一个想不到的结果，得出了错误的结论。他把发现的问题放到因特网上，随后引发了一场风暴，成千上万的人发现了同样的问题，并且发现在另外一些情形下也会得出错误的结果。万幸的是，这种情况很少见，仅仅在进行精度要求很高的数学、科学和工程计算中才会导致错误。大多数用来进行税务处理和商务应用的用户根本不会遇到此类问题。
这件事情引人关注的并不是这个软件缺陷，而是英特尔公司解决问题的方式：

他们的软件测试工程师在芯片发布之前进行内部测试时已经发现了这个问题。英特尔的管理层认为这没有严重到一定要修正甚至公开的程度。
当软件缺陷被发现时，英特尔通过新闻发布和公开声明试图弱化这个问题的已知严重性。
受到压力时，英特尔承诺更换有问题的芯片，但要求用户必须证明自己受到缺陷的影响。

舆论大哗。互联网新闻组里充斥着愤怒的客户要求英特尔解决问题的呼声。新闻报道把英特尔公司描绘成不关心客户和缺乏诚信者。最后，英特尔为自己处理软件缺陷的行为道歉并拿出4亿多美元来支付更换问题芯片的费用。现在英特尔在Web站点上报告已发现的问题，并认真查看客户在互联网新闻组里留的反馈意见。
注意：2000年8月28日，在本书第1版出版的前夕，英特尔针对已投产月余并已开始发货的所有1.13MHz奔腾III处理器，宣布了一项召回通告，因为发现了在执行某些特定指令时可能导致运行程序被挂起的问题。计算机生产商正在制定召回已经交付客户使用的PC计划，并计算更换问题芯片的费用。

1.1.3　美国航天局火星极地登陆者号探测器（1999年）

1999年12月3日，美国航天局的火星极地登陆者号探测器试图在火星表面着陆时失踪。故障评估委员会（Failure Review Board，FRB）调查了故障，认定出现故障的原因极可能是一个数据位被意外置位。最令人警醒的问题是：为什么没有在内部测试时发现呢？
从理论上看，着陆的计划是这样的：当探测器向火星表面降落时，它将打开降落伞减缓探测器的下降速度。降落伞打开几秒后，探测器的三条腿将迅速撑开，并锁定位置，准备着陆。当探测器离地面1 800米时，它将丢弃降落伞，点燃着陆推进器，缓缓地降落到地面。
美国航天局为了省钱，简化了确定何时关闭着陆推进器的装置。为了替代在其他太空船上使用的贵重雷达，他们在探测器的脚部装了一个廉价的触点开关，在计算机中设置一个数据位来控制触点开关关闭燃料。很简单，探测器的发动机需要一直点火工作，直到脚“着地”为止。
遗憾的是，故障评估委员会在测试中发现，许多情况下，当探测器的脚迅速撑开准备着陆时，机械震动也会触发着陆触点开关，设置致命的错误数据位。设想探测器开始着陆时，计算机极有可能关闭着陆推进器，这样火星极地登陆者号探测器飞船下坠1 800米之后冲向地面，撞成碎片。
结果是灾难性的，但背后的原因却很简单。探测器经过了多个小组测试。其中一个小组测试飞船的脚折叠过程，另一个小组测试此后的着陆过程。前一个小组不去注意着地数据位是否置位—这不是他们负责的范围；后一个小组总是在开始测试之前复位计算机、清除数据位。双方独立工作都做得很好，但合在一起就不是这样了。

1.1.4　爱国者导弹防御系统（1991年）

美国爱国者导弹防御系统是里根总统提出的战略防御计划（即星球大战计划）（Strategic Defense Initiative, SDI）的缩略版本，它首次应用在海湾战争对抗伊拉克飞毛腿导弹的防御战中。尽管对此系统赞誉的报道不绝于耳，但是它确实在对抗几枚导弹中失利，包括一次在沙特阿拉伯的多哈击毙了28名美国士兵。分析发现症结在于一个软件缺陷，系统时钟的一个很小的计时错误积累起来到14小时后，跟踪系统不再准确。在多哈的这次袭击中，系统已经运行了100多个小时。

1.1.5　千年虫问题（大约1974年）

20世纪70年代早期的某个时间，某位程序员（假设他叫Dave）正在为本公司设计开发工资系统。他使用的计算机存储空间很小，迫使他尽量节省每一个字节。Dave自豪地将自己的程序压缩得比其他任何人都紧凑。他使用的其中一个方法是把4位数年份如1973缩减为2位数73。因为工资系统相当依赖于日期的处理，所以Dave需要节省大量昂贵的存储空间。他简单地认为只有在到达2000年他的程序开始计算00或01这样的年份时问题才会发生。虽然他知道会出这样的问题，但是他认定在25年之内程序肯定会升级或替换，而且眼前的任务比现在计划遥不可及的未来更加重要。然而这一天毕竟是要到来的。1995年，Dave的程序仍然在使用，而Dave退休了，谁也不会想到深入到程序中检查2000年兼容问题，更不用说去修改了。
估计全球各地更换或升级类似的Dave程序以解决潜在的2000年问题的费用已经达数千亿美元。

1.1.6　危险的预见（2004年）

1994年4月1日，在一些互联网用户组上贴出了一条消息，是关于在互联网上发现了一封将病毒嵌入在几张JPEG格式图片中的邮件的，而且很快就传播开了。消息警告说只要简单地打开或查看受病毒感染的图片，病毒就会感染你的PC，甚至还有警告说该病毒会破坏你的显示器，其中又数索尼的Trinitron显示器最易被破坏。
警告受到了广泛的关注，并且很多人把自己机器上的JPEG文件都清除掉了。有些系统管理员甚至阻止系统通过E-mail接收JPEG图片。
后来人们终于知道这个最初的消息发布在“愚人节”，整个事情就是一个玩笑。专家们这时发表意见说，不可能在查看一幅JPEG图片时，病毒会感染你的PC。不管怎样，图片只是一些数据，它不是可执行的程序代码。
10年后，2004年的秋天，一个原形（proof-of-concept）病毒被制造出来，证明了JPEG图片可以带病毒并且在查看时感染系统。软件更新补丁也很快发布以防止病毒的扩散。不管怎样，像这种原本正常的图片通过某种传播手段造成互联网的灾难性破坏，可能只是时间问题。

1.2　软件缺陷是什么

刚才我们看到了软件失败所发生的事件的一些实例。其后果也许是带来不便，比如电脑游戏玩不成了，也可能是灾难性的，会导致人员的伤亡。改正软件缺陷也许花费很小，但解决方案的实施却可能需要花费数百万美元。在这些事件中，显然软件未按预期目标运行。作为软件测试员，可能会发现大多数缺陷不如上面那些明显，只是一些简单而细微的错误，以致难以区分哪些是真正的错误，哪些不是。

1.2.1　软件失败的术语

作为软件测试员，在不同环境下要用不同的术语描述软件失败时的现象。这里给出一些例子：
**缺点（defect）偏差（variance）
故障（fault）失败（failure）
问题（problem）不一致（inconsistency）
错误（error）事件（incident）
缺陷（bug）异常（anomaly）**
（还有许多没有提到的术语，但上面提到的是程序员们常用的术语。）
读者也许会奇怪，描述软件缺陷的术语为什么这么多呢？这完全取决于公司的文化和开发软件的过程。如果从字典中查这些词，就会发现它们的含义几乎相同。在日常的会话中，它们还具有其他的含义。
例如，故障、失败和缺点都指的是确实严重的情况，甚至是危险的情况。图标的颜色设置不正确称为故障听起来就不对。这些词汇同时也意味着责备：“这是他的过错造成软件失败的。”
异常、事件和偏差不是那么尖锐，主要指未按预料的运行，而不是说全部失败。“总统声称是软件异常导致导弹未按规定飞行。”
问题、错误和缺陷也许是最常用的术语。
该怎么称呼就怎么称呼
有趣的是，某些公司和产品开发小组浪费了许多宝贵的开发时间去争论用什么词汇来描述软件问题。有一个著名的计算机公司花费数周时间与工程师讨论，最终把产品异常报告（Product Anomaly Report，PAR）改为产品事件报告（Product Incident Report，PIR）。大量的资金浪费在决定用哪个术语更好的过程上。决议形成后，所有书面材料、软件、表格等都要根据新的术语调整。谁知道这对程序员和测试员的工作成效会有什么作用？
那么，为什么还要谈论这个话题？因为对软件测试员来说，了解与自己合作的产品开发小组的特点是很重要的。他们提及软件问题的方式反映出他们处理整个开发过程的方式。他们是谨慎、小心、直接，还是简单生硬呢？
虽然你所在的开发小组会选择不同的名称，但在本书中，所有软件问题都被称为缺陷（bug）。并不在乎缺陷多大多小，是有意的还是无意的，或者是否让一些人感到不适。在用词上过多地计较是没有意义的。

1.2.2　软件缺陷的官方定义

把所有的软件问题都称为缺陷听起来也许非常简单，但是这样做并不能真正解决问题。现在，问题（problem）这个词需要加以定义。为了避免循环定义，就需要给出缺陷的明确定义。
首先需要了解一个辅助术语：产品说明书（product specification）。产品说明书有时又简称为说明（spec）或产品说明（product spec），是软件开发小组的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。第2章“软件开发的过程”会讲述产品说明书和开发过程的更多内容，但是现在，这样的定义就足够了。
出于本书和软件行业的原因，只有至少满足下列5个规则之一才称发生了一个软件缺陷（software bug）：
**1）软件未实现产品说明书要求的功能。
2）软件出现了产品说明书指明不应该出现的错误。
3）软件实现了产品说明书未提到的功能。
4）软件未实现产品说明书虽未明确提及但应该实现的目标。
5）软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好。**
为了更好地理解每一条规则，下面我们来看看计算器的例子。
计算器的产品说明书可能声称它能够准确无误地进行加、减、乘、除运算。假如你作为软件测试员，拿到计算器后，按下加（+）键，结果什么反应也没有，根据第1条规则，这是一个缺陷。假如得到错误答案，根据第1 条规则，这同样是个缺陷。
产品说明书可能声称计算器永远不会崩溃、锁死或者停止反应。假如你狂敲键盘使计算器停止接受输入，根据第2条规则，这是一个缺陷。
假如你拿计算器进行测试，发现除了加、减、乘、除之外它还可以求平方根，说明书中从没提到这一功能，雄心勃勃的程序员只因为觉得这是一项了不起的功能而把它加入。这不是功能，根据第3条规则，这是软件缺陷。软件实现了产品说明书未提到的功能。这些预料不到的操作，虽然有了更好，但会增加测试的工作，甚至可能带来更多的缺陷。
第4条规则中的双重否定让人感觉有些奇怪，但其目的是捕获那些产品说明书上的遗漏之处。在测试计算器时，会发现电池没电会导致计算不正确。没有人会考虑到这种情况下计算器会如何反应，而是想当然地假定电池一直都是充足了电的。测试要考虑到让计算器持续工作直到电池完全没电，或者至少用到出现电力不足的提醒。电力不足时无法正确计算，但产品说明书未指出这个问题。根据第4条规则，这是个缺陷。
第5条规则是全面的。软件测试员是第一个真正使用软件的人，否则，客户就是第一个使用软件产品的人。如果软件测试员发现某些地方不对劲，无论什么原因，都要认定为缺陷。在计算器例子中，也许测试员觉得按键太小，也许“＝”键布置的位置使其极其不好按，也许在明亮光下显示屏难以看清。根据第5条规则，这些都是缺陷。
注意：每一个使用过一些软件的人都会对软件的工作方式有自己的意见和想法，要编写令所有用户都满意的软件是不可能的。作为软件测试员，在运用第5条测试规则时应记住下面这一点：要全面，最重要的是要客观评价，并非所有测试发现的缺陷都要修改。这些后面章节中还会提及。
这些都是极简单的例子，所以请考虑如何将这些规则应用到日常使用的软件中。哪些功能是需要的？哪些功能是不需要的？哪些已经说明，哪些被遗忘了？还有，是什么原因造成你不喜欢某个软件？
虽然这个软件缺陷的定义涉及面甚广，但是使用上面5条规则有助于在软件测试中区分不同类型的问题。

1.3　为什么会出现软件缺陷

现在我们知道了软件缺陷是什么，但它们为什么会出现呢？令人感到惊奇的是我们发现大多数软件缺陷并非源自编程错误。对众多从小到大的项目进行研究而得出的结论往往是一致的，导致软件缺陷最大的原因是产品说明书（见图1-1）。

产品说明书成为造成软件缺陷的罪魁祸首有不少原因。在许多情况下，说明书没有写；其他原因可能是说明书不够全面、经常更改，或者整个开发小组没有很好地沟通。为软件做计划是极其重要的，如果没做好，软件缺陷就会出现。
软件缺陷的第二大来源是设计。这是程序员规划软件的过程，好比是建筑师为建筑物绘制蓝图。这里产生软件缺陷的原因与产品说明书是一样的—随意、易变、沟通不足。
注意：古人云：“说不出来就做不到。”此话用在软件开发和测试身上再合适不过了。
程序员对编码错误太熟悉了。通常，代码错误可以归咎于软件的复杂性、文档不足（特别是升级或修订过的代码的文档）、进度压力或者普通的低级错误。一定要注意，许多看上去是编程错误的软件缺陷实际上是由产品说明书和设计方案造成的。经常听到程序员说：“这是按要求做的。如果有人早告诉我，我就不会这样编写程序了。”
剩下的原因可归为一类。某些缺陷产生的原因是把误解（即把本来正确的）当成缺陷。还有可能缺陷多处反复出现，实际上是由一个原因引起的。一些缺陷可以归咎于测试错误。不过说到底，此类软件缺陷只占极小的比例，不必担心。

1.4　软件缺陷的修复费用

看了第2章你就会明白，软件不仅仅是表面上的那些东西—通常要靠有计划、有条理的开发过程来实现。从开始到计划、编程、测试，再到公开使用的过程中，都有可能发现软件缺陷。图1-2显示了修复软件缺陷的费用是如何随着时间推移而增加的。
费用指数级地增长，也就是说，随着时间的推移，费用以十倍增长。在我们的例子中，当早期编写产品说明书时发现并修复缺陷，费用只要1美元甚至更少。同样的缺陷如果直到软件编写完成开始测试时才发现，费用可能要10~100美元。如果是客户发现的，费用可能达到数千甚至数百万美元。

举一个例子来说明，比如前面的迪士尼狮子王实例。问题的根本原因是软件无法在流行的PC平台上运行。假如早在编写产品说明书时有人已经研究过什么PC流行，并且明确指出软件需要在这种配置上设计和测试，付出的代价就会小得几乎可以忽略不计。如果没有这样做，还有一个补救措施是，软件测试员去搜集流行PC样机并在其上验证。他们可能会发现软件缺陷，但是修复费用要高得多，因为软件必须调试、修改、再测试。开发小组还应把软件的初期版本分发给一小部分客户进行试用，这叫beta测试。那些被挑选出来代表庞大市场的客户可能会发现问题。然而实际的情况是，缺陷被完全忽视，直到成千上万的光盘被压制和销售出去。而迪士尼公司最终支付了客户投诉电话、产品召回、更换光盘，以及又一轮调试、修改和测试的费用。如果严重的软件缺陷到了客户那里，就足以耗尽整个产品的利润。

1.5　软件测试员究竟做些什么

我们已经看到了令人厌恶的软件缺陷实例，知道了软件缺陷的定义，还了解了其修复费用的情况。因此，软件测试员的目标很显然就是：
软件测试员的目标是发现软件缺陷。
经常遇到有产品开发小组要测试员仅仅证实软件可以运行，而不是找出缺陷。重新看一下火星极地登陆者号探测器的用例，就会明白这种方法为什么是错的。如果只是为了测试应当达到的功能，建立测试使其通过，就会遗漏功能不足之处。这样会漏掉缺陷。
如果漏掉缺陷，就是在浪费项目本身和公司的钱财。作为软件测试员，不能满足于仅仅找到软件缺陷—而应该考虑如何在开发过程中尽快地找出软件缺陷，以便降低修复成本。
软件测试员的目标是尽可能早地找出软件缺陷。
然而，找出缺陷，甚至早一点找出缺陷，仍嫌不足。不要忘记了软件缺陷的定义，软件测试员是客户的眼睛，是第一次看到软件的人，代表客户说话，应力求完美。
软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复。
这个最终定义非常重要。牢记这一点，在学完本书后面的测试技术后再来重温这句话。
注意：要记住，“修复”缺陷并非指一定要改正软件。可以是指在用户手册中增加一段注释或为用户提供特殊的培训。这可能需要改变市场部门广告宣传的数据甚至推迟缺陷部分功能的发布。从本书中将了解到，软件测试员虽然在追求完美，确保缺陷都被修复，但软件测试的实质则是另外一回事。千万不要在无法达到的完美上纠缠和兜圈子。

1.6　优秀的软件测试员应具备的素质

在电影《星际迷航记Ⅱ：可汗的愤怒》（Star TrekⅡ：The Wrath of Khan）中，Spock说过：“在宇宙的历史中，毁灭总是比创建容易。”表面看起来，软件测试员的工作似乎比程序员要容易一些，分析代码并寻找软件缺陷显然比从头编写代码容易。令人惊奇的是，事实并非如此。要从本书中学到井井有条的软件测试所付出的努力和投入不亚于编写程序，两者所需的技术极为相似。尽管软件测试员不必成为一个经验丰富的程序员，但是拥有编程知识会很有好处。
现在，大多数成熟的公司都把软件测试视为高级技术工程职位。他们意识到在项目组中配备经过培训的软件测试员，并在开发过程早期投入工作可以生产出质量更优的软件。遗憾的是，目前还是有一些公司对软件测试带来的挑战以及杰出测试工作的价值不以为然。在自由市场的时代，这些公司是不会长久的，因为用户是不会购买他们那些有缺陷的软件产品的。一个好的测试组织（或者缺少测试的组织）可以成就（或搞垮）一个公司。
下面是大多数软件测试员应具备的素质：

他们是群探索者。软件测试员不会害怕进入陌生环境。他们喜欢拿到新软件，安装在自己的机器上，观看结果。
他们是故障排除员。软件测试员善于发现问题的症结。他们喜欢解谜。
他们不放过任何蛛丝马迹。软件测试员总在不停地尝试。他们可能会碰到转瞬即逝或者难以重现的软件缺陷。他们不会当作是偶然而轻易放过，而会想尽一切可能去发现它们。
他们具有创造性。测试显而易见的事实，对软件测试员来说还不够。他们的工作是要设想出富有创意甚至超常的手段来寻找缺陷。
他们是群追求完美者。他们力求完美，但是当知道某些无法企及时，不去苛求，而是尽力接近目标。
他们判断准确。软件测试员要决定测试内容、测试时间，以及看到的问题是否是真正的缺陷。
他们注重策略和外交。软件测试员常常带来的是坏消息。他们必须告诉程序员，你的“孩子”（程序）很丑。优秀的软件测试员知道怎样有策略和职业地处理这些问题，也知道如何和不够冷静的程序员合作。
他们善于说服。软件测试员找出的缺陷有时被认为不重要，不用修复。测试员要善于清晰地表达观点，说明软件缺陷为何必须修复，并推进缺陷的修复。

软件测试很有趣！
软件测试员的一个基本素质是打破砂锅问到底。他们喜欢找出那些难以捉摸的系统崩溃。他们乐于处理最复杂的问题。经常看到他们高高兴兴地来回奔忙，相互间击掌庆贺，拿到系统时手舞足蹈的样子。这就是平凡生活中的乐趣。
除了这些素质外，在软件编程方面受过教育也很重要。从第6章“检查代码”中可知，了解软件是怎样编写的，可以从不同角度找出软件缺陷，从而使测试更加高效。这还有助于开发第15章“自动测试和测试工具”中讨论的测试工具。
最后要说的是，对于非计算机领域的专家来说，其专业知识对开发新产品的软件小组的价值可能无法衡量。编写软件的目的是解决现实中的问题。因此，教学、烹饪、航空、木工、医疗等知识对查找该领域软件的缺陷都有莫大的帮助。
## 小结
软件测试是一项批判性的工作。随着当今软件的规模和复杂性日益增加，进行专业化、高效的软件测试的要求越来越迫切。太多的事情处于危机中，我们不需要更多的计算机缺陷芯片，更多崩溃的系统，更多被盗的信用卡账户。
第一部分的第2章将讲述软件开发以及软件测试如何融入开发中。这些知识对于运用本书其他章节所述的测试技术极有帮助。
##小测验
以下是帮助读者加深理解的小测验。答案参见附录A—但是不要偷看！

在千年虫例子中，Dave有错误吗？
判断是非：公司或者开发小组用来称呼软件问题的术语很重要。
仅仅测试程序是否按预期方式运行有何问题？
产品发行后修复软件缺陷比项目开发早期这样做的费用要高出多少？
软件测试员的目标是什么？
判断是非：好的测试员坚持不懈地追求完美。
给出几个理由说明产品说明书为什么通常是软件产品中制造缺陷的最大来源。

带你读《软件测试（原书第2版）》之一：软件测试的背景

第一部分

第1章