软考软件工程&结构化开发复习指南

Posted 2021-12-05 小哈里

1、根据考纲

根据考纲：

软件工程：
（1）软件工程知识：软件生存周期与软件生存周期模型、软件开发方法、软件开发项目管理、
软件开发工具与软件开发环境。
（2）系统分析基础知识：系统分析的主要步骤、机构化分析方法。
（3）系统设计基础知识：概要设计与详细设计的基本任务、系统设计的基本原理、系统模块结
构设计、结构化设计方法、面向数据结构的设计方法、系统详细设计。
（4）系统实施基础知识：系统实施的基本内容、程序设计方法、程序设计的基本模块、系统测
试、系统转换。
（5）系统运行和维护基础知识：系统可维护性的概念、系统维护的类型、系统评价的概念和类
型
（6）软件质量管理基础知识：软件质量特性（ISO/IEC 9126软件质量模型）、软件质量保证、
软件复杂性的概念及度量方法（McCabe度量法）、软件评审（设计质量评审、程序质量评审）、
软件容错技术。
（7）软件过程改进基础知识：软件能力成熟度模型CMM、统一过程（UP）与极限编程（XP）
的基本概念。

数据流图：
补充数据流图的缺失部分，包括补充数据流、补充外部实体、补充数据存储。
数据流图的改错，包括修正数据流名称、数据流的起点与终点、删除多余数据流。

软件工程3大开发

• 原型法：瀑布（走一遍流程），快速原型（交互模型），增量（不断增加模块），演化（不断修改），敏捷（XP极限编程），喷泉（面向对象过程中多次重复）
• 结构化：先分析（数据流图 ），再设计（先概要再详细，详细即模块有2原则信息屏蔽和独立耦合 ）。
• 面向对象：先分析OOA（UML图 ），再设计OOD（设计原则 ），最后编程OOP

软件测试与维护
+

2、软件工程

开发生命周期模型

• 系统开发的生命周期是指一个系统历经计划、分析、设计、编程、测试、维护直至淘汰的整个过程。
• 生命周期阶段的划分通常可以采用以下三种方法：
• Boehm划分法：计划（问题定义、可行性研究）、开发（需求分析、总体设计、详细设计、编码、测试）、运行（维护） 三大阶段。
• 国标（GB8566-1988）划分法：可行性研究与计划、需求分析、概念设计、详细设计、实现、组装测试、确认测试、使用和维护。 并在《GB/T8566-1995信息技术——软件生存期过程》中定义了获取过程、供应过程、开发过程、运行过程、维护过程、管理过程、支持过程七个部分 。
• RUP划分法：分为初始、细化、构造、移交 四个主要阶段。

开发模型：

