详细软件测试策略与过程答疑讲解

详细软件测试策略与过程答疑

2.1问：分析软件测试的复杂性。

答：（1）在软件测试当中，由于测试所需的输入量太大、测试的输出结果太多、软件实现的途径太多、软件规格说明没有一个客观标准等原因，无法对软件进行完全的测试，并找出所有的软件缺陷。

（2）通过软件测试只能报告软件已被发现的缺陷和故障，但无法显示潜在的软件缺陷和故障。

（3）经测试后的程序中隐含的故障数目与已发现的故障数目成正比。

（4）软件测试进行得越多，其程序中缺陷的免疫力就越强。在测试时，即使付出再多的时间和代价，也不能够使所有的软件故障都得到修复。

（5）如果不能做到去测试软件所有的情况，则该软件就是有风险的。软件测试不可能对软件使用中所有的情况进行测试，但有可能客户会在使用该软件的时候遇到，并且可能发现软件的缺陷。等到那个时候，再进行软件缺陷的修复，代价将是很高的。

2.2问：软件测试充分性准则的内容是什么？

答：（1）对任何软件都存在有限的充分测试集合。

（2）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。

（3）即使对软件所有成分都进行了充分的测试，也并不表明整个软件的测试已经充分了。这一特性称为非复合性。

（4）即使对软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。

（5）软件测试的充分性应该与软件的需求和软件的实现均相关。

（6）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。

（7）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

2.3问：什么是静态测试？静态测试包括哪些内容？

答：静态测试是指不利用计算机运行被测程序，也就是说，计算机并不真正运行被测试的程序，而是通过其他手段达到检测的目的。静态测试是对被测程序进行特性分析的一些方法的总称。

静态测试包括代码检查、静态结构分析、代码质量度量等。其中：代码检查又包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面；

静态结构分析主要是以图形的方式表现程序的内部结构，如函数调用关系图、函数内部控制流图；代码质量度量则是以目前已有的几种度量参数（Line复杂度、Halstead复杂度、McCabe复杂度）来衡量软件的质量。

2.4问：静态测试可以完成哪些工作？

答：（1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、

不允许的递归；调用不存在的子程序，遗漏标号或代码。

（2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。

（3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。

（4）为进一步查找做好准备。

（5）选择测试用例。

（6）进行符号测试。

2.5问：什么是动态测试？动态测试包括哪些内容？

答：动态测试是指计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，达到检测的目的。动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

2.6问：简述黑盒测试法和白盒测试法。

答：若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试方法。黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它从用户观点出发的测试。用这种方法进行测试时，把被测试程序当作一个黑盒，在不考虑程序内部结构的内部特性、测试者只知道该程序输入和输出之间的关系或程序功能的情况下，依靠能够反映这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。

若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试方法。白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密的检验。针对特定条件和循环集设计测试用例，对软件的逻辑路径进行测试。在程序的不同点检验程序的状态，来进行判定其实际情况是否和预期的状态相一致。

黑盒测试法和白盒测试法是从完全不同的起点出发，并且这两个出发点在某种程度上是完全对立的，反映了测试思路的两方面情况。这两类方法在长期的软件测试实践过程中被证明是有效和实用的方法。

2.7问：比较黑盒测试法和白盒测试法。

2.8问：简述软件测试过程。

答：软件测试过程按测试的先后次序可分为：单元测试、集成测试、确认（有效性）测试、系统测试和验收（用户）测试共5个步骤。

（1）单元测试：针对每个单元的测试，以确保每个模块能正常

工作为目标。

（2）集成测试：对已测试过的模块进行组装，进行集成测试。这项测试的目的在于检验与软件设计相关的程序结构问题。

（3）确认测试：在完成集成测试后，对开发工作初期制定的确认准则进行检验。它是检验所开发的软件能否满足所有功能和性能需求的最后手段。

（4）系统测试：在完成确认测试后，应属于合格软件产品。但为了检验它能否与系统的其他部分（比如硬件、数据库及操作人员）协调工作，还需要进行系统测试。

（5）验收测试：检验软件产品质量的最后一道工序是验收测试。验收测试主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

2.9问：单元测试的主要任务是什么？

答：单元测试针对每个程序的模块，主要测试5个方面的问题——模块接口、局部数据结构、边界条件、独立的路径和错误处理。

（1）模块接口测试：检查进出程序单元的数据流是否正确，对模块接口数据流的测试必须在任何其他测试之前进行。

（2）局部数据结构测试：测试其内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。

（3）路径测试：检查是否存在由于计算错误、不正确的判定或是不正常的控制流而产生的错误。

（4）边界条件测试：是单元测试的最后一步，必须采用边界值

分析方法来设计测试用例，测试为限制数据处理而设置的边界处，看模块是否能够正常工作。

（5）出错处理测试：测试模块在工作中发生了错误时，其中的出错处理设施是否有效。

