一、CMM( 能力成熟度模型 )

CMM 将软件过程改进分为以下五个级别

初始级：杂乱无章，没有明确定义的步骤
可重复级：建立了基本的项目管理过程和实践，有必要的过程准则来重复以前在同类项目中的成功
已定义级：软件过程文档化、标准化
已管理级：制定了软件过程和产品质量的详细度量标准
优化级：加强了质量分析，通过过程质量反馈、新观念、新技术等不断改进

二、 CMMI( 能力成熟度集成模型 )

阶段式模型，结构类似 CMM ，关注组织的成熟度

• 初始的，过程不可预测缺乏控制
• 已管理的，过程为项目服务
• 已定义的，过程为组织服务
• 定量管理的，过程已度量和控制
• 优化的，集中于过程改进

连续式模型，关注每个过程域的能力

• CL0( 未完成的 ) ：表明过程域的一个或多个目标没有被满足
• CL1( 已执行的 ) ：过程域特定目标完成，转化可识别的输入目标产品，产生可识别的输出目标产品
• CL2( 已管理的 ) ：已管理的过程制度化，关注针对单个过程实例的能力
• CL3( 已定义级 ) ：已定义的过程制度化，关注过程的组织标准化及部署
• CL4( 定量管理级 ) ：可定量管理的过程制度化
• CL5( 优化的 ) ：优化的过程制度化，持续改进优化

三、瀑布模型

1. 瀑布模型是将软件生命周期中各个活动，规定为依线性顺序链接的若干阶段模型
2. 需求分析 》 设计 》 编码 》 测试 》 运行与维护，由前至后，相互衔接的固定次序
3. 瀑布模型假设，一个待开发的系统需求是完整的，简明的，一致的，而且可以先于设计和实现之前完成
4. 以项目的阶段评审和文档控制来对开发过程进行指导
5. 优点：

• 容易理解，管理成本低
• 强调开发早期计划，需求调研，和产品测试
• 适合开发需求明确的，大致固定不会随意变更的系统

• 缺点：

• 客户必须要完整的，正确的，清晰的表达出需求
• 开始的两到三个阶段很难评估进度
• 接近项目结束时，出现大量的集成和测试工作
• 项目结束之前都不能演示系统能力
• 需求或者设计中的错误，到了项目后期才能发现
• 项目风险控制能力较弱

• V 模型是瀑布模型的一个变体，重点在于质量保证活动和沟通，将基本问题逐步细化，实际上执行了一系列测试

四、增量模型

1. 融合了瀑布模型的基本成分，和原型实现的迭代特征，它假设可以将需求分段为一系列的增量，每一个增量可以分别开发
2. 第一个增量往往是核心产品，客户对每个增量的使用和评估都作为下一个增量的新特征和功能
3. 每个增量均发布一个可操作版本

优点：

1. 具有瀑布模型的所有优点
2. 第一个可交付版本所需的成本时间很少
3. 开发由增量表示的小系统所承担的风险不大

缺点：

1. 如果没有对用户的变更要求有规划，那么产生的初始增量可能造成后续增量的不稳定
2. 管理成本、进度、复杂性

五、演化模型

1. 演化模型是迭代的过程模型，使得软件开发人员能够逐步的开发出更完整的软件版本
2. 演化模型特别适合对软件需求缺乏准确认识的情况，
3. 典型的演化模型有，原型模型和螺旋模型
4. 演化模型与增量模型区别：增量每次开发的时小的功能模块，演化每次开发整个产品

六、原型模型

1. 原型模型比较适合用户需求不清、需求经常发生变化的情况，当系统规模不是很大，也不太复杂时采用比较合适
2. 一个原型不必满足目标软件的所有约束，其目的是能快速、低成本的构建原型，迅速的开发出一个看得见摸得着的系统框架
3. 步骤：交流沟通 》 快速计划 》 快速设计方式建模 》构建原型 》部署交付和反馈 – 完成后继续循环步骤
4. 原型始于沟通其目的是为了定义软件的总体，有效的捕获用户需求
5. 原型模式不适合大规模的系统开发

七、螺旋模型

1. 螺旋模型将瀑布模型和演化模型相结合，加入了两个模型都忽略了的风险分析
2. 每个螺旋周期和瀑布模型大致相符合
3. 每个螺旋周期分为四个步骤

