第12章 系统实施.

Presentation on theme: "第12章 系统实施."— Presentation transcript:

1 第12章 系统实施

2 本章主要内容 12.1 系统实施阶段的任务 12.2 制定软件实现策略 12.3 编程方法（Coding）
12.4 系统测试（Testing） 12.5 系统排错（Debuging） 12.6 系统交付（Transition）

3 12.1 系统实施阶段的内容 ？ 主要包括以下几个方面的任务： 1. 硬件准备 2. 软件准备 3. 人员培训 4. 数据准备 分析
硬件准备 软件准备 程序开发及测试 软件产品安装部署 软件的客户定制 租用服务 人员培训 数据准备 分析 设计 分析文档 设计文档 ？

4 实施阶段的特点 工作量大 投入的人力、物力多 对项目管理人员的要求高

5 12.2 制定实现策略 结构化方法：通常主张自顶向下实现，尽量先实现上层模块，逐步向下，最后实现下层最基本的模块（也可以自底向上）
面向对象方法：主张基于构件的实现方法，划分构件后，尽量先完成构件接口，然后可实现各构件的并行开发（构件之间存在依赖关系，根据依赖也可以选择自顶向下或自底向上） 面向服务方法：同样是基于构件的实现方法，所有服务及其接口定义好后，具体实现和组装可以并行开展

6 自顶向下的实现 能有效地解决接口问题。接口解决不好，往往不得不对调试过的程序反复修改，甚至推倒重来，造成重大的返工。
整体性好，结构风险较小。 及早提交菜单、窗口等高层模块/类，鼓舞士气

7 自底向上的实现 必须完成全部设计之后进行 具体细节问题能够及早解决
在最后实现高层模块/类并集成时，可能会发现结构的重大问题，低层已实现的模块或构件面临返工

8 其他策略 “三明治”，结合自顶向下和自底向上 按功能增量或迭代 并行开发，持续集成（敏捷方法，例如“每日集成”）

9 12.3 编程方法 做一名好的程序员，应了解以下几个方面： (1) 了解好程序的判断标准； (2) 掌握常用的程序设计技术；
(1) 了解好程序的判断标准； (2) 掌握常用的程序设计技术； (3) 行业认同的编程规范；

10 12.3.1 好程序的标准 一般认为好程序应具备下列素质： (1) 能够工作 (2) 调试代价低 (3) 易于维护 (4) 易于修改
(1) 能够工作 (2) 调试代价低 (3) 易于维护 (4) 易于修改 (5) 设计不复杂 (6) 效率高

11 程序设计技术 结构化程序设计 面向对象程序设计 可视化程序设计 Web程序设计 组件开发技术 插件技术 框架技术 ……

12 12.3.2 程序的注释 需要注意以下几点： 每个文件的开始部分应指明程序的主要内容、编写者、最后修改日期等信息，以利于管理。
每个过程或函数前应有简要的接口描述信息，如函数功能、参数要求、返回值或其他特别说明。 注释必须与程序一致, 所以修改程序时，要注 意对注释作相应的修改。 对程序段作注释，而不是对每个语句作注释。

13 程序注释举例

14 12.3.3 程序结构 简单、直接地反映意图 表达式的书写应一气呵成 算法复杂性尽量小 判断、循环嵌套不宜过深 避免使用GOTO语句
避免使用全局变量（部分属于设计问题）

15 12.3.4 编程规范 模块、文件、窗口界面元素、常变量的命名 排版格式的规范化（缩进、空行、括号） 不要直接使用数字 类成员的布局次序
一个文件一个类 …… 参考阅读经典书籍《代码大全》

16 变量的使用 命名规范 初始化尽量与变量声明靠近 作用域尽量小 单一用途 尽量减少中间变量使用 不同数据类型前缀、全局/局部前缀、循环计数
如声明的同时就初始化 int count=0; 作用域尽量小 如函数局部变量，代码段局部变量 单一用途 如循环变量只用于计数，循环结束就不要再使用 尽量减少中间变量使用

17 变量名称举例 对比 x = x – y; z = m + tax(m); x = x + lf(c1, x) + z;
x = x + it(c1, x); 对比 balance = balance – lastPayment; monthlyTotal = newPurchases + SalesTax(newPurchases); balance = balance + LateFee(customerID, balance) + monthlyTotal; balance = balance + Interest(customerID, balance);

18 公司编程规范举例 华为公司编程规范文档

