软件工程题库考试Word格式.docx
《软件工程题库考试Word格式.docx》由会员分享，可在线阅读，更多相关《软件工程题库考试Word格式.docx（49页珍藏版）》请在冰豆网上搜索。
配置管理是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。
配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
9.信息聚合
10.组件图
组件图是用来反映代码的物理结构。
从组件图中，您可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。
使用组件图可以将系统划分为内聚组件并显示代码自身的结构。
11.条件覆盖
条件覆盖是指选择足够的测试用例，使得运行这些测试用例后，要使每个判断中每个条件的可能取值至少满足一次，但未必能覆盖全部分支。
12.软件危机
随着计算机硬件技术的进步，要求软件能与之相适应。
然而，软件技术的进步一直未能满足形势发展提出的要求，致使问题堆积起来，形成日益尖锐的矛盾，最终导致了软件危机。
13.配置项
凡是纳入配置管理范畴的工作成果都是配置项；
一个纯软件的CIs通常也称为软件配置。
14.数据聚合
15.活动图
活动图是阐明了业务用例实现的工作流程。
业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。
业务用例由一系列活动组成，它们共同为业务主角生成某些工件。
工作流程通常包括一个基本工作流程和一个或多个备选工作流程。
工作流程的结构使用活动图来进行说明。
16.路径覆盖
路径覆盖要求设计足够多的测试用例，在白盒测试法中，覆盖程度最高的就是路径覆盖，因为其覆盖程序中所有可能的路径。
17.软件生存周期
软件生存周期又称为软件生命期，生存期。
是指从形成开发软件概念起，所开发的软件使用以后，直到失去使用价值消亡为止的整个过程。
18.基线
基线是软件文档或源码（或其它产出物）的一个稳定版本,它是进一步开发的基础。
基线是项目储存库中每个工件版本在特定时期的一个“快照”。
它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。
建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
19.控制耦合
如果一个模块通过传送开关、标志、名字等控制信息，明显地控制性选择另一模块中的功能，就是控制耦合。
20.协作图
协作图（也叫合作图）是一种交互图，强调的是发送和接收消息的对象之间的组织结构。
一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。
对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。
使用协作图来说明系统的动态情况。
协作图使描述复杂的程序逻辑或多个平行事务变得容易。
协作图显示某组对象如何为了由一个用例描述的一个系统事件而与另一组对象进行协作的交互图。
21.条件组合覆盖
在白盒测试法中，选择足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。
显然，满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的。
22.软件过程
是软件生存期中的一系列相关软件工程活动的集合。
每个软件过程是由一组工作任务、项目里程碑、软件工程产品和交付物、质量保证点等组成。
23.里程碑
里程碑一般是项目中完成阶段性工作的标志，标志着上一个阶段结束、下一个阶段开始，将一个过程性的任务用一个结论性的标志来描述，明确任务的起止点。
一系列的起止点就构成了引导整个项目进展的里程碑。
里程碑定义了当前阶段完成的标准和下一新阶段启动的条件和前提。
24.标记耦合
标记耦合指两个模块之间传递的是数据结构,如高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个数据结构的地址。
25.时序图
时序图，亦称为序列图或循序图，是一种UML行为图。
它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。
它可以表示用例的行为顺序，当执行一个用例行为时，时序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。
26.等价类划分
等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。
然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。
利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。
等价类划分法是一种系统性的确定要输入的测试条件的方法。
27.软件基本过程
28.项目范围管理
项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。
它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：
确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。
29.数据耦合
数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递。
一个模块访问另一个模块时，彼此之间是通过简单数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的。
30.状态图
状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。
通常我们创建一个UML状态图是为了以下的研究目的：
研究类、角色、子系统、或组件的复杂行为。
31.边界值测试
人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。
通常输入等价类与输出等价类的边界，就是应着重测试的边界情况。
应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。
32.软件支持过程
33.项目整体管理
项目整体管理，一方面体现完整和善始善终的意思，所以整体管理是唯一贯穿启动到收尾所有过程组的知识体系，从项目启动到项目收尾项目整体管理都得管，对于微型项目来讲，其它项目知识体系或过程组都可以裁剪，但整体管理则是最小的过程集，每一个过程都项目来讲都非常重要；
其二取整合之意，主要是资源的整合，干系人的整合,对其它项目过程组的整合，项目四要素的整合。
34.预防性维护
为了降低设备失效或功能退化的概率，按预定的时间间隔或规定的标准进行的维护。
35.对象图
对象图是显示了一组对象和他们之间的关系。
使用对象图来说明数据结构，类图中的类或组件等的实例的静态快照。
对象图和类图一样反映系统的静态过程，但它是从实际的或原型化的情景来表达的。
对象图显示某时刻对象和对象之间的关系。
36.基本路径测试
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。
设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。
37.软件组织过程
38.软件度量
软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。
39.适应性维护
为使软件产品在改变了的环境下仍能使用而进行的维护。
40.类图
类图是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
类图不显示暂时性信息。
41.黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
42.过程框架
43.功能点分析
44.结构化程序设计
结构化程序设计是进行以模块功能和处理过程设计为主的详细设计的基本原则。
它的主要观点是采用自顶向下、逐步求精及模块化的程序设计方法；
使用三种基本控制结构构造程序，任何程序都可由顺序、选择、循环三种基本控制结构构造。
结构化程序设计主要强调的是程序的易读性。
45.用例图
用例图是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
46.白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
47.软件能力成熟度模型
CMM。
它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
48.工作分解结构
工作分解结构（WBS）：
以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
无论在项目管理实践中，还是在PMP考试中，工作分解结构（WBS）都是最重要的内容。
WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。
WBS同时也是控制项目变更的重要基础。
项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
49.非功能性需求
所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。
软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。
50.统一建模语言UML
它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。
51.单元测试
集中对用源代码实现的每个程序单元进行测试，检查各个模块是否正确地实现了规定的功能。
52.个体软件过程
就是为使软件工程师更好地工作而设计的一个框架，它指出如何估计和计划工作，如何按照这些计划来跟踪自己的性能，以及如何提高程序的质量。
53.COCOMO模型
构造性成本模型，它是在静态、单变量模型的基础上构造出来的。
它是一种精确、易于使用的，基于模型的成本估算方法。
54.信息隐蔽
信息隐蔽指在设计和确定模块时,使得一个模块内包含信息（过程或数据）,对于不需要这些信息的其他模块来说,是不能访问的。
在面向对象方法中，信息隐蔽是通过对象的封装性来实现的。
信息隐蔽的概念与模块的独立性直接相关。
55.面向对象
首先根据客户需求抽象出业务对象；
然后对需求进行合理分层，构建相对独立的业务模块；
之后设计业务逻辑，利用多态、继承、封装、抽象的编程思想，实现业务需求；
最后通过整合各模块，达到高内聚、低耦合的效果，从而满足客户要求。
56.集成测试
根据软件设计规定的软件体系结构，把已测试过的模块组装起来，在组装时，检查程序结构组装的正确性。
57.团队软件过程
团队软件过程是为开发软件产品的开发团队提供指导，TSP的早期实践侧重于帮助开发团队改善其质量和生产率，以使其更好的满足成本及进度的目标。
加上PSP帮助高绩效的工程师在一个团队中工作，来开发有质量保证的软件产品，生产安全的软件产品，改进组织中的过程管理。
58.项目计划评审技术
计划评审技术就是工程项目当作一种系统，用网络图或者表格或者矩阵来表示各项具体工作的先后顺序和相互关系，以时间为中心，找出从开工到完工所需要时间的最长路线，并围绕关键路线对对系统进行统筹规划，合理安排以及对各项工作的完成进度进行严密的控制，以达到用最少的时间和资源消耗来完成系统预定目标的一种计划与控制方法。
59.内聚
内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。
60.主动对象
主动对象内部包含一个线程，可以自动完成动作或改变状态。
主动对象是内部拥有自己的控制线程的对象。
61.确认测试
检查已实现的软件是否满足了需求规格说明中所确定的各种需求，以及软件配置是否完全、正确。
（过程：
功能性测试---软件配置复查---验收测试----α测试和β测试）
62.过程模式
63.RMMM计划（RiskMitigation,MonitoringandManagementPlan）
64.耦合
耦合是模块之间的相对独立性（互相连接的紧密程度）的度量。
65.多态性
同一操作作用于不同的类的实例，将产生不同的执行结果，即不同类的对象收到相同的消息时，得到不同的结果。
对象根据所接受的消息而做出动作，同样的消息被不同的对象接受时可能导致完全不同的行为，这种现象称为多态性。
66.系统测试
是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外部设备、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。
67.统一过程
是软件工程的过程。
它提供了在开发组织中分派任务和责任的纪律化方法。
它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。
统一过程模型是一种“用例驱动，以体系结构为核心，迭代及增量”的软件过程框架，由UML方法和工具支持。
68.软件质量
与软件产品满足规定的和隐含的需求的能力有关的特性或特性的全体。
或“所有描述计算机软件优秀程度的特性的组合。
”
69.体系结构
体系结构包括一组部件以及部件之间的联系。
70.消息
消息，软件对象之间进行交互作用和通讯是利用消息的。
在面向对象的程序设计中，消息是指一个类实例和另一个类实例之间传递的信息。
71.压力测试
在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
72.瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
瀑布模型核心思想是按工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
73.结构复杂性度量
74.决策表
决策表又称判断表，是一种呈表格状的图形工具，适用于描述处理判断条件较多，各条件又相互组合、有多种决策方案的情况。
精确而简洁描述复杂逻辑的方式，将多个条件与这些条件满足后要执行动作相对应。
但不同于传统程序语言中的控制语句，决策表能将多个独立的条件和多个动作直接的联系清晰的表示出来。
75.继承
继承是指一个对象直接使用另一对象的属性和方法。
76.测试配置
77.快速原型模型
快速原型模型又称原型模型，它是增量模型的另一种形式；
它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。
通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；
第二步则在第一步的基础上开发客户满意的软件产品。
78.文本复杂性度量
79.数据字典
精确地、严格地定义了每个与系统相关的数据元素，并以字典式顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。
80.封装
隐藏对象的属性和实现细节，仅对外公开接口,控制在程序中属性的读和修改的访问级别。
封装就是将抽象得到的数据和行为（或功能）相结合，形成一个有机的整体，也就是将数据与操作数据的源代码进行有机的结合，形成“类”，其中数据和函数都是类的成员。
81.静态测试
1、静态测试是指无须执行被测代码，而是借助专用的软件测试工具评审软件文档或程序，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。
2、静态测试是指测试不运行的部分：
只是检查和审阅,如规范测试、软件模型测试、文档测试等。
动态测试是通常意义上的测试，也就是运行和使用软件。
3、通过评审文档、阅读代码等方式测试软件称为静态测试，通过运行程序测试软件称为动态测试。
在动态测试中，通常使用白盒测试和黑盒测试从不同的角度设计测试用例，查找软件代码中的错误。
4、静态测试是指不用执行程序的测试，它主要采取方案—代码走查、技术评审、代码审查的方法对软件产品进行测试。
（t）称为：
时刻的瞬时利息率（是无风险利率）。
82.增量模型
增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。
早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。
83.软件可靠性
（1）在规定的条件下，在规定的时间内，软件不引起系统失效的概率。
（2）在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。
其中的概率是系统输入和系统使用的函数，也是软件中存在的故障的函数，系统输入将确定是否会遇到已存在的故障（如果故障存在的话）。
84.上下文数据流图
85.对象/类
类是对象的抽象，而对象是类的具体实例。
类是抽象的，不占用内存，而对象是具体的，占用存储空间。
86.动态测试
所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。
目前，动态测试也是公司的测试工作的主要方式。
87.螺旋模型
对于复杂的大型软件，开发一个原型往往达不到要求。
螺旋模型将瀑布模型与演化模型结合起来，并且添加两种模型均忽略的风险分析。
螺旋模型沿着螺线旋转，分4个方面的活动：
制定计划、风险分析、实施工程、客户评估。
沿螺旋线自内向外每旋转一圈，便开发出一个更为完善的、新的软件版本。
88.错误播种（植入）模型
89.数据流图
数据流图：
简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
90.静态视图
是因为它不描述与时间有关的系统行为，此种行为在其他视图中进行描述。
静态视图主要是由类及类间相互关系构成，这些相互关系包括：
关联、泛化和各种依赖关系，如使用和实现关系。
91.Beta测试
Beta测试由软件的最终用户们在一个或多个客房场所进行。
与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。
用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。
接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
92.极限编程
极限编程是一个轻量级的、灵巧的软件开发方法；
同时它也是一个非常严谨和周密的方法。
它的基础和价值观是交流、朴素、反馈和勇气；
即，任何一个软件项目都可以从四个方面入手进行改善：
加强交流；
从简单做起；
寻求反馈；
勇于实事求是。
XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；
通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
93.软件质量模型
94.业务流程图
业务流程图是一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表，利用它可以帮助分析人员找出业务流程中的不合理流向，它是物理模型。
业务流程图主要是描述业务走向。
业务流程图描述的是完整的业务流程，以业务处理过程为中心，一般没有数据的概念。
95.动态视图
96.因果图
鱼骨图也称为因果分析图或石川图。
它看上去有些象鱼骨，问题或缺陷（即后果）标在"
鱼头"
外。
在鱼骨上长出鱼刺，上面按出现机会多寡列出产生生产问题的可能原因。
鱼骨图有助于说明各个原因之间如何相互影响。
它也能表现出各个可能的原因是如何随时间而依次出现的。
这有助于着手解决问题。
97.过程规范
98.基于时间的缺陷到达模式
99.过程模型
所谓软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。
对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。
一个错误模型的选择，将迷失我们的开发方向。
100.领域分析
1.论述面向对象方法对传统方法的优势和问题
答：
面向对象方法（Object-OrientedMethod）是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO（Object-Oriented）方法，是建立在“对象”概念基础上的方法学。
对比传统方法，它的优点是：
所开发的程序是面向对
升级会员 