• 制定计划：确定软件目标，制定实施方案，明确项目开发的限制条件
• 风险分析：识别风险、消除风险
• 实施工程：软件开发、验证阶段性产品
• 用户评估：提出修正建议，制定下一周期开发计划

• 螺旋模型的特点是加入了风险分析，适合大规模、高风险、需求变化的系统
• 缺点：过多的迭代次数，会增加开发成本，延迟提交时间

八、喷泉模型

1. 喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合与面向对象的开发方法
2. 喷泉模型克服了瀑布模型不支持软件重用，和多项开发活动集成的局限性
3. 喷泉模型的开发过程具有迭代性和无间隙性
4. 无间隙是指在开发活动（分析、设计、编码）之间不存在明显边界，允许活动交叉、迭代进行

优点：

• 软件开发效率高，节省开发时间

缺点：

• 开发阶段重叠，需要大量开发人员，管理成本高
• 需要严格的管理文档，审核难度大
• 需要严格的管理文档，审核难度大

九、统一过程模型（ UP ）

1. 是一种 用例和风险驱动，以架构为中心，迭代并增量的开发过程
2. 每次迭代有 5 个核心工作流
3. 统一过程的四个技术阶段及里程碑

• 起始阶段：专注于项目初创；里程碑：生命周期目标
• 精化阶段：需求分析和架构演进；里程碑：生命周期架构
• 构建阶段：关注系统的构建，产生实现模型；里程碑：初试运作功能
• 移交阶段：关注软件提交方面的工作，产生软件增量；里程碑：产品发布

十、敏捷开发

1. 总体目标是尽可能早、持续地对有价值的软件交付
2. 敏捷开发使用户能够在开发周期的后期增加或改变需求
3. 极限编程 (XP)

• XP 是一种轻量级（敏捷）、高效、低风险、柔性、可预测、科学的软件开发方式
• XP 的四大价值观：沟通、简单性、反馈、勇气
• 5 个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作
• 12 个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周 40h 、现场客户和编码标准

    4.水晶法 (Crystal) ：每一个不同的项目都需要一套不同的策略、约定和方法论

    5.并列征求法 (Scrum)：使用迭代的方法，每 30 天一个冲刺，按需求级别来实现产品

• 自适应软件开发(ASD)： 6 个基本原则

• 有一个使命作为指导
• 特征被视为客户价值的关键点
• ”重做“与”做“同样关键
• 变化不被视为改正，而是 ”调整“
• 交付时间迫使考虑每一个生产版本的关键需求
• 风险包含

敏捷统一过程（ AUP ） : 采用 ”在大型上连续，在小型上迭代“的原理来构建
每个 AUP 执行以下活动：建模、实现、测试、部署、配置及项目管理、环境管理

十一、需求分析

1. 软件需求：指用户对目标软件在功能、行为、性能、设计约束等方面的期望
2. 功能需求 : 考虑系统做什么、何时做
3. 性能需求
4. 用户或人因素：用户理解使用系统难度、错误操作的可能性
5. 环境需求：硬件或软件环境，机型，操作系统，平台
6. 界面需求：考虑来自其他系统输入输出，数据格式存储介质规定
7. 文档需求：文档针对那些读者
8. 数据需求：接收发送数据格式
9. 资源使用需求：运行所需计算机资源，维护所需人力
10. 安全保密需求：数据隔离，系统备份
11. 可靠性需求：隔离错误，出错重启等待
12. 软件成本消耗和开发进度
13. 其他非功能性需求

十二、概要设计

1. 设计软件系统的总体结构：将复杂系统按功能分成模块，并确定模块的功能、调用关系、接口、结构和质量
2. 数据结构及数据库设计：数据库设计（概念设计 E-R 、逻辑设计、物理设计）
3. 编写概要设计文档：概要设计说明书、数据库设计说明书、用户手册、修订测试计划
4. 评审

十三、详细设计

1. 对每个模块进行详细的算法设计
2. 对模块内的数据结构进行设计
3. 对数据库进行物理设计
4. 其他设计
5. 编写详细设计说明书
6. 评审

十四、系统测试

1. 系统测试的意义：为了发现错误而执行程序的过程，成功的测试就是发现了至今为发现的错误
2. 测试的目的：以最小的人力和时间发现潜在的各种错误和缺陷
3. 测试的基本原则：