2.10问：简单说明单元测试中的辅助测试模块。

答：在对每个模块进行单元测试时，不能完全忽视它们和周围模块的相互关系。为模拟这一联系，在进行单元测试时，需要设置一些辅助测试模块。辅助测试模块有两种：一种是驱动模块（Drive），用来模拟被测试模块的上一级模块，相当于被测模块的主程序。驱动模块在单元测试中接收数据，把相关的数据传送给被测试的模块，启动被测模块，并打印出相应的结果。另一种是桩模块（Stub） ,用来模拟被测试模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便检验被测模块与其下级模的接口。被测模块、驱动模块和桩模块共同构成了一个如下图所示的单元测试的测试环境：

2.11问：为什么在单元测试之后要进行集成测试？如何组织集成测试？

答：实践表明，软件的一些模块能够单独地工作，但并不能保证组装连接之后也肯定能正常工作。程序在某些局部反映不出来的问题，在全局情况下有可能暴露出来，影响软件功能的实现。可能的原因有：（1）模块相互调用时引入了新的问题；（2）几个子功能组合后不能实现预计的主功能；（3）计算的误差累计达到了不能接受的程

度；（4）全局数据结构出现错误。因此，在单元模块完成单元测试后，需要按照设计的程序结构图进行组合、进行集成测试，检测与接口有关的各种故障。

组织集成测试的一种方法是先独立的测试每个模块，然后再将它们组合成一个整体进行测试；另一种方法是先把下一个待测试模块组合到已经测试过的那些模块上去，再进行测试，逐步完成集成测试。由此产生了两种集成测试方法：非增量式测试和增量式测试。

2.12问：简述集成测试中的非增量式测试和增量式测试方法。

答：非增量式测试方法是采用一步到位的方法来构造测试：对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。

增量式测试的集成是逐步实现的：逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。按照不同的实施次序，增量式测试又可以分为自顶向下增量式测试和自底向上增量式测试：

（1）自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上而下进行的，即模块集成的顺序是首先集成主控模块（主程序），然后依照控制层次结构向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。其中，深度优先的集成首先集成的是在结构中的一个主控路径下的所有模块，主控路径的选择是任意的；广度优先的集成首先沿着水平方向，

把每一层中所有直接隶属于上一层的模块集成起来，直到底层。

（2）自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的，即从程序模块结构的最底层模块开始集成和测试。由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

图见P49图2.3所示

2.13问：比较几种不同的集成测试方法。

答：（1）非增量式集成测试与增量式集成测试的比较：

非增量式测试的方法是先分散测试，然后集中起来再一次完成集成测试。假如在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来。与此相反，增量式测试是逐步集成和逐步测试的方法，把可能出现的差错分散暴露出来，便于找出问题和修改。而且一些模块在逐步集成的测试中，得到了较多次的考验，因此，可能会取得较好的测试效果。总之，增量式测试要比非增量式测试具有一定的优越性。

（2）自顶向下与自底向上增量式测试的比较：

自顶向下增量式测试的主要优点在于它可以自然的做到逐步求精，一开始就能让测试者看到系统的框架。它的主要缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难。同时，观察和解释测试的输出常常也比较困难。自

底向上增量式测试的优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也无困难。如果关键的模块是在结构图的底部，那么自底向上测试具有优越性。它的主要缺点在于，直到最后一个模块被加进去之后才能看到整个程序（系统）的框架。

2.14问：确认测试的准则是什么？

答：确认测试也称为合格性测试，是检验所开发的软件是否能按用户提出的要求进行。经过确认测试，应该为已开发的软件给出结论性评价：

（1）经过检验的软件的功能、性能及其他要求均已满足需求规格说明书的规定，则可被认为是合格的软件。

（2）经过检验发现与需求说明书有相当的偏离，得到一个各项缺陷清单。

对于这种情况，往往很难在交付期之前把发现的问题纠正过来。这就需要开发部门与用户进行协商，找出解决的办法。

2.15问：为什么要进行系统测试？

答：由于软件只是计算机系统中的一个组成部分，软件开发完成之后，最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。因此，在投入运行前要完成系统测试，以保证各组成部分不仅能单独的得到检验，而且在系统各部分协调工作的环境下也能正常工作。

2.16问：系统测试的内容包含哪些？简单说明每一种测试的要点。

答：系统测试的内容包括恢复测试、安全测试、强度测试、性能测试、正确性测试、可靠性测试、兼容性测试、Web网站测试等。尽管每一种测试有特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。

（1）恢复测试是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力。如果系统恢复是自动的（由系统自身完成），则应该检验重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。如果这一恢复需要人为干预，则应考虑平均修复时间是否在限定的、可以接受的范围之内。

（2）安全测试的目的在于验证安装在系统内的保护机制能否在实际中保护系统且不受非法入侵，不受各种非法干扰。在安全测试过程中，测试者扮演着试图攻击系统的个人角色，因此要设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

