全国计算机等级考试 四级_2017年全国计算机等级考试四级纲要辅导4

黑盒测试是根据规格说明所规定的功能来设计测试用例，它不考虑程序中的内部结构和处理过程。常用的黑盒测试技术有等价类划分、边值分析、错误猜测等。

1.等价类划分

前面已经讲过，不能穷举所有可能的输入数据来进行测试，所以只能选取少量有代表性的输入数据，来揭露尽可能多的程序错误。这里首先要介绍一个有效的输入数据和无效的输入数据。有效的输入数据是指符合规格说明要求的合理的输入数据，它主要用来检验程序是否实现了规格说明中的功能。无效的输入数据是指不符合规格说明要求的不合理或非法的输入数据，它主要用来检验程序是否做了规格说明以外的事。如果把所有可能的输入数据（有效的和无效的）划分成若干个等价类，那么可以合理地做出假定:如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误;反之，如果一个输入数据不能检测出某个错误，那么等价类中其他输入数据也不能发现这一错误（除非这个等价类的某个子集还属于另一等价类）。等价类划分方法首先把输入数据划分成若干个有效等价类和若干个无效等价类，然后设计测试用例覆盖这些等价类。来源：www.examda.com

2.边值分析

大量的实践说明，程序中在处理边界情况时出错的概率比较大，因此设计一些测试用例，使程序运行在边界情况附近，这样揭露程序中错误的可能性就更大。所谓边界条件是指相对于输入与输出等价类直接在其边界上，或稍高于其边界，或稍低于其边界的这些状态条件。使用等价类划分方法设计测试用例时，原则上讲，等价类中的任一输入数据都可作为该等价类的代表用作测试用例。而边值分析则是专门挑选那些位于边界附近的值作为测试用例。由于边值分析方法所设计的测试用例，更有可能发现程序中的错误，因此经常把边值分析方法与其他设计测试用例方法结合起来使用。

3.错误猜测

错误猜测是一种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例的方法。这种方法没有机械的执行步骤，主要依靠直觉和经验。

四、软件维护

软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期，它是在软件交付使用后，为了改正软件中隐藏的错误，或者为了使软件适应新的环境，或者为了扩充和完善软件的功能或性能而修改软件的过程。一个软件的开发时间可能需要一两年，但它的使用时间可能要几年或几十年，而整个使用期都可能需要进行软件维护，所以软件维护的代价是很大的，而且维护的代价还在逐年上升，据1994年Software Engineering Encyclopedia记载，在整个软件生存周期所花费的代价中，20世纪80年代末用于软件维护的代价约为75%到90年代初为90%。因此，如何提高软件维护的效率、降低维护的代价成为十分重要的问题。

（一） 软件维护的分类

根据引用软件维护的原因，软件维护通常可分成改正性维护、适应性维护、完善性维护、预防性维护。

1.改正性维护

由于程序正确性证明尚未得到圆满的解决，软件测试又不可能找出程序中的所有错误，因此，在交付使用的软件中都可能隐藏着某些尚未被发现的错误，而这些错误在某种使用环境下会暴露出来。改正性维护就是在使用过程中发现了隐藏的错误后，为了诊断和改正这些隐藏错误而修改软件的活动。

2.适应性维护

由于计算机的发展非常迅速，新的机型、新的操作系统、新的软件系统不断地涌现，为了适应计算机的飞速发展，可能要更正在运行的软件的运行环境，如新的机型、数据库管理系统等。适应性维护就是为了适应变化了的环境而修改软件的活动。

3.完善性维护

用户在使用软件的过程中，随着业务的发展，常常希望扩充原有软件的功能，或者希望改进原有的功能或性能，以满足用户的新要求，完善性维护就是为了扩充或完善原有软件的功能或性能而修改软件的活动。

4.预防性维护

软件维护活动主要是上述三类维护，另有一类维护称为预防性维护，它是为了提高软件的可维护性和可靠性，为未来的进一步改进打下基础而修改软件的活动。据有关资料统计，在整个软件维护活动中，改正性维护约占20%，适应性维护约占25%，完善性维护约占50%以上，其他维护约占4%。

（二） 与软件维护有关的问题

软件维护人员通常不是该软件的开发人员，这给软件维护带来很大的困难，特别是有些软件在开发时没有遵循软件开发的准则，没有开发方法的支持，维护这样的软件就更困难。下面列举一些与软件维护有关的问题。

（1）要维护一个软件，首先要理解它。而理解别人的程序通常是非常困难的，尤其是对软件配置（指各种文档）不齐的软件，理解起来更为困难。

