第6章系统测试、实施与维护83p

《第6章系统测试、实施与维护83p》由会员分享，可在线阅读，更多相关《第6章系统测试、实施与维护83p（83页珍藏版）》请在金锄头文库上搜索。

1、第第6 6章章 系统测试、实施与维护系统测试、实施与维护 6.1 软 件 测 试6.2 调 试6.3 系 统 实 施6.4 系 统 维 护6.5 实 验 五6.1 软 件 测 试6.1.1 测试的基本概念软件测试是对软件计划、软件设计、软件编码进行查错和纠错的活动。测试的目的是为了找出软件开发过程中各个阶段的错误，以便分析错误的性质和确定错误的位置，并纠正错误。软件测试伴随着程序设计的出现而出现，随着软件技术的发展，人们对软件测试的认识也在不断加深。通常人们认为“软件测试是为了证明软件是正确的”。实际上这种认识是错误的。1983年，IEEE提出的软件工程标准术语中软件测试的定义是：“使用人工或

2、自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求，或弄清 预期结果与实际结果之间的差别”。G.J.Myers则认为“程序测试是为了发现错误而执行程序的过程”。上面的两种定义有不同的强调方面，关于软件测试的概念，我们要注意以下两点：(1) 软件测试是为了发现程序中的错误而不是证明程序的正确性。按照Myers的观点，“成功的测试是发现了至今尚未发现的错误的测试”。当然测试的目的不仅仅是发现错误，还包含检验、评价等。(2) 软件测试方法不仅仅是执行程序，也包括人工方法。事实上，人工测试在某些测试阶段可以发现大部分的错误。 6.1.2 测试的基本原则要高质量地完成测试工作，找出软

3、件中的错误，应该遵守下面的一些基本原则：(1) 测试队伍与开发队伍应分别建立。开发和测试工作两者在思想和方法上都是不一样的，为了保证测试的质量，应分别建立开发和测试队伍。开发工作是建设性的，而在测试阶段，人们设计出一系列的输入数据（称为测试用例），目的是为了“破坏”已经建造好的软件。就像给硬件产品做高低温试验、震动试验、破坏性试验一样。而且一般程序编写者往往认为自己编写的程序是正确的，要他们找出自己程序中的错误是十分困难的。 (2) 设计测试用例时，要给出测试的预期结果。一个测试用例应由两部分组成： 对程序进行测试的一组输入数据的描述； 由这一组输入数据所产生的程序的预期输出结果的描述。预期输

4、出结果不一定是精确的输出结果，对于一些复杂的计算，人工计算结果可能需要很大的工作量，可以给出一个对输出结果有效范围的描述。(3) 设计测试用例时，应包括对有效的和期望的输入条件的测试，也应包括对无效的和非期望的输入条件的测试。一个程序不仅当输入合法时能正确运行，而且当有非法输入时，应该能够拒绝这些非法输入，并给出适当的提示信息。 (4) 在程序修改之后，要进行回归测试。对程序的任何修改都有可能引入新的错误，所以必须进行回归测试，即将以前的所有测试用例再次输入测试，而不是仅仅测试以前结果不正确的测试用例。回归测试有助于发现由于修改程序而引入的新错误。(5) 对发现错误较多的程序段，应进行深入的测

5、试。如果发现某个程序段错误较多，则表明这个程序段质量很低，有可能隐藏有更多的错误，应该进行深入的测试。 6.1.3 测试方法软件测试方法有多种，这些测试方法具有不同的思路和出发点。总的来说，测试方法可分为静态测试方法和动态测试方法两大类。所谓静态测试方法，是指不在计算机上运行被测试程序，而是采用其它手段达到对程序进行检测目的的测试方法。静态测试方法包括人工测试方法和计算机辅助静态分析方法。所谓动态测试方法，是指在计算机上运行被测试程序，并用所设计的测试用例对程序进行检测的方法。动态测试方法根据设计测试用例的思想不同可分为白盒测试、黑盒测试以及穷举测试等。1. 人工测试方法人工测试方法是指依靠人

