复旦961-软件工程笔记

先推一下复旦软工考研大群

QQ群号：690285208
今天调剂复试了，帖子发出来给考961的大家参考下，也攒攒人品。

图

• 汇总
• 用例图-这人博客有很多关于怎么画图的
• 数据流图
• 数据流图（文件的输入输出流不需要写名称，画线画箭头即可）
• 数据流图
• 类图（当关联关系有头的时候，若ab间箭头指向b端，但我觉得更确切应该说是“由a能得出b，b不能得出a”）
• 类图
• 类图
• 顺序图
• 活动图、泳道图
• 包图、构件图、部署图
• 包图、构件图、部署图
• 状态机图（箭头表示迁移，上面写事件，事件后面跟个方括号，方括号里面写事件发生的条件）

大纲知识点

一.软件过程

1.软件过程的概念

• 软件过程又称软件生存周期过程，是生产一个（最终满足需求&达到工程目标的）软件产品所需要的步骤
• 定义了软件组织和人员在软件产品的定义、开发和维护等阶段所实施的一系列活动&任务，并描述了活动&任务的时序关系和达到预期目标的途径

2.经典软件过程模型（概念、优缺点、适用）

• 瀑布模型
• 定义：传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。软件开发中各项活动按顺序线性联接。上一阶段活动完成并经过评审才能开展下一阶段
• 特点：1.阶段间具有顺序性和依赖性；2.推迟实现的观点；3.质量保证的观点。瀑布模型的成功在很大程序上是由于它基本上是一种文档驱动的模型
• 优点：a.可强迫开发人员采用规范的技术方法 ；b.严格地规定了每个阶段必须提交的文档 ；c.每个阶段结束前必须正式进行严格的技术审查和管理复审
• 缺点：1.假设每个活动都能“一次性通过”，忽略了需求和困难的不确定性；2.全过程结束才能看到成品，交付及时性太差
• 快速原型模型
• 定义：所谓“快速原型”， 是快速建立起来的、可在计算机上运行的程序，它所能完成的功能往往是最终的软件产品所能完成的功能的子集。“原型“”是软件开发人员与用户沟通的强有力工具，因此有助于所开发出的软件产品满足用户的真实需求。
• 优点：A . 开发出的软件产品通常能满足用户的真实需求；B．软件产品的开发过程基本上是线性顺序过程。
• 模型类型：探索型-用于需求分析阶段，旨在帮助缺乏经验的项目明确用户需求，探索各方案的可行性；实验型-用于设计阶段，考察方案是否合适；演化型-贯穿软件开发全过程，旨在尽早构建一个包含主要功能的原型系统框架，后续再扩充
• 增量模型
• 将整个开发过程分为若干个日程时间交错的线性序列，每个序列产生一个可发布的版本，前面的增量一般覆盖了产品的核心/探索性功能，后面的增量相当于附加&补充&修改
• 优点：1.早开始早交付；2.因为存在并行所以可以人力资源效益更大化；3.降低商业/技术风险
• 缺点：对程序架构要求高
• 演化模型（其实就是原型模型的一种）
• 先做一个初始可运行版本（原型—探索型/实验型/演化型），然后根据过程中的意见&问题来改进，依此迭代最终取得成果
• 优点：更好地适应产品需求/商业环境的变化，缓解商业压力&产品竞争压力
• 螺旋模型
• 可以认为是演化模型的一种，每次迭代都包含（制定计划、风险分析、实施工程、客户评估）4个阶段
• 优点：1.强调风险，降低损失；2.每个周期分4部分，更清晰，利于沟通&协作
• 适用于内部开发的大型软件项目
• 统一过程模型（Rational Unified Process）
• 是一个增量和迭代的过程框架，一次增量向系统中添加一部分功能，形成一个新的软件版本（这就是一次迭代）
• 整个过程分4个阶段：初始、细化、构造、移交；4个阶段对应4个里程碑
• 每个阶段包含1次或多次迭代，每个迭代包含6个核心过程工作流&3个核心支持工作流
• 特点：用况驱动；以构架为中心；迭代和增量

3.CMM&CMMI