19 接下来…… 程序写好了，然后呢？ 调试程序 编写程序 再设计 复审和测试

20 软件质量控制 静态检查：指人工评审软件文档或程序，发现其中的错误（代码审查Inspection 、代码走查Walkthrough、同行评审Peer Review等手段） 动态检查：就是测试。测试是为了发现错误而执行程序的过程。 正确性证明？

21 12.4 测试 测试的目的（概念） 测试的类型、步骤 测试技术 测试用例的设计

22 12.3.1 测试的概念 (1) 测试是指“用意在发现错误而执行一个程序的过程”；
(2) 一个好的测试用例是指这个测试用例有很高的概率可以发现一个尚未发现的错误； (3) 一个成功的测试是指它成功地发现了一个尚未发现的错误。 测试的关键问题：设计有限的测试用例，在有限的研制时间、研制经费的约束下，尽可能多地发现程序中的错误。

23 对测试理解的误区 测试最终能证明程序没有错误 测试是改善软件质量的法宝 伟大的测试就是没有找到任何缺陷 只有程序编写完成后，测试才能开始
永远不能！ 测试是改善软件质量的法宝 不！高质量的设计和开发、质量保证体系 伟大的测试就是没有找到任何缺陷 作为测试人员，成功就是发现更多缺陷 只有程序编写完成后，测试才能开始 测试活动与其它活动同步、测试驱动的开发模式TDD

24 测试类型 模块测试 联合测试 确认测试 系统测试 也称单元测试。 也称集成测试，检验模块及系统结构。 测试对需求的满足，也可称验收测试。
是对整个信息系统的测试，将硬件、软件、操作人员看作一个整体，来分析系统的功能与执行性能

25 1. 模块测试 模块测试又称单元测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。
模块测试的目的在于发现各模块内部可能存在的各种差错。 模块测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。 单元测试一般由程序员自己负责。

26 模块测试方法 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
驱动模块 (driver，测试驱动开发方法强调 比如人工吹气测试自行车的气门芯，测试没有问题后再安装 桩模块 (stub) ── 存根模块 某演员缺席使用替补，彩排继续

27 模块测试工具 比如常见的单元测试工具： JUnit NUnit VS2005内含单元测试。示例 这些工具实质上是一种测试框架，一般提供一些基本接口，开发人员继承这个接口，来编写测试程序，而测试程序的具体运行交给框架来负责。 可以集成到开发环境中

28 2. 集成测试 将所有模块集成在一起所进行的系统功能的测试 集成测试的策略有多种： 一次性集成 自顶向下的集成 自底向上的集成
并行开发，持续集成/每日集成

29 一次性集成测试 Big-bang Integration
首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

30 自顶向下的集成测试 Top-down Integration（自顶至下） 按系统程序结构，沿控制层次自顶向下进行组装。
通过设置下层模块为桩，检查控制流，较早地验证了主要的控制和判断点。 需要制作较多的桩模块，并且桩模块不能返回真实的数据。

31 自顶向下的集成测试 31

32 自底向上的集成测试 Bottom-up Integration（自底向上） 从程序模块结构的最底层的模块开始组装和测试。
对于一个给定层次的模块，它的子模块及其下属模块已经组装并测试完成，所以不再需要桩模块。 要到最后才窥得全貌，重大结构问题不能及早发现

33 持续集成 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试 ) 来验证，从而尽快地发现集成错误。 持续集成要素： 统一的代码库 自动构建 自动测试 每个人每天都要向代码库主干提交代码 每次代码递交后都会在持续集成服务器上触发一次构建 保证快速构建 模拟生产环境的自动测试 每个人都可以很容易的获取最新可执行的应用程序 每个人都清楚正在发生的状况 自动化的部署

34 3. 确认测试 确认测试主要是进行功能的有效性测试。 一般不考虑程序内部结构，验证被测软件是否满足需求规格说明书列出的需求。
目的是检验软件符合需求，获得客户的确认，为验收作准备 通常由专门的测试小组完成

35 α测试和β测试 α测试和β测试 α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。微软产品的Beta版

36 回归测试 回归测试 当软件发生变化后（例如：增加了新的模块、或修改错误代码），可能使得原来通过测试的功能不能正常运行，回归测试就是通过重新执行已经执行过的测试来验证改动过的程序功能的有效性。 回归测试可以用人工来执行所有测试用例的一个子集，或者采用捕捉回放工具来进行（自动化测试工具，如WinRunner等功能测试软件）。

