07解题方法与技巧精解6-应对软件测试维护、安全类型的问题.docx

《07解题方法与技巧精解6-应对软件测试维护、安全类型的问题.docx》由会员分享，可在线阅读，更多相关《07解题方法与技巧精解6-应对软件测试维护、安全类型的问题.docx（80页珍藏版）》请在三一办公上搜索。

1、 第 8讲 计算机数值表示与非数值表示第7讲 如何应对软件测试、维护、安全类型的问题 本讲导读 定量化的说明。 随着软件产业的推进和测试技术的发展，测试驱动开发越来越受到开发人员的重视，测试技术也渗透到软件开发的每一个角落。同时，虽然硬件技术已经获得了巨大的发展，但应用需求的快速增长也大大超出了人们的想象，如何更好地评价系统的各项性能指标对充分发挥系统的性能越来越来起到更为重要的作用。同时，测试驱动开发的思想也使得人们对测试技术更为重视，尤其是测试的基本方法。而对于系统安全，则是反复强调的重点，基本的安全设备，安全的体系结构等等属于考察的重点。 本讲内容 7.1 案例一软件可靠性测试7.1.1

2、 问题某企业信息部门的李工程师正在为其下属单位开发一个应用软件，在编写软件需求规格说明书时，涉及到如何定量地描述软件可靠性的问题。 李工认为软件可靠性指的是在将要使用的指定环境下，软件能以用户可接受的方式正确运行任务所表现出来的能力。从定量角度看，似乎应当是该软件在约定的环境条件下和在给定的时间区间内，按照软件规格说明的要求，成功地运行程序所规定功能的概率。但是，他感到要具体地做定量描述有些困难。为此，李工查阅到了本部门某个软件需求规格说明书中有关的一段内容：“（1）在集成与系统测试期间，由非开发组人员参与测试，每10k行可执行代码可能检测到的错误（BUG）不能大于6个； （2）在提交使用的系

3、统中，每10k行可执行代码可能保留着的错误数不能大于8个； （3）在第一年工作期间，系统在99.9%的工作日期间内，应能保持100%的正常工作状态。” 在上述说明后，还有一条注解是：错误（BUG）可采用蒙特卡罗（MonteCarlo）随机植入技术进行测试。 问题1李工程师首先想到了曾经学到过采用蒙特卡罗随机统计技术确定不规则形状封闭图形面积的方法，即是采用一个大的矩形把待测的封闭图形完全包围在该大矩形的内部，由计算机大量生成在此矩形内均匀分布的“点”，然后，计数清点一下在大矩形内总的“点”的个数和在封闭图形内的“点”的个数，应当近似地有：封闭图形的面积=对于某些使用于重要场合的软件，或者运行时

4、发生故障会产生相当严重后果的软件，必须要求有更高的可靠性，即在软件开发的所有相关环节采取相应的严格管理和措施，保证其能稳定可靠地运行，避免失效可能会引起的严重损失。 如果把这个思想应用于系统测试过程，先在某个程序中随机地人为植入10个错误（BUG），然后，由一个测试组进行测试，结果一共发现有120个错误，其中有6个是人为植入的错误。 请你估算一下这时该程序中将会遗留下多少个未被发现的隐藏错误。同时也请你用100字以内的文字，简要地以提纲方式列举出采用这种错误随机植入方式来估算系统中遗留错误所固有的局限性。 问题2 在进行上述分析后，李工程师感到有些困惑，于是与本企业维护系统的一位系统管理员进行

5、了讨论，系统管理员告诉他可以借用硬件的MTTF（失效的平均等待时间，MeanTimeToFailure）或者MTBF（失效的平均间隔时间）作为软件可靠性的主要指标。 这时，李工程师查到了本企业中的一个典型例子：某软件在提交使用后，在第1周内有5次软件故障（查出了有关的BUG），在第2周至第4周内共有23次出错（也排除了错误根源），在2个月以后该软件一直能正常使用运行（大家反映不错），一直到6年半后的一天突然停工，即工作不正常。 请你用100字以内文字分析该软件最后一次工作不正常的可能原因，并说明MTBF是在什么意义下反映了软件的可靠性。 问题3信息部门的吴总工程师向李工程师建议了另一类测试方案

