画布 1
软件工程复习
  第一章 概述
    软件概念
      软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合
      程序是按事先设计好的功能性能要求执行的指令序列(instructions)
      数据是使程序能正常操纵信息的数据结构(data structures)
      文档是与程序开发，维护和使用有关的图文材料(documents)
    软件危机
      定义
        软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题
      表现
        对软件开发成本和进度的估计常常很不准确
        用户对“已完成的”软件系统不满意的现象经常发生
        软件产品的质量往往靠不住
        软件常常是不可维护的
        软件通常没有适当的文档资料
        软件成本在计算机系统总成本所占的比例逐年上升
        软件开发生产率提高的速度，远远跟不上计算机应用普及的速度
    软件工程
      定义
        IEEE
          把系统的、规范的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程应用于软件
          研究上述所提到的途径
      三要素
        三层（ 由低到高方向）：过程->方法->工具
    软件职业道德
      从不为了个人利益而窃取数据
      从不散布或售卖你所工作的软件项目的专利信息
      从不恶意地破坏或修改别人的程序、文件或数据
      从不侵犯别人、别的团队或组织的隐私
      从不为了某种利益而非法入侵别人的系统
      从不创建或传播计算机病毒
  第二章 软件过程
    软件过程描述
      软件过程流
        线性
          从沟通到部署顺序执行五个框架活动
        迭代
          在执行下一个活动前重复执行之前的一个或多个活动
        演化
          采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本
        并行
          将一个或多个活动与其他活动并行执行
    软件过程结构（4个基本活动）
      软件规格说明
        定义系统应该做什么
      软件设计与实现
        定义系统的架构和实现
      软件确认
        检验系统是否满足用户的需求
      软件演变
        随用户需求的变化变更系统
    软件过程模型
      瀑布模型
        定义
          传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述
          文档驱动的模型
        优点
          规范的方法
          文档驱动
          质量保证
        缺点
          文档驱动（需求规格说明），几乎完全依赖于书面的规格说明
        适用项目：适用于需求已明确定义且固定的项目
      快速原型模型
        定义
          所谓“快速原型”， 是快速建立起来的、可在计算机上运行的程序，它所能完成的功能往往是最终的软件产品所能完成的功能的子集
          有助于所开发出的软件产品满足用户的真实需求
        优点
          基本上是线性开发
          确保交付的产品满足用户的需求
        缺点
          产品的先天性不足，因为开发者常常需要做实现上的折中，可能采用不合适的操作系统或程序设计语言，以使原型能够尽快工作
        适用项目：适用于用户驱动的系统（需求模糊或随时间变化）
      螺旋模型
        增加了风险分析的快速原型模型
      增量模型
        优点
          用户可以更早的使用软件
          软件的核心功能能够得到更充分的测试
        缺点
          再把新的增量构件集成到现有软件体系结构中时，必须不破坏已经开发出来的软件，因此，软件体系结构必须开放
        适用项目
          初始的软件需求明确；需要向用户快速提供一个有限功能的软件，在后续版本中精化和增加功能
      喷泉模型
        喷泉模型是一种以用户需求为动力，以对象作为驱动的模型
        适合于面向对象的开发方法
      Rational统一过程（RUP）
        三个视图
          动态视图
          静态视图
          实践视图
        四个阶段
          初始阶段Inception
          精化阶段Elaboration
          构建阶段Construction
          移交阶段Transition
        工作流（9个）
          核心过程工作流
            业务建模
            需求
            分析与设计
            实现
            测试
            部署
          核心支持工作流
            配置与变更管理
            项目管理
            环境
        最佳实践（6个）
          迭代式开发、管理需求、使用基于构件的体系结构、可视化建模（UML）、验证软件质量、控制软件变更
        优点
          提高了团队生产力
            它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性
        缺点
          RUP只是一个开发过程，并没有涵盖软件过程的全部内容
        适用项目
          多功能和广泛适用
    敏捷软件开发
      敏捷宣言
        个体和交互胜过过程和工具
        可以工作的软件胜过面面俱到的文档
        客户合作胜过合同谈判
        响应变化胜过遵循计划
      敏捷=理念+优秀实践+具体应用
      极限编程XP（eXtreme Programming）
        用户故事
        重构Refactoring
          定义
            在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构
          重构方法
            提炼函数（Extract Method）
              将一些与此函数相关性不大的语句提炼至其他函数
            函数改名（Rename Method）
              修改函数的参数名，使其具有自解释性（self-explanation）
            搬移函数（Move Method）
            内联函数（Inline Method）
              在编译时将指定函数体插入函数调用处，节省函数调用带来的时间开支
            内联临时变量（Inline Temp
        TDD（测试驱动开发）
          XP 测试特性
            测试驱动开发（Test-driven development，TDD）
            用户参与测试开发和确认的过程
            使用自动化测试框架
        结对编程
        持续集成
  第三章 需求工程
    需求过程概述
      需求工程定义
        对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程
      需求工程包含两个方面
        需求开发
        需求管理
      需求的两个层次
        用户需求
        系统需求
      需求的两种类型
        功能需求
        非功能需求
    需求获取和分析
      过程
      技术
        访谈 (Interviews)
        情景 (Scenarios)
        用例 (Use cases)
        原型 (prototypes)
    需求规格说明( SRS，software requirements specification)
      将用户需求（不包含技术信息）、系统需求（包含系统信息：使用自然语言、图形模型、数学模型）文档化的过程
    需求验证
      一致性
      完整性
      现实性
      有效性
    系统建模
      模型分类
        环境模型
        交互模型
          用例图
          顺序图
        结构模型
          类图
        行为模型
          状态图
        数据驱动模型
          数据流图
      系统建模方法
        结构化分析SA
          数据模型
            实体-联系图ER图
              银行计算机储蓄系统
          功能模型
            数据流图DFD
            数据字典DD
              定义
                是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合
              内容
                数据流
                数据流分量（数据元素）
                数据存储
                处理
            数据流图和数据字典共同构成系统的逻辑模型。没有数据字典，数据流图就不严格，然而没有数据流图，数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明
          行为模型
            状态转换图P65
        面向对象分析OOA
          面向对象方法学概论
            面向对象基本概念
              对象(object)
                对象是由现实世界实体的正确抽象，它是由描述内部状态表示静态属性的数据，以及可以对这些数据施加的操作封装在一起的统一体。这个封装体有可以唯一标识它的名字，而且向外界提供一组服务（即共有操作）
              类(class)
              消息(message)（合作之道）
              封装(encapsulation)
              继承(inheritance)
              多态(polymorphism)
            统一建模语言UML
              用例图
              顺序图（SD）
              类图
            面向对象开发软件，需要建立3种形式的模型
              对象模型：描述系统数据结构—数据结构。
              动态模型：描述系统控制结构—执行操作。
              功能模型：描述系统功能—数值变化
          面向对象建模
            基于场景建模
              统一建模语言UML
                用例图
                  用例之间的关系有扩展和包含
                    图书管理系统用例图
                顺序图SD
                  用户登录
                    上传数据
                类图
                开发活动图
                泳道活动图
                  注意开头和结尾的实心圆
            基于类建模
              CRC模型（类-职责-协作者）
                识别和组织与系统或产品需求相关的类，表示类的标准索引卡片的集合
                表示类的标准索引卡片的集合
                  顶部：类名
                  左侧：类的职责
                  右侧：类的协作者
            基于行为建模
  第四章 面向对象分析OOA
  第五章 设计
    设计概述
      从技术角度，设计分为4部分
        数据/类设计
          将类模型转化为设计类的实现和必要的数据结构
        体系结构设计
          定义软件系统各主要成份之间的关系
        接口设计
          软件内部各成份之间、软件与其它协同系统之间及软件与用户之间的交互机制
        构件设计
          把软件系统各主要成份转换成软件构件的过程性描述
      从管理角度，设计分为2阶段
        概要/总体设计
          总体/概要设计的目标是什么？
            将软件需求转化为数据结构和软件的系统结构
        详细设计
          通过对结构表示进行细化，得到软件的详细的数据结构和算法
      顺序图能为接口设计提供哪些信息？
    设计概念/原理（五个）
      模块化(Modularity)
        就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求
      抽象(Abstraction)
        现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。
      逐步求精(Stepwise Refinement)
        定义：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑
        是人类解决复杂问题时采用的基本方法，也是许多软件过程技术的基础
        Miller法则：一个人在任何时候都只能把注意力集中在(7±2)个知识块上
      信息隐藏(Information Hiding)
      模块独立
        耦合（Coupling)
          定义
            是对一个软件结构内不同模块之间互连程度的度量。耦合要低，即每个模块和其他模块之间的关系要简单
          实例（非苏特空外共内）
            非直接耦合（good）
            数据耦合
              两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据
            标记/特征耦合
              把整个数据结构（记录、数组等）作为参数而调被调用的模块只需要其中一部分数据元素
            控制耦合
              两个模块彼此之间传递的信息中有控制信息
            外部耦合
              模块与外部环境（操作系统函数、通信功能等）连接在一起，并受到约束时就出现较高程度的耦合
            公共耦合
              两个或多个模块通过访问同一个公共数据环境相互作用
                访问全局变量
                读写同一个数据库的同一个记录
            内容耦合（bad）
              一个模块内的分支转移到另一个模块之中
          应 该 采 取 下 述 设 计 原 则 ：