37 功能测试工具 自动录制生成脚本程序 运行脚本回放（自动测试）

38 自动化功能测试原理 步骤：

39 4. 系统测试 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。 系统测试为系统的正式运行做准备，也可称为试运行。

40 系统测试的内容 功能测试 可靠性测试 强度测试（压力测试） 性能测试
在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。 可靠性测试 平均失效间隔时间 MTBF（Mean Time Between Failures） 因故障而停机的时间MTTR(Mean Time To Repairs) 强度测试（压力测试） 检查在系统运行环境非正常乃至发生故障的情况下，系统可以运行到何种程度 性能测试 检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。 性能测试（或称多用户并发性能测试）、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。下面将几个概念进行介绍。 性能测试（Performance Test）：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。 关注点：how much和how fast 负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。 关注点：how much 强度测试（Stress Test）： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括 Spike testing：短时间的极端负载测试 Extreme testing：在过量用户下的负载测试 Hammer testing：连续执行所有能做的操作 容量测试(Volume Test)：确定系统可处理同时在线的最大用户数 关注点：how much（而不是how fast） 容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。 其中，容量测试、负载测试、强度测试的英文解释为： Volume Testing = Large amounts of data Load Testing = Large amount of users Stress Testing = Too many users, too much data, too little time and too little room 40

41 系统测试的内容（续） 恢复测试 启动／停止测试
证实在克服硬件故障(包括掉电、硬件或网络出错等)后，系统能否正常地继续进行工作，并不对系统造成任何损害。 采用人工模拟硬件故障，故意造成软件出错。 启动／停止测试 验证在机器启动及关机阶段，软件系统正确处理的能力。 反复启动软件系统 ，例如操作系统自举、网络的启动、应用程序的调用等。 在尽可能多的情况下关机。

42 系统测试的内容（续） 配置测试 安全性测试 可使用性测试 检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。
包括配置命令测试、循环配置测试、修复测试。 安全性测试 检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。 可使用性测试 从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。

43 系统测试的内容（续） 可支持性测试 安装测试 验证系统的支持策略对于公司与用户方面是否切实可行。
对系统安装进行测试，找出在安装过程中出现的错误。 系统的每一部分是否都齐全； 所有文件是否都已产生并确有所需要的内容； 硬件的配置是否合理，等等

44 系统测试的内容（续） 兼容性测试 容量测试 文档测试 验证软件产品在不同版本之间的兼容性。 有两类基本的兼容性测试：向下兼容、交错兼容
检验系统的能力最高能达到什么程度。 对于信息检索系统，让它使用频率达到最大。 在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力，也称压力测试。 文档测试 检查用户文档(如用户手册)的清晰性和精确性。

45 12.4.3 测试用例设计 先了解测试技术： 根据测试技术设计测试用例 黑盒测试 白盒测试 白盒测试技术：语句覆盖、判定覆盖…
黑盒测试技术：等价类划分、边界值分析

46 黑盒测试 这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序模块的详细说明，检查程序的功能是否符合它的功能说明。 黑盒测试又叫做功能测试或数据驱动测试。

47 黑盒的穷举测试 如果能够穷举所有可能的输入条件及其输出结果来测试程序，那么就可以证明正确性。 然而这是不可能的。举例：
假设一个程序P有输入整数X和整数Y及输出Z。 可能采用的测试数据组： 232×232 ＝ 264 如果测试一组数据需要1微秒，一年工作365× 24小时，完成所有测试需万年以上。

48 白盒测试 此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有内部逻辑结构进行测试。 通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

49 白盒的穷举测试 对一个具有多重选择和循环嵌套的程序，穷举所有的程序逻辑，会怎样？ 给出一个小程序的流程图，它包括了一个执行20次的循环。
包含的不同执行路径数达520条，对每一条路径进行测试需要1微秒 一年工作365×24小时 测试完需3年。

50 使用测试用例 以尽可能少的数据发现尽可能多的错误 所以，不论使用什么测试技术，我们都不可能采用穷举测试来证明没有错误。
一个测试用例就是为了测试某个目标（模块、功能、性能）而准备的一份输入数据及其预期结果

51 测试用例的设计 设计测试用例时，根据黑盒技术和白盒技术的原理，可以有不同的方法： 逻辑覆盖法（白盒） 等价类划分法（黑盒）
边界值分析法（黑盒）

52 逻辑覆盖 逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术，属于白盒测试。 根据覆盖测试的目的不同，逻辑覆盖分为： 语句覆盖
判定覆盖 条件覆盖 条件组合覆盖 路径覆盖

