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

《2022年07解题方法与技巧精解6-应对软件测试维护、安全类型的问题.doc》由会员分享，可在线阅读，更多相关《2022年07解题方法与技巧精解6-应对软件测试维护、安全类型的问题.doc（33页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第7讲 如何应对软件测试、维护、平安类型的征询题 本讲导读 定量化的说明。 随着软件产业的推进和测试技术的开展，测试驱动开发越来越遭到开发人员的注重，测试技术也浸透到软件开发的每一个角落。同时，尽管硬件技术已经获得了宏大的开展，但应用需求的快速增长也大大超出了人们的想象，如何更好地评价系统的各项功能指标对充分发挥系统的功能越来越来起到更为重要的作用。同时，测试驱动开发的思想也使得人们对测试技术更为注重，尤其是测试的根本方法。而关于系统平安，则是反复强调的重点，根本的平安设备，平安的体系构造等等属于调查的重点。 本讲内容 7.1 案例一软件可靠性测试7.1.1 征询题某企业信息部门的李工程师正在

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

3、存着的错误数不能大于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）两周来发觉的错误在全部错误中有着代表性； （

14、2）两组发觉的不同错误数所占的比例相对是特别低的。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）有利

18、于加强测试治理。征询题2 测试过程按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. 测试和测试在软件交付使用之后，用户将如何实际使用程序，关于开发者来说是无法预测的。由于用户在使用过程中常常会发生对使用方法的误解、异常的数据组合、以及产生对某些用户来说大概是明晰的但对另一些用户来说却难以理解的输出等等。假如软件是为多个用户开发的产品的时侯，让每个用户逐一执行正式的验收测试是不实在际的。特别多软件产品消费者采纳一种称之为测试和测试的测试方法，以发觉可能只有最终用户才能发觉的错误。测试是由用户在开发环境下进展的测试，也但是公司内部的用户在模仿实际操作环境下进展的测试。这是在

30、受操纵的环境下进展的测试。测试的目的是评价软件产品的FURPS（即功能、可使用性、可靠性、功能和支持），尤其注重产品的界面和特色。测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修正意见特别有价值。测试可从软件产品编码完毕之时开场，或在模块（子系统）测试完成之后开场，也能够在确认测试过程中产品到达一定的稳定和可靠程度之后再开场。有关的手册（草稿）等应事先预备好。测试是由软件的多个用户在一个或多个用户的实际使用环境下进展的测试。与测试不同的是，开发者通常不在测试现场。因而，测试是在开发者无法操纵的环境下进展的软件现场应用。在测试中，由用户记下遇到的所有征询题，包括真实的以及主观认

31、定的，定期向开发者报告，开发者在综合用户的报告之后，做出修正，最后将软件产品交付给全体用户使用。测试主要衡量产品的FURPS。着重于产品的支持性，包括文档、客户培训和支持产品消费才能。只有当测试到达一定的可靠程度时，才能开场测试。测试和测试在软件测试中占有特别重要的地位，要留意细心体会意义及区别。由于测试处在整个测试的最后阶段，不能盼望这时发觉主要征询题。同时，产品的所有手册文本也应该在此阶段完全定稿。由于测试的主要目的是测试可支持性，因而测试应尽可能由主持产品发行的人员来治理。所谓系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员

32、等其它系统元素结合在一起，在实际运转（使用）环境下，对计算机系统进展一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比拟，发觉软件与系统定义不符合或与之矛盾的地点。系统测试的测试用例应依照需求分析规格说明来设计，并在实际使用环境下来运转。80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，假如你想使软件测试有效地话，记住常常光临其高危多发“ 地段 ” 。在那儿发觉软件缺陷的可能性会大的多。这一原则关于软件测试人员提高测试效率及缺陷发觉率有着严重的意义。聪明的测试人员会依照这个原则特别快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地四处搜寻。 80-20 原

33、则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发觉和防止 80% 的软件缺陷，此后的系统测试能够协助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户通过大范围、长时间使用后才会曝露出来。由于软件测试只能够保证尽可能多地发觉软件缺陷，却无法保证能够发觉所有的软件缺陷。 80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷能够借助人工测试而发觉， 20% 的软件缺陷能够借助自动化测试能够得以发觉。由于这二者间具有穿插的部分，因而尚有 5% 左右的软件缺陷需要通过其他方式进展发觉和修正。软件测试的品种大

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

