选择题考点

软件架构风格：
是指描述特定领域软件的组织方式和惯用模式。
集成开发环境与用户的交互方式、集成开发环境的扩展性、集成开发环境的数据管理阐述
组织方式：描述了系统组成构件和这些构件组织的方式
惯用模式：则反映了众多系统共有的结构和语义

从集成开发环境与用户交互方式看，用户通常采用交互的方式对脚本进行编辑、解释执行与调试。
在这种情况下，采用以数据存储为中心的软件架构风格能够很好地支持交互式数据处理，而管道-过滤器风格则对用户的交互式数据处理支持有限。

从集成开发环境的扩展性来看，系统核心需求要求实现各种编辑、语法检查、解释执行等多种功能的灵活组织、配置与置换。

在这种情况下，采用以数据为中心的架构风格、以数据格式解耦各种功能之间的依赖关系，并可以灵活定义功能之间的逻辑顺序

管道-过滤器架构风格同样以数据格式解耦数据处理过程之间的依赖关系，但其在数据处理逻辑关系的灵活定义方面较差。

从集成开发环境的数据管理来看，集成开发环境需要支持脚本语言、语法树（用于检查语法错误）、可视化模型、调试信息等多种
数据模型，并需要支持数据格式的转换。

以数据存储为中心的架构将数据在统一的中心存储器中，中心存储器能够表示多种数据格式，并能够为数据格式转换提供各种支持。、

管道-过滤器架构风格通常只能支持有限度的数据格式并在数据格式转换方面灵活性较差。

软件架构设计的核心问题是能否使用重复的软件架构模式，能否达到架构级别的软件重用。

软件架构风格：
    描述某一特定应用领域中系统组织方式的惯用模式（Idiomatic paradigm）。
    架构风格定义了一个系统家族，一个架构定义一个词汇表和一组约束。
    词汇表中包含一些构件和连接件类型，组约束指出系统如何将这些构件和连接件组合起来。
    架构风格反映了领域中众多系统所共有的结构和语义特性，指导如何将各个模块和子系统有效地组织成一个完整的系统。
    按照这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

讨论架构风格时要回答的问题是：

 
数据流风格

批处理的风格的每一步处理都是独立的，并且每一步都是顺序执行的，只有当前一步处理完，后一步处理才能开始。
数据传输在步与步之间作为一个整体。（组件为一些列固定顺序的计算单元，组件间通过数据传递交互。每个处理步骤是一个独立的程序，
每一步必须在前一步结束后才能开始）数据必须是完整的，以整体的方式传递  
-----应用 1.经典数据处理，2.程序开发，3windows下的BAT程序就是这种应用的典型实例。

管道-过滤器
在管道-过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出流。这个过程通常通过对输入流的变换及增量计算来完成，
所以在输入被完全消费之前，输出便产生了。这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤的输出传到另一个过滤器的输入。
此风格的特别重要的过滤器必须是独立

2）集成开发环境需要提供一组可视化的编程界面，用户通过对界面元素拖拽和代码填充的方式就可以完成功能插件核心业务流程的编写与组织。

3）在代码调试功能方面，集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能。具体来说，早调试过程中，编辑界面需要想用调试断点命中事件，并自动跳转到当前断点处所对应的代码。

1.
面向对象架构风格的特征是将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身表示的完整性，
对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，对象之间的协作完成计算过程。

控制环路架构风格是将过程输出的指定属性维护在一个特定的参考价值（设定点）。控制环路风格包括过程变量、被控变量、输入变量、操纵变量、和设定点等构件。
通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态。

2.对于系统的增减速功能面采用面向对象风格的巡航控制系统首先会定义司机、油门、时钟、速度和车轮等构件。
整个计算过程：
    ①司机进行增/减速操作设置期望速度，该期望速度以消息的形式传递给速度计。
    ②速度计通过向车轮和时钟发送消息获取消息获取车轮转速和时钟值得到当前速度。
    ③速度计用来计算当前速度和期望速度的速度差值
    ④该差值以消息的形式发送给油门，油门通过速度差值调节自身状态。
    ⑤整个过程在时钟的控制下定期向速度计发送消息，重复执行2-4
控制环路的架构风格以控制器为核心，期望速度，车轮脉冲、时钟和油门等作为构件
    ①司机进行增/减速操作设置期望速度值
    ②将设定值置为期望速度值
    ③
    ④
    ⑤

        
需求跟踪包括编制每个需求与系统元素之间的联系文档，这些元素跟包括别的需求、体系结构、其他设计部件、
源代码模块、测试、帮助文件和文档等、跟踪能力信息使变更影响分析十分便利，有利于确认和
评估实现某个建议的需求变更所必须的工作。

利用需求跟踪能力链，可以跟踪一个需求使用的全过程，也就是从初始需求到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征，
为了实现跟踪能力必须统一地表示出每一个需求，以便能明确地进行查阅。