53 逻辑覆盖举例 (A>1) and (B=0) (A=2) or (X>1) X=X/A X=X+1 T F a b d c e

54 1. 语句覆盖 语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。 测试用例的设计格式如下
在图例中，正好所有的可执行语句都在路径L1上，所以选择路径 L1设计测试用例，就可以覆盖所有的可执行语句。 测试用例的设计格式如下 【输入的(A, B, X)，输出的(A, B, X)】 为图例设计满足语句覆盖的测试用例是: 【(2, 0, 4)，(2, 0, 3)】　 覆盖 ace【L1】 语句覆盖是最弱的逻辑覆盖准则

55 2. 判断覆盖 判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个IF判断语句的取真分支和取假分支至少一次。
判定覆盖又称为分支覆盖。 对于图例，如果选择路径L1和L2，就可得满足要求的测试用例: 【(2, 0, 4)，(2, 0, 3)】覆盖 ace【L1】 【(1, 1, 1)，(1, 1, 1)】覆盖 abd【L2】

56 3. 条件覆盖 T4 条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中所有判断的每个子条件的可能取值至少执行一次。
在图例中，我们事先可对所有条件取值加以标记。例如： 对于第一个判断： 条件 A＞1 取真为 ，取假为 条件 B＝0 取真为 ，取假为 对于第二个判断： 条件A＝2 取真为 ，取假为 条件X＞1 取真为 ，取假为 T4

57 条件覆盖 测试用例 覆盖分支 条件取值 【(2, 0, 4)，(2, 0, 3)】 L1(c, e)
测试用例 覆盖分支 条件取值 【(2, 0, 4)，(2, 0, 3)】 L1(c, e) 【(1, 0, 1)，(1, 0, 1)】 L2(b, d) 【(2, 1, 1)，(2, 1, 2)】 L3(b, e) 或 【(1, 0, 3)，(1, 0, 4)】 L3(b, e)

58 4. 条件组合覆盖 条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
记 ① A＞1, B＝0 作 ② A＞1, B≠0 作 ③ A≯1, B＝0 作 ④ A≯1, B≠0 作 ⑤ A＝2, X＞1 作 ⑥ A＝2, X≯1 作 ⑦ A≠2, X＞1 作 ⑧ A≠2, X≯1 作

59 条件组合覆盖 测 试 用 例 覆盖条件 覆盖组合 【(2, 0, 4), (2, 0, 3)】(L1) ①, ⑤
测 试 用 例 覆盖条件 覆盖组合 【(2, 0, 4), (2, 0, 3)】(L1) ①, ⑤ 【(2, 1, 1), (2, 1, 2)】(L3) ②, ⑥ 【(1, 0, 3), (1, 0, 4)】(L3) ③, ⑦ 【(1, 1, 1), (1, 1, 1)】(L2) ④, ⑧

60 5. 路径覆盖 路径覆盖就是设计足够的测试用例，覆盖程序中所有可能的路径。 测试用例 通过路径 覆盖条件
测试用例 通过路径 覆盖条件 【(2, 0, 4), (2, 0, 3)】 ace (L1) 【(1, 1, 1), (1, 1, 1)】 abd (L2) 【(1, 1, 2), (1, 1, 3)】 abe (L3) 【(3, 0, 3), (3, 0, 1)】 acd (L4)

61 6. 等价类划分 等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。 使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。

62 等价类划分 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。 等价类的划分有两种不同的情况： 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。 设计测试用例时，要同时考虑有效等价类和无效等价类的设计。 不同类型的数据，划分等价类不同

63 如何划分等价类 （1）如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。 在数轴上表示成:
例如，在程序的规格说明中，对输入条件有一句话： “数量可以从1到999” 则有效等价类是“1≤数量≤999” 两个无效等价类是“数量＜1”或“数量＞999”。 在数轴上表示成:

64 如何划分等价类 （2）如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。
例如，在C语言中对变量标识符规定为“以字母打头的……串”。那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。 （3）如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

65 如何划分等价类 （4）如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。 例如：在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。

66 如何划分等价类 （5）如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
例如，变量名“所有以字母或数字打头的，不包含……等字符的非保留字”等。 在明确规则的几个条件后，确立每个条件的有效等价类和无效等价类，建立等价类表。最后，确定测试用例。

67 如何划分等价类 在某一种语言版本中规定：“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为8个。”
并且规定：“标识符必须先说明，再使用。” “在同一说明语句中，标识符至少必须有一个。”