6、作为“错误随机植入”测试方法的补充。即由甲和乙两组测试人员同时相互独立地测试同一份程序的两个拷贝，测试了两周后，甲组发现的错误总数为330个，乙组发现的错误总数为320个，其中两个组发现的相同错误数目为300个。请你大体上估算一下在测试前此程序原有多少个错误?并也请你以100字以内文字，简要说明使用这类估算方法的必要前提。7.1.2 背景知识与解题分析 根据可靠性的概念，要在软件需求规格说明书中定量地、确切地表述出软件可靠性是最困难的。软件可靠性需求应根据不同的软件使用的环境条件与不同的应用场合提出不同的要求，笼统地说：“软件应有99.9%的可靠性”是没有多大意义的。因为各类软件在运用时，出现

7、失效所造成的影响和损失各不相同，在需求分析时应对所开发的软件在投入运行后不发生故障的概率，按实际的运用环境条件提出适度的不同要求。 问题1在一个待测试的程序中人为地随机植入10个错误。测试后发现了120个错误，其中有6个是植入的错误。要求估算在该程序中还遗留有多少个“未被发现的错误”，指出以这类随机植入错误方案估算程序中错误所固有的局限性。有关随机植入错误方法，请参考试题4的分析。随机植入错误方法有几个明显的优点； （1）工作方式相当直观，能在一定程序上反映出软件的质量； （2）虽然在技术上不完善，但至少产生了与软件质量相关的定量的结果； （3）在最坏的情况下，起码可用来衡量“测试工作的有效性

8、”，在某种程序上作为测试是否能结束的一项标志，因为如果连这类播种入的错误都不能发现，一定不会是很成功的测试。 现在本题要求回答此类方案的局限性，大体上可从下面两方面分析。按照公式计算，这实际上就是一个比较简单的比例问题。MTBF反映了软件错误出现的频度，是“用户的可预测性”与“软件中存在错误数”的一个复杂的函数。 （1）要想使随机植入的错误有助于正确地推出固有的错误数时，如何有效地选择和植入这类错误相对很困难，因为所有错误不会平等地以同样的可能性出现，错误还有着连带性与相关性，比如一个错误往往会隐藏着某些其他的错误。（2）检测错误与修改好错误不是一件轻而易举的任务，一方面，随机植入的错误本身会

9、增加检测发现错误和修改错误的工作量，另一方面，在检测错误时，错误一般不会等同地被发现，在修复错误时经常会引出新的错误。从而很难用如此简单的公式获得很理想的估计值。随机植入错误测试方案的估算公式及其局限性： 程序中错误的总数：（10120）/6=200个。 遗留未被发现的错误数=200-120-（10-6）=80-4=76个。 （1）所有错误不会平等地出现； （2）错误有着连带相关性（一个错误可能隐藏另一错误）； （3）在检测错误时，错误不会等同地被发现：（4）在修复错误时经常会引起新的错误。 问题2 问题2要求分析软件正常工作了6年半后突然停工的可能原因，以及用失效的平均间隔时间MTBF反映软

10、件可靠性的含义是什么? 要分析一个软件稳定正常地运行了6年半后突然有一天停工，即工作不正常的原因时，从题目的上下文来看，主要应当从软件本身的质量和软件生存期的有关活动加以分析。 （1）在软件运行过程中用户的可预测性：最大的可能性应是用户突然启用了软件的一个应当提供的新功能，而软件的该项功能实现有错误，在以前的6年半中从未使用过该功能。类似地，用户新使用的正好是软件考虑不周的与时间有关的某个功能（包括类似于两千年问题等），与计数溢出有关的功能，与队列、堆栈、存储器容量或缓冲区大小有关的功能等。所有这些都可归入用户使用的可预测性问题，本质上是新暴露了软件所隐藏着的固有问题。 （2）在软件运行与维护

11、过程中引起了新的软件错误，最典型的是某个软件维护人员犯了错误，引入了一个新错误，这也是相当常见的现象。比如随着时间的推移，软件维护人员为了跟上发展，试一下能否为软件加一点新功能，没有成功便取消了，但无意中引入一个错误在软件中。也可能是在正常的日常维护（如备份或恢复系统）的过程中犯了一个小错误等。因此，从这些观点来看，MTBF是用户可预测性和软件中存在有的各类错误的一个复杂的函数，即使两个软件用来提供同样的功能并有着相同的错误数目，在不同的用户使用情况下不会有不同的MTBF（与用户的可预测性有关），功能上大体相同的两个软件在同样的用户使用条件下，由于软件有不同的错误数，因此有不同的MTBF（这时