（3）强度测试（也称压力测试）的目的是要检测非正常的情形，测试是想要破坏程序。强度测试需要在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度。

（4）性能测试用来测试软件在系统集成中的运行性能，特别是针对实时系统和嵌入式系统，仅提供符合功能需求但不符合性能需求的软件是不能被接受的。性能测试常常和强度测试结合起来进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要在一种苛刻的环境中衡量资源的使用。

（5）正确性测试检查软件的功能是否符合规格说明。正确性测试基本的方法是构造一些合理输入，检查是否得到期望的输出，这是枚举法。还有一种有效的测试方法是边界值测试，即采用定义域或者等价区间的边界值来进行测试。因为程序设计容易疏忽边界情况，程序也容易在边界值处出错。

（6）可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。可靠性测试需要从用户角度出发，模拟用户实际使用系统的情况，设计出系统的可操作视图。在这个基础上，根据输入空间的属性及依赖关系导出测试用例，然后在仿真的环境或真实的环境下执行测试用例并记录测试的数据。

（7）兼容性测试是检测各软件之间能否正确地交互和共享信息，其目标是保证软件按用户期望的方式进行交互，使用其它软件检查软件操作的过程。兼容性的测试通常需要解决以下问题：新开发的软件需要与哪种操作系统、Web浏览器和应用软件保持兼容，如果要测试的软件是一个平台，那么要求应用程序能在其上运行；应该遵守哪种定义软件之间交互的标准或者规范；软件使用何种数据与其它平台、与新的软件进行交互和共享信息。

（8）Web 网站测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适，以及从最终用户的角度进行安全性和可用性测试。通常 Web 网站测试包含文字测试、链接测试、图形图像测试、表单测试、动态内容测试、

数据库测试、服务器性能及负载测试、安全性测试。

2.17问：面向对象的软件测试与传统软件测试有什么不同？

答：面向对象的软件特有的继承、封装和动态绑定等特性与传统的软件有了较大的区别，这给软件测试带来一系列新的问题。在传统的面向过程的程序中，通常考虑的是函数的行为特征；而在面向对象的程序中，就需要考虑基类函数、继承类函数的行为特征。

面向对象的程序结构已不再是传统的功能模块结构。封装是面向对象软件的一个重要特征，将数据及对数据的操作封装在一起，限制了对象属性对外的透明性和外界对它的操作权限，在某种程度上避免了对数据的非法操作，有效的防止了故障的扩散。但同时，封装的机制也给测试数据的生成、测试路径的选取以及测试结构的分析带来了困难。

继承和动态绑定机制是面向对象实现的主要手段。继承实现了共享父类中定义的数据和操作，同时也可定义新的特征。子类是在新的环境中存在，所以父类的正确性不能保证子类的正确性。继承使代码的重用率得到了提高，但同时也使故障的传播几率增加。因此，继承关系的测试方法及策略是面向对象测试工作的重点和难点。动态绑定也增加了系统运行中可能的执行路径，而且给面向对象软件带来了更为严重的不确定性，使得测试覆盖率的进行带来新的困难。

与传统软件相比，由于存在诸如继承、关联、动态绑定等关系，面向对象软件具有更复杂的依赖关系，一个类将不可避免的依赖于其它的类，从而增加了面向对象软件测试的难度。传统软件中存在的依

赖关系有：变量间的数据依赖；模块间的调用依赖；变量与其类型间的定义依赖；模块与其变量间的功能依赖。而面向对象软件除了存在上述依赖关系外，还存在以下的依赖关系：类与类间的依赖；类与操作间的依赖；类与消息间的依赖；类与变量间的依赖；操作与变量间的依赖；操作与消息间的依赖；操作与操作间的依赖。

2.18问：简述面向对象的单元测试与集成测试的思路策略。

答：与传统的单元不同，面向对象软件测试中的单元是封装的类和对象。类包含一组不同的操作，并且某个或某些特殊操作可能作为一组不同的类的一部分而存在，测试时不再测试单个孤立的操作，而是测试操作类及类的一部分，单元测试的意义发生了较大的变化。对面向对象软件的类测试等价于对面向过程软件的单元测试。传统的单元测试主要关注模块的算法和模块接口之间数据的流动，即输入和输出；而面向对象软件的类测试主要是测试封装在类中的操作以及类的状态行为。

面向对象的程序结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已变得不可行，传统的自顶向下和自底向上的集成策略对于面向对象的集成测试是没有意义的。通常面向对象的集成测试需要进行两级集成：其一是将成员函数集成到完整类中，其二是将类与其它类集成。对面向对象的集成测试有两种不同的策略：

（1）基于线程的测试。集成针对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别进行测试。

（2）基于使用的测试。首先测试独立的类，并开始构造系统，然后测试下一层的依赖类（使用独立类的类），通过依赖类层次的测试序列逐步构造完整的系统。