6、而不是计算机来对程序进行检测的方法。人工测试可以找出计算机测试不容易发现的错误，可以减少系统测 试的总工作量。根据统计，人工测试能有效地发现30%70%的逻辑设计和编码错误。人工测试可以采用人工运行和代码审查的方式。代码审查可以由程序编写者本人非正式地进行，也可以由审查小组正式进行。代码审查主要是对照常见程序错误清单对程序代码进行分析审查，并将发现的错误记录下来。表6.1是由Myers提供的常见程序错误清单，该表主要针对FORTRAN一类的程序设计语言所编写的程序，其它的程序设计语言编写的程序也可参照该清单。表中的参数相当于C语言中函数的形式参数，而变元相当于C语言中函数调用时的实际参数。 表

7、6.1 Myers提供的常见程序错误清单 一、模块块接口检查检查 表 1.模块接收的输入参数个数与模块的变元个数是否一致？2.参数与变元的属性是否匹配？3.参数与变元所用的单位是否一致？4.传送给被调用模块的变元的数目是否等于那个模块的参数的数目 ？5.传送给被调用模块的变元属性和参数的属性是否一致？6.传送给被调用模块的变元的单位和参数的单位是否一致？7.传送给内部函数的变元属性、数目和次序是否正确？8.是否修改了只是作为输 入用的变元？9.全程变量的定义在各个模块中是否一致？10.有没有把常数当作变量来传送？ 二、完成外部输入/输出时的检查 表 4. 文件属性是否正确？2.打开文件语句是否

8、正确？3.格式说明与输入/输出语句给出的信息是否一致？4.缓冲区大小与记录 大小是否匹配？5.是否所有文件在使用前都已打开了？6.对文件结束条件的判断和处理是否正确？7.对输 入/输出错误 的处理是否正确？8.输出信息中有没有正文错误 ？ 三、模块局部数据结构的检查 表 4. 有没有不正确或不一致的说明？2. 有没有不正确的初始化和缺省值？3. 有没有错误 的变量名？4. 有没有不相容的数据类型？5. 有没有下溢、上溢或地址错误 ？ 四、计算错误检查 表 4. 对运算优先次序的错误 理解或错误处 理。2.发生了混合运算（运算对象的类型不相容）。3.初始化错误 。4.计算精度不够。5.表达式的符

9、号表示错误 。 五、比较错误 的检查 表 4. 不同数据类型的数据进行比较。2.逻辑 运算符或其优先次序用错。3.本应相等的数据，由于精度原因而不相等。4.变量本身有错或比较有错。 5.循环终 止不正确或循环不止。6.“差1”错（多一次或少一次循环）。7.当遇到发散的迭代不能摆脱出来。 8.循环控制变量修改有错。 六、出错处 理的检查 表 1.对错误 的描述难以理解。2.指明的错误 并非实际 遇到的错误 。3.出错后尚未进行错误处 理，错误 条件已引起了系统干预。4.对错误 的处理不正确。5.提供的错误 信息不足，以致无法找到出错的原因。人工测试还可以采用软件审查的方式，它可以用于系统开发的各

10、个阶段，对产品的质量进行评审。限于篇幅，本书不再详细介绍。 2. 计算机辅助静态分析方法计算机辅助静态分析方法是利用计算机测试工具对被测程序的特性进行分析方法的总称。静态分析工具主要有下面几种形式：(1) 静态确认工具：对程序进行静态分析和确认，收集一些程序中的信息，以查找程序中的各种缺陷和可疑的程序构造。例如，使用了一个尚未赋值的变量，或者赋了值的变量一直没有使用等。(2) 符号执行工具：以符号值作为程序的输入，使程序符号执行，对程序的运算规律加以检验。(3) 程序验证工具：交互式程序验证系统是证明程序正确性的一种工具。它通过系统内部基于符号的逻辑变换和结构归纳，提取程序的语义和结构的要点来

11、分析证明程序的正确性。3. 黑盒测试黑盒测试又称功能测试，即不管程序内部是如何编制的，只考虑程序输入和输出之间的关系，或只考虑程序的功能。因此，测试者必须根据软件的规格说明书来确定和设计测试用例。黑盒测试也被称为数据驱动测试或基于规格说明书的测试。黑盒测试适合于对内部结构未知的软件进行测试，例如对于外购的软件包，只能根据软件包的功能说明书进行测试。另外，用户对系统的验收测试也使用黑盒测试方法，因为用户关心的是软件是否能实现所需的功能。也可以说，黑盒测试是从用户观点进行的测试。4. 白盒测试白盒测试也称为结构测试，它是根据被测试程序的逻辑结构设计测试用例。使用白盒测试方法需要了解程序的内部结构，