68 7. 边界值分析 边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。
人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。 比如我们在操作链表指针时，出现错误的往往是在边界值的情况下（如在表头或表尾进行插入或删除），判定条件、循环条件等也常常是在正常值左右出现问题。

69 边界值分析 这里所说的边界是指：相当于输入等价类和输出等价类而言，等于其边界值及稍高/低于其边界值的一些特定情况。
使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。 比如，在计算个人所得税时，全月应纳税所得额超过1000元至2000元的部分税率为5%。那么在测试时，可以选择的测试用例是： x=999 x=1000 x=1001 x=2000 x=2001

70 边界值分析 对于数据库应用系统，很多的功能是与记录处理有关，我们可以扩大边界值的概念，根据以下提示选择测试用例：
新记录（第一条记录前，最后，记录的项目不全） 处理业务（第一条、最后一条、相邻、超常规、错误范围、记录不存在） 记录删除（第一条、最后一条、指定范围、当前记录等） 查看（第一页/条、指定页/条、最后一页/条）

71 12.4.4 测试原则 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
测试用例应由测试输入数据和对应的预期输出结果这两部分组成。程序员应避免检查自己的程序。（结对编程） 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。 充分注意测试中的群集现象。经验表明：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比 严格执行测试计划，排除测试的随意性。 应当对每一个测试结果做全面检查和分析。 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

72 何时引入测试 在系统生命周期，越早引入测试越好： 计划阶段：评估测试可行性分析。 分析阶段：需求走查，制定确认测试计划、设计功能测试用例。
设计阶段：确认设计符合需求，制定单元测试和集成测试计划、设计单元测试和集成测试用例。 实施阶段：进行单元测试和集成测试。最后进行确认测试和系统测试。

73 利用软件工具的测试过程 测试也是技术活 测试开发 测试计划 测试设计 测试评估 测试执行

74 系统测试度量 测试覆盖率：评价测试的完备性 性能指标 测试报告 需求覆盖率（黑盒） 代码覆盖率（白盒） 动态监控 响应时间/吞吐量报告
百分比报告 测试报告

75 12.5 排错/调试 区分调试（Debug）和测试（Test）： 测试工作主要由测试人员完成，程序员一般仅负责单元测试任务
测试是发现缺陷 调试是定位并排除缺陷 Bug是通过测试发现的缺陷 Debug就是要排除它 测试工作主要由测试人员完成，程序员一般仅负责单元测试任务 而调试则通常是程序员的工作

76 Bug的来历 Bug用于比喻软件中的缺陷和漏洞：
格雷丝·霍珀记录事件报告 格雷丝·霍珀(Grace Hopper)，美国海军少将，实现了第一种编译语言和编译器、创造了世界上第一种商业编程语言COBOL

77 定位错误 从技术角度来看，查找错误的难度在于： 现象与原因所处的位置可能相距甚远。
当其它错误纠正时，此错误所表现的现象可能会暂时消失，但并未实际排除。 现象实际上是由一些非错误原因（如舍入不精确）引起的。 现象可能是由于一些不容易发现的人为错误引起的。 错误是由于时序问题引起的，与处理过程无关。 现象是由于难于精确再现的输入状态引起。 现象可能是周期出现的，在嵌入式系统中常常遇到。

78 调试方法 试探法 跟踪法/回溯法 对分查找法 归纳法 演绎法

79 调试技术 单步跟踪 设置断点 实时监视和编辑变量 改变执行语句 ……

80 12.6 系统的交付使用 系统的交付（Transition）即系统的转换或切换

81 直接切换 直接转换指在某一时刻，老系统停止运行，新系统立即开始运行。
特点：这种切换方式简单，用户没有重复劳动，最省费用，但风险高，结果无比较性。 适用范围：对一些小系统，或者新系统已进行过多次真实测试，或者老系统已完全不能使用。

82 并行切换 并行切换是新老系统并行工作一段时间，经过这段时间考验，以后新系统代替旧系统。
特点：风险小，有安全感，可以将结果进行对照；重复劳动，费用高。 并行时间一般为3-6个月。

83 分段切换 该切换方式是前两种切换方式的结合。在新系统正式全部运行前，一部分一部分代替老系统。
特点：低风险，比并行节省费用，可以积累经验，能循序渐进。但新旧系统的子系统间、功能间接口多，实施复杂，技术成本高。 一般较大系统皆采用之。