尽 量 使 用 数 据 耦 合 ，
少 用 控 制 耦 合 和 标 记 耦 合 ，
限 制 公 共 环 境 耦 合 的 范 围 ，
完 全 不 用 内 容 耦 合 。
        内聚(Cohesion)
          定义
            标志一个模块内部各个元素彼此结合的紧密程度。简单地说， 理想内聚的模块只做一件事情。内聚要高，每个模块完成要高相对独立的特定子功能。
          实例（偶螺蛳过通顺能）
            偶然内聚（ bad）
              一个模块内执行多个完全不相关的操作
              例：一组语句在程序的多处出现，为了节省内存空间把这些语句放在一个模块中
            逻辑内聚
              把几种功能组合在一起（类似于瑞士军刀），每次调用时，由传递模块的判定参数来确定该模块应执行哪一种功能
            时间内聚
              一个模块包含的任务必须在同一时间段内执行
            过程内聚
              一个模块内的处理元素是相关的，而且必须以特定次序执行
            通信内聚
              如果模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据，则称为通信内聚。即在同一个数据结构上操作
            顺序内聚
              如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，则称为顺序内聚
              通常顺序内聚中一个处理元素的输出是另一个处理元素的输入
              例：
            功能内聚（ good）
              模块内所有处理元素属于一个整体，完成一个单一的功能
              例：按给出的生日计算雇员年龄的子程序
          由上至下，效果越好
        内聚性显示了某个模块相关功能的强度，耦合性显示了模块间的相互依赖性。 模块设计追求高内聚，低耦合
    面向对象设计OOD
      面向对象设计准则
        弱耦合
          交互耦合
            消息连接（要松散）
          继承耦合
            互为基类和派生类（要紧密）
        强内聚
          服务内聚
            一个服务应该完成一个且仅完成一个功能
          类内聚
          一般-特殊内聚
            设计出的一般-特殊结构，应该符合多数人的概念，是对相应领域知识的正确抽取
        可重用
      设计类（了解一下）
      设计模型（了解一下）
      设计过程
        类设计
        体系结构设计
        接口设计
        构件设计
    体系结构设计
      体系结构设计概述
      体系结构设计决策
      体系结构风格（style）
        定义
          不同系统的体系结构设计方案存在着许多共性问题，把这些共性部分抽象出来，就形了具有代表性的和可广泛接受的体系结构风格
        经典体系结构风格
          数据为中心体系结构
          管道-过滤器体系结构
          主程序子程序
          分层体系结构
          客户机/服务器体系结构
          MVC
      应用体系结构
    构件设计
      定义
        系统中的一个模块化的、可部署的、可替换的部件，它封装了内部实现并提供了一系列的对外接口，这个部件称作构件
      设计过程
        第一次迭代：构件中的每个类都包括和实现相关的所有属性和方法
        第二次迭代：为每个属性定义合适的数据结构；为每个方法设计算法（活动图、过程设计方法）
        定义每个类和其它类进行通信的所有接口
      软件重用
        类构件复用方式
          实例复用
          继承复用
          多态复用
      基本设计原则
        开闭原则（ OCP） —— 抽象是关键
        针对接口编程原则 —— 针对抽象编程
        类的单一职责原则（ SRP）
          搜索引擎的设计图
        Liskov替换原则（ LSP）
        接口隔离原则（ ISP）
        迪米特法则（ LoD）
        合成/聚合复用原则 ( CARP )
      构件详细设计
        程序流程图
          程序流程图中经常使用的基本符号如图所示
            ”→“代表控制流
        盒图（N-S图）
        问题分析图（PAD图）
        判定表、判定树
        PDL伪代码
      基于构件的软件工程-CBSE
        两个子过程
          领域工程
            识别、开发、分类、传播面向特定应用领域的软件构件，形成可复用的构件库
          基于构件的开发
    用户界面设计
      黄金规则
        置于用户控制之下
        减少用户记忆负担
        保持界面一致
    基于模式的设计
      设计模式的概念
      分类
      工厂模式
      模板方法模式
  第六章 实现
    编码
      定义
        把软件设计结果翻译成用某种程序设计语言书写的程序
      良好编程实践
        变量的命名要有意义且一致
        代码的self-documenting
        使用参数
      编码风格
        程序内部的文档
        数据说明
        语句构造
    软件配置管理SCM
      概念
        软件配置管理（SCM）
          定义
            软件配置管理是在软件的整个生命周期内管理变化的一组活动
        软件配置SC（SoftwareConfiguration）
          计算机程序（源代码和可执行程序）
          描述计算机程序的文档（针对技术开发者和用户）
          数据（包含在程序内部和程序外部）
          在技术文档中明确说明最终组成软件产品的功能或物理属性
          包含了所有在软件过程中产生的信息
        基线（Baseline）
          IEEE定义
            已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它
              简而言之，就是通过了正式复审的软件配置项
          PPT定义
            基线是评审过的一个或多个SCI，每一个基线都是下一步开发的出发点和基础，是软件开发中的里程碑
          类型
            功能基线（Functional Baseline）
            分配基线（Allocated Baseline）
            产品基线（Product Baseline）
            PPT跟教材上根本就没有你敢信？
          在SCI变成基线之前，变化可以迅速而非正式地进行。一旦基线已经建立，变化可以进行，但是，必须应用特定的、正式的规程来评估和验证每个变化
        配置管理库（ SCM Repository）
          定义
            配置管理库也称受控库，用于存储软件配置项以及相关配置管理信息
      配置管理过程（5项任务）
        标识软件配置中的对象
        变更控制
          流程
        版本控制
          分支与合并
        配置审计
        状态报告
    质量管理
      原则
      过程
      软件质量
      软件质量保证（SQA）
        SQA主要措施
          评审和审计
            技术评审
            代码审查
          软件测试
          程序正确性证明
    软件度量（3个维度）
      定义
        软件度量（ Metrics）是指对软件产品、软件开发过程及软件开发项目的定量描述
      3个维度
        产品度量
          需求模型度量
            功能点度量FP
              考课上例题
          设计模型度量
          源代码度量
        过程度量
        项目度量
  第七章 软件测试
    软件测试基础
      目标/定义
        测试是为了发现程序中的错误而执行程序的过程
      准则
      方法
        黑盒测试（功能测试）
        白盒测试（结构测试）
    软件测试策略
      单元/模块测试
        5个测试重点
          模块接口
            确保数据能够正确地进出构件
          局部数据结构
            确保程序执行过程中临时存储的数据的完整性
          重要执行通路
            测试最有代表性、最可能发现错误的执行通路，发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误
          错误处理路径
            设置适当的处理错误的通路，并认真测试这些通路
          边界条件
            处理数组 n 的第 n 个元素，i 次循环中的第 i 次迭代时的检测，检测最大值或最小值的边界
        单元测试过程
          驱动程序Drive
          存根程序Stub
        自动化测试
          测试过程自动化
          测试用例的自动化生成
        驱动程序和存根程序代表测试开销，通常并不把它们作为软件产品的一部分交给用户
      集成测试
        非渐增式测试
          把所有模块组合在一起,并把庞大的程序作为一个整体来测试
            优点：测试次数少，节约时间
            缺点：测试程序庞大，难以精确定位错误
        渐增式测试
          逐个把未经过测试的模块组装到已经测试过的模块上去，进行集成测试。每加入一个新模块进行一次集成测试，重复此过程直至程序组装完毕
            优点：每次测试小部分程序，容易定位和改正错误
            缺点：测试次数较多
        回归测试
          回归测试是指重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用
      确认测试
        Alpha测试
        Beta测试
      系统测试
    软件测试技术
      白盒测试（结构测试）
        逻辑覆盖（5种）
          语句覆盖
            最弱
          判定覆盖（分支覆盖）
          条件覆盖
          判定/条件覆盖
          条件组合覆盖
            最强
        基本路径测试（4个步骤）
          画出流图（ Flow graph）
          计算环形复杂度
          以该复杂度为指南定义独立路径的基本集合
          从该基本集合导出测试用例
        课上例题
          设计判定覆盖测试用例
