1、第二章软件需求与软件需求规约背景介绍（1） 、需求与需求获取1. 需求定义（1） 一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统功能能力、性能参数或其它性质。（2） 需求的基本性质1、必要的，该需求是用户所要求的。2、无歧义的，该需求只能用一种方式解释。3、可测的，该需求是可进行测试的。4、可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。5、可测量的，该需求是可测量的。2. 需求分类 （1）、功能需求，是整个需求的主体。 （2）、非功能需求：性能需求、外部接口需求、设计约束和质量属性需求。1.外部接口需求：用户接口、硬件接口、软件接口、通信接口、内存约束、 运行及地点需求3.
2、需求发现技术1、自悟2、交谈3、观察4、小组会5、提炼注意：详细介绍自考通P7（2） 、需求规约1. 需求规约定义（1） 、是一个软件/产品/系统所有需求陈述的正式文档，它表达了一个软件/产品/系统的概念模型。（2） 、需求规约的基本性质1、重要性和稳定性程度：对需求进行分级。2、可修改的：在不过多地影响其他需求的前提下，可以容易的修改一个 单一需求。3、完整的：没有被遗漏的需求。4、一致的：不存在互斥的需求。2. 需求规约（草案）格式（1）、IEEE标准830- 1998(IEEE 1998) 描述的需求规约说明书模板。1、引言 目的、范围、定义、缩略语、参考文献、概述2、总体描述 产品描述
3、、产品功能、用户特性、约束、假设和依赖3、特定需求:是文档的技术核心4、附录5、索引3. 需求规约（规格说明书）的表达（1）、表达需求的语言。1、非形式化的需求规约2、半形式化的需求规约3、形式化的需求规约4. 需求规约的作用 1、需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。 2、需求规约是一个管理控制点 3、对于产品/系统的而设计，需求规约是一个正式的、受控的起始点 4、需求规约是创建产品验收计划和用户批的基础第三章结构化方法 （25分）（一）、结构化需求分析1.需求分析面临的挑战 问题空间理解 人与人之间的通信，“有效沟通” 需求的变化性2. 基础术语
4、1、数据：客观事物的一种表示2、信息：具有特定语义的数据3、数据：是信息的载体4、数据流：数据的流动5、加工：数据变换单元6、数据存储7、数据源和数据潭表达方式：数据流加工数据存储数据流数据潭3. 系统功能模型表示1、数据流图(DFD图) 一种表示数据变换的图形化工具2、数据流程图的元素 数据源/数据潭，数据流，数据加工，数据存储4. 建模过程1、 建立系统环境图，确定系统语境2、 自顶向下，逐步求精，建立系统的层次数据流图3、 定义数据字典定义数据流程图中所有数据流和数据存储的数据结构。 顺序结构: + 选择结构：| 重复结构: 子界: m.n4、 描述加工(1)判定表判断表(Decisio
5、n Table) 也称为决策表，是一个二维表，它说明了每一种条件组合所产生的结果。(2)判定树判断树(Decision Tree) 也称为决策树，是用来描述在一组不同的条件下，决策的行动是根据不同条件及其取值来选择的处理过程。业务规则的描述通常可以使用判断树这一过程描述工具。4、应用中注意的问题1、模型平衡问题 DFD图与数据字典的一-致 底层加工的处理逻辑描述，与数据字典一致2、信息的复杂性控制问题 上层数据流可以打包 下层模块个数: 7士2 每个加工的数据流不能太多:增加层次5、需求验证1、验证:必要性、无歧义性、可测性、可跟踪性、可测量性2、需求中发现的错误类型 不正确的事实: 40%
6、遗漏: 31% 不一致 13% 歧义性: 5% 错放: 2% 其它: 9%6.需求技术的基本特征需求技术的基本特征提供方便通信的机制鼓励需求分析人员使用问题空间的术语思考问题，编写文档提供定义系统边界的方法提供支持抽象的基本机制为需求分析人员提供多种可供选择的方案提供特定的技术，适应需求的变化（二）、结构化设计1.总体设计（以系统为对象）1、总体设计的任务：把系统的功能需求分配到一个特定 的软件系统结构中。2、引入了两个概念： 模块：软件中具有特定标识的独立成分 模块调用：木块之间的一种使用关系3.如何表达模块和模块调用?1、Your don提出的模块结构图2、层次图3、美国IBM公司提出的H
7、IPO图 H:层次图 IPO:输入/处理/输出图注意：图形解释图 自考通：P46P475、 总体设计的步骤将DFD图映射为设计层面的模块及模块调用。(1)将DFD图转换为初始的模块结构图(2)基于“高内聚、低耦合”的软件设计原理，通过模块化，将初始的模块结构图转化为最终的模块结构图。6、两种映射方法(1)变换设计 基于变换的数据流程图是个线性的顺序结构，由输入、输出和变换 中心三部分组成。变换型数据流程图是一个线性的顺序结构，由输入臂、输出臂和变换中心三部分组成。其中变换中心使系统数据发生本质的变化，输入臂将物理输入变换成逻辑输入，而输出臂则将逻辑输出变换成物理输出。 如果待分解的模块是-个数
8、据凝聚的模块，称该模块为以转换为中心的模块。可以把它分解为输入、处理、输出三大模块。(2)事务设计 基于事务的数据流程图中有一个事务处理中心，它将输入分为许多 相互平行的加工路径，然后根据输入的属性，选择某一加工路径。 如果模块为逻辑凝聚的模块，可以将它分解为-个检查业务类型的模块和一个调度模块，根据不同的业务类型，调度模块调用不同的下层模块。6、 模块化及其启发式规则(1)模块 执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成:模块接口和模块体。(2)模块化的两个问题 如何将系统分解成软件模块 如何设计模块7、 如何将系统分解成软件模块 “分而治之”和“抽象” 自顶向下，逐
9、步求精 形成模块层次结构8、 模块化把一个待开发的软件分解成若干个简单的、具有高内聚低耦合的模块，这一过程称为模块化。(1)模块耦合 耦合(coupling)是对两个模块之间相互依赖程度的一种度量。模块间的依赖程度越大，则其耦合程度也就越大;反之，模块间的依赖程度越小，则其耦合程度也就越小。(2)模块内聚是指一个模块内部个成分之间相互关联程度的度量。也就是说，内聚是对模块内各处理动作组合强度的一种度量。很显然，一个模块的内聚越大越好。(3)启发式规则“高内聚、低耦合”改进软件结构，提高软件独立性。模块分解模块规模适中力求深度、宽度、扇出、扇入适中。 深度:表示其控制的层数。 宽度:同一层次上模
10、块总数的最大值。 扇出:一个模块直接控制的下级模块的数据。 扇入:有多少个上级模块直接调用它。尽量使模块的作用域在其控制域内。 模块的控制域:这个模块本身以及所有直接或间接从属它的模块的集合。 模块的作用域:受该模块内一个判断所影响的所有模块的集合。尽力降低模块接口的复杂度力求模块功能可以预测9、模块间耦合类型内容耦合：一个模块直接修改或操作另一模块数据。公共耦合：两个模块共同引用一个全局数据项。控制耦合：一个模块向另一模块传递控制信号。标记耦合：一个模块向两个模块传递一个公共参数。数据耦合：模块之间通过参数来传递数据10、内聚的类型偶然内聚：模块的各成分没有任何关系。逻辑内聚：逻辑上相关的处
11、理放在一起时间内聚：模块内的功能在同一时间完成过程内聚：模块内的处理以特定的次序执行。通信内聚：操作同一数据集顺序内聚：一个成分的输出作为另一成分的辅。功能内聚：模块的所有成分完成单-的功能2.详细设计（以模块为对象） 具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构。 详细设计的目标：将总体设计阶段产生的系统高层结构映射为以相关术语表达的低层结构，也是系统的最终结构。1、结构化程序设计方法 是一种基于结构的编程方法，即采用顺序结构、选择结构和重复结构进行编程，其中每一结构只允许一个入口和一个出口。 结构化程序设计的本质是:使程序的控制流程线性化，实现程序动
12、态执行顺序符合静态书写的结构，提高程序的可读性。（1） 顺序结构(2)选择结构(3)多分支结构(4)循环结构2、详细设计工具 (1)程序流程图 程序流程图:程序流程图又称为程序框图，它是历史最悠久使用最广泛的描述过程设计的方法，然而它也是用得最混乱的一种方法。 (2)盒图(N-S图) 出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。（3）PAD图 PAD是问题分析图(Problem Analysis Diagram)的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，
13、将这种图翻译成程序代码比较容易。下图给出PAD图的基本符号。PAD图的基本符号(4)类程序设计语言PDLPDL也称为伪码，它是用正文形式表示数据和处理过程的设计工具。PDL具有严格的关键字外部语法，用于定义控制结构和数据结构:一般说来PDL是一种“混杂”语言，它使之一种语言(通常是某种自然语言)的词汇，同时却使用另一种语言( 某种结构化的程序设计语言)的语法。3、设计规约完整准确地描述满足需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能机制。设计规约包括概要设计规约和详细设计规约。(1)概要设计规约（1）指明高层软件体系结构（2）系统环境（3）软件模块的结构模块描述文件结构和全局数
14、据文件的逻辑结构 测试需求(2)详细设计规约详细设计规约主要作为软件设计人员与程序员之间交流的媒体。（1）各处理过程的算法（2）算法所涉及的全部数据结构的描述第4章 面对对象方法UML（1015）（1） 、UML术语表面向对象技术的发展中，一个重要的里程碑是UML。UML是一种可视化的语言，可用于规约系统制品、构造系统的制品、建立系统制品的文档，可以作为软件需求规约、设计和实现的工具。UMI方法学中不同抽象层次术语以及模型表达工具.或者说UML给出规约软件系统产品的术语和表达。1. 表达客观事物的术语1. 对象( object ) 对象(object)是系统中用来描述客观事物的实体。一个对象由
15、一组属性和对这组属性进行操作的一组方法组成。2.类类(Class) 是具有相同属性、操作、关系一组对象的集合，它为属于该类的全部对象提供的抽象描述，其内部包括属性和服务两个主要内容(2)类语义的进一步表达详细叙述类的职责通过类/操作的注解，详细注释类的定义通过类/操作的注解，详细注释各操作的前置条件和后置条件详述类的状态机(状态图)详述类的内部结构(活动图)类与其他类的协作 (协作图)(3)类的语义表达的详细程度取决于建模的意图 为了与最终用户和领域专家沟通:较低的形式化手 为了支持正向和逆向工程:采用较高的形式化手段 为了对模型进行推理，证明其正确性:采用很高形式化手段(4)类在建模中的用途
16、 模型化问题域中的概念 建立系统的职责分布模型 模型化建模中使用的基本类型 (5) 类要满足的基本条件 一个结构良好的类，必须符合下列条件:明确抽象了问题域或解域中某个有形事务概念包含了一个小的、明确定义的职责集，并能很好地去实现清晰地分离了抽象和实现3.接口(1)接口的含义 接口是操作的一个集合，其中每个操作描述了 类、构件或子系统的一个服务。(2)接口的表示 采用具有分栏和关键字的矩形符号来表示 采用小圆圈和半圆圈来表示(3)使用中的问题如何描述接口的语义应用中应当注意的问题 (4)应用中注意的问题接口只能被其它类目使用，其本身不能访问其它类目接口描述类的外部可见操作，通常是该类的一个特定
17、有限行为接口不描述其中操作的实现，也没有属性和状态接口之间没有关联、泛化、实现和依赖3.协作协作是一个交互，涉及交互的三要素:交互各方、交互方式以及交互内容。 4.用况(usecase)/用例对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。5.主动类 至少具有一个进程或线程的类。能够启动系的控制活动，并且其对象的行为通常与其它元素行为并发的 表示方法:两条竖线 用来模型化系统中的并发行为6.构件/组件 系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现 具有相同接口的构件可以相互替代 构件可以嵌套 构件用于表达解空间中可独立标识7.制品(Artifact)
18、 系统中包含物理信息的、可替代的物理部件 部署制品:这类制品是构成一个可执行系统必要而的制品，例如: DLL、 EXE文件 工作产品制品:这类制品本质上是开发过程的产物源代码文件、数据文件等用来创建部署制品的事物构成8.节点 节点是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。2. 表达关系的术语关联 关联反映了类和类之间的静态关系。关联在模型中，特别是在永久业务对象模型中是最基本的关系。 关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述。 链:对象之间具有特定语义关系的抽象关联的语义表达: 关联名 导航 角色 可见性 多重性:多重性(Multipli
19、city) 定义了与一个对象/类相联系的对象类出现一次，该对象/类可能出现的最小和最大的数目 限定符 聚合:一个类是另一类的一部分。 组合:是聚合的一种特殊形式 关联类具有关联和类特性的模型元素 约束有序(ordered)、无重复的(set) 、有重复的(bag)、有序集合(order set )、列表( list) 、只读(read only)泛化 特殊类(子类)的对象拥有其一般类(超类)的全部属性与服务，称作特殊类对一般类的继承(Inheritance)。 利用继承( inheritance)，子类以继承父类的属性和方法。子类/父类也可分别特殊类/一般类、子类/超类、派生类/基类等。实现/
20、实现 细化是类目之间的语义关系，其中一个类目规约了保证另一类目执行的契约。 用空心三角形的虚线表示。 在以下2个地方会使用实现关系:接口与实现它们的类和构件之间;用况与实现它们的协作之间。依赖 依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务。 用有向虚线段表示。依赖-依赖的的分类:(1)绑定(Bind )(2)导出(Derive )(3) 允许(Permit)(4)实例( Instant iate)关系术语的使用： 结构关系 继承关系 精化关系 依赖关系3. 表达组合信息的术语包 包:是模型元素的一个分组，一个包本身可以被嵌套在其它包中，并且可以含有子包和其它类型的模型元素包的可
21、见性符号包之间的关系访问( use access )引入( import )4. 面向对象建模过程的步骤1、需求获取 建立用况(use case)模型和用况场合2、需求分析 建立活动图和状态图 类图(建立域模型) 顺序图(实现用况)3、编写需求规格说明书4、需求验证（2） 、UML的模型表达格式1、类图 类图(class diagram) 表达了系统的静态结构信息，即系统是由哪些类组成的，这些类之间的关系是什么。 类图显示系统各个部分以及怎样将它们组装起来。2、 用况图(use case图) 用况是对一个参与者(actor )使用系统的一项功能时所进行的交互过程的一个文字描述序列。 用况图是一
22、种表达系统功能模型的图形化工具。用况图的6个模型元素: 主题 用况 参与者:系统用户、另一个系统、时间 关联、泛化、依赖用况是系统开发的起点 大多数的系统功能都可以表示成用况3、 状态图 状态图(state chart diagram) 使用状态、事件和转换来记录对象在其生命周期中所历经的状态序列对象的初始状态是图中任何事件都未对该对象起作用时的状态。状态代表对象生命周期中的某一瞬间。转换表明作为对事件的响应结果，对象将从一种状态转换到另-种状态并执行某个动作。触发状态转换的事件在状态转换字符串中命名。双击一个状态转换，除事件签名以外，还可用字符串为其加注临界条件、动作表达式等标签。状态图中的
23、3个术语: 状态:一个实例所处的特定阶段、所具对外呈现以及所能提供的服务 事件信号事件调用事件时间事件变化事件 状态转移4、顺序图 顺序图(sequence diagram) 表示了对象之间传送消息的时间顺序，也就是对象之间的交互顺序。 这些交互是指在场景或用况的事件流中发生的。 每一个对象(类)用一条生命线来表示即用垂直线代表整个交互过程中对象的生命期。顺序图中的基本元素包括:活动者，指用况中的活动者。对象，指在用况中的内部对象。生命线:在顺序图中的一个对象下面的竖线，用以显示这个对象的生命期。消息，指场景内由事件流定义的内部事件成为在对象和活动者或其他对象之间的消息。消息的类型：(1)同步
24、消息返回消息， 同步消息假定有一个返回消息，同步消息用有实心的箭头表示;返回消息用虚线、箭头也不用实心来表示:(2)反身消息消息的发送方和接收方是同一个对象;(3)异步消息没有返回值的消息，用非实心箭头表示(4)定时消息对消息附加时间约束条件，包括发送时间、接受时间、已用时间等;控制操作子:为了控制交互行为描述的复杂性，以便更清晰的表达顺序图中的复杂控制，UML给出了4中最常用的控制操作子. 1)选择执行操作子(Operator for Optional Execut ion该控制操作子记为Opt”, 由两部分组成，一是监护条件，二是控制体 2)条件执行操作子(Operator for Con
25、ditional Exee该控制操作子记为“alt” ,控制体通过水平线将其分成一些部分，每一部分表示一个条件分支，每个分支有一个监护条件。 3)并发执行操作子(Operator for Parallel Executior该控制操作子记为“par”，该控制操作 子的体通过水平线分为多个部分。每一部分表示一个并行计算。在大多数情况下每一部分涉及不同的生命线。该控制操作子表明，当进入该控制操作子时，所有部分并发执行。 4)迭代操作子Operator for Iterative Execution )控制操作子记为“loop”。第5章 面向对象方法RUP（1015）背景介绍统一软件开发过程(Rat
26、ional Unified Process: RUP) 是对象管理组织(OMG) 所推荐的一个有关过程的标准。RUP是基于UML的一种过程框架。比较完整地定义了将用户需求转换成产品所需要的活动集,并提供了活动指南以及对产生相关文档的要求。RUP适应于大多数软件系统的开发，基于构件。过程模型:1.需求获取模型2.需求分析模型3.软件设计模型4.软件实现模型5.软件测试模型（1） 、RUP的特点以用况驱动的、以体系结构为中心的迭代、增量式开发(1)用况驱动 在系统的生存周期中，以用况作为基础，驱动系统有相关人员对所要建立系统的功能需求进行交流，驱动系析、设计、实现和测试等活动，包括制定计划、分配任
27、监控执行和进行测试等，并将它们有机地组织在一起使各个阶段中都可以回溯到用户的实际需求。(2)以体系结构为中心系统体系结构:是对系统语义的概括对所有项目有关人员都是可以理解的。关注子系统、构件、接口、协作、关系点等重要模型元素，而忽略其其他细节(3)迭代与增量迭代是重复的部分增量是增加的部分 初始阶段的基本目标获得与特定用况和平台无关的系统体系结构轮廓为系统建立商业案例确定项目的边界从业务角度指出该项目的价值第一个重要的里程碑:生命周期目标(Lifecycle Objective)里程碑 细化阶段细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险第二个重要的里
28、程碑:生命周期结构(Liefcycle Architecture)里程碑构造阶段形成最终的系统体系结构基线开发完整的系统确保产品可以开始向客户交付第三个重要的里程碑:初始功能( InitialOperational)里程碑交付阶段确保软件对最终 用户是可用基于用户反馈的少量的调整第4个里程碑:产品发布(Product Release)里程碑（2） 、核心工作流1 需求获取 RUP运用用况(Use Case) 技术来获取需求 需求获取的基本步骤:列出候选的需求:特征列表理解系统语境:领域模型或业务模型捕获功能需求:用况模型捕获非功能需求:补充需求或针对一些特定的用况(1)列出候选的需求搜取特征:
29、是一个新的项( Item) 及其简要描述(2) 理解系统语境创建领域模型或业务模型业务用况模型:业务参与者和业务用况业务对象模型:三个术语:工作人员、业务实体、工作单元，用交互图和活动图来表达(3)捕获功能需求:建立系统的用况模型发现和描述参与者发现并描述用况确定用况的优先级精化用况构造用户界面模型用况模型的结构化2 需求分析 需求分析的目标:在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述1.术语(1)分析类:是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的。 存在三种不同类型的类:实体类、边界类和控制类 其表达方法如下图所
30、示:(2)用况细化 用况细化是一个协作。 针对一个用况，其行为可以用多个分析类之间的相互作用细化，并记为用况细化。(3)分析包 分析包体现了“局部化”“问题分离”等软件设计原理 分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况，形成一些不同的分析包 体现“高内聚、低耦合”2. 分析模型的表达 分析模型是由“分析系统”来定义的 分析系统包含一组具有层次结构的包 一个包可以包含一些分析类和用况细化3.分析的主要活动活动1:体系结构分析标识分析包处理分析包之间的共性标识服务包定义分析包的依赖标识重要的实体类标识分析包和重要实体类的公共特性需求活动2:用况分析标识分析类描述分析
31、类之间的交互活动3:类的分析标识责任标识属性标识关联和聚合包的分析活动4:包的分析 确保分析包尽可能与其它包相对独立 确保分析包实现了它的目标，即细化了某些领域类或用况 描述依赖3.需求分析总结 三个术语:分析包、分析类、用况细化 四个步骤体系结构分析细化用况对类分析对包进行分析 一个成果:分析模型3 设计 软件设计：定义满足需求规约所需要的软件结构 RUP的设计目标:定义满足系统/产品分析模型所规约需求的软件结构。1. 相关术语设计类用况细化设计子系统接口2.设计模型、部署模型及相关视角下的体系结构描述(1)设计模型:设计子系统设计类用况细化接口 (2) 部署模型:是一个对象模型，描述了系统
32、物理分布，即如何把功能分布于各个节点上。3、设计的主要活动活动1: 体系结构设计 标识节点和它们的网络配置 标识子系统和它们的接口 标识在体系结构方面有意义的设计类和它们的接口 标识一般性的设计机制活动2: 用况的设计 标识参与用况细化的设计类 标识参与用况细化的子系统和接口活动3: 类的设计 概括描述设计类 标识操作 标识属性 标识关联和聚合 标识泛化 描述方法 描述状态活动4: 子系统设计 维护子系统依赖 维护子系统所提供的接口 维护子系统内容4 RUP的实现和测试1. RUP的实现目标(1)基于设计类和子系统生成沟件(2)对构成进行单元测试(3)进行集成和连接(4)把可执行的构件映射到部
33、署模型2. RUP实现的主要活动(1)实现体系结构(2)集成系统(3)实现子系统(4) 实现类(5)完成单元测试3. RUP的测试包括：内部测试、中间测试和最终测试4. RUP测试包括的主要活动(1)计划测试(2) 设计测试(3)实现测试(4)执行集成测试(5)执行系统测试(6)评价测试第6章 软件测试（25分）（1） 、软件测试目标与软件测试过程模型1、 软件测试目标测试的目的应该是通过软件测试尽可能多地发现并改正软件种存在的错误。（1）软件测试的对象软件=程序+文档测试对象：各个阶段产生的源程序和文档。（2）软件测试的定义软件测试(Software Test ing)是按照特定规程发现软件
34、错误的的过程。使用人工或自动手段，运行或测定某个系统的过程，其目的是检验它是否满足规定的需求，或清楚了解预期结果与实际结果之间的差异。（3）“测试”和“调试”的区别 测试证明“失败”，调试证明“正确” 测试以已知条件开始测试时有计划的 测试是一个发现错误、改正错误、重新测试 测试的执行是有规程的 测试由独立的测试小组完成 测试的执行和设计可由工具支持2、 软件测试过程模型1、测试设计 环境模型 对象模型 错误模型2、测试执行3、测试结果比较（2） 、软件测试技术1、 路径测试技术 是一种白盒测试技术 依据的是程序的逻辑结构 采用控制流程图来表达被测程序模型。 通过合理地选择一组穿过程序的路径，
35、以达到某种测量度量。1、控制流程图 是一种表示程序控制结构的图形化工具，其基本元素是过程块、节点、判定。2、控制流程图路径:是由链组成的，包含一串指令或语句，其长度由链的数目决定。对软件测试而言，限定路径为:从程序的入口开始，在出口结束3、测试策略路径覆盖(PX) :执行所有可能穿过程序控制流程的路径。最强的测试度量。语句覆盖(P1) :至少执行程序中所有语句一次。最“低”的测试度量。分支覆盖(P2) :至少将程序中的每个分支执行一次。条件覆盖与条件组合覆盖几种测试覆盖存在以下基本关系:语句覆盖分支覆盖条件组合覆盖路径覆盖4、路径选取与用例设计最小的强制性测试需求是语句覆盖率。路径选取的一般原
36、则:(1)选择最简单的、具有一定功能含义的入口/出口路径；(2)在已选取的基础上，选择无循环的路径，选取短路径、简单路径；(3)选取没有明显功能含义的路径，要研究该路径为什么存在。2、 基于事物流的测试技术是一种功能测试技术属于黑盒测试技术1.事务:是指从系统用户的角度出发所见到的一个工作单元，有其“生”，有其“亡” 短信提醒 节日问候 数据更新事务由一系列操作组成，用“事务流”表达。事务流:是系统行为的一种表示方法，为功能测试建立了程序的动作模式。事务流程图:表达系统的行为，多个事务流的执行。事务流程图中的相关概念1、并生:事务处理产生一个新事务，由此这两事务继续执行。2、丝分裂:事务处理产
37、生两个新事务。3、汇集:事务的不同活动可以汇集一处。4、吸收:一个事务可以被另一个事务吸食5、结合:两个事务结合后产生一个新事务如何根据事务流程图设计测试用例？步骤1:获得事务流程图步骤2:浏览、复审步骤3:用例设计步骤4:测试执行2、等价类法 是根据程序的I/0特性，将程序的输入划分为有限个等价区段，使得从每个区段内抽取的代表性数据进行的测试等价于该区段内任何数据的测试。 对于每个输入条件存在着程序有效输入的有效等价类和对程序错误输入的无效等价类。1、如果某个输入条件规定了输入数据的取值范围，则可以确立一个有效等价类和两个无效等价类。2、如果某个输入条件规定了输入数据的个数，则可以确立一个有
38、效等价类和两个无效等价类。3、如果某个输入条件规定了输入数据的一组可能取的值,每一个输入值就是一个有效等价类，一个无效等价类。4、如果某个输入条件是一个布尔值，则可以划分一个有效等价类和一个无效等价类5、如果某个输入条件规定了必须符合的条件，则可以划分一个有效等价类和一个无效等价类。6、若在已划分的某个等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。3、边值分析法是一种根据I/O边界等价类上或紧靠边界的条件，选择测试用例的更有效的方法。4、因果图法因一输入条件和果一输出结果， 通达因果图将功能说明转换成一张判定表，然后为每种输件条件的组合设计测试用例。着重检查输入
39、条件的组合。原因和原因之间的约束关系(1) E (互斥) :只能有一个成立(2) I (包含) :至少有一个条件成立(3) O (唯一) :有且仅有一个成立(4) R (要求) :当a出现时，b必须出现(5) M (屏蔽) :当a=1时， b必须是0, 当a=0时，b的值不确定。用因果图生成测试用例的步骤步骤1:找出模块的原因(输入条件或输入条件的等价类)和结果步骤2:分析原因与结果之间的对应关系，画出因果图步骤3:在因果图上标识出一些特定的约束和限制条件步骤4:把因果图转化为判定表步骤5:把判定表的每一列作为依据，设计测试用例3、 其他功能测试技术简述（3） 、软件测试步骤1、 单元测试单元
40、测试(Unit Test ing)又称模块测试(ModuleTesting)，或模块分调，用于测试单个程序模块，确定模块的逻辑和功能是否正确。单元测试采用白盒测试技术。单元测试要考虑模块的4个特征:(1)模块接口(2)局部数据结构(3)重要的执行路径(4)错误执行路径单元测试还需要开发驱动模块和承接模块:(1)驱动模块:调用被测试模块的模块。(2)承接模块:被测试模块调用的模块。2、 集成测试 集成测试(Integr at ion Test ing)用来测试模块之间接口的正确性,也即模块之间的数据和控制传递。 集成测试是与单元测试平行进行的。两种策略: 自顶向下的集成测试:需要设计承接模块 自
41、底向上的集成测试:需求设计驱动模块每加只新的模块，还要进行回归测试。3、 有效性测试目标是发现软件实现的功能与需求规格说明书一致的错误。采用黑盒测试技术第七章软件生存周期过程与管理过程（一）、软件生存周期过程与管理1、引言2、ISO/IEC系统与软件工程软件生存周期过程122072008标准简介 2个过程类、7个过程组、43个过程。2个过程类“系统语境的过程”“软件开发的过程”。3、ISO/ IEC软件生存周期过程12207-1995标准软件生存周期过程的类型：1、 基本过程(1)指那些与软件生产直接相关的活动集。(2)包括5个过程:获取过程供应过程开发过程(1)开发过程包含的活动 过程实现过程实现包含的任务选择合适的生存周期模型选择相应的标准、方法、工具和程序设计语言制定实施开发计划可以使用一些非交付的软件项。 系统需求分析 建立系统需求规格说明 对系统需求进行评估有关获取方面需要的可追踪性有关获取方面需要的一致性可测