12、对程序的不同逻辑路径进行测试。由于采用不同方法设计测试用例对程序的逻辑路径覆盖的程度不一，白盒测试又被称为基于“覆盖”的测试。覆盖率越高，测试越充分。 5. 穷举测试软件测试的主要目的是查找软件中存在的错误，而不能证明软件的正确性。实际上采用一般的测试方法根本无法证明软件的正确性。有人 主张通过白盒或黑盒测试方法对所有可能的情况进行测试，如果所有的 情况都是正确的，则可证明程序是正确的。这种方法被称为穷举测试， 实际上除了一些简单的程序外，它是无法实现的。使用黑盒测试进行穷举测试，必须穷举所有可能的输入数据。举一个简单的例子，假设输入三个无符号整数作为三角形的三条边长，判断 该三角形是否为直角

13、三角形。C语言中无符号整数的范围为0216-1，如 果要穷举所有的输入数据，则测试用例数为216*216*2163*1014，假定程 序每执行一次需要1 ms，则需要一万年。白盒测试要实现穷举测试同样难以实现，当程序中包含有较复杂的循环和条件语句嵌套时，可能的执行路径数目同样很多，测试用例要覆 盖所有的执行路径是根本不可能的。 6.1.4 设计测试用例使用白盒测试和黑盒测试都需要设计测试用例，上一节中已经提到要将所有可能的情况穷举出来是不可能的，因此在设计测试用例时必须依据一定的原则，以保证既能对程序进行充分的测试，而测试用例的数目又不能太大。本节将介绍常用的白盒和黑盒测试用例设计的方法。1.

14、 白盒测试白盒测试根据模块设计阶段对模块内部逻辑结构的描述设计测试用例。根据测试用例对模块所有可能执行路径的覆盖程度，可将其分为语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖和路径覆盖。 1) 语句覆盖语句覆盖要求所设计的用例使程序中的每一条语句至少执行一次。 这是覆盖程度很低的一种覆盖标准。下面是一个简单的例子。假设程序的流程图如图6.1所示，对应的C语言源程序片段如下：X=0;if(A1|B2)X=A+B;printf(“%d”, X);现在按语句覆盖标准设计测试用例，只需设计一组测试用例使条件“A1 or B2”成立即可，例如：输入数据：A=2，B=0；输出数据：X=2。 图6

15、.1 被测试程序的流程图这组测试用例虽然覆盖了所有的语句，但对条件语句的分支测试不充分，只测试了条件为真的分支。如果条件表达式中的第一个条件表达式A1误写为A=1（C语言中该表达式值为真），这组测试用例无法检测该错误。同样，如果条件表达式中的第二个条件表达式B2写错，这组测试用例也不能检测出程序的错误。 2) 判定覆盖判定覆盖要求对程序中所有判定的分支都必须能够执行到。对于上面的例子，可设计两组测试用例：第一组输入数据：A=2，B=0； 输出数据：X=2；第二组输入数据：A=1，B=0； 输出数据：X=0。这两组测试用例分别使条件语句中的条件表达式取“真”和“假”，很显然也是语句覆盖，但对程序

16、的测试比语句覆盖更充分。判定覆盖也是一种较弱的覆盖，这里的例子对条件表达式中B2的测试很不充分，没有测试该表达式为真的情况。 3) 条件覆盖条件覆盖是指设计的测试用例能使程序中判定的每一个条件的可 能取值都满足一次。对于上面的例子，判定中有两个条件，每个条件的可能取值为：条件1：A1 真记为T1假（A1）记为F1条件2：B2 真记为T2假（B2）记为F2可以设计两组测试用例：第一组输入数据：A=2，B=3； 输出数据：X=2；满足T1、T2；第二组输入数据：A=1，B=0； 输出数据：X=0；满足F1、F2。在大部分情况下，条件覆盖比判定覆盖强，因为它使判定表达式中每个条件都取得了可能的值，而判定覆盖只关心整个判定的取值。读者可以很容易地看出，这里的两组测试用例也满足判定覆盖的要求。但条件覆盖并不一定总是满足判定覆盖的要求，对上面的例子，我们看下面的两组测试用例：第一组输入数据：A=2，B=0； 输出数据：X=2；满足T1、F2；第二组输入数据：A=1，B=3； 输出数据：