软件测试技术基础概论

1MILY: 黑体; mso-bidi-font-size: 12.0pt">．6  软件测试概论

1． 软件测试的概念

    由于软件及软件错误的复杂性，长期以来，人们对软件测试的认识一直是模糊的。许多科学家从不同的角度给出了软件测试的不同定义，但总体来看，都是不全面的。Myers认为：“程序测试是为了发现错误而执行程序的过程”，该定义明确给出了软件测试就是为了发现软件中的错误，这一概念目前被人们所公认。但该定义认为软件测试仅仅是程序编码的测试，这显然是不全面的，在某种意义上说是有害的，因为许多软件错误并不是编码上的错误，而人们往往会忽略这一点。

1983年IEEE给出的定义是：“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别”。应该说该定义是比较全面的。应该说，上述两个定义都是以检验软件是否存在错误为目的，也可以说是一种正确性测试。但也有人不同意这种观点，认为软件测试还应包括可靠性测试、健壮性测试、性能测试、效率测试等。作者认为，软件的测试是和软件的需求是密切相关的，对一般的民用软件，正确性测试是能够满足要求的。而对某些关键性软件，如导航控制软件、核电站控制软件等则必须进行后几种测试。但要指出的是，进行后几种测试，仅仅编写一个软件测试程序是不够的，往往研制必须的硬件环境，其代价往往是很大的。因此，本文我们所论述的测试一般都是指面向软件正确性的测试。

2． 如何认识软件错误

目前，影响软件测试技术发展的一个重要因素就是人们对软件测试在认识上存在的误区。误区之一是设计者、程序员对自己所做的工作特别有信心，不愿意让别人来挑自己的毛病。误区之二是既然软件测试不能证明软件是正确的，何必又需要测试呢？误区之三是由于软件测试是一种辅助性的工作，既费力又难以出成绩。很多人不愿意做这个工作。因此，解决人们认识上的问题是非常有必要的。

（1）软件能否彻底的测试：回答是不能。例如，一元二次方程ax²+bx+c=0求根的程序，该程序的3个输入a、b、c是实数，假设计算机有32位（假设8位阶码），每个数据的数据个数至少为10³⁰，则总的数据个数要大于10⁹⁰。要彻底测试一个软件，就要每个数据都至少运行一次，这是目前所有计算机都不可能做到的。上述还仅仅考虑了输入的一部分，在使用中，用户有意或无意的可能输入其它数据，例如字符等。考虑到这些因素，要彻底测试一个软件是不可能的。

软件不能被彻底的测试并不否定软件测试的作用。正如一个再好的医生也不可能检查出病人的所有毛病一样，据此就否定医生的作用是错误的。早在1972年，Dijkstra曾说过一句名言：“软件测试只能表明错误的存在，而不能表明错误不存在”。

（2）早期的错误是否应在早期排除：回答是肯定的。软件的错误存在于软件生存期的各个阶段，在每一阶段发现的错误都应在此阶段将其排除掉，否则，越往后，排除讲越困难。有人作过统计，在后一个阶段排除前一个阶段的错误，其费用将提高10倍。经过近些年来软件工程技术的实践，人们对这个问题已不在有什么怀疑。但存在的问题是：不是人们发现了早期的错误不排除，而是没人去发现早期的错误，这种情形很普遍，是软件设计的灾难，必须引起足够的重视。

（3）能否用验证技术代替软件测试：回答是不能。程序验证是采用形式化的方法来检验软件是否正确，从理论上看，该方法对检验软件的错误是完备的。但实际上，程序验证技术有很大的局限性，实践表明，该方法只能对一些小的例子是有效的，大中型软件正确性验证无论从方法上还是从验证效率上，都是不实际的。此外，经过程序验证的软件，需求分析错误、接口错误等也检验不出来。

3． 软件测试的费用

统计表明，软件测试与维护的费用要占到整个软件开发费用的50%以上。图1.5给出了估计修复软件缺陷费用的现行行业标准（资料来源：B.Bohem,Software Engineeering,IEEE Transactions on Computer,1976.12）。表明缺陷发现的越晚，费用将如何惊人的增长。

4．

（1）减少软件的缺陷数目或者降低软件的缺陷密度：通过测试可以发现软件中存在的缺陷，通过完全的修改这些缺陷，可以减少软件中缺陷的总数目或者降低其缺陷密度。

（2）提高软件的可靠性：软件的缺陷数目是影响软件可靠性的主要因素，通过测试减少软件的缺陷数目可以达到提高软件可靠性的目的。

（3）评估软件的性能指标：通过软件测试，根据所发现的缺陷数目和发现缺陷的时间，可以评估软件的可靠性等指标。即使软件测试没有发现缺陷，也同样可以达到这个目的。

（4）增加用户对软件的信心。软件通过了何种测试对用户来说是非常重要的，严格的软件测试可以大大用户对该软件的信心。