• CMM
• Capability Maturity Model，能力成熟度模型，是国际公认的对软件公司进行成熟度等级认证的重要标准
• 基本思想：由于问题是由人们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。CMM有助于软件开发机构建立一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间延误和费用超支之苦
• 两个主要应用：软件过程评估和软件能力评价。
• 分5个等级：
  1、初始级：软件过程的特征是无序的，有时甚至是混乱的
  2、可重复级：软件机构建立了基本的项目管理过程(过程模型),可跟踪成本、进度、功能和质量
  3、已定义级：软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。所有的项目组都使用文档化的、经过批准的过程来开发和维护软件
  4、已管理级：软件机构对软件过程（过程模型和过程实例）和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的
  5、优化级：软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。
• CMMI（能力成熟度模型集成）
• 概念：是若干过程模型的综合&改进，是支持多个工程学科&领域的系统一致的过程改进框架，能适应现代工程的特点和需要，提高过程的质量和工作效率
• 两种表示法：1.阶段式模型，关注组织成熟度，分为5个成熟度等级；2.连续式模型，关注每个过程域的能力，分为4/6个能力等级
• 阶段式模型5个等级：1.初始的-过程不可预测&缺乏控制；2.已管理的-过程为项目服务；3.已定义的-过程为组织服务；4.定量管理的-过程已度量且控制；5.已优化的-集中于过程改进
• 连续式模型6个等级：0.未完成的；1.已执行的；2.已管理的；3.已定义的；4.定量管理的；5.优化的
• 适用于集成化产品开发的能力成熟度模型

4.过程评估

软件过程评估所关注的是软件组织自身内部软件过程的改进问题，目的在于发现缺陷，提出改进的方向。

5.敏捷宣言与敏捷过程的特点

• 敏捷宣言4个价值观
• 个人与交互 重于 过程和工具
• 可以工作的软件 重于 详尽的文档
• 客户合作 重于 合同谈判
• 响应变化 重于 遵循计划
• 敏捷过程的特点（实际上就是对应敏捷宣言4个方面总结出来的，敏捷宣言背下来了这个就可以自己总结出来）
• 1.与传统开发相比有着更强的适应性而不是预设性；2.更注重人的因素；3.整个项目是测试驱动而不是文档驱动

二.软件需求

1.软件需求的概念

• 软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望；是对软件产品和服务所需具备的外部属性的一种刻画，这些属性应保证所提供的解决方案能满足用户所需要解决的现实世界问题的要求
• 都有哪些软件需求
• 功能需求：指定系统必须提供的服务
• 性能需求：指定系统必须满足的定时约束&容量约束，通常包括速度、信息量速率、主存容量、磁盘容量、安全性等需求
• 可靠性&可用性需求：可靠性需求定量地指定系统的可靠性，可用性量化了用户可以使用系统的程度
• 出错处理需求：说明系统对环境错误怎样响应
• 接口需求：描述应用系统与其环境的通信格式。常见的接口需求有：用户、硬件、软件、通信接口需求
• 约束：设计约束或实现约束描述在设计或实现应用系时应遵守的限制条件
• 逆向需求：说明软件系统不应做什么
• 将来可能的需求：应明确地列出那些虽不属于当前系统开发范畴，但据分析将来很可能会提出的要求

2.需求工程的基本过程（5个方面）

• 需求获取：识别需求来源，收集并获取初始的系统需求信息，建立对于待解决问题的基本认识，初步明确待开发系统的范围
• 需求分析：对收集的需求信息进行分析、整合，识别&解决其中隐含的冲突，从系统需求中导出细化的软件需求
• 文档化（系统建模，需求规约）：对需求分析过程得到的软件需求进行规范化的描述&记录，形成需求文档&规格说明
• 需求确认（需求验证）：验证需求文档&规格说明符合相关的格式规范，满足相关的质量属性（一致、完整、无歧义、可理解等）；确认所得到的需求与所要解决的问题相符
• 需求管理：规划需求工程活动，保证相关活动有效开展，确保需求制品的完整性&可追踪性，对需求变更进行有效管理

3.怎么获取软件需求（5种背3种左右就行）

• 市场搜索法：通过广泛搜集市场需求（包括通过互联网、向目标群体直接了解需求的方式），搜集产品需求。
• 项目提炼法：指从组织建设的若干用户的项目中，抽取出通用需求，形成产品需求的一种方式。
• 问卷调查法：在已经拥有比较完整的产品需求的基础之上，就一些细节需求、需要进一步明确的需求（或问题），通过采用向目标群体发送问卷调查表的方式，弄清产品需求的一种需求获取方法。
• 会议讨论法：指邀请相关专家、目标群体的代表，召开若干次需求讨论会议，挖掘出产品需求的一种需求获取方法。
• 原型法：指根据自己所了解的产品需求，开发出原型系统给目标群体试用，借助原型系统和目标群体进行交流和沟通，挖掘出产品需求的一种需求获取方法。