12、错误数起主要作用）。从软件本身来分析软件突然停止正常工作的原因，主要的可能是： （1）用户突然启用了一个原来从未用过的新功能（用户的可预测性）； （2）某个软件维护人员犯了错误，引入了一个新错误。 问题3 独立测试方案的估算测试前程序中原有错误数=（330320）/300=352个。估算前提是： （1）两周来发现的错误在全部错误中有着代表性；（2）两组发现的不同错误数所占的比例相对是很低的。7.1.3 参考答案问题1 随机植入错误测试方案的估算公式及其局限性： 程序中错误的总数：（10120）/6=200个。 遗留未被发现的错误数=200-120-（10-6）=80-4=76个。 （1）所有错

13、误不会平等地出现； （2）错误有着连带相关性（一个错误可能隐藏另一错误）； （3）在检测错误时，错误不会等同地被发现： （4）在修复错误时经常会引起新的错误。 问题2 从软件本身来分析软件突然停止正常工作的原因，主要的可能是： （1）用户突然启用了一个原来从未用过的新功能（用户的可预测性）； （2）某个软件维护人员犯了错误，引入了一个新错误。 MTBF反映了软件错误出现的频度，是“用户的可预测性”与“软件中存在错误数”的一个复杂的函数。 问题3 独立测试方案的估算测试前程序中原有错误数=（330320）/300=352个。估算前提是： （1）两周来发现的错误在全部错误中有着代表性； （2）两组

14、发现的不同错误数所占的比例相对是很低的。7.2 案例二软件测试基础及测试工具使用7.2.1 问题某软件公司在研制与开发各类应用软件的过程中，深切地体会到软件测试的重要性与复杂性，认为这是关系到公司信誉、软件质量和软件维护的关键技术活动之一。公司的王总工程师多次召集公司有关的管理人员与技术骨干，分析了软件测试的规范化问题，讨论中一致认为规范化应涉及下列一些基本的软件测试活动：这是一道关于测试管理与方法的辨别试题，以及要求考生掌握至少一种测试工具。 （1）编制软件测试计划； （2）拟定软件测试大纲； （3）设计并生成各类测试用例； （4）以一系列“测试小周期”实施软件测试； （5）产生相应的软件问

15、题报告； （6）软件测试过程的整体性管理。 王总工程师要求开发部的赵工程师整理出几份专题性的报告。 问题1 针对公司里原来习惯于根据“谁开发谁测试”的原则进行软件测试，赵工程师在报告中建议采用“专业化测试人员”专职全身心地从事于软件测试工作。 请以100字以内文字，用提纲方式简明说明这可能会有什么好处。 问题2 在赵工程师拟就的专题报告中，提出了以下的一些见解： （1）软件测试过程应与整个软件的开发过程基本上并行地展开和进行。比如：许多测试准备工作都在测试实施阶段之前即已开始。 （2）软件的测试与纠错通常是反复迭代地进行的，改进软件的再测试与回归测试是提高软件测试效率与质量的重要环节之一。 （

16、3）根据测试是否针对软件系统的内部结构，一般可把软件测试的方法大体上区分为两大类：白盒子方法指的是功能测试，黑盒子方法指的是结构测试。 （4）测试用例的选择应注意代表性，即输入数据、操作与环境设置时应能代表有合理的或不合理的，合法的或非法的，界限内的或越界的等各类情况，也应包括有临界的或极限的情况。 （5）要求测试结果呈现“可判定性”（可评估或判定测试执行结果是否正确）和“可再现性”（对同样的测试用例，软件系统的执行结果相同）的特征。 （6）软件测试实施的主要依据是事先拟定好的软件测试计划，因此测试计划的拟定必须周密、全面与完善。 （7）针对公司中技术人员大量使用C语言指针编程开发的具体特点，

17、必须加强内存使用错误方面的软件测试。 请从上述叙述中选出你认为提法上不恰当的两条的序号，各用30字以内文字简要说明理由。 问题3在讨论中，王总工程师强调指出使用软件测试工具的必要性。请你以100字以内文字，用提纲方式简要列举某一种软件测试工具的主要功能（可以是你所使用过或看到过的工具，或者你所期望有的某一种软件测试工具）。7.2.2 背景知识与解题分析 问题1 问题1要求考生回答采用“专业化测试人员”的好处。采用专业化测试人员的好处大致如下： （1）可以避免程序员的习惯性错误； （2）可以从不同角度考虑问题； （3）有利于测试人员独立工作，杜绝人情关系； （4）有利于加强测试管理。问题2 测试