1．7 软件测试方法

    软件的错误存在于软件生存期的各个阶段，不同阶段的错误性质是不同的，不同的错误对应了不同的测试方法。本章所论述的静态测试方法、动态测试方法、黑盒测试方法和白盒测试方法就是根据上述问题而发展起来的。有些方法是通用的，例如静态测试技术，在软件生存期各个阶段的错误检测中都可以使用，而有些方法只是对某个阶段才能使用，例如，动态测试技术，只有当程序出来以后才能进行动态测试。不同的测试方法对各个阶段错误检测的效率也是不同的，有些时候，在同一阶段，当各种方法组合使用时，错误检测的效果会更好。此外，对程序测试而言，分步测试更有利于尽快的发现错误，减少测试的开销。

1．静态测试方法

（1）测试方法：在软件开发过程中，每产生一个文档，都必须对它进行测试，以确定它的质量是否满足要求。静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以对各种文档进行测试，是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此，在这些阶段，静态测试的作用尤为重要。目前，比较常用的静态测试方法有：Yourdon的结构化走通法和Fagan检查法。

1） 结构化走通法。结构化走通是由一组人员对一个文档从多种不同的角度进行检查，以尽可能多地发现其中的错误。它以该文档的产生者为中心，由产生者向参加审阅的其他人员报告其文档。所发现的错误或怀疑是错误的问题则由召集人记录在案。审阅的中心问题是发现错误，而不是纠正错误。在结构化走通的审阅过后，由文档的产生者将记录在案的错误纠正。

Yourdon指出，结构化走通的审阅过程应该由如下人员组成：

· 报告者：该文档的拥有者和文档的产生者；

· 召集人：组织并主持审阅；

· 秘书：负责事先将文档散发给有关人员，记录审阅过程和结果，并将记录递交给报告者；

· 维护者：将负责维护该文档的人员的代表；

· 标准检查员：负责对照该文档所适用的标准进行检查的人员；

· 用户代表：负责从其使用者的观点检查该文档；

· 其他人员：任何对该文档的检查能够有所贡献的人员。

2）Fagan检查。Fagan检查是由IBM发展起来的，其总的原理和Yourdon的结构化走通非常类似。但是Fagan检查是将审阅放在一个质量计划、度量和控制的更广泛的环境下，使之具有双重目的：一是发现产品的错误；二是通过对错误的分析、统计，提供今后对所发现的同类错误进行控制的数据。Fagan检查强调的是对错误进行分类和统计，从而发现共同的错误类型和将来避免这类错误的方法。简言之，Fagan检查强调对开发过程的反馈和从错误中吸取教训。

（2）测试内容。静态测试测试的范围和内容很多。从范围上讲，凡是能形成文档的设计都应该进行测试。这包括需求定义文档的静态测试、概要设计文档的静态测试、详细设计文档的静态测试、编码文档的静态测试、测试文档的静态测试等。从内容上看，针对不同的文档，虽测试的内容不尽相同，但都是按照软件质量的要求，即第一章给出的软件质量的11个要素进行测试。下面以源代码的静态测试为例说明静态测试所包括的内容。

1）完备性测试。检查代码是否完全、准确地实现了设计规约中所规定的内容；代码是否满足设计要求；代码是否创建了所需的数据库或其它初始化数据；是否有未引用的或未定义的变量、常量或数据类型。

2）一致性测试。检查代码在逻辑上与设计规约是否一致；是否自始自终使用了相同的格式、调用约定、结构等。

3）正确性测试。代码是否符合标准；变量的定义和使用是否都正确；注释是否正确；子程序调用的参数个数是否正确等。

4）易修改性测试。检查代码是否避免了直接使用地址，而采用标号或符号常量；代码是否由单入口、单出口的子程序构成；是否有交叉引用数据等。

5）可测试性测试。检查程序中是否有递归；是否包含了无穷循环等。

6）健壮性测试。检查代码是否防止可以发现的运行时刻的错误，如：下标变量越界、除数为0、栈溢出等。

7）结构化测试。检查程序的每一个功能是否都可以作为一块代码而识别出；循环是否只有一个入口等。

8）易追溯性测试。检查是否有一个交叉引用表，通过它可以便捷地从代码找到相应的设计；是否有修改历史记录，它记录对代码的所有修改历史和修改原因。

9）易理解性测试。检查注释是否简洁、充分；是否有不必要的复杂代码等。

10）可验证性测试。检查实现是否避免了使用测试难度大的技术和方法等。

（3）方法评述：静态测试主要靠人来完成的。虽然近些年来，从需求分析开始的软件生存期的各个阶段，开发了不少的工具，但短期内难以实现其设计的自动化和测试的自动化。因此，静态测试错误发现的多少完全依赖于测试的组织和测试者的水平，实践也表明在这个方面有许多成功的范例，例如中国的某个有数万行航天类控制软件，通过静态测试发现了其中的3000多个缺陷。但从目前静态测试的效果来看尚存在如下的一些问题。

1）认识不足。特别是决策者的认识不足。但这种情况正在改变。

2）测试的问题太多，不知从何处下手。解决这个问题的办法是可以对静态测试的范围和内容进行分门别类的测试，效果可能会更好。

3）自动化或半自动化的测试工具是必须的。有了这个工具，可以大大提高测试者的兴趣和发现错误的能力。但目前基本上是空白。

4）开发的软件缺少静态测试所必须的文档。这个在一些地方还十分突出，但这种情况正在好转。