• 瀑布模型：严格遵循 软件生命周期各阶段的 固定顺序 ，一个阶段完成再进入另一个阶段。其优点是：可以使过程比较规范化，有利于评审 ；缺点在于：过于理想，缺乏灵活性，容易产生需求偏差。所以瀑布模型的应用场合为：需求明确的项目、二次开发项目以及与原型法配合使用。——像瀑布一样流过。
• 快速原型模型：采用了一种动态定义需求的方法 ，通过快速地建立一个能够反映用户主要需求 的软件原型，让用户在计算机上使用它，了解其概要，再根据反馈的结果进行修改 ，因此能够充分体现用户的参与和决策。原型化人员对原型的实施很重要，衡量他们的重要标准是能否从用户的模糊描述中快速地获取实际的需求 。所以快速原型模型很好的弥补了瀑布模型的缺陷，它适合于需求不够明确的项目 。——原型设计
• 演化模型：也是一种原型化开发，但与快速原型不同的是，快速原型模型在获得真实需求时，就将抛弃原型。而演化模型则不然，它将从初始的模型中逐渐演化为最终软件产品 ，是一种“渐进式”原型法。其应用场合也是需求不明确的项目 。
• 增量模型：它采用的是一种“递增式”模型，它将软件产品划分成为一系列的增量构件 ，分别进行设计、编码、集成和测试。相对于原型法而言，这种模型其实是从系统开发的另一个方面看待问题，原型法关注点是“制作一个原型”，而增量模型的关注点是系统的功能模块不是一次完成的，而是一块一块开发，以增加的方式进行的 。在现实开发中，我们会发现，一个项目开发过程既用了原型模型也用了增量模型。所以增量模型仍有利于进行需求不明确的项目开发。——先发布版本1.0，再不断填坑和完善
• 螺旋模型：结合了瀑布模型和演化模型 的优点，最主要的特点在于加入了风险分析 。它是由制定计划、风险分析、实施工程、客户评估这一循环组成的，它最初从概念项目开始第一个螺旋。+ 喷泉模型：主要用于描述面向对象的开发过程，最核心的特点是迭代。所有的开发活动没有明显的边界，允许各种开发活动交叉进行。
• UP：既是一个统一的软件开发过程，是一个通用过程框架 ，可以应付种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP是基于构件的，这意味着利用它开发的软件系统是由构件构成的 ，构件之间通过定义良好的接口相互联系 。在准备软件系统所有蓝图 的时候，UP使用的是统一建模语言UML 。与其他软件过程相比，UP具有三个显著的特点 ：用例驱动、以基本架构为中心、迭代和增量。UP中的软件过程在时间上被分解为四个顺序的阶段 ，分别是初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审 ，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。UP一般用于大型软件的开发 。——初赛复赛总决赛，每次评审分析，不断演化为更优的产品。
• 敏捷开发：从敏捷开发一词的敏捷可以看出，该方法是一种轻量级的开发方法 。这种开发方法的主要思想是：传统的软件工程方法文档量太“重”了 ，现在需要进行减负，所以将不必要的文档都去掉，这就形成了敏捷开发。具体一点讲，敏捷方法包括：XP（极限编程）、自适应开发、水晶方法、特性驱动开发 等。这些方法中，最著名的是XP方法（当然，XP方法最著名，并非因为方法本身很好，而是提出该方法的人，是个牛人）。
• 在XP方法中，提出了四大价值观 ：沟通、简单、反馈、勇气。五大原则 ：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。十二个最佳实践 ：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准。
• 喷泉模型：主要用于描述面向对象的开发过程。喷泉一词体现了面向对象开发过程的迭代和无间隙特征 。迭代意味着模型中的开发活动常常需要多次重复 ，每次重复都会增加或明确一些目标系统的性质，但却不是对先前工作结果的本质性改动。无间隙是指在开发活动（如分析、设计、编程之间不存在明显的边界，而是允许各开发活动交叉、迭代地进行。

3、系统开发方法论

系统开发方法 包括：结构化方法、原型法、面向对象方法。 其中原型法仅用于需求分析阶段，且在上一节已有描述。

结构化方法：

• 一种传统的软件开发方法，它是由结构化分析、结构化设计和结构化程序设计 三部分有机组合而成的。
• 结构化分析：即我们平时所说的需求分析阶段 ，该阶段的主要任务是：解决“做什么”的问题。自顶向下，逐步求精 为基点。
• 结构化设计：以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模块化 的过程。
  主要工作内容是进行概要设计与详细设计 。
  概要设计 的主要任务是把需求分析得到的数据流图转换为软件结构和数据结构 。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系 、确定模块间的接口及人机界面等。
  详细设计 是对概要设计的一个细化，就是详细设计每个模块实现算法，所需的局部结构。
• 模块设计原则：
  主要是两个方面：信息隐蔽与模块独立。
  信息隐蔽 指在设计和确定模块时，使得一个模块内包含信息（过程或数据），对于不需要这些信息的其他模块来说，是不能访问的 。让所有的操作都通过标准的接口进行，提高软件的可修改性、可测试性和可移植性。
  模块独立 是指每个模块完成一个相对独立的特定子功能 ，保持模块的高度独立性。通常我们用耦合（模块之间联系的紧密程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量， 我们的目标是高内聚、低耦合。
• 模块的内聚类型通常 可以分为7种，根据内聚度从高到低排序
  
• 除了满足以上两大基本原则之外，通常在模块分解时还需要注意：保持模块的大小适中 ；尽能减少调用的深度 ；直接调用该模块的个数应该尽量大 ，但调用其他模块的个数则不宜过大 ；保证模块是单入口、单出口的；

---

面向对象基本概念：