三.软件设计与构造

1.软件体系结构&体系结构风格

• 体系结构含义：
• 描述了分解和抽象，定义了设计和演化原则，是重要的设计决策，同特定的环境相关
• 普遍运用的一些体系结构风格
• 数据为中心
• 数据流风格
• 调用和返回风格
• 面向对象风格
• 层次式风格

2.设计模式的概念（区别‘风格’与‘模式’，‘风格’从相似性出发来描绘系统结构、更注重方案域；‘模式’从解决问题同上下文的共通性出发、更关注问题域）

• 在类似场景下可复用的设计

3.软件设计原则–模块化设计的基本思想及概念（抽象、分解、模块化、封装、信息隐藏、功能独立—含义，什么情况下使用）

• 模块化（模块化实际上是系统分解和抽象的过程）
• 含义：把软件按照规定原则，划分为一个个较小的，相对独立又相互关联的部件
• 优点：可靠性；可修改性；便于阅读&理解
• 广泛适用
• 抽象&分解（抽象与逐步求精）
• 抽象：以概括性的术语描述解决方案；手段：过程抽象（任何一个完成明确定义的操作都可被使用者当做单个实体看待，尽管这个操作实际上是由一系列更低级的操作来完成的）和数据抽象（是定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据）
• 逐步求精：是把问题的求解过程分解成若干个步骤或阶段，每一步都比上一步更精细化、更接近问题的解法
• 两者关系：抽象&逐步求精是一对互补的概念。抽象使得设计者能够描述过程和数据而忽略低层次的细节，求精有助于设计者在设计过程中揭示低层次的细节。
• 信息隐藏
• 含义：定义和实施对模块的过程细节和局部数据结构的存取限制
• 特点：隐藏的不是模块的一切信息–模块间通信所需要的必要信息还是透明的，只是每个模块的实现细节对其他模块是不可见的
• 优点：将来修改软件时偶然引入的错误所造成的影响可以局限在一个或几个模块内部，避免影响到软件其他部分
• 功能独立
• 含义：程序模块实现独立功能，与其他模块接口简单，模块间关联&依赖程度尽可能小
• 优点：易于实现（因为功能被分隔且接口简单）；易于维护；修改的副作用小
• 内聚与耦合（衡量独立性的两个指标）（有可能考代码）
• 内聚–模块内各元素结合的紧密程度
• 耦合–模块间相互依赖的紧密程度
• 高内聚，低耦合，则独立性强
• 耦合的种类（越往下耦合度越强，独立性越差）
  1.数据耦合：如果两个模块间的通讯信息是若干参数，其中每一个参数都是一个数据元素，称这种耦合为数据耦合。这是模块之间影响最小的耦合关系。 传递数据
  2.标记耦合：当把整个数据结构作为参数传递而被调用模块只需要使用其中一部分数据元素 标记耦合时，这种情况称为标记耦合。 传递地址–降藕方式：采用接口或简单参数类型的方法降藕
  3.控制耦合： 如果模块A向模块B所传递的信息控制了模块B的内部逻辑，那么A和B之间则称为控制耦合。
  4.公共耦合：如果两个或多个模块都和同一个公共数据域有关，则称为公共耦合。公共耦合是一种不良的耦合关系，它给模块的维护和修改带来困难。 如果两个模块共享的数据很多，都通过参数传递很不方便时，可以利用公共耦合。
  5.内容耦合：如果一个模块和另一个模块的内部属性（即运行程序和内部数据）有关，则称为 内容耦合。