（2）需要维护的软件往往缺少合格的文档，或者文档资料不齐，甚至没有文档。在软件维护中，合格的文档十分重要，它有助于理解被维护的软件。合格的文档不仅要完整正确地反映开发过程各阶段的工作结果，而且应该容易理解并应程序源代码一致。而错误的文档会把对程序的理解引入歧途。

（3）在软件维护时，不要指望得到原来开发该软件的人员的帮助。开发人员开发完一个软件后，往往去从事另一软件的开发，甚至已调离开发单位。即使原先的开发人员还在，也可能因为相隔时间太久而遗忘了实现的细节。

（4）多数软件在设计时没有考虑今后的修改，给软件的修改带来困难，而且在修改软件时容易带来新的差错。对那些缺乏模块独立性和非结构化的程序来说，更是如此。

（5）软件维护通常不是一件吸引人的工作。从事维护工作常使维护人员感到缺乏成就感。这也严重影响维护工作。从而导致维护质量的不高。可以看出，上述的有些问题都与被维护的质量密切相关，所以在开发软件时，要认真写好各类文档，并且应注意提高软件的可维护性，这样可在很大程序上缓解软件维护的困难。

（三） 可维护性软件可维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件可维护性的因素有可理解性、可测试性和可修改性。

1.可理解性

2.可测试性

可测试性是指测试和诊断软件（主要指程序）中错误的难易程度。测试主要是发现软件中的错误，而诊断错误的性质和出错的位置通常是调试的任务。提高软件可测试性的措施有:书写详细正确的文档，采用良好的程序结构，使用测试工具和调试工具，保存以前的测试过程和测试用例等等。

3.可修改性

可修改性是指修改软件（主要指程序）的难易程度。在修改程序时经常会发生这样的情况:修改程序中某个错误的同时又产生新的错误（由程序的修改引起的），或者在程序中增加了某个功能的同时，原先的某些功能不能正常执行。这主要是因为程序中各成分之间存在着许多联系，当程序中某处修改时，这个修改可能会影响到程序的其他部分。如果修改程序时稍有考虑不周，就会出现上述顾此失彼的情况。因此，如果一处修改所涉及到的范围越少，发生上述情况的概率也越小，其可修改性也越好。在软件设计中我们介绍的那些设计准则都是影响可修改性的因素，如信息隐蔽原则、模块独立、模块间联系的低耦合高内聚等等。

（四） 软件维护活动流程

凡是需要软件维护，都应有一个软件维护的申请报告。改正性维护的申请报告应完整地描述导致错误的环境，包括输入数据、错误清单以及有关的材料。适应性维护或完善性维护的申请报告应提供一份简短的需求说明书。维护申请书由维护管理员和系统管理员审批。并指明所需修改的性质，申请修改的优先级，所需的工作量等。维护活动的第一步是确定维护的类型，若是改正性维护，则要估计错误的严重程度，对严重的错误，则马上分派人员执行维护任务;对不严重的错误，则可将其暂时保存，在以后适当时候再进行改正。若是适应性维护或完善性维护，则要根据其优先级来决定维护的先后次序，优先级高的维护则马上开始;优先级低的可暂时保存，以便统筹安排。适应性维护或完善性维护的过程相当于一个小的开发过程，它同样要经历需求分析、设计、编码、测试等阶段。不管是哪种维护，有些工作是每种维护活动都必须做的，如在修改程序代码的同时还要修改（如有必要）相应的需求说明文档、设计文档等，还要进行回归测试和软件配置复审等。

五、软件管理

软件工程项目高质量高效率的完成与其他产品的工程项目一样，不仅取决于所采用的技术、方法和工具，还决定于管理的好坏。两者相辅相成，缺一不可。就目前软件开发中的问题，更多的是管理问题。本节将集中讨论与管理方面有关的问题。

（一） 确定工作范围和资源

1.软件工作范围

软件计划的第一个任务就是确定软件的工作范围，即软件的用途及对软件的要求。其中主要包括软件的功能、性能、接口和可靠性等四个方面。计划人员必须使用管理人员和技术人员都能理解的无二义性的语言来描述工作范围。对于软件功能的要求，在某些情况下要进行求精细化，以便能够提供更多的细节，因为成本和进度的估算都与功能有关。软件的性能包括处理时间的约束、存储限制以及依赖于机器的某些特性。要同时考虑功能和性能，才能做出正确的估计。接口又可分为硬件、软件和人三类:

（1）硬件指执行该软件的硬件，如中央处理机和外部设备，以及由该软件控制的各种间接设备，如各种机器和显示设备等;

