西门子TD200面板

试文档

测试文档将在后面章节中详细讨论，在此提出是因为它是完整的软件产品的一部分。和程序员必须对工作进行计划和进行文档记录的原因一样，测试员也必须编写测试文档软件。测试软件小组提交的文档比程序员还多的情况并不少见。

下面是比较重要的测试提交清单。

① 测试计划（Test Plan）。描述用于验证软件是否符合产品说明书和客户需求的整体方案，包括质量目标、资源需求、进度表、任务分配、方法等。

② 测试用例（Test Cases）。列举测试的项目，描述验证软件的详细步骤。

③ 缺陷报告（Bug Reports）。描述执行测试用例找出的问题。可以记录在纸上，但通常记录在数据库中。

④ 测试工具和自动测试（Test Tools and Automation）。如果测试小组使用自动化测试工具测试软件，不管是购买的还是自己编写的工具，都必须有文档记录。

⑤ 度量、统计和总结（Metrics、Statistics、Summaries）。测试过程的汇总，采用图形、表格和报告等形式。

2.1.2 软件产品的组成

到目前为止，知道了制作软件产品所需的投入。同样重要的是，要认识到当产品打包分发时，不仅仅分发的是代码，许多支持包含在内

多数情况下，焦点人群是不知道软件公司的名字的，但通常很容易猜到是谁。2.产品说明书

对客户需求的研究结果其实只是原始资料，并没有描述要做的产品，只是确定是否需要做（或不需要做）以及客户要求的功能。产品说明书综合上述信息以及没有提出但必须要实现的需求，真正地定义产品是什么、有哪

些公司（特别是为政府、航天部门、金融机构和医药企业开发产品的公司）采用严格的过程，要进行大量的检查和对比。结果是产品说明书极其详细完整，而且是“锁定”的，也就是说，没有极特殊的理由绝不能变。开发小组的每一个成员都清楚地知道他们在做的是什么。

有一些开发小组，通常是开发不很关键应用的小组，在草稿纸上就粗略写出产品说明书。这样做的明显好处是非常灵活，但是存在的风险是并非所有人都“站在一起”。此外，*终产品是什么样在发布之前无从得知。式：（4）×835。如果答案是0，就说明该计算机浮点运算没问题。如果答案不是0，就表示计算机的浮点除法存在缺陷。1994年，英特尔奔腾CPU芯片就曾经存在一个软件缺陷，而且被大批生产出来卖到用户那里，*后，英特尔为自己处理软件缺陷的行为道歉并拿出4亿多美元来支付更换芯片的费用，可见，这个软件缺陷造成的损失有多大！

这个缺陷是美国弗吉尼亚州Lguchbny大学的Thomas R.Nicely博士发现的。他在奔腾PC上做除法实验时记录了一个没想到结果。他把发现的问题放到因特网上，随后引发了一场风暴，成千上万的人发现了同样的问题，以及得出其他错误结果的情形。万幸的是，这种情况很少见，仅仅在进行精度要求很高的数学、科学和工程计算中才导致错误。大多数进行财会管理和商务应用的用户根本不会遇到此类问题。这个故事不仅说明软件缺陷所带来的问题，更重要的是说明对待软件缺陷的态度。

英特尔的软件测试工程师在芯片发布之前进行内部测试时已经发现了这个问题，但管理层认为这没有严重到一定要修正，甚至需要公布这个问题。当软件缺陷被发现时，英特尔通过新闻发布和公开声明试图掩饰这个问题的严重性。

缺陷的影响。结果舆论大哗，因特网新闻组充斥着愤怒的客户要求英特尔解决问题的呼声。得到这个教训之后，英特尔在网站上报告已发现的问题，并认真对待客户在因特网新闻组上的反馈意见。指出但应达到的目标。

⑤ 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者*终用户认为不好。

在测试计算器时，会发现电池没电会导致计算器计算不正确，没有人会考虑应如何应付这种情况，使计算器反应正常，而盲目以为电池永远充足了电。测试要持续进行到电池完全没电，至少要看到电力不足的迹象。产品说明书指出电力不足无法正确计算，但未指出会怎样。

导致软件缺陷*大的原因是产品说明书，第二是设计方案，第三是代码，第四是某些软件缺陷产生的条件被错误地认定。

1.5.2 软件缺陷与软件故障案例1.火星登陆事故

1999年12月3日，美航天局火星登陆飞船在试图登陆火星表面时失踪。从理论上看，火星登陆的过程是这样的：飞船在试图降落到火星表面的过程中，首先着陆降落伞被打开，减缓飞船的下落速度。在降落伞打开后的几秒钟内，飞船的3条支撑腿将迅速撑开，并在预定地点着陆。当飞船离火星表面1800m时，它将丢弃降落伞，同时，点燃登陆推进器，在余下的高度缓慢降落到火星表面。

然而，美国宇航局为了省钱，简化了确定何时关闭登陆推进器的装置，为了替代其他太空船上使用的贵重雷达，在飞船的脚上装了一个廉价的触点开关，在计算机中设置一个数据位来关掉燃料。很简单，飞船的脚不“着地”，推进器引擎就会一直处于着火工作状态，不

（3）使软件产品推向市场时间滞后。

是由许多庞大且昂贵的真空管组成的，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子Bug钻进了一支真空管内，导致求的一致性、适用性”，而且要增加其他的要求——“预算内、按时发布、易于维护”。

软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：如果在需求阶段修正一个错误的代价是1，那么在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是40～1000倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。

软件市场呼唤一种公认的标准测试程序和方法用于测试软件质量。一旦有了这样的程序，人们的注意力将集中到如何改进这个程序而不会怪罪具体的测试工程师或软件厂商。如果没有这个程序，一旦软件出现故障，我们就理直气壮地认为测试不当，而软件厂商将首当其冲，软件程序的责任反而微乎其微了。

软件测试存在缺陷是指软件开发者和用户在测试时花费的成本比更有效的测试方法更高。由此看来，几乎所有的测试都存在缺陷。在本文中，软件测试存在缺陷又称为不当测试。

测试的不当性体现在如下4方面。1.集成和互操作性测试

各种应用需集成在一块，以免产生信息孤岛。应用的集成是一个复杂和不确定的过程。集成工作有可能占到系统实现的1/3的技术（Booker，1999）。企业应用集成（EAI）的费用一般占到企业信息技术预算的