• 内聚种类：
  1.功能内聚：如果一个模块内部的各组成部分的处理动作全都为执行同一个功能而存在， 并且 功能内聚： 只执行一个功能，则称为功能内聚。判断一个模块是不是功能内聚，只要看这个模块是“做什么” 是完成一个具体的任务，还是完成多任务。
  2.顺序内聚：如果一个模块内部的各个组成部分执行的几个处理动作有这样的特征： 前一个处理动作所产生的输出数据是后一个处理动作的输入数据，称为顺序内聚。 顺序内聚维护起来不如功能内聚方便， 要修改模块中的一个功能， 会影响到同一个模块中的 其他功能。
  3.通讯内聚： 如果一个模块内各组成部分的处理动作都使用相同的输入数据或产生相同的输出数据，称为通讯内聚。
  4.过程内聚：如果一个模块内部的各个组成部分的处理动作各不相同，彼此也没有联系，但他 们都受同一个控制流支配，决定他们的执行次序，称为过程内聚。
  5.暂时内聚（时间内聚）：如果一个模块内的各组成部分的处理动作和时间有关，暂时内聚模块的处理动作必须在特定的时间内完成。-----指在一个特定的时间范围内 完成，但完成次序不重要。例如：程序设计中的模块的初始化。
  6.逻辑内聚：如果一个模块内部的各组成部分的处理动作在逻辑上相似， 但功能都彼此不同或 逻辑内聚： 无关，则称为逻辑内聚。一个逻辑内聚模块往往包括若干个逻辑相似的动作，使用时可以选 用一个或几个功能。例如：把编辑各种输入数据的功能放在一个模块中。
  7.机械内聚（偶然内聚）： 如果一个模块的内部各组成部分的处理动作彼此没有任何联系，则称为机械内聚
  这章概念十分重要，也是每个概念控制在两句话总结出特点就可以

4.软件重构的概念

• 重构是一种重新组织的技术，可以简化构件的设计而无需改变其功能或行为。

5.类&接口

• 什么是“类”？
• 类的实质是一种数据类型，但因为它的本质是类型，而不是数据，所以不存在于内存中，不能被直接操作，只有被实例化为对象时，才会变得可操作
• 类的内部封装了方法，用于操作自身的成员
• 类的构成包括数据成员和成员函数
• 类和外界发生交互的操作称为接口
• 接口可以说是软件内部，软件与协作系统，软件同人之间的通信渠道

6.面向对象设计原则（开闭原则、Liskov替换原则、依赖转置原则、接口隔离原则）

• 单一职责原则（Single Responsibility Principle，简称SRP ）
  核心思想：应该有且仅有一个原因引起类的变更
  问题描述：假如有类Class1完成职责T1，T2，当职责T1或T2有变更需要修改时，有可能影响到该类的另外一个职责正常工作。
  优点：类的复杂度降低、可读性提高、可维护性提高、扩展性提高、降低了变更引起的风险。
  需注意：单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可以度量的，因项目和环境而异。
• 里氏替换原则（Liskov Substitution Principle,简称LSP）
  核心思想：在使用基类的地方可以任意使用其子类，能保证子类完美替换基类。
  通俗来讲：只要父类能出现的地方子类就能出现。反之，父类则未必能胜任因为子类有可能发展出自己的功能
  优点：增强程序的健壮性，即使增加了子类，原有的子类还可以继续运行。
  需注意：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系 采用依赖、聚合、组合等关系代替继承。
• 依赖倒置原则（Dependence Inversion Principle,简称DIP）
  核心思想：高层模块不应该依赖底层模块，二者都该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象；
  说明：高层模块就是调用端，低层模块就是具体实现类。抽象就是指接口或抽象类。细节就是实现类。
  通俗来讲：依赖倒置原则的本质就是通过抽象（接口或抽象类）使个各类或模块的实现彼此独立，互不影响，实现模块间的松耦合。
  问题描述：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
  解决方案：将类A修改为依赖接口interface，类B和类C各自实现接口interface，类A通过接口interface间接与类B或者类C发生联系，则会大大降低修改类A的几率。
  优点：在大中型项目中可以减少需求变化引起的工作量。使并行开发更友好。
• 接口隔离原则（Interface Segregation Principle,简称ISP）
  核心思想：类间的依赖关系应该建立在最小的接口上
  通俗来讲：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
  问题描述：类A通过接口interface依赖类B，类C通过接口interface依赖类D，如果接口interface对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
  需注意：
  接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情
  优点：符合高内聚低耦合的设计思想.从而使得类具有很好的可读性,可扩展性和可维护性
  为依赖接口的类定制服务。只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

迪米特法则（Law of Demeter,简称LoD）
核心思想：类间解耦。
通俗来讲： 一个类对自己依赖的类知道的越少越好。自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。

开放封闭原则（Open Close Principle,简称OCP）
多增加，少修改。对扩展开放，对修改关闭
核心思想：尽量通过扩展软件实体来解决需求变化，而不是通过修改已有的代码来完成变化
通俗来讲： 一个软件产品在生命周期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计的时候尽量适应这些变化，以提高项目的稳定性和灵活性。