• 人类在认识和理解现实世界中普遍运用的三个构造法 ，对象及属性、类属及成员、整体及其部分。
• 面向对象开发方法 的发展经历了一个漫长的周期，先后提出了多个不同的方法：OMT方法、Coad/Yourdon方法、OOSE方法， 而这些方法又进一步组合，形成了大家所熟知的UML。
• OOA即面向对象的分析 ，它的任务是了解问题域所涉及的对象、对象间的关系和操作 ，然后构造问题的对象模型。第一步是确定问题域 。
• OOD即面向对象的设计 ，在分析对象模型的基础上，设计各个对象、对象之间的关系（例
  如，层次关系、继承关系等 ）和通信方式（例如，消息模式）。
  面向对象的设计需要遵循一系列的 设计原则：
  单一职责 原则：设计目的单一的类；
  开放-封闭 原则：对扩展开放，对修改封闭；
  李氏(Liskov)替换 原则：子类可以替换父类；
  依赖倒置 原则：要依赖于抽象，而不是具体实现； 针对接口编程，不要针对实现编程 ；
  接口隔离 原则：使用多个专门的接口比使用单一的总接口要好 ；
  组合重用 原则：要尽量使用组合，而不是继承关系 达到重用目的；
  迪米特(Demeter)原则 (最少知识 法则)：一个对象应当对其他对象有尽可能少的了解。
• OOP即面向对象编程 ，实现在OOD阶段所规定的各个对象所应完成的任务。它包括每个对象的内部功能的实现，确立对象哪一些处理能力应在哪些类中进行描述，确定并实现系统的界面、输出的形式等。

例题：

试题1
模块A执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能，则该模块具有__(1)__
内聚。
（1）A．顺序 B．过程 C．逻辑 D．功能
试题2
确定软件的模块划分及模块之间的调用关系是__(2)阶段的任务。
（2）A．需求分析 B．概要设计 C．详细设计 D．编码
试题3
模块A直接访问模块B的内部数据，则模块A和模块B的耦合类型为(3)。
（3）A．数据耦合 B．标记耦合 C．公共耦合 D．内容耦合
试题4
采用面向对象开发方法时，对象是系统运行时基本实体。以下关于对象的叙述中，正确的是
(4)。
（4）A．对象只能包括数据（属性）
B．对象只能包括操作（行为）
C．对象一定有相同的属性和行为
D．对象通常由对象名、属性和操作三个部分组成
试题5
面向对象分析的第一步是(5)__。
（5）A．定义服务 B．确定附加的系统约束
C．确定问题域 D．定义类和对象

答案：CBDDC

4、软件测试与维护

软件测试更有效率与效果，测试应遵循 以下原则 ：
（1）尽早、不断的进行测试；
（2）程序员避免测试自己设计的程序；
（3）既要选择有效、合理的数据，也要选择无效、不合理的数据；
（4）修改后应进行回归测试 ；
（5）尚未发现的错误数量与该程序已发现错误数成正比。

测试阶段
软件测试按阶段划分，可分为：单元测试，集成测试，确认测试，系统测试。
（1）单元测试
单元测试，也称模块测试 ，通常可放在编程阶段 ，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法 。单元测试主要发现编程和详细设计中产生的错误，单元测试计划应该在详细设计阶段制定。单元测试期间着重从以下几个方面对模块进行测试：模块接口、局部数据结构 、重要的执行通路、出错处理通路、边界条件等。——函数测试
（2）集成测试
集成测试，也称组装测试 ，它是对由各模块组装而成的程序进行测试 ，主要目标是发现模块间的接口和通信问题 。例如，数据穿过接口可能丢失；一个模块对另一个模块可能由于疏忽而造成有害影响 ；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等。集成测试主要发现设计阶段产生的错误，集成测试计划
应该在概要设计阶段制定。
集成的方式可分为非渐增式和渐增式 。
非渐增式集成 是先测试所有的模块 ，然后一下子把所有这些模块集成到一起，并把庞大的程序作为一个整体来测试 。这种测试方法的出发点是可以**“一步到位”** ，但测试者面对众多的错误现象，往往难以分清哪些是“真正的”错误，哪些是由其他错误引起的“假性错误”，诊断定位和改正错误也十分困难 。非渐增式集成只适合一些非常小的软件。——调试bug测数据
渐增式集成 是将单元测试和集成测试 合并到一起，它根据模块结构图 ，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起进行测试 ，每次增加一个模块，直到所有模块被集成在程序中。这种测试方法比较容易定位和改正错误，目前在进行集成测试时已普遍采用渐增式集成。——调不出来了对着copy
（3）确认测试
确认测试（Validation Testing）主要依据软件需求说明书检查软件的功能、性能及其他特征 是否与用户的需求一致。确认测试计划应该在需求分析阶段制定 。
软件配置复查 是确认测试的另一项重要内容。复查的目的是保证软件配置的所有成分都已齐全 ，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节。如果一个软件是为某个客户定制的 ，最后还要由该客户来实施验收测试 （acceptancetesting），以便确认其所有需求是否都已得到满足。由于软件系统的复杂性，在实际工作中，验收测试可能会持续到用户实际使用该软件之后的相当长的一段时间。
如果一个软件是作为产品被许多客户使用的 ，不可能也没必要由每个客户进行验收测试。绝大多数软件开发商都使用被称为α（Alpha）测试和β（Beta）测试的过程 ，来发现那些看起来只有最终用户才能发现的错误。α测试由用户在开发者的场所进行 ，并且在开发者的指导下进行测试。开发者负责记录发现的错误和使用中遇到的问题。也就是说，α测试是在“受控的”环境中 进行的。β测试是在一个或多个用户的现场由该软件的最终用户实施的，开发者通常不在现场 ，用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者 。也就是说，β测试是在“非受控的”环境中进行的。经过确认测试之后的软件通常就可以交付使用了。
（4）系统测试
系统测试的对象是完整的、集成的计算机系统 ，系统测试的目的是在真实系统工作环境 下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。
系统测试的技术依据是用户需求或开发合同 ，除应满足一般测试的准入条件外，在进行系统测试前，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。
一般来说，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法 ，性能测试主要验证软件系统在承担一定负载的情况下所表现出来的特性是否符合客户的需要，主要指标有响应时间、吞吐量、并发用户数和资源利用率等。

