计算机软考软件设计师考前练习及答案.docx

计算机软考软件设计师考前练习及答案.docx

《计算机软考软件设计师考前练习及答案.docx》由会员分享，可在线阅读，更多相关《计算机软考软件设计师考前练习及答案.docx（87页珍藏版）》请在冰豆网上搜索。

计算机软考软件设计师考前练习及答案

软件自动化测试实例分析

　　软件测试是对创造力和智力非常有挑战性的任务。

测试一个大型软件需要的智能要超过设计这个程序的智能。

软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。

确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。

一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。

在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。

在这种情况下，软件的质量、性能和功能不可能得到保障。

此外，什么时候测试结束？

或是否要对该程序作进一步的测试？

对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。

　　项目测试管理

1.帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。

2.提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。

　　3.结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一　　软件测试是对创造力和智力非常有挑战性的任务。

测试一个大型软件需要的智能要超过设计这个程序的智能。

软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。

确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。

一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。

在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。

在这种情况下，软件的质量、性能和功能不可能得到保障。

此外，什么时候测试结束？

或是否要对该程序作进一步的测试？

对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。

　　项目测试管理

1.帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。

2.提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。

　　3.结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一手信息。

　　测试计划

软件系统不仅变得越来越庞大，但是也变得越来越复杂。

复杂的代码是很难阅读、理解和修改的；必须化更多的精力去测试、维护和再测试。

测试复杂性分析能帮助软件工程师容易并精确地去计划他们的测试活动。

提供系统级复杂性分析和过程级复杂性分析去精确地测量复杂性，帮助工程师更好地计划他们的测试活动。

帮助工程师更好估计和使用测试复杂性度量，为满足不同层次的测试覆盖的要求，必需提供：

块测试复杂性、分支测试复杂性、段测试复杂性、条件-判定测试复杂性、条件-段测试复杂性。

测试复杂性的值取决于用于记录对应的测试覆盖数据的插装点的点数。

手信息。

测试用例管理

　　1.OO-Test提供了在国内外市场上最全面的测试覆盖分析能力，去满足不同的测试覆盖需求：

　　●类的测试覆盖

　　●函数的测试覆盖

　　●块的覆盖

　　●循环边界的覆盖

　　●分支的覆盖

　　●段的覆盖

　　●条件（判定）的覆盖

　　●段--条件的覆盖

　　2．TCA能确定每一个测试用例作用的范围，通过给出的测试用例就能确定被测试的类，或函数，或段。

这种功能对于评估测试用例的效率，和对于修改以后指定的类或函数或段的再测试是非常有用的。

　　3．此外，TCA能从初始测试用例中自动地抽取最小测试用例集，并对基于类的、函数的、分支的、块的、段的覆盖等等各自分别进行划分。

它可以对系统级的再测试节省大量的时间和费用。

　　训练新成员

　　1.提供全面的静态和动态系统分析的能力，能抽取各种信息及自动生成系统文档，并且可以使被抽取的信息让新成员联机访问，大大的节省了设计人员和工程师的时间。

　　2.通过提供最新的和精确的各种系统概貌图和流程图（包括数据结构、类继承图、函数调用图和程序树），全局数据分析的详细报告，详细的程序逻辑图和源代码的控制流程图，帮助他们了解系统和深入地理解代码。

　　3.使用的GUI接口,使开发组的新成员容易自我训练；具有一个从顶层到详细的代码系统动态的和图形化的表达能力；具有链接不同层次的结构图和流程图在一起的能力。

　　4.提供基于函数分析和流程图化的能力与基于类分析和流程图化的能力，使得一个面向对象的系统很容易被透彻地了解。

　　单元测试的考虑单元测试是要检验程序最小单位（模块）有无错误，它是在编码完成后，首先要施行的测试工作。

一般由编码人员自己来完成，因而通常把单元测试看成是编码步骤的附属品。

单元测试大多从程序的内部结构出发设计测试用例，即采用白盒测试方法，多个程序模块可以并行地独立开展测试工作。