一句话概括:单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。

四.软件测试

1.软件测试的概念

• 两个维度
• 正：验证正确----侧重于质量，适用于安全攸关系统
• 反：找出错误—侧重于目标&效率，适用于一般系统

2.测试用例的概念

为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求

• 测试用例的优劣
  （1）测试用例书写格式正确、描述清晰， 其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去（简单来说， 其他人能看懂，能执行）。
  （2）测试用例对测试点覆盖完全，也就是说测测过程中发现的问题基本都是通过测试用例发现的，发现的比例越高越好， 越高说明测试用力的防护能力越强，当然测试用例不可能特别完备，在我们执行测试用例的过程，如果bug不是通过用例发现，我们需要对用例进行增加，这样我们下一次就可以把这个问题给防护住。（但是不是所有的bug都需要增加测试用例）（简单说就是bug尽可能都是测试用例发现的）
  （3）测试用例所属功能上线后，用户反馈好。

3.测试策略，及软件测试过程模型（单元测试、集成测试、确认测试、系统测试、回归测试的概念,v形图，复p162，清p267）

• 单元测试（检测代码是否符合详细设计的要求）（针对程序中的模块或构件，主要揭露编码阶段产生的错误）
  单元测试侧重于软件设计的最小单元（软件构建或模块）的验证工作。利用构件级设计描述作为指南，测试重要的控制路径以发现模块内的错误。测试的相对复杂度和这类测试发现的错误受到单元测试约束范围的限制。单元测试侧重于构件的内部处理逻辑和数据结构，这种类型的测试可以对多个构件并行执行。
• 集成测试，也叫组装/联合测试
  （检测此前测试过的各组成部分是否能完好地组合在一起）（针对集成的软件系统，主要揭露设计阶段产生的错误）
  集成测试时构建软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。其目标是利用已通过单元测试的构建建立设计中描述的程序结构
  增量集成程序以小增量的方式逐步进行构建和测试，这样错误易于分离和纠正，更易于对接口进行彻底测试，而且可以运用系统化的测试方法。
  自顶向下集成
  自底向上集成
• 确认测试（根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误）
  确认测试始于集成测试的结束，在那时已测完单个构件，软件已经组装成完整的软件包，接口错误已经被发现和改正。测试集中于用户可见的动作和用户可识别的系统输出。
  通过一系列表明软件功能与软件需求相符合的测试而获得的。即对于那些最终用户显而易见的错误。
• 系统测试（检测已集成在一起的产品是否符合系统规格说明书/系统工程的要求）
  including： 恢复测试 通过各种方式强制的让系统发生故障，并验证其能适当恢复；安全测试 验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵；压力测试 要求以一种非正常的数量，频率或容量的方式执行系统；性能测试 用来测试软件在集成环境中的运行性；部署测试 在软件将要运行的每一种环境中运行软件
• 验收测试（检测产品是否符合最终用户的需求）
• 回归测试 每当加入一个新模块作为集成测试的一部分的时候，回归测试重新执行已经测试过的某些子集，以确保变更没有传播不期望的副作用。回归测试有利于保证变更不引入无意识行为或者额外的错误。
• 冒烟测试

4.调试、调试&测试的关系

调试出现在成功的测试之后，测试发现错误后，调试修正错误
调试并不是测试，但是调试总是发生在测试之后，执行测试用例，对测试结果进行评估，期望的表现和实习表现不一致的时候，调试的过程就开始了。
调试试图找到隐藏在症状背后的原因，从而使错误得到修正。
区别：软件测试是软件测试人员和程序员都参与的一项工作，是贯穿整个生命周期的，只需要发现软件的错误，而软件调试主要是程序员自己参与，对程序（设计、编码）进行修改、排除错误，主要是在开发阶段。

调试方法：
蛮干法 最常用但是低效
回溯法
原因排除法
自动调试

5.测试覆盖度

测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一，来确定测试是否达到事先设定的测试任务完成的标准。测试覆盖率则是测试覆盖度评估中一种量化的表示方法，一般通过被测试的软件产品需求、功能点、测试用例数或程序代码行等来进行计算。

