第10章 系统实施

本章主要内容 系统实施阶段的任务 程序设计 程序设计技术 编程规范 系统测试和调试 测试技术 测试类型 测试工具 系统转换

系统实施场景报道 4月2日下午的下班时间早已过去了3个小时，原本和记者约定在8点一起聚餐的波导股份部分员工却仍然在加班加点地工作。他们之所以滞留，无非是因为在新系统调试过程中一个同事疏忽而导致该部门所有数据不得不重新输入。     “最近半个月时间里，像这样的事情在波导公司经常发生。”生产部的工程师告诉记者，“从3月28日起，波导股份总部各部门就开始配合信息部的工作人员不分昼夜地将数据从原来的金蝶K/3系统中导出来，然后切换到新上的SAP系统中去。”

系统实施阶段任务与步骤 主要包括以下几个方面的任务： (1)硬件准备 (2)软件准备 (3)人员培训 (4)数据准备

实施阶段的特点 系统实施阶段的特点 系统实施阶段的主要问题 工作量大 投入的人力、物力多 如何保证所开发的软件具有高质量； 如何将设计的新系统更快地投入运行； 如何培训系统用户。

10.1 制定实现策略 结构化方法主张自顶向下实现，尽量先实现上层模块，逐步向下，最后实现下层最基本的模块。 首先实现系统的轮廓或框架，在此基础上不断添加新的功能，逐步完善，最后达到物理模型所要求的全部功能。 面向对象方法主张基于构件的实现方法，按层划分构件后，尽量先完成构件接口，然后可实现并行开发。 先实现底层构件，然后开发上层构件

自顶向下方法的优点 这种自顶向下的实现方法有效地解决了接口问题。接口解决不好，往往不得不对调试过的程序反复修改，甚至推倒重来，造成重大的返工。 这种方法整体性好，结构风险较小。 便于控制进度，保证研制工作按时完成。

10.2 编写程序 编写程序，要考虑以下几个方面： (1) 了解什么是好程序； (2) 采用什么程序设计技术； (1) 了解什么是好程序； (2) 采用什么程序设计技术； (3) 遵循什么样的编程规范；

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

2、程序设计技术 结构化程序设计 面向对象程序设计 可视化程序设计 Web程序设计 插件技术 ……

结构化程序设计 通常认为结构化程序设计包括以下四方面的内容： （1） 限制使用GO TO语句 （2） 逐步求精的设计方法 （3） 自顶向下的设计、编码和调试 （4） 主程序员制的组织形式

面向对象程序设计 封装、继承、多态 程序以对象为基本元素，对象包含属性和方法，设计程序通常不采用顺序结构 数据是特定对象的数据，只有对象自身的函数或过程（方法）可以维护对象的数据（属性） 公用的功能通常设计组件（类）以实现重用 需要分析并表达出对象之间的关系

可视化编程技术 所见即所得的交互编程 基于事件驱动的原理 可以使用模板自动生成部分代码 结合面向对象编程技术

3、编程规范 必要的内部注释 清晰的结构 良好的风格 严格的源代码管理 ……

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

清晰的程序结构 简单、直接地反映意图 表达式的书写应一气呵成 嵌套不宜过深 避免使用GOTO语句 避免使用全局变量（通常是设计问题）

其他规范 排版格式的规范化 文件名、过程名、变量名的规范化 不要直接使用数字 …… 参考阅读《代码大全》

10.3 系统测试 测试的目的（概念） 测试的类型、步骤 测试技术 测试用例的设计 找错

系统测试 目前，检验软件有三种手段：动态检查、静态检查和正确性证明。 程序正确性证明技术目前还处于初级阶段， 静态检查指人工评审软件文档或程序，发现其中的错误（代码审查、代码走查、同行评审）。 动态检查就是测试。测试是为了发现错误而执行程序的过程。测试只能证明程序有错误，而不可能证明程序没有错误。

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

10.3.2 测试类型 模块测试 联合测试 确认测试 系统测试 也称单元测试，根据模块的功能说明检验每个单独的模块是否存在错误。 也称集成测试，检验模块及系统结构。 确认测试 检验系统说明书的各项功能与性能是否实现，是否满足要求。也可称验收测试。 系统测试 是对整个信息系统的测试，将硬件、软件、操作人员看作一个整体，来分析系统的功能与执行性能

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

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

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