（2）软件指已有的而且必须与新开发软件连接的软件，如数据库、子程序包和操作系统等;

（3）人指通过终端或输入/输出设备使用该软件的操作人员。在这三种情况下，都要详细地了解通过接口的信息传递。计划人员还必须考虑各个接口的性质及复杂程度，以确定对开发资源、成本和进度的各种影响。

2.资源

（1）人员软件危机中提出的最严重的问题是缺少有经验的软件人员，人是软件开发的主要资源。这里所讨论的不是小项目，而是大项目，1、2个人是干不了的。在大项目的软件开发中，人员尤其重要。软件工程各个阶段对人员有不同的要求。开始时管理人员要用较多的精力，因为作为管理人员的决策，这时是很关键的，最后验收时也要投入较多的精力。高级技术人员同样如此。初级技术人员前期工作不多，在详细设计、编码和早期测试中参与最多，单元测试时为高峰。

（2）硬件硬件也是一种软件开发工具。硬件资源包括:

①宿主机宿主机是指在软件开发阶段使用的计算机和有关外部设备。对于一些专门的开发机构，为了能够接受更多的用户任务，并能方便地使用多种类型的开发支持工具，常备有专门的开发系统。目前很多微机都设置有单独的开发系统，而且进一步发展为专用的软件开发环境，这一部分将在第9章讨论。

②目标机运行所开发软件的计算机叫目标机，其中也包括有关的外部设备，在很多情况下，宿主机与目标机是统一的。

③其他硬件设备在进行专用软件的开发时，有时需要某些特殊的硬件资源，如开发过程控制软件时所需的A/D、D/A等专用设备。

（3）软件和硬件一样，也是一种软件开发工具。软件资源包括:

①支持软件包括范围广泛的各种工具。最基础的支持软件是操作系统、编译程序、数据库、图形包和网络软件等。它们是开发人员的必备工具。在软件生存期的各阶段还要有其它相应的支持软件:在需求分析阶段，有需求分析和生成程序;在设计阶段，有设计语言处理程序、流程图/框图生成程序和模拟程序;在编码和单元测试阶段，有动态调试程序、交叉汇编程序/编译程序和宏处理程序;在测试阶段，有测试驱动程序和测试结果分析程序等。恰当地使用支持软件，可以大大地提高软件开发的生产率和软件的质量。但是为了使支持软件能够在开发系统上运行，需要很大的工作量和费用，所以在考虑支持软件时，成本和效益两者之间的关系是一个必须考虑的重要问题。

②实用软件相当于软件库，可以结合到新的系统中去，如各种标准子程序等。实用软件现在应该说是非常丰富的，这是重用技术的基础。但重用技术的问题是如何选择重用对象、分类、建库，以及解决通用接口的机制问题，使其能适用于任一硬、软件环境。实用软件作为资源时，计划人员应认识到:如果现有软件符合要求，那么利用实用软件的费用几乎总是小于开发同等软件所需的费用;如果在与系统结合起来之前需要作某些修改，那就必须特别小心，因为修改现有软件所需费用有时会大于开发同等软件的费用。一般在计划阶段，软件资源常常被忽视，只有在开发阶段才成为头等大事。若能够及时地确定对软件资源的要求，则可以较好地对各种方案进行技术评价，并能尽早地获得所需的方案。

（二）成本估算

为了使开发项目能够在规定的时间内完成，而且不超过预算，成本估算的管理控制是关键。计算机广泛使用有35年，而高级语言应用仅30年。费用估算大约开始于50年代的第一个大型程序设计，60年代估算过于乐观，结果费用大大超支，70年代以后，费用估算才引起人们的普遍重视。由于影响软件成本的因素太多（如人、技术、环境以及政治因素等），直到最近，软件成本估算仍是一门很不成熟的技术，国外已有的技术只能作为我们的借鉴。

1.成本估算方法

有两种基本的估算方法:自顶向下和自底向上。自顶向下的方法是对整个项目的总开发时间和总工作量做出估算，然后把它们按阶段、步骤和工作单元进行分配。自底向上的方法则正好相反，分别估算各工作单元所需的工作量和开发时间，然后相加，就得出总的工作量和总的开发时间。两种方法都要求采用某种方法做出估算。有许多现成的方法可以利用，大致可分为三类:

（1）专家估算法;

（2）类推估算法;

（3）算式估算法。

（1）专家估算法这种方法依靠一个或多个专家，对要求

的项目做出估计，其精确性主要取决于两点，即专家对估算项目的定性参数的了解和他们的经验。后者类似于类推估算法。来源：www.examda.com