软件测试覆盖率常用的计算公式：
功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 （功能点）
需求覆盖率= 被验证到的需求数量 /总的需求数量 （需求）
覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 （测试用例）
逻辑覆盖测试是一种基本的白盒测试方法，主要的覆盖标准有：
语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
判定覆盖率= 判定结果被评价的次数 / 判定结果总数
条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
判定/条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
路径覆盖率= 至少被执行一次的路径数/程序总路径数
上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数上下文内的判定分支总数)
基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)

6.白盒/黑盒测试

白盒测试与黑盒测试分别有哪些测试方法？如何对具体问题测试？
白盒测试对程序模块的所有的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假” 白盒测试的两种情况都至少测试一次；白盒测试也叫逻辑覆盖法包括：语句覆盖，判定覆盖，条件覆盖
黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据， 来检查程序是否都能产生正确的输出。黑盒测试有等价类法和边界值分析法

概念（注意白/黑测试用例的区别）：
白盒测试：又称结构测试，这种测试方法把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，用以检查程序中所有逻辑路径是否都按预定的要求正确地工作
黑盒测试：又称行为测试，这种方法把测试对象看做一个黑盒子，测试人员完全不考虑程序内部特性和逻辑结构，只依据程序的需求规格说明书设计测试用例，检查程序的功能是否符合它的功能需求

适用：

7.代码圈复杂度的计算方法

公式:V(G)=区域数=判定节点数+1（还有其他公式，百度百科上有）

8.白盒测试：基本路径测试方法（清华例题）

• 基本路径法
  基本路径测试
  基本路径测试允许测试用例设计者设计出过程设计的逻辑复杂性测量，并以这种测量为直到来定义执行路径的基本集。执行该基本集导出的测试用例保证程序中的每一条语句至少执行一次。

9.黑盒测试：等价类划分方法（清华例题）

等价类划分是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。理想的测试用例可以单独发现一类错误，否则在观察到一般的错误之前需要运行许多测试用例。
等价类划分的测试用例设计师基于对输入条件的等价类进行评估。

20191206知识点

1. 画类图时，聚合情况相较于组合情况稍多，例如出现XX行为，XX列表，就要想到多个xx行为聚合成xx列表（比如外借，打印外借列表，就要想到是多个外借情况组成的外借列表；再比如书籍，书籍列表也是聚合关系）
2. 不同项目有不同功能，用来实现这些核心功能的代码就叫业务逻辑

20190806

• 涉及到概念同一本书上给出很多不同定义，两本书之间描述也有差异，答题时候怎么答？清华的定义比较简洁，涉及到概念答题时候答2-3句即可
• 软件过程模型后面几个类型（演化、增量、原型…）都挺像的，怎么区分？演化更类似于原型模型，先做出一个核心原型，再在这个基础之上进行用户反馈与完善；增量每次加一个功能；主要通过适用性来区分记忆吧
• 关于CMMI的连续式模型表示法，复书说4个能力等级，清书说6个能力等级？？统一按5个等级记吧
• 用例图中《extend》的作用？字面意思理解，实际应用看不太懂–include和extend的箭头都是指向被动方，include指向被包含的，extend指向被拓展的
• 用例的好坏判断？能用尽量少的用例去判断更多的条件，就称为好的用例
• 怎么判断一段代码的内聚程度？
• 状态机图（钱乐秋P164+关于状态机图各组成部分的定义有的看不太懂）参考ppt和网页版讲解
• 大纲条目里没有的还要看吗？比如清书14章web工程，15章软件维护与再工程等等等？不用
• 每次看书自己能总结出来的问题都不是特别多，就像硬往脑子里灌一样，感觉这样不对不好？所以要自己总结笔记，后期主要看自己总结的东西，重新翻一遍书的话耗时长效率又低
• 笔记怎么记？涉及的所有问题都依照答题时的思路来总结，就是说无论是画图还是概念性的问题，答题的时候怎么答，记笔记的时候就怎么写。也就是说不要照搬书，也不要写的太简短

理解性综述（自己总结）

软件过程：统筹安排软件生存周期过程中的所有工程
软件需求：从要解决什么问题的角度出发
软件设计与构造：逻辑设计+编码+围绕编码的详细设计如调试等
软件测试：找错+验证正确性，用来保证软件系统质量

参考书目

1. 《软件工程：方法与实践》
2. 《软件工程（第3版）》

参考资料

我重新装了系统，之前收藏过一个“8号风球”的博客，网址找不到了，他总结的各科非常棒，大家感兴趣可以去找一下。