白盒测试和黑盒测试：
白盒测试：——调试bug
白盒测试，又称透明盒测试、结构测试等 ，软件测试的主要方法之一。测试应用程序的内部结构或运作 ，而不是测试应用程序的功能（即黑盒测试）。在白盒测试时，以编程语言的角度来设计测试案例 。测试者了解待测试程序的内部结构、算法等信息 ，这是从程序设计者的角度对程序进行的测试。
白盒测试可以应用于单元测试、集成测试和系统的软件测试流程 ，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。
白盒测试主要是从覆盖源程序语句的详尽程度来分析 。逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖、路径覆盖 。
语句覆盖：为了暴露程序中的错误，程序中的每条语句至少应该执行一次 。该方法会选择足够多的测试数据，使被测程序中每条语句至少执行一次 。语句覆盖是很弱的逻辑覆盖。
判定覆盖：比语句覆盖稍强的覆盖标准是判定覆盖 。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”， 或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
条件覆盖：在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖 ，可以采用条件覆盖的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
多条件覆盖：多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
路径覆盖：最全面的覆盖。 路径覆盖的含义是，选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路径至少经过一次）。
黑盒测试： ——submit
黑盒测试也称功能测试 ，它是通过测试来检测每个功能是否都能正常使用 。在测试中，把程序看作一个不能打开的黑盒子 ，在完全不考虑程序内部结构和内部特性的情况下 ，在程序接口进行测试 ，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息 。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面
和软件功能进行测试。
常用的黑盒测试法包括：等价类划分、边值分析、错误推测和因果图。
（1）等价类划分 ——构造经典数据
在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合 ，对于一个等价类中的输入值来说，它们揭示程序中错误的作用是等效的。也就是说，如果等价类中的一个输入数据能检测出一个错误 ，那么等价类中的其他输入数据也能检测出同一个错误；反之，如果等价类中的一个输入数据不能检测出某个错误，那么等价类中的其他输入数据也不能检测出这一错误（除非这个等价类的某个子集还属于另一等价类）。如果一个等价类内的数据是符合（软件需求说明书）要求的、合理的数据，则称这个等价类为有效等价类。有效等价类主要用来检验软件是否实现了软件需求说明书中规定的功能。
如果一个等价类内的数据是不符合（软件需求说明书）要求的、不合理或非法的数据，则称这个等价类为无效等价类。无效等价类主要用来检验软件的容错性。
黑盒测试中，利用等价类划分方法设计测试用例的步骤如下。
①根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。
②设计一个测试用例，使其覆盖尽可能多的尚未被覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖。
③设计一个测试用例，使其覆盖一个尚未被覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。应当特别注意，无效等价类用来测试非正常的输入数据，因此每个无效等价类都有可能查出软件中的错误，所以要为每个无效等价类设计一个测试用例。
（2）边值分析 ——构造边界数据
经验表明，软件在处理边界情况时最容易出错。 设计一些测试用例，使软件恰好运行在边界附近， 暴露出软件错误的可能性会更大一些。通常，每一个等价类的边界，都应该着重测试，选取的测试数据应该恰好等于、稍小于或稍大于边界值 。将等价类划分法和边值分析法结合使用，更有可能发现软件中的错误。
（3）错误推测 ——构造特殊数据
使用等价类划分和边值分析技术，有助于设计出具有代表性的、容易暴露软件错误的测试方案。 但是，不同类型不同特征的软件通常又有一些特殊的容易出错的地方。错误推测法主要依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案。
（4）因果图 ——乱搞数据
因果图法是根据输入条件与输出结果 之间的因果关系来设计测试用例的，它首先检查输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后为每种输出条件的组合设计测试用例。