客户需求向前追溯到软件需求。这样就能区分开发过程中或者开发结束后，由于客户需求变更受到影响的软件需求，
这也就可以确保软件需求规格说明包括了所有客户需求。从软件需求回溯到客户需求。这也就是确认每个软件需求的源头，
如果使用实例的形式来描述客户需求，那么客户需求与软件需求之间的跟踪情况就是使用实例和功能性需求。

从软件需求向前追溯到下一集工作产品。由于开发过程中系统需求转变为软件需求、设计、编码等，
所以通过定义单个需求和特定的产品元素之间的（联系）链，可以从需求向前追溯到下一级工作产品、
这种联系链告诉我们每个需求对应的产品部件，从而确保产品部件满足每个需求。

从产品部件追溯到软件需求。说明了每个部件存在的原因。如果不能把设计元素，代码段或测试回溯到一个需求，可能存在"多余"
的程序，这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求

客户需求---------------->软件需求----------->下一集工作产品

两种常用的需求定义方法：严格定义方法和原型方法

严格定义方法（预先定义），需求的严格定义建立在以下基本假设之上：
1、所有需求都能够背预先定义，这意味着在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑判断得到。
   但这种假设在许多场合是不能成立
2.开发人员在用户之间能够准去而清晰地交流
3.采用图形（或文字）可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流与沟通的
  主要工具是定义报告，包括文字、图形、逻辑规则和数据字典等技术工具。

原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许在
开发过程中提出更好的需求，根据用户的需求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。
采用原型方法时的原则：
1.并非所有的需求都能在系统开发前被准去说明
2.项目干系人之间通常存在交流上的困难
3.需要实际的、可供用户参与的系统模型
4.有合适的系统开发环境
5.反复是完全需要和值得提倡的。需求一旦确定，就应该遵从严格定义的方法。

软件需求工程是包括创建和维护软件需求文档锁必须的一切活动的过程，可以分为需求开发和需求管理两大工作。

需求开发包括需求获取、需求分析、编写需求规格说明书（需求定义）和需求验证4个阶段。在需求开发阶段需要确定软件所期望的用户类型，
获取各种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务需求。

需求管理是一个对系统需求变更、了解和控制的过程，通常包括定义需求基线、处理需求变更和需求跟踪方面的工作。

需求管理强调：控制对需求基线的变动；保持项目计划与需求的一致。控制单个需求和需求文档的版本情况；
需求管理和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系。跟踪基线中的需求状态。

需求开发与需求管理是相辅相成的，需求开发是主线、目标；需求管理是支持、保障。

变更控制
 可以定义变更请求的数据项
 可以定义变更请求生存期的状态转换图
 可以加强状态转换图，是经授权的用户，仅能做出允许的状态变更
 记录每一种状态变更的数据，确认作出变更的人员
 可以定义在提交新请求或请求状态被更新后应自动通知的设计人员
 可以根据需要生成标准的或定制的报告和图标
 
过程能力成熟度模型()在软件开发机构中广泛用来知道软件过程改进。该模型描述了软件过程能力的5个成熟度级别，
每一级包含若干关键过程域（KPA）

CMM的第二级为可重复级，它包括了6个关键过程域，分别是：需求管理，软件项目计划‘软件项目跟踪和监督
软件分包合同管理、软件质量保证和软件配置管理。

需求管理的目标是微软件需求建立一个基线，提供给软件工程和管理使用：软件计划、产品和活动与软件需求保持一致。

需求变更策略：
1.所有需求变更必须遵循变更控制过程
2.对于未获得批准的变更，不应该做设计和实现工作
3.变更应该由项目变更控制委员会决定实现那些变更
4.项目风险承担者应该能够了解变更数据库的内容
5.决不能从数据库中删除或者修改变更请求的原始文档
6.每一个集成的需求变更能跟踪到一个核准的变更请求。

需求管理：是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出同时就启动了
需求管理计划，一旦形成了需求文档的初稿，需求管理活动就开始了。

需求管理过程域内的原则和策略
1.需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求
2.开发人员在客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件
3.关键处理领域建议通过版本控制和变更控制来管理需求文档

软件需求的基础知识
1完整性、
每一项需求都必须完整地描述即将交付使用的功能
2.正确性
每一项需求都必须正确正确地描述将要开发的功能
3.可行性
需求必须能够在系统及其运行环境的已知能力和约束条件内实现
4.必要性
每一项需求记录的功能都必须使用户的真正需要
5.无歧义
每一项需求声明对所有读者应该只有一种一致的解释
6.可验证性
如果某项需求不可验证，那么判定其实现的正确与否就成了主观臆断

--------------------------------------测试试题--------------------------------------

软件集成测试将已通过单元测试模块集成在一起，
组装策略可分为：一次性组装和增量式组装