18、过程按4个步骤进行，即单元测试、组装测试、确认测试和系统测试。图4-2显示出软件测试经历的4个步骤。单元测试集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。然后，进行集成测试，根据设计规定的软件体系结构，把已测试过的模块组装起来，在组装过程中，检查程序结构组装的正确性。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。严格地说，系统测试已超出了软件工程的范围。单元测试针对程序模块，进行正确性检验的测试。其目的在于发现

19、各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。单元测试的内容包括：模块接口测试，对通过被测模块的数据流进行测试。为此，对模块接口，包括参数表、调用子模块的参数、全程数据、文件输入输出操作都必须检查。局部数据结构测试，设计测试用例检查数据类型说明、初始化、缺省值等方面的问题，还要查清全程数据对模块的影响。 路径测试，选择适当的测试用例，对模块中重要的执行路径进行测试。对基本执行路径和循环进行测试可以发现大量的路径错误。错误处理测试，检查模块的错误处理功能是否包含有错误或缺陷。例如，是否拒绝不合理的输入；出错的描述是否难以理解、是否

20、对错误定位有误、是否出错原因报告有误、是否对错误条件的处理不正确；在对错误处理之前错误条件是否已经引起系统的干预等。如果一个模块要完成多种功能，且以程序包或对象类的形式出现，例如C+中的类。这时可以将这个模块看成由几个小程序组成。对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。注意掌握几种集成测试之间的比较，体会它们相互之间的优缺点。边界测试，要特别注意数据流、控制流中刚好等于

21、、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。这些辅助模块分为两种：l 驱动模块，相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。l 桩模块，用以代替被测模块调用的子模块。桩模块可以做

22、少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。 被测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”。在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑：在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；一个模块的功能是否会对另一个模块的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，从而达到不能接受的程度;单个模块的错误是否会导致数据库错误。选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次

23、序和测试的次序、以及生成测试用例的费用和调试的费用。通常，把模块组装成为系统的方式有两种方式：l 一次性集成方式。它是一种非增殖式集成方式。也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。l 增殖式集成方式。又称渐增式集成方式。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。自顶向下的增殖方式：将模块按系统程序结构，沿控制层次自顶向下进行集成。由于这种增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个

24、功能划分合理的程序结构中，判断常出现在较高的层次，较早就能遇到。如果主要控制有问题，尽早发现它能够减少以后的返工。自底向上的增殖方式：从程序结构的最底层模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。混合增殖式测试：自顶向下增殖的方式和自底向上增殖的方式各有优缺点。自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及复杂算法和真正输入输出的模块一般在底层，它们是最容易出问题的模块，到组

25、装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。自底向上增殖方式的缺点是“程序一直未能做为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。但这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试。有鉴于此，通常是把以上两种方式结合起来进行组装和测试。除了按合同规定的内容和要求，由人工审查

26、软件配置之外，在确认测试的过程中，应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。必须仔细记录发现的遗漏和错误，并且适当地补充和改正。衍变的自顶向下的增殖测试：它的基本思想是强化对输入输出模块和引入新算法模块的测试，并自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行增殖测试。 自底向上-自顶向下的增殖测试：它首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统做自顶向下的组装与测试。回归测试：这种方式采取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系

27、统与其上级模块的接口是否适配。确认测试又称有效性测试。它的任务是验证软件的有效性，即验证软件的功能和性能及其它特性是否与用户的要求一致。在软件需求规格说明书描述了全部用户可见的软件属性，其中有一节叫做有效性准则，它包含的信息就是软件确认测试的基础。1. 进行有效性测试（功能测试）有效性测试是在模拟的环境（可能就是开发的环境）下，验证被测软件是否满足需求规格说明书列出的需求。为此，需要首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求都能达到，所有

28、的文档都是正确且便于使用。同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试，确认是否满足。2. 软件配置复查软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必需的细节，而且已经编排好分类的目录。3. 验收测试在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果。一般使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性

29、、可维护性、错误的恢复功能等进行确认。4. 测试和测试在软件交付使用之后，用户将如何实际使用程序，对于开发者来说是无法预测的。因为用户在使用过程中常常会发生对使用方法的误解、异常的数据组合、以及产生对某些用户来说似乎是清晰的但对另一些用户来说却难以理解的输出等等。如果软件是为多个用户开发的产品的时侯，让每个用户逐个执行正式的验收测试是不切实际的。很多软件产品生产者采用一种称之为测试和测试的测试方法，以发现可能只有最终用户才能发现的错误。测试是由用户在开发环境下进行的测试，也可是公司内部的用户在模拟实际操作环境下进行的测试。这是在受控制的环境下进行的测试。测试的目的是评价软件产品的FURPS（即