35、格要求，所有内部成分是否已通过检查。这种测试方法确实是白盒测试。白盒测试把测试对象看做一个打开的盒子，同意测试人员利用程序内部的逻辑构造及有关信息，设计或选择测试用例，对程序所有逻辑途径进展测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。不管是黑盒测试，依然白盒测试，都不可能把所有可能的输入数据都拿来进展所谓的穷举测试。由于可能的测试输入数据数目往往到达天文数字。对一个具有多重选择和循环嵌套的程序，不同的途径数目也可能是天文数字。灰盒测试，是介于二者之间的，能够如此理解，灰盒测试关注输出关于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完好，只是通过一些表

36、征性的现象、事件、标志来推断内部的运转状态，有时候输出是正确的，但内部事实上已经错误了，这种情况特别多，假如每次都通过白盒测试来操作，效率会特别低，因而需要采取如此的一种灰盒的方法。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以加强测试效率、错误发觉和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。征询题2要求考生在给出的7条表达中选出2条不恰当的表达，并说明

37、理由。我们可选择法，逐一核对，选择出本人认为最不恰当的2条表达。显然，第（3）条和第（5）条是不恰当的。静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件和Panorama系列。动态测试工具的代表有DevPanner软件、Rational公司的Purify系列。测试治理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord等软件。 第（3）条：白盒子方法指的是构造测试，黑盒子方法指的是功能测试。 第（5）条：测试结果不一定能呈现“可再现性”，例如，与时间有关的错误。 征询题3 一般情况下，我们将测试

38、工具分为白盒测试工具、黑盒测试工具、功能测试工具、测试治理工具几个大类。 1白盒测试工具 白盒测试工具一般是针对代码进展测试，测试中发觉的缺陷能够定位到代码级，依照测试工具原理的不同，又能够分为静态测试工具和动态测试工具。 （1）静态测试工具。静态测试工具直截了当对代码进展分析，不需要运转代码，也不对代码编译链接，生成可执行文件。静态测试工具一般是对代码进展语法，找出不符合编码标准的地点，依照某种质量模型评价代码的质量，生成系统模块的调用关系图或者类关联图等。 （2）动态测试工具。动态测试工具与静态测试工具不同，动态测试工具的一般采纳“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用

39、来统计程序运转时的数据和程序运转的途径。其与静态测试工具最大的不同确实是动态测试工具要求被测系统实际运转。 2黑盒测试工具 黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和功能测试工具。黑盒测试工具的一般原理是利用脚本的录制（Record）/回放（Playback），模仿用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比拟。黑盒测试工具能够大大减轻黑盒测试的工作量，在迭代开发的过程中，能够特别好地进展回归测试。黑盒测试工具的代表有Rational公司的 TeamTest、Robot，Compuware公司的QACenter，另外，专用于功能测试的工具包括有Radvi

40、ew公司的WebLoad、Microsoft公司的WebStress等工具。 3测试治理工具 测试治理工具用于对测试进展治理。一般而言，测试治理工具对测试计划、测试用例、测试施行进展治理，同时测试治理工具还包括对缺陷的跟踪治理。 4其他测试工具 除了上述的测试工具外，还有一些专用的测试工具，例如，针对数据库测试的TestBytes，对应用功能进展优化的EcoScope等工具。 （1）软件质量自动分析。通过软件度量反映了软件质量的根本方面，而且反映了面向对象软件的质量特征。使用这些软件质量度量，使得软件质量能够看得见，从而有利于进展软件的质量改良，加速软件的开发。 （2）系统流程分析。直截了当从

41、程序源代码产生逻辑流程图。 （3）自动生成测试文档。自动地分析程序源代码同时生成超过一百多种报告和图表，这些文档包括类的定义、构造、数据成员、成员函数、类的复杂性、类的调用、大小、类间耦合度、全局变量、静态变量、跳转标号、测试覆盖等。（4）测试用例生成分析，测试用例的自动回放。 7.2.3 参考答案 征询题1 （1）能够防止程序员的习惯性错误； （2）能够从不同角度考虑征询题； （3）有利于测试人员独立工作，杜绝人情关系； （4）有利于加强测试治理。 征询题2 （3）：白盒子方法指的是构造测试，黑盒子方法指的是功能测试。 （5）：测试结果不一定能呈现“可再现性”，例如，与时间有关的错误。 征询题3 （1）软件质量自动分