设计条件组合覆盖测试用例
          使用基本路径测试方法，设计测试上面伪码程序的测试用例
      黑盒测试（功能测试）
        等价类划分
        边界值分析
        错误推测
Copyleft (c) 2020 by 御风.
No rights reserved.
例题答案采用了一些同学的作业截图
关于二级分支的划分，可按照老师的复习建议来
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。
程序是按事先设计好的功能性能要求执行的指令序列(instructions)
数据是使程序能正常操纵信息的数据结构(data structures)
文档是与程序开发，维护和使用有关的图文材料(documents)
软件 = 程序+数据+文档
程序 = 算法+数据结构
扇出是一个模块直接控制的模块数量
一个模块的扇入表明有多少个上级模块直接调用它；
好的软件系统，往往顶层高扇出、底层高扇入
要求掌握每种模型的特点、优缺点和适用项目类型
所谓“快速原型”， 是快速建立起来的、可在计算机上运行的程序，它所能完成的功能往往是最终的软件产品所能完成的功能的子集。 原型是软件开发人员与用户沟通的强有力工具，因此有助于所开发出的软件产品满足用户的真实需求
螺旋模型将瀑布模型和快速原型模型结合起来，将软件过程划分为若干个开发回线，每一个回线表示开发过程的一个阶段
增量模型也称为渐增模型
迭代是软件开发过程中普遍存在的一种内在属性。在面向对象范型中，软件开发过程各阶段之间的迭代或同一阶段内各个工作步骤之间的迭代，比在结构化范型中更常见
用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层功能分解的系统分析方法来定义系统的需求。（数据与处理过程分离）
包含数据对象、数据对象的属性以及数据对象彼此之间相互连接的关系
是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换
画数据流图步骤
首先画系统的输入输出，即先画顶层数据流图。顶层流图只包含一个加工，用以表示被开发的系统，然后考虑该系统有哪些输入数据，这些输入数据从哪里来；有哪些输出数据，输出到哪里去。
画系统内部，即画下层数据流图。一般将层号从０开始编号，采用自顶向下，由外向内的原则。
注意事项
命名。不论数据流、数据存储还是加工，合适的命名使人们易于理解其含义。
一般不画物质流。数据流反映能用计算机处理的数据，并不是实物，因此对目标系统的数据流图一般不要画物质流
父图与子图的平衡。子图的输入输出数据流和父图相应加工的输入输出数据必须一致，此即父图与子图的平衡。
局部数据存储。当某层数据流图中的数据存储不是由图中相应加工的外部接口，而只是本图中某些加工之间的数据接口，则称这些数据存储为局部数据存储。
提高数据流图的易理解性。注意合理分解，要把一个加工分解成几个功能相对独立的子加工，这样可以减少加工之间输入、输出数据流的数目，增加数据流图的可理解性。
是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为
所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述；建立模型是为了减少复杂性
用例图的模型元素有系统、行为者、用例以及用例之间的关系这四种
用例之间的关系有扩展和包含
扩展extend：将主用例的异常行为或可选分支抽象为扩展用例
包含include：将不同用例的共同行为提取为一个用例
对系统中对象间的相互建模
对用例图的补充说明，描述用例中交互的例子
每个模块完成一个相对独立的子功能，并且和其他模块间的接口简单
怎么做构件组合、领域工程的基本概念
通常把编码和测试统称为实现。
基于非执行的测试+基于执行的测试+程序正确性证明
软件开发过程中所生成的各种文档和程序
假设使用FP估算的方法估算出某系统的功能点数为375，这类系统的平均生产率为6.5功能点/人月，开发人员价格是每月8000元
1、计算每个功能点的成本
2、估算项目总成本
3、工作量估算是多少人月？
与软件开发有关的各种活动，如软件设计等
度量项目规模、项目成本、项目进度等
所有测试都应该能追溯到用户需求
应该远在测试开始之前就制定出测试计划
把Pareto原理应用到软件测试中（80%/20%原理）
应该从“小规模”测试开始，并逐步进行“大规模”测试
穷举测试是不可能的
为了达到最佳的测试效果，应该由独立的第三方从事测试工作
黑盒测试(功能测试)
把程序看做一个黑盒子
完全不考虑程序的内部结构和处理过程
是在程序接口进行的测试
白盒测试(结构测试)
把程序看成装在一个透明的盒子里
测试者完全知道程序的结构和处理算法
目的：是保证每个模块作为一个单元能正确运行。在编写出源程序代码并通过了编译程序的语法检查之后，就可以用详细设计描述作指南，对重要的执行通路进行测试，以便发现模块内部的错误。
回归测试是指重新执行已经做过的测试的某个子集，以保证测试过程中的变化没有带来非预期的副作用。
回归测试用于保证由于测试或其他原因引起的变化，不会导致非预期的软件行为或额外错误。
 回归测试可以通过重新执行全部测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具自动进行。
确认测试必须有用户积极参与，或者以用户为主进行。
软件配置复查
Alpha测试：
由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。在受控的环境中进行。
Beta测试（验收测试）：
由软件的最终用户们在一个或多个客户场所进行。开发者通常不在现场。用户记录测试过程中遇到的问题，并报告给开发人员。
系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。
测试类型：功能测试、性能测试、压力测试、安全性测试、恢复测试、安装测试
注意与流程图的区别
注意结点合并以及映射方法
主要思想：把软件的输入数据集合按输入条件划分为若干个等价类，从中生成测试用例
主要思想：处理边界情况时程序最容易发生错误，测试时需要特别考虑等价类的边界值
一个含有n个变量的程序，边界值分析会产生4n+1个测试用例
健壮性边界分析
一个含有n个变量的程序，边界值分析会产生6n+1个测试用例
错误推测法在很大程度上靠直觉和经验进行。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案