（2）类推估算法自顶向下的方法中，类推估算法是将估算项目的总体参数与类似项目进行直接相比得到结果。自底向上的方法中，类推是在两个具有相似条件的工作单元之间进行。

（3）算式估算法专家估算法和类推估算法的缺点在于，它们依靠带有一定盲目性的和主观的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响。用于估算的算式方法有两种基本类型:（1）由理论导出;（2）由经验得出。

2.成本估算模型

（1）IBM模型1977年Walston和Felix总结了IBM联合系统分部（FSD）负责的60个项目的数据。其中源代码从400到467000行，工作量从12到11758人-月，共使用29种不同语言和66种计算机。

（2）SLIM模型1979年前后，Putnam在软件开发生存期雷利（Rayleigh）曲线模型的基础上提出SLIM商业化的成本估算模型，SLIM基本估算算式为L=C k K 1/3 t 4/3d 其中:L和t d 分别表示可交付的源指令数和开发时间（单位以年计）;K是整个生存期内人的工作量（单位以人一年计），可从总的开发工作量ED=0.4K求得;C k 是根据经验数据确定的常数，表示了开发技术的先进性级别。如果软件开发环境较差（没有一定的开发方法，缺少文档和评审或批处理方式），取C k =6500;正常的开发环境（有适当的开发方法，较好的文档和评审，以及交互式的执行方式），C k =10000;而一个较好的开发环境（自动工具和技术），则取C k =12500。交换上式，可得开发工作量算式 K=L 3 C 3k t 4d 可从美国或英国买到SLIM计算程序，它除了提供开发时间和成本估算外，还提供关于风险、可行性、估算CPU时间需求及项目计划中其它有关信息。

（3）PRICE-S模型Freiman在1979年提出了另一个商业化的成本估算模型RCA PRICE-S。PRICE-S计算程序以一个未发表的启发式算法为基础，将若干成本因素作为输入，关键是生成源代码或目标代码指令的数量，然后输出成本和进度估算，以及其它可供选择的项目管理数据。另一个程序PRICE-SL可用于估算系统维护成本，根据若干个用户提供的参数，如软件的期望寿命、发展和使用率等，PRICE-SL运行时以PRICE-S的输出作为它的输入。

（4）COCOMO模型TRW开发的结构性成本模型COCOMO（Constructive Cost Model）是最精确、最易于使用的成本估算方法之一，1981年Boehm在他的著作中进行了详尽的描述。

（5）Belley-Basili元模型这种模型提供了最适用于在给定的开发环境中，工作量估算方程的开发方法。结果类似于IBM和COCOMO模型。

（6）Schneider模型上述所有模型完全是经验性的，1978年Schneider根据1977年Halstead的软件科学理论推导出几种估算方程，得到的工作量方程与幂定律算式形式相同。

3.代码行的成本估算方法

这是一种自底向上的估算方法，即从模块开始进行估算，步骤如下:

（1）确定功能首先将功能反复分解，直到可以对为实现该功能所要求的源代码行数做出可靠性的估算为止。对各子功能，根据经验数据或实践经验，可以给出极好、正常和较差三种情况下的源代码估算行数的期望值，分别用a、m、b表示。

（2）根据经验数据，确定各子功能的代码行成本

（3）计算各子功能的成本和工作量，并计算任务的总成本（元）和总工作量（人-月）

（4）计算开发时间

（5）对结果进行分析比较4.每项任务工作量的成本估算方法开发过程中，最常用的是每项任务工作量的成本估算方法。工作量可以用人-日、人-月或人-年的数量来表示。知道单位工作量的成本，就可得到估算成本。

下面仍以上节中的CAD软件包为例，估算步骤如下:

（1）确定任务 即每个功能都必须经过需求分析、设计、编码和测试工作

（2）确定每项任务的工作量，对每项任务要估算它们所需要的人-月数。

（3）找出与各项任务的对应的劳务费数据 即每个单位工作量成本（元/人-月）。因为各阶段的劳务费用不同，需求分析和概要设计阶段需要较多的高级技术人员;而详细设计、编码和早期测试则要求较多的初级技术人员。而他们的工资是不相同的。

（4）计算 计算各个工作各个阶段的成本和工作量，然后计算总成本和总工作量。

（5）分析比较 在整个开发工作量中，需求分析和设计用去了75人-月，约占全部分任务工作量的50%，说明了这项工作的重要性。劳务费反映了劳动者的成本，其中包括管理费。需求分析的劳务费（5200元/人-月）比设计、编码和单元测试都高，这也说明了这项工作的重要性。

本文来源：https://www.wddqw.com/JfGn.html