2、联合测试 将所有模块集成在一起所进行的系统功能的测试 集成测试的策略有多种： 一次性组装 自顶向下的组装 自底向上的组装

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

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

自顶向下的集成测试

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

3、验收测试 验收测试主要是进行功能的有效性测试。 运用黑盒测试的技术，验证被测软件是否满足需求规格说明书列出的需求。 目的是使软件符合需求，获得客户的确认，为验收作准备。

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

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

系统测试的内容 功能测试 可靠性测试 强度测试（压力测试） 性能测试 在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。 可靠性测试 平均失效间隔时间 MTBF（Mean Time Between Failures） 因故障而停机的时间MTTR(Mean Time To Repairs) 强度测试（压力测试） 检查在系统运行环境非正常乃至发生故障的情况下，系统可以运行到何种程度 性能测试 检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。

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

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

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

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

10.3.3 测试技术 黑箱测试/黑盒测试 白箱测试/白盒测试

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

黑箱的穷举测试 用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。 但这是不可能的。举例： 假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试： 可能采用的测试数据组： 232×232 ＝ 264 如果测试一组数据需要1毫秒，一年工作365× 24小时，完成所有测试需5亿年。

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

白箱的穷举测试 对一个具有多重选择和循环嵌套的程序，不同的路径数目可能也是天文数字。 给出一个小程序的流程图，它包括了一个执行20次的循环。 包含的不同执行路径数达520条，对每一条路径进行测试需要1毫秒 一年工作365×24小时 测试完需3170年。

3、使用测试用例 以尽可能少的数据发现尽可能多的错误 不论使用什么测试技术，我们都不可能采用穷举测试，如何选择测试用例，达到： 一个测试用例就是为了测试某个目标（模块、功能、性能）而准备的一份输入数据及其预期结果

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

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

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

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

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

条件覆盖 测试用例 覆盖分支 条件取值 【(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)

条件组合覆盖 条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 记 ① 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 作

条件组合覆盖 测 试 用 例 覆盖条件 覆盖组合 【(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) ④, ⑧

路径覆盖 路径覆盖就是设计足够的测试用例，覆盖程序中所有可能的路径。 测试用例 通过路径 覆盖条件 测试用例 通过路径 覆盖条件 【(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)

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

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

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

10.3.4 测试原则 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。程序员应避免检查自己的程序。 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。 充分注意测试中的群集现象。经验表明：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比 不仅检查程序是否实现预期功能，还应检查程序是否作了不该做的事

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

10.4 调试 区分调试和测试： 测试是发现缺陷 调试是定位并排除缺陷 Bug是通过测试发现的缺陷，Debug就是要排除它 测试工作主要由测试人员完成，程序员只负责单元测试任务 而调试则通常是程序员的工作

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

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

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

10.5 系统的交付使用 系统的交付使用即系统的转换

直接转换 (1)直接转换 直接转换指在某一时刻，老系统停止运行，新系统立即开始运行。 特点：这种切换方式简单，最省费用，但又很大风险。 适用范围：对一些小系统，或者新系统已进行过多次真实测试，或者老系统已完全不能使用。 老系统 新系统 切换

并行切换 (2)并行切换 并行切换是新老系统并行工作一段时间，经过这段时间考验，以后新系统代替旧系统。 特点：风险小，但费用大，经常被使用。 并行时间一般为3～6个月，甚至1年。 老系统 新系统 并行

分段逐步切换 (3)分段切换 该切换方式是前两种切换方式的结合。在新系统正式全部运行前，一部分一部分代替老系统。 特点：既可靠，比并行节省费用，但要注意子系统间、功能间的接口问题。 一般较大系统皆采用之。 老系统 新系统

转换方式的比较 1. 直接方式 用户没有重复劳动，转换开支小 高风险，结果无比较性，用户无安全感 2. 平行方式 低风险，有安全感，可以将结果对照 重复劳动，费用高，计算机双重处理开销 3. 分段方式 低风险，可以积累经验，能循序渐进 新旧系统接口多，实施复杂，费用高

转换方式的选择 选择的依据： 信息系统的设计 用户需求和资源配备 风险因素 新旧系统如果相似，使用平行方式，区别很大，采用直接方式。 信息系统中的关键业务选平行方式，普通业务 进行直接转换。