　　单元测试是针对每个程序模块，解决5个方面的问题：

模块接口、局部数据结构、边界条件、独立的路径和错误处理。

　　1.模块接口:

　　对模块接口的测试，是检查进出程序单元的数据流是否正确。

对模块接口数据流的测试必须在任何其他测试之前进行，因为如果不能确保数据正确地输入和输出的话，所有的测试都是没有意义的。

　　2.局部数据结构:

　　在模块工作过程中，必须测试其内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。

　　3.独立的路径:

　　在单元测试中，最主要的测试是针对路径的测试。

测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。

　　4.边界条件:

　　软件常常在边界地区发生问题。

　　5.错误处理:

　　测试出错处理的要点是模块在工作中发生了错误，其中的出错处理设施是否有效。

　　单元测试的过程

　　单元测试常常和代码编写同步进行，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。

在对每个模块进行单元测试时，不能完全忽视它们和周围模块的相互联系。

为模拟这一联系，在进行单元测试时，需设置若干辅助测试模块。

辅助模块有两种，一种是驱动模块（driver），用以模拟被测模块的上级模块。

驱动模块在单元测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。

另一种是桩模块（stub），用以模拟被测模块工作过程中所调用的模块。

桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。

　　驱动器和桩都是额外的开销，这两种模块虽然在单元测试中必须编写，但却不作为最终的软件产品提供用户。

如果驱动器和桩很简单的话，那么开销相对较低，然后，使用“简单”的模块是不可能进行足够的单元测试的，模块间接口的全面检验要推迟到集成测试时进行。

软件自动化测试流程

　　件自动化测试工具的软件测试流程，不仅仅包含完整的软件测试流程框架，同时还提供了内嵌软件测试流程的测试管理工具的支持，包括完整的测试评测方法。

　　1.软件自动化测试工具软件测试流程框架

　　软件自动化测试工具标准流程提供了一套完整的测试流程框架，软件测试团队可以以它为基础，根据业务发展的实际要求，定制符合团队使用的软件测试流程。

　　每个测试环节的具体阐述如下：

　　◆制定测试计划的目的是确定和描述要实施和执行的测试。

这是通过生成包含测试需求和测试策略的测试计划来完成的。

可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测试类型，也可以为每种测试类型制定一个测试计划。

　　◆设计测试的目的是确定、描述和生成测试过程和测试用例。

　　◆实施测试的目的是实施（记录、生成或编写）设计测试中定义的测试过程。

输出工件是测试过程的计算机可读版本，称为测试脚本。

　　◆执行测试的目的是确保整个系统按既定意图运行。

系统集成员在各迭代中编译并链接系统。

每一迭代都需要测试增加的功能，并重复执行以前版本测试过的所有测试用例（回归测试）。

◆评估测试的目的是生成并交付测试评估摘要。

这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。

测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。

　　2.软件自动化测试工具的评测方法

软件测试的主要评测方法包括测试覆盖和质量评测。

测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。

2.1覆盖评测

覆盖指标提供了“测试的完全程度如何？

”这一问题的答案。

最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。

简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

　　◆基于需求的测试覆盖

　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。

测试覆盖通过以下公式计算：

　　测试覆盖=T^（p,i,x,s）/RfT

其中：

T是用测试过程或测试用例表示的测试（Test）数（已计划的、已实施的或成功的）。

RfT是测试需求（RequirementforTest）的总数。

　　◆基于代码的测试覆盖

　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。

代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。

基于代码的测试覆盖通过以下公式计算：

　　测试覆盖=I^e/TIic

其中：

I^e是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。

TIic（TotalnumberofItemsinthecode）是代码中的项目总数。

　　2.2质量评测

　　测试覆盖的评估提供对测试完全程度的评测，对在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。

因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

　　◆缺陷报告

　　一般，可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。

这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

　　◆性能评测

　　评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。

这些评测主要在“评估测试”活动中进行评估，但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。

　　主要的性能评测包括：

　　◆动态监测-在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

　　◆响应时间/吞吐量-测