软件维护 ：——新版app

软件维护主要是指根据需求变化或硬件环境的变化 对应用程序进行部分或全部的修改 。在修改时应充分利用源程序，修改后应填写程序改登记表，并在程序变更通知书上写明新旧程序的不同之处 。
软件维护是整个软件生命周期中最长的一个阶段，同时他也花费了整个软件生命周期中最多的成本，20世纪80年代末用于软件维护的花费为整个软件生命周期总花费的75% ，而且还在逐年上升。
软件维护通常可分为以下四种类型 ：
改正性维护 ：是指改正在系统开发阶段已发生而系统测试阶尚未发现的错误 。这方面的维护工作量要占整个维护工作量的17%～21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行；而有的错误非常重要，甚至影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。——修复bug
适应性维护 ：是指使用软件适应信息技术变化和管理需求变化而进行的修改 。这方面的维护工作量占整个维护工作量的18%～25%。由于目前计算机硬件价格的不断下降，各类系统软件层出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。——增加性能
完善性维护 ：这是为扩充功能和改善性能 而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%～60%，比重最大。——增加功能
预防性维护 ：为了改进应用软件的可靠性和可维护性 ，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能 ，以使应用系统适应各类变化而不被淘汰。例如：目前的网络带宽够用，但新系统一旦上线，将面临带宽不够的风险，此时进行带宽的扩容就是一种预防性维护。这方面的维护工作量占整个维护工作量的4%左右。——预防bug

在软件维护这个主题中，另一个值得注意的方面是：软件的可维护性问题 。
软件的可维护性是指理解、改正、改动、改进软件的难易程度 。
根据Boehm质量模型，通常影响软件可维护性的因素有可理解性、可测试性和可修改性 。
（1）可理解性：可理解性是指维护人员理解软件的结构、接口、功能和内部过程的难易程度。
（2）可测试性：可测试性是指测试和诊断软件错误的难易程度。
（3）可修改性：可修改性是指修改软件的难易程度。
为了提高软件的可维护性，在软件生命周期的各个阶段都必须充分考虑维护问题。先进的软件工程方法是软件可维护的基础保证。
面向对象方法 学的对象封闭机制、消息通信机制、继承机制和多态机制从根本上提高了 软件的可理解性、可测试性和可修改性。
结构化设计的几条主要原则 ，如模块化、信息隐蔽、高内聚、低耦合等，对于提高软件的可理解性、可测试性和可修改性也都有重要的作用。
另外，书写详细正确的文档、书写源文件的内部注解、使用良好的编程语言 、具有良好的程序设计风格，也有助于提高软件的可理解性。使用先进的测试工具、保存以前的测试过程和测试用例，则有助于提高软件的可测试性。

试题2
答案：BDCCCCC

试题2
不属于黑盒测试技术的是__(3)。
（3）A．错误猜测　　B．逻辑覆盖　　C．边界值分析　　D．等价类划分
试题3
在某班级管理系统中，班级的班委有班长、副班长、学习委员和生活委员，且学生年龄在15～
25岁。若用等价类划分来进行相关测试，则(4)不是好的测试用例。
（4）A．（队长，15） B．（班长，20）C．（班长，15） D．（队长，12）
试题5
在改正当前故障的同时可能会引入新的故障，这时需要进行(6)。
（6）A．功能测试 B．性能测试 C．回归测试 D．验收测试
试题7
以下关于软件测试的叙述中，正确的是(8)。
（8）A．软件测试不仅能表明软件中存在错误，也能说明软件中不存在错误
B．软件测试活动应从编码阶段开始
C．一个成功的测试能发现至今未发现的错误
D．在一个被测程序段中，若已发现的错误越多，则残存的错误数越少
试题8
某企业由于外部市场环境和管理需求的变化对现有软件系统提出新的需求，则对该软件系统进行的维护属于(9)维护。
（9）A．正确性 B．完善性 C．适应性 D．预防性
试题9
针对应用在运行期的数据特点，修改其排序算法使其更高效，属于(10)维护。
（10）A．正确性 B．适应性 C．完善性 D．预防性
试题10
软件系统的可维护性评价指标不包括(11)__。
（11）A．可理解性　　B．可测试性　　C．扩展性　　D．可修改性

