软件测试理论基础

1. 什么是软件测试

软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。模块的编写者与测试者是同一个人。编码与单元测试属于软件生存期中的同一个阶段。在这个阶段结束之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段，通常由专门的测试人员承担这项工作。

2. 软件测试的目的和原则

Grenford J.Myers就软件测试目的提出以下观点：

•  测试是程序的执行过程，目的在于发现错误；
•  一个好的测试用例在于能发现至今未发现的错误；
•  一个成功的测试是发现了至今未发现的错误的测试。

设计测试的目标是想以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。

测试不能表明软件中不存在错误，它只能说明软件中存在错误。

软件测试的原则：

① 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患。

② 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

测试以前应当根据测试的要求选择测试用例（Test case），用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。

③ 程序员应避免检查自己的程序。

程序员应尽可能避免测试自己编写的程序，程序开发小组也应尽可能避免测试本小组开发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调试（debuging）相混淆。调试由程序员自己来做可能更有效。

④ 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，不合理的输入条件是指异常的，临界的，可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。

⑤ 充分注意测试中的群集现象。

在被测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。

⑥ 严格执行测试计划，排除测试的随意性。

测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、输入和输出、测试内容、进度安排、资源要求、测试用例的选择、测试的控制方式和过程等，还要包括系统的组装方式、跟踪规程、调试规程，回归测试的规定，以及评价标准等。对于测试计划，要明确规定，不要随意解释。

⑦ 应当对每一个测试结果做全面检查。

有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征侯，暴露错误。

⑧ 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

3.测试与软件开发各阶段的关系

软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排的 自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。参看下图，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试。最后从系统全体出发，运行系统，看是否满足要求。

“程序员应避免测试自己的程序”。

开发者被指定测试自己的代码是一件很糟糕的事。开发和测试生来就是不同的活动。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试--单元测试。不同当一个程序员在完成了设计，编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。许多户主都知道，揭掉糊墙纸（破坏性过程〉是不容易的，若糊墙纸原先是由他而不是别人贴上的，他几平会感到难以忍受的沮丧。所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。 除了这个心理学问题之外，还有一个重要的问题：程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。

　　再者，可以把测试看做是对一篇论文或—本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容的。

　　以上看法并不意味着程序员不可能测试自已的程序。不过相比之下如果由另外—些人来进行程序测试，就会更有效、更成功。注意：这个论断并不适用于纠错（改正已知错误），由原来程序的作者纠错肯定效率更高。

4.程序错误分类：

由于人们对错误有不同的理解和认识，所以目前还没有一个统一的错误分类方法。错误难于分类的原因，一方面是由于一个错误有许多征兆，因而它可以被归入不同的类。另一方面是因为把一个给定的错误归于哪一类，还与错误的来源和程序员的心理状态有关。

(1) 按错误的影响和后果分类（常用）

•  较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。
•  中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。
•  较严重错误：系统的行为因错误的干扰而出现明显不合情理的现象。比如开出了0.00元的支票，系统的输出完全不可信赖。
•  严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。
•  非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。
•  最严重的错误：系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。

(2) 按错误的性质和范围分类

B.Beizer从软件测试观点出发，把软件错误分为5类。

① 功能错误

•  规格说明错误：规格说明可能不完全，有二义性或自身矛盾。
•  功能错误：程序实现的功能与用户要求的不一致。这常常是由于规格说明中包含错误的功能、多余的功能或遗漏的功能所致。
•  测试错误：软件测试的设计与实施发生错误。软件测试自身也可能发生错误。
•  测试标准引起的错误：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。

② 系统错误