30、功能、可使用性、可靠性、性能和支持），尤其注重产品的界面和特色。测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见特别有价值。测试可从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应事先准备好。测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与测试不同的是，开发者通常不在测试现场。因而，测试是在开发者无法控制的环境下进行的软件现场应用。在测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最后将

31、软件产品交付给全体用户使用。测试主要衡量产品的FURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当测试达到一定的可靠程度时，才能开始测试。测试和测试在软件测试中占有非常重要的地位，要注意仔细体会意义及区别。由于测试处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。由于测试的主要目标是测试可支持性，所以测试应尽可能由主持产品发行的人员来管理。所谓系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一

32、系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析规格说明来设计，并在实际使用环境下来运行。80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发“ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。 80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工

33、作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。 80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。软件测试的种类大致可以分为人工测试和基于计算机的测试。而基于计算机的测试由可以分为白盒测

34、试、黑盒测试、灰盒测试。根据软件产品的功能设计规格，在计算机上进行测试，以证实每个实现了的功能是否符合要求。这种测试方法就是黑盒测试。黑盒测试意味着测试要在软件的接口处进行。就是说，这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求分析规格说明，检查程序的功能是否符合它的功能说明。用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。这种测试方法就是白盒测试。白盒测试把测试

35、对象看做一个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。不论是黑盒测试，还是白盒测试，都不可能把所有可能的输入数据都拿来进行所谓的穷举测试。因为可能的测试输入数据数目往往达到天文数字。对一个具有多重选择和循环嵌套的程序，不同的路径数目也可能是天文数字。灰盒测试，是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经

36、错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。问题2要求考生在给出的7条叙述中选出2条不恰当的叙述，并说明理由。我们可筛选法，逐一核对，挑选出自己认为最不恰当的2条叙述。显然，第（3）条和第

37、（5）条是不恰当的。静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件和Panorama系列。动态测试工具的代表有DevPanner软件、Rational公司的Purify系列。测试管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord等软件。 第（3）条：白盒子方法指的是结构测试，黑盒子方法指的是功能测试。 第（5）条：测试结果不一定能呈现“可再现性”，例如，与时间有关的错误。 问题3 一般情况下，我们将测试工具分为白盒测试工具、黑盒测试工具、性能测试工具、测试管理工具几个大类。 1白盒测试工

38、具 白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。 （1）静态测试工具。静态测试工具直接对代码进行分析，不需要运行代码，也不对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统模块的调用关系图或者类关联图等。 （2）动态测试工具。动态测试工具与静态测试工具不同，动态测试工具的一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据和程序运行的路径。其与静态测试工具最大的不同就是动态测试工具要求

39、被测系统实际运行。 2黑盒测试工具 黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制（Record）/回放（Playback），模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。黑盒测试工具的代表有Rational公司的 TeamTest、Robot，Compuware公司的QACenter，另外，专用于性能测试的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。 3测试管理工

40、具 测试管理工具用于对测试进行管理。一般而言，测试管理工具对测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟踪管理。 4其他测试工具 除了上述的测试工具外，还有一些专用的测试工具，例如，针对数据库测试的TestBytes，对应用性能进行优化的EcoScope等工具。 （1）软件质量自动分析。通过软件度量反映了软件质量的基本方面，而且反映了面向对象软件的质量特征。使用这些软件质量度量，使得软件质量能够看得见，从而有利于进行软件的质量改进，加速软件的开发。 （2）系统流程分析。直接从程序源代码产生逻辑流程图。 （3）自动生成测试文档。自动地分析程序源代码并且生成超过一百多种报告和图表，这些文档包括类的定义、构造、数据成员、成员函数、类的复杂性、类的调用、大小、类间耦合度、全局变量、静态变量、跳转标号、测试覆盖等。（4）测试用例生成分析，测试用例的自动回放。 7.2.3 参考答案 问题1 （1）可以避免程序员的习惯性错误； （2）可以从不同角度考虑问题； （3）有利于测试人员独立工作，杜绝人情关系； （4）有利于加强测试管理。 问题2 （3）：白盒子方法指的是结构测试，黑盒子方法指的是功能测试。 （5）：测试结果不一定能呈现“可再现性”，例如，与时间有关的错误。 问题3 （1）软件质量自动分析。 （2）系统流程分析。 （3