软件质量保证与软件过程改进
软件质量就是软件与显性与隐性需求相一致 的程度。

软件质量保证，就是保证软件产品充分满足消费者要求的质量而进行的有计划、有组织的活动。它主要包括质量方针的制定和展开、质量保证方针和质量保证标准的制定、质量保证体系的建立和管理、明确各阶段的质量保证工作、各阶段的质量评审、确保设计质量、重要质量问题的提出与分析、总结实现阶段的质量保证活动、整理面向用户的文档和说明书、产品质量和质量保证系统的鉴定、质量信息的收集分析及使用。而软件过程改进同样要靠标准作为指导方针，所以在本节将介绍到很多与质量相关的标准。

1．软件质量特性标准
为了能够统一地描述软件质量特性 ，形成了许多质量特性标准，其中最常用的有国际通用的ISO/IEC 9126软件质量模型 和Mc Call软件质量模型 。
（1）IEO/IEC 9126模型
IEO/IEC 9126模型是考试当中经常考查的一个知识点，考查方式主要是在选择题中，选出一个质量属性类中不属于（或属于）这一类的子特性 ，所以要求考生掌握此标准中的质量属性分类与其子特性。值得注意的是IEO/IEC 9126模型等价于我国的国家标准《GB/T 16120—1996 软件产品评价、质量特性及其使用指南》。

McCall质量模型
McCall质量模型从软件运行、软件修改和软件转移三个方面来考查软件的质量，其体系如图7-5所示。

软件技术评审
正式的技术评审FTR（Formal Technical Review） 是软件工程师组织的软件质量保证活动。它通常会采用系统化、严密的过程 ，包括制订计划、总体会议、做准备、开会、返工、追踪和因果分析。应培训审查者，依赖于缺陷检查表和其他错误分析技术；不是由作者来主持主审，而是由主持人陈述。
制订计划：确定谁参加，一般需要将人数控制在7人之内；确定准备哪些内容。
总体会议：确定评审的背景、假设及目标。
做准备：评审员预先阅读评审的材料。
评审会议：主持人引导，根据预先准备的检查表进行评审。
返工：评审会议是为了发现问题，问题应在会后进行返工。
跟踪：确定错误已经修改，并通知所有的评审人。

能力成熟度模型集成（CMMI）
能力成熟度模型集成融合了多种模型，形成了组织范围内过程改进的单一集成模型，其主要目
的是消除不同模型之间的不一致和重复，降低基于模型进行改进的成本。CMMI有两种表示法：阶
段表示法和连续式表示法。这两种表示方法各有优缺点，均采用统一的24个过程域，它们在逻辑上
是等价的，对同一个组织采用两种模型分别进行CMMI评估，得到的结论应该是相同的。但在考试
时，往往涉及的是阶段表示法，所以在此仅对阶段表示法进行说明。
阶段式模型基本沿袭CMM模型框架，仍保持五个成熟等级，但关键过程域做了一些调整和扩
充，如表7-5所示。

软件项目管理

软件项目本身是复杂的，如果没有仔细地计划，复杂的项目 是不可能成功的。
一个计划良好的项目 将受到有效的控制，进展明显，而参加该项目的人员都会得到支持以进行其工作。
软件项目本身也具有风险性，如果没有有效的风险管理也是不能成功的。
通常软件工程项目的管理比其他工程项目的管理更困难，这是因为：软件产品不可见。开发的进度及产品的质量是否符合要求不明显，比较难进行把握。没有标准的软件过程。尽管近几年来“软件过程改进”领域有许多进步，但由于团队、人员的个性化因素，还不存在一个放之四海皆真理的标准化软件过程。大型软件项目常常是一次性项目。由于这些项目都是“前无古人”的，因此缺乏可以借鉴的历史经验。
在软件设计师考试中，项目管理知识考查的分值较少，同时知识点比较集中，所以本节不会面面俱到的介绍项目管理知识，而是取了几个知识点来进行说明。主要包括网络计划技术中的一些计算问题以及项目管理相关的一些基本概念。