• 尽早和不断的测试，贯穿整个开发阶段
• 避免由原开发人员进行测试
• 测试时要有预期的输出结果，与测试结果作比较
• 关心不合理的输入或操作造成的结果
• 不仅要检查程序是否做了该做的事，还要检查程序是否做了不该做的事
• 严格按照计划测试，避免随意性
• 妥善保存测试用例及相关文档
• 后续测试以前次测试的基础上修改
• 系统测试的测试目标来源于需求分析阶段

十五、单元测试

1. 单元测试又称为模块测试，在模块编写完成且没有编译错误后开始执行
2. 单元测试侧重于模块内部的处理逻辑与数据结构
3. 单元测试检查模块的 5 个特征

• 模块接口：保证测试模块的数据流可以正常输入输出；测试：形参与实参是否匹配，全局变量使用， I/O 格式 , 文件处理等
• 局部数据结构：测试：变量定义及使用
• 重要的执行路径
• 出错处理
• 边界条件

     4. 单元测试过程

• 由于模块不是独立运行的，各模块之间存在调用与被调用关系，因此测试时需要开发两种模块

• 驱动模块：相当于一个主程序，接收测试用例的数据，将数据输入到被测试模块，输出测试结果
• 桩模块（存根模块）：用来代替 被测试模块所调用的子模块，检测测试模块的输入

     5. 高内聚可以简化单元测试

十六、集成测试

1. 集成测试就是将模块按照系统说明书组合起来测试，旨在发现与接口相关错误
2. 集成后可能出现的问题：

• 穿过模块的数据丢失
• 一个模块的功能对其他模块造成有害影响
• 模块集成后没有达到预期功能
• 全局数据结构出现问题
• 模块组合后误差累积

    3. 自顶向下集成测试：属于增量方法，模块集成顺序从主控模块开始，沿着控制层次逐步向      下，不用编写驱动模块，需要编写桩模块
    4. 自底向上集成测试：模块集成顺序从底层原子模块开始，沿着控制层次逐步向上，不用编写桩模块，需要编写驱动模块

十七、回归测试

1. 软件发生变更，可能会使原来正常的功能产生问题，这时需要回归测试重新执行一下已经测试过的某些子集，确保没有传播不期望的副作用
2. 回归测试有助于保证不引入无意识的行为或者额外的错误

十八、冒烟测试

1. 将已经转换为代码的软件构件集成到构件中
2. 设计一系列测试以暴露影响构建正确的完成其功能的错误

十九、测试方法

1. 静态测试：被测程序不在机器上运行，采用人工检测和计算机辅助静态分析来对程序进行检测
2. 动态测试：通过运行程序发现错误，可以采用黑盒测试和白盒测试
3. 测试用例：由测试的输入数据和预期输出结果组成，设计用例时应包含合理的输入条件和不合理的输入条件

二十、黑盒测试

1. 不考虑软件内部结构和特性，把软件当做和黑盒子，测试软件的外部特性
2. 常用的黑盒测试技术

• 等价类划分：将程序输入输出划分为若干等价类，然后每个等价类中取一个代表性数据作为测试用例，测试时需要同时测试有效等价类和无效等价类
• 边界值分析：输入的边界比中间更容易发生错误，应测试边界值和刚刚超过边界值的值
• 错误推测：基于经验推测
• 因果图：通过因果图转换判定表

二十一、McCabe 度量法

1. 通过定义环路复杂度，建立程序复杂度的度量，它基于一个程序模块的程序图中环路的个数
2. 计算公式为 V(G) = m - n + 2 ; G 表示程序图， V(G) 表示程序图的环路复杂度， m 表示有向弧的个数， n 表示节点的个数
3. 也可以通过查找图中有多少个闭合区域 k , 然后 V(G) = k + 1

二十二、白盒测试

白盒测试也称结构测试，根据程序的内部结构来设计测试用例
白盒测试的常用技术是：逻辑覆盖、循环覆盖、基本路径测试
白盒测试原则：

• 程序模块中的所有独立路径至少执行一次
• 逻辑判断中 取”真“ 和 ”假“的情况都至少执行一次
• 每个循环都要在边界条件和一般条件下各执行一次
• 测试程序内部数据结构的有效性