集成测试计划通常是在软件概要设计阶段完成，集成测试一般采用黑盒测试方法

软件测试分类：单元测试、集成测试、配置项测试、系统测试、验收测试、回归测试

单元测试（模块测试），测试的对象是可独立编译或汇编的程序模块、软件构件或面向对象软件中的类
（统称为模块），目的是检查每个模块能否正确地事先设计说明中的功能、性能、接口和其他涉及约束等条件
发现模块内可能存在各种差错。

单元测试的技术依据是软件详细设计说明书。

集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求

集成测试的技术依据是软件概要设计文档

系统测试的对象是完整的，集成的计算机系统、系统测试的目标是在真实系统环境下，验证完整的软件配置项能否和系统
正确连接，并满足系统/子系统设计文档和软件开发合同规定 的要求。

系统测试的技术依据是用户需求和开发合同

配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与软件需求规格说明的一致性

验收测试是针对软件需求规格说明，在交付前以用户为主进行的测试。

回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的复合型，以及对软件原有的、正确的功能、
性能和其他规定的要求的不损害性。

静态测试方法知识点
静态测试知识被测试测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析手段对程序进行检测。
静态测试包括对文档的静态测试和对代码的静态测试。
对代码的静态测试包括：控制流分析，数据流分析，接口分析和表达式分析

1.控制流分析.控制流分析是指使用控制流程图检查，被测程序控制结构的过程。
例如，可检查被测程序是否存在没有使用的语句或子程序，是否待用并不存在的子程序，以及是否存在无法达到的语句等

2.数据流分析：数据流分析是指使用控制流程图分析数据各种异常情况的过程。包括数据初始化，数值或引用过程中的异常、

3.接口分析：接口分析主要包括模块之间接口的一致性分析、模块与外部数据库及其其他软件配置之间的一致性分析、子程序和
函数之间的接口一致性分析。例如可以检查函数形参与实现的数量、顺序、类型使用的一致性。

4.表达式分析。表达式分析用于检查程序代码的表达式错误。例如括号不配对、数组引用越界、除数为零、浮点数变量比较时误差等错误。

软件测试与调试之间的区别
软件测试在将软件交付给客户之间所必须完成的重要步骤。软件调试（排错）与成功的测试形影相随。

测试成功的标志是发现错误，根据错误迹象确定错误的原因和准确位置，并加以改正，主要依靠软件调试技术
软件调试与软件测试区别：
1.测试的目的是找出存在的错误，而调试的目的是定位错误修改程序以修正错误
2.调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同
3.测试从一个已知的条件开始，使用预先定义的过程，有预知的结果，调试从一个未知的条件开始，结束的过程不可预知。
4.测试过程可以实现设计，进度可以实现确定，而调试不能描述过程或持续时间。

单元测试的基本概念：
单元测试也是（模块测试），测试对象是可独立编程或汇编的程序模块，软件构件或面向对象软件中的类（统称为模块），
其目的是检查每个模块能否争取地实现设计说明中的功能，性能，接口和其他设计约束等条件，发现模块内存可能存在的各种差错

单元测试的技术一居室软件详细设计说明书

测试一个模块时，可能需要为该模块编写一个驱动模块和若干个模块。

驱动模块用来调用北侧模块，他接受测试者提供的测试数据，并发这些数据传送给北侧模块，然后从被测模块接收测试结果
并以某种可见的方式将测试结果返回给测试人员

桩模块用模拟测试被测模块所调用的子模块，它接受北侧模块的调用，检验调用参数，并以町能简单的操作模拟被调用的
子程序模块功能，把结果送回被测模块

顶层模块测试时不需要驱动模块，底层模块测试时不要桩模块。

单元测试策略主要包括自顶向下的单元测试，自底向上的单元测试、孤立测试和综合测试策略。

1.自顶向下的单元测试先测试上层模块，在测试下层模块。测试下层模块时由于它的上层模块臆测试过，
  所以不必另外编写驱动模块
2、自底向上的单元测试。自底向上的单元测试先测试下层模块，在测试上层模块。测试上层模块由于它的下层模块已经测试过了，所以不必另外编写桩模块
3、孤立测试不需要考虑每个模块与其他模块之间的关系，逐一完成所有模块的测试由于各模块之间不存在依赖性，单元测试可以并行进行，
   但因为需要为每个模块单独设计驱动模块和桩模块，增加了额外的测试成本
4.综合测试
  上述三种测试策略各有利弊，实际测试时可以根据软件特点和进度安排情况，将集中测试方法混合使用。

白盒测试:结构测试，主要用于软件单元测试阶段，测试人员按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路
是否都能按预定要求正确订做。百合测试方法主要有控制流测试，数据流测试和程序变异测试。

控制流测试根据程序的内部逻辑结构设计测试用例，常用的技术是逻辑覆盖。主要的覆盖标准语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖

语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测试程序的每个语句至少执行一次。

判定覆盖也称为分支覆盖，它是指不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。

条件覆盖是指不仅每个语句至少执行一次，而且是判定表达式中的每个条件都取得各种可能的结果。

条件/判定覆盖同时满足判定覆盖和条件覆盖

它的含义是选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身所有可能结果也至少出现一次

条件组合覆盖是指选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次

修正的条件/判定覆盖。需要足够的测试用例来确定各个条件能够影响到包含的判断结果。

路径覆盖是指选取足够的测试用例，使得程序的每条都可能执行到的路都至少经过一次（如果程序中有环路，
则要求每条环路路径至少经过一次）

黑盒测试（功能测试）主要用于集成测试、确认测试和系统测试阶段。黑盒测试根据软件需求规格说明所规定的功能来设计用例，
一般包括功能呢个分析、等价类划分、边界值分析、判定表、因果图、状态图、随即测试、错误推断和正交试验

在设计测试用例是，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对每一个输入条件确定若干
有效等价类和若干无效等价类，分别设计覆盖有效等价类和无效等价类的测试用例。

无效等价类是用来测试非正常的输入数据的，所以要为每个无效等价类设计一个测试用例。

边界值分析通过选择等价类边界作为测试用例，不仅重视输入条件边界而且也必须考虑输出域边界。在实际测试工作中，
将等价类划分方法和边界值分析结合使用能有效地发现软件中的错误

因果图方法是从自然语言书写的程序规格说明的描述中找出（输入条件）因果（输出或程序状态的改变）可以通过因果图转换为判定表

正交实验设计方法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率

静态分析包括五个阶段：控制流分析阶段找出并突出显示那些带有多重出口或入口的循环以及不可达的代码段；数据使用分析
阶段突出程序中变量的使用情况；
接口分析阶段检查子程序和过程声明及他们使用的一致性；信息流分析阶段找出输入变量和输出变量之间的依赖关系；路径分析阶段
找出程序中所有肯能的路径并画出再次路径中执行的语句

确认测试：1.内部确认测试 2.α测试（用户在开发环境下进行测试），β测试（用户在实际使用的环境下进行测试）
      3.待验收测试。验收测试是指针对软件爱你需求规格说明书，在交付前以用户为主进行的测试。

测试对象的完整、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件爱你系统是否满足开发技术
合同或软件需求规格说明书。验收测试的结论是用户确定是否接收该软件的主要依据。

系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发
合同规定要求。

系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试。其中
性能测试包括负载测试、压力测试、可靠性测试和并发测试。

系统测试根据系统方案说明书来设计测试用例，常见的系统测试主要由恢复测试、安全测试、压力测试、性能测试
可靠性测试、可用性测试、可维护性测试和安装测试

基准测试：运行一个标准程序对多种计算机系统进行检验，以比较和评价他们的性能。

确认测试称为有限性测试：软件功能、性能及其它特性是否与用户需体一致。分类：内部测试、Alpha、Beta和验收测试

实际上Java IDL 即idl to java 编译器就是一个ORB，可以用来在Java语言中定义，实现和访问Corba对象，Java IDL支持的
是一个瞬间的Corba对象，即在对象服务器处理过程中有效。

实际上，Java IDL的ORB 是一个类库而已，并不是一个完整的平台软件，但是它对Java IDL 应用系统和其他CORBA应用系统
之间提供了很好的底层通信支持实现了OMG定义的ORB基本功能。

--------------------------------------------------------系统运行与维护--------------------------------------------------------------------
1.改正性维护，为了识别和纠正软件错误，改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的国策和那个为改正性维护。
2.适应性维护，在使用过程中，外部环境（新的硬软件配置）、数据环境【数据库、数据格式、数据输入/输出方法、数据存储介质】可能发生变化。
  为使软件适应这种变化而修改软件的过程称为（软硬件升级）
3.完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求，为了满足这些要求，需要修改或再开发软件，以扩充软件功能，增强
  软件性能、改进加工效率、提高软件的可维护性。
4.预防性维护。 指预先提高软件的可维护性、可靠性等为以后进一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的软件或软件中
  的某一部分（重新）进行设计、编码和测试。

---------------------------------------------------------信息化方面的基础值---------------------------------------------------------------
ERP 是信息化三流:信息流，资金流，物流

ERP系统中，库存管理（Inventory management） 模块主要是对企业无聊的进、出、存、进行管理。

供应链中的信息流覆盖了从供应商、制造商到分销商、再到零售商等供应链中的所有环节，其信息流分为需求信息流供应信息流

需求信息流【客户订单、生产计划、采购合同】从需求方向供方流动时，便引发物流。
供应信息（入库单、完工报告单、库存记录、可供销售量和提货发运单）同物料一起沿着供应链从供方向需方流动。