•  外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间，人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外还包括对输入／输出格式错误理解，对输入数据不合理的容错等等。
•  内部接口错误：内部接口指程序之间的联系。它所发生的错误与程序内实现的细节有关。例如，设计协议错、输入／输出格式错、数据保护不可靠、子程序访问错等。
•  硬件结构错误：这类错误在于不能正确地理解硬件如何工作。例如，忽视或错误地理解分页机构、地址生成、通道容量、I／O指令、中断处理、设备初始化和启动等而导致的出错。
•          操作系统错误：这类错误主要是由于不了解操作系统的工作机制而导致出错。。当然，操作系统本身也有错误，但是一般用户很难发现这种错误。
•          软件结构错误：由于软件结构不合理或不清晰而引起的错误。这种错误通常与系统的负载有关，而且往往在系统满载时才出现。这是最难发现的一类错误。例如，错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定不会发生中断而导致不能封锁或开中断；错误地假定程序可以绕过数据的内部锁而导致不能关闭或打开内部锁；错误地假定被调用子程序常驻内存或非常驻内存等等，都将导致软件出错。
•          控制与顺序错误：这类错误包括：忽视了时间因素而破坏了事件的顺序；猜测事件出现在指定的序列中；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。
•         资源管理错误：这类错误是由于不正确地使用资源而产生的。例如，使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接在错误的队列中等等。

③ 加工错误

•  算术与操作错误：指在算术运算、函数求值和一般操作过程中发生的错误。包括：数据类型转换错；除法溢出；错误地使用关系比较符；用整数与浮点数做比较等。
•  初始化错误：典型的错误有：忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式，数据或类型进行初始化等等。
•  控制和次序错误：这类错误与系统级同名错误类似，但它是局部错误。包括：遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。
•  静态逻辑错误：这类错误主要包括：不正确地使用CASE语句；在表达式中使用不正确的否定（例如用“＞”代替“＜”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。

④ 数据错误

•  动态数据错误：动态数据是在程序执行过程中暂时存在的数据。各种不同类型的动态数据在程序执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，就会导致数据出错。由于动态数据被破坏的位置可能与出错的位置在距离上相差很远，因此要发现这类错误比较困难。
•  静态数据错误：静态数据在内容和格式上都是固定的。它们直接或间接地出现在程序或数据库中。由编译程序或其它专门程序对它们做预处理。这是在程序执行前防止静态错误的好办法，但预处理也会出错。
•  数据内容错误：数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容本身没有特定的含义，除非通过硬件或软件给予解释。数据内容错误就是由于内容被破坏或被错误地解释而造成的错误。
•  数据结构错误：数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构错误主要包括结构说明错误及把一个数据结构误当做另一类数据结构使用的错误。这是更危险的错误。
•  数据属性错误：数据属性是指数据内容的含义或语义。例如，整数、字符串、子程序等等。数据属性错误主要包括：对数据属性不正确地解释，比如错把整数当实数，允许不同类型数据混合运算而导致的错误等。

⑤ 代码错误

主要包括：语法错误；打字错误；对语句或指令不正确理解所产生的错误。

(3) 按软件生存期阶段分类

Good enough－Gerhart分类方法把软件的逻辑错误按生存期不同阶段分为4类。

① 问题定义（需求分析）错误

它们是在软件定义阶段，分析员研究用户的要求后所编写的文档中出现的错误。换句话说，这类错误是由于问题定义不满足用户的要求而导致的错误。

② 规格说明错误

这类错误是指规格说明与问题定义不一致所产生的错误。它们又可以细分成：

•  不一致性错误：规格说明中功能说明与问题定义发生矛盾。
•  冗余性错误：规格说明中某些功能说明与问题定义相比是多余的。
•  不完整性错误：规格说明中缺少某些必要的功能说明。
•  不可行错误：规格说明中有些功能要求是不可行的。
•  不可测试错误：有些功能的测试要求是不现实的。

③ 设计错误

这是在设计阶段产生的错误，它使系统的设计与需求规格说明中的功能说明不相符。它们又可以细分为：

•  设计不完全错误：某些功能没有被设计，或设计得不完全。
•  算法错误：算法选择不合适。主要表现为算法的基本功能不满足功能要求、算法不可行或者算法的效率不符合要求。
•  模块接口错误：模块结构不合理；模块与外部数据库的界面不一致，模块之间的界面不一致。
•  控制逻辑错误：控制流程与规格说明不一致；控制结构不合理。
•  数据结构错误：数据设计不合理；与算法不匹配；数据结构不满足规格说明要求。

④ 编码错误

编码过程中的错误是多种多样的，大体可归为以下几种：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入／输出错，及其它的错误。

在不同的开发阶段，错误的类型和表现形式是不同的，故应当采用不同的方法和策略来进行检测。