逻辑覆盖

• 语句覆盖：选择足够的测试数据，使得被测试程序中每条语句至少执行一次（只要保证每条语句执行，因此可能错过一些判断逻辑分支），语句覆盖对程序执行逻辑的覆盖程度很低，是很弱的逻辑覆盖
• 判定覆盖：设计足够的测试用例，是的测试程序的每个判定表达式至少获得一次 ”真“值和”假“值，每个取”真“和”假“的分支都至少跑一次，因此也称为分支覆盖
• 条件覆盖：创造一组测试用例，是的每一个判断语句中的每个逻辑条件的各种可能的值都至少满足一次
• 判定 / 条件覆盖：需要同时满足判定覆盖和条件覆盖的要求
• 条件覆盖组合：在 判定 / 条件覆盖 的要求前提下，判定表达式的所有真假不同组合都要测试一遍，例如 A>0 && b>0 就要测试四种 T&&T, F&&F, T&&F, F&&T
• 路径覆盖：指测试用例要覆盖程序中所有可能路径

            路径覆盖： 每一条路径可能都要有
            如何覆盖所有路径：只要能把路径都走一遍就行
如果有伪代码则先将其转换成流程图，然后计算

二十三、运行和维护

1. 软件维护是软件生命周期最后一个阶段，不属于系统开发过程
2. 系统可维护性评价指标：可理解性、可测试性、可修改性
3. 文档是软件可维护性的决定因素
4. 可维护性在开发阶段就需要考虑到，此后的每个阶段也都需要考虑

二十四、软件文档

1. 编写高质量的文档可以提高软件开发质量
2. 文档也是软件产品的一部分，没有文档的软件不能称之为软件
3. 软件文档的编制在软件开发中占有突出的地位，和相当大的工作量
4. 高质量的文档对软件产品的效益有着重要意义
5. 总的来说软件文档只好不坏

二十五、软件维护内容

1. 正确性维护：改正在系统开发和测试阶段未发现的问题
2. 适应性维护：适应行业环境变化和管理需求而做出的修改
3. 完善性维护：为扩充功能和改善性能而做出的修改
4. 预防性维护：为了适应未来的软硬件环境变化而主动做出的预防

二十六、软件可靠性、可用性、可维护性公式

1. 可 靠 性 ： 给 定 时 间 间 隔 、 给 定 条 件 下 无 失 效 运 作 的 概 率 MTTF/(1+MTTF) MTTF: 平均无故障时间
2. 可用性：给定时间，系统正确运作的概率 MTBF/(1+MTBF) MTBF:平均失效间隔时间
3. 可维护性：给定时间，使用规定的过程和资源完成维护活动的概率1/(1+MTTR) MTTR: 平均修复时间

二十七、沟通路径计算

1. n 个程序员，无主程序员： (n-1)*n/2
2. n 个程序员，一个主程序员： n-1

二十八、软件项目估算

1. COCOMO 估算模型：精确的易于使用的成本估算模型，按精细程度分为基本 COCMO、中级 COCOMO 、详细 COCOMO

基本 COCOMO 模型 : 静态单变量模型

中级 COCOMO 模型：静态多变量模型，将系统模型分为系统和部件两个层次

详细 COCOMO 模型：将软件系统模型分为系统、子系统和模块三个部分

     2.COCOMOII 估算模型：层级结构的估算模型，分为三个阶段

应用组装模型：软件开发的前期阶段使用，使用对象点估算

早期设计阶段模型：在需求已经稳定，并且基本的软件体系结构已经建立的时期使用，使用功能点估算

体系结构阶段模型：软件构造过程中使用，使用代码行估算

二十九、Gannt 图（甘特图）

1. 一种简单的水平条形图，以日历为基准描述项目任务，水平轴展示日历时间线，每个横条表示一个任务，水平条的起点终点对应日历时间，表示任务的开始和结束，其长度代表任务持续时间，同一时间段的多个水平条间是并发关系
2. 优点：清晰描述任务的开始结束时间，任务进展情况，和任务间的并行关系
3. 缺点：不能清晰的反应出任务间的依赖关系，不能反映项目的关键，不能反应计划中有潜力的部分

三十、PERT 图

1. PERT 图是一个有向图
2. 图中的箭头表示”任务“，箭头上的时间表示完成”任务“所需时间
3. 图中的节点表示”事件“，表示指向当前节点的”任务“结束。并且由当前节点指出的”任务“开始
4. 当流入该节点的所有任务都结束时，由当前节点指出的任务才会开始
5. 事件本身不消耗时间和资源，仅表示一个时间点
6. ”事件“节点由三部分组成：事件号、出现事件的最早时刻、最迟时刻
7. 开始节点：没有流入的任务的节点，可以有多个，开始节点的最早时刻为 0
8. 结束节点：没有流出的任务的节点，只能有一个，结束节点的最迟时刻等于其自身的最早时刻
9. 最早时刻计算要从开始节点向结束节点推算，最晚时刻要从结束节点向开始节点推算
10. 最早时刻：能开始该事件节点出发的后续任务的最早时刻，有多个流入的任务时，则选择计算后的最大的那个
11. 节点的最早时刻计算：流入的任务的所需时间 + 流入前一个节点的最早时刻
12. 最迟时刻：从此节点出发的任务，必须在此时刻前开始，否则工程不能如期完成，有多个流出的任务时，则选择计算后最小的那个
13. 节点的最迟时刻计算：流出任务指向的节点的最晚时刻 - 流出任务所需时间
14. 松弛时间：在不影响工期的前提下，完成该任务有多少机动余地，是挂在任务下的
15. 松弛时间计算：链接任务的两个节点中，箭头指向的节点的最迟时刻- 任务的耗时 - 箭头尾部的节点的最早时刻
16. 关键路径：从开始节点到结束节点，松弛时间都是 0 的路径
17. PERT 图优点：给出任务开始结束时间，还能给出任务建的依赖关系、关键路径
18. PRET 图缺点：不能反映出任务键的并行关系

三十一、项目活动图

1. 与 PERT 图类似，其中：顶点表示里程碑，链接定点的变表示活动，边上的数字表示活动所需时间
2. 除了图形及命名与 PERT 图不一样，其他计算方面基本相似

三十二、软件配置管理

1. 软件配置管理主要目标：变更标识、变更控制、版本控制、确保变更正确的实现、变更报告
2. 软件配置管理内容：版本管理、配置支持、变更支持、过程支持、团队支持、变化报告、审计支持
3. 软件配置管理内容（第二版）：软件配置标识、变更管理、版本控制、系统建立、配置审核、配置状态报告
4. 配置数据库分为三类 : 开发库、受控库、产品库

三十三、风险管理

1. 软件风险的特性：不确定性（可能发生也可能不发生）和损失（如果发生就会产生恶性后果）
2. 软件风险的分类

• 项目风险：拖延项目进度、增加项目成本。例如：预算、进度、人员、资源、项目复杂度、规模及结构不确定
• 技术风险：质量和交付时间。例如：设计、实现、接口、维护等方面的问题
• 商业风险：威胁软件生存能力

三十四、风险识别

1. 系统的指出对项目计划（估算、进度、资源分配等）的威胁，识别出已知风险和可预测风险后，项目管理者要回避这些风险，必要时控制这些风险
2. 识别风险的一种方法是建立 ”风险条目检查表“
3. 风险条目检查表格式：列出每一种类型的有关特性，最终给出一组风险因素和驱动因子及发生概率，风险因素包含性能、成本、支持、进度

三十五、风险预测

1. 又称风险估计，通过两个方面进行评估， 1. 风险发生概率 2. 风险发生后果
2. 风险预测活动：

• 建立一个尺度或者标准，反应风险发生的可能性
• 描述风险产生的后果
• 估算风险对项目和产品的影响
• 标注风险预测的精确度，以免产生误解

    3.风险预测技术：建立风险表
    4.影响风险产生后果的三个因素：风险的本质、范围、时间
    5.整体风险显露度 = 风险发生的概率 * 风险发生给项目带来的成本
    6.风险评估：一种对风险评估很有用的技术是定义风险参照水准

三十六、风险控制

1. 风险控制的目的：辅助项目组建立处理风险的策略
2. 风险避免：应对风险的最好办法，就是主动的避免风险
3. 风险监测：项目管理者应监控某些因素，这些因素可以提供风险是否正在变低或者变高的指示
4. RMMM 计划：将所有风险分析工作文档化，并由项目管理者作为整个项目计划的一部分来使用
5. 风险缓解是一种问题规避活动，风险监测是一种项目跟踪活动
6. 风险监测的另一个任务就是找到“起源”

三十七、软件质量

ISO/IEC 9126 软件质量模型：由三层组成：质量特性 》 质量子特性 》 质度量指标
功能性：满足规定或隐含需求的那些功能

• 适应性：是否适合有关的软件属性
• 准确性：能够得到正确的结果
• 互用性：与其他系统进行交互的能力
• 依从性：服从有关标准、法规
• 安全性：避免非授权访问，和意外访问

可靠性：一定时间内软件维持性能水平的能力

• 成熟性：软件故障引起失效的频率
• 容错性：在软件错误或违反指定接口的情况下维持指定的性能水平
• 易恢复性：故障后，回复的能力

易使用性：是否容易使用，使用付出学习成本

• 易理解性：
• 易学性
• 易操作性

效率：软件性能水平和所占资源

• 时间特性：响应处理时间
• 资源特性：所使用的资源量

可维护性

• 易分析性：诊断所需要的成本
• 易改变性：缺陷改正成本
• 稳定性：不发生风险的能力
• 易测试性

可移植性

• 适应性：软件转移到不同环境耗时和成本
• 易安装性：指定环境下安装软件成本
• 一致性：不同环境安装后软件能力一致
• 易替换性

三十八、软件评审 （低概率考）

设计质量：设计的规格说明书符合用户要求
程序质量：程序按照规格说明书所规定的情况正确执行
设计质量评审内容：

• 评价软件的规格说明是否符合用户要求
• 评审可靠性，即是否能避免输入异常
• 评审保密措施实施情况
• 评审性能实现情况
• 评审软件可修改性、可扩充性、可互换性、和可移植性
• 评审软件可测试性
• 评审软件复用性

程序质量评审内容： 从开发者角度进行评审，与开发技术直接相关，着眼于软件本身结构

• 功能结构
• 功能的通用性
• 模块的层次
• 模块结构：控制流结构、数据流结构、模块结构与功能结构之间的对应关系
• 处理过程的结构
• 与运行环境的接口：与硬件的接口、与用户的接口

完成质量评估的中心活动是技术评审，目的是揭露质量问题

三十九、软件容错技术

对无可避免的差错，使其影响减到最小
容错软件的定义

• 对自身错误具有屏蔽能力的软件
• 一定程度上能从错误状态恢复到正常状态的软件
• 发生错误仍能完成预期任务的软件
• 一定程度上具有容错能力

容错的一般方法：实现容错的主要手段是冗余，冗余是指对于实现系统功能的多余的那部分资源

四十、四类冗余技术

1. 结构冗余：静态冗余、动态冗余、混合冗余
2. 信息冗余：为检测或纠正信息在运算或传输中的错误而外加的一部分信息
3. 时间冗余：重复执行程序或指令来先出瞬时错误的影响
4. 冗余附加技术：

• 屏蔽硬件错误的附加技术： 1. 关键程序和数据的冗余存储。 2.检测、表决、切换、重构、纠错、复算
• 屏蔽软件错误的附加技术： 1. 冗余备份程序的存储及调用。 2.实现错误检查和错误恢复。 3. 实现容错软件所需的固化程序

四十一、软件工具

软件开发工具

• 需求分析工具
• 设计工具
• 编码与排错工具
• 测试工具

软件维护工具

• 版本控制工具
• 文档分析工具
• 开发信息库工具
• 逆向工程工具
• 再工程工具

四十二、其他

1. 高质量文档特性：针对性、精确性、清晰性、完整性、灵活性、可追溯性
2. 软件工程基本要素：方法、工具和过程
3. 数据处理领域不太复杂的软件适合结构化开发方法
4. 软件调试方法：

• 试探法：猜测问题所在位置，通过输出语句获得错误线索
• 回溯法：从发现问题的位置开始，沿着程序的控制流程往回跟踪代码
• 对分查找法：通过缩小错误范围，找出问题
• 归纳法：收集正确的与不正确的数据，分析他们之间的关系，提出假想的错误原因
• 演绎法：列出所有可能的错误原因，排除、尝试