系统分析与设计基础-6
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
15
全局变量命名：全局可以被任何外部和内部模块
的函数使用 全局变量命名规则如下： + “功能模块名的缩写” + ”_” + “有意义的名字” ”g” 标示该变量为全局变量 功能模块名的缩写：全部大写并且要求尽量短小 有意义的名字：由一个或者几个有意义的单词构 成，且单词首字母大写 例：int gPROC_Handle;
路 径 覆 盖
弱
强
29
例1：被测程序
PROCEDURE TEST(VAR A,B,X : REAL); BEGIN IF (A>1 AND B=0) THEN X:= X/A; IF (A=2 OR X>1) THEN X:=X+1; END;
30
被测程序流程图
a
A>1 AND B=0 b F T c X=X/A
21
5.5.2 测试的基本原则
1. 测试应贯穿在开发的各阶段，尽早进行测试从而 尽快发现问题：软件测试对象 ＝ 文档 ＋ 程序 2. 测试队伍与研发队伍应分别建立：若由开发人员 来设计测试方案，则很容易根据自己的编程思路 来制定，具有局限性 3. 设计测试用例时，不仅要包括合理有效的输入条 件，也要包括不合理、无效的输入条件 4. 设计测试用例时不仅要确定输入数据，而且要 根据系统的功能确定预期的输出结果 5. 既要检查程序是否完成了它应做的工作，也要 检查它是否还做了它不应做的事情 6. 测试用例应长期保留，直到该程序被废弃。程 序修改之后，要利用它们进行回归测试 22
2
5.1 结构化的编程实现方法
5.1.1 自顶向下的实现方法
自顶向下实现方法：先实现结构图中的顶层模块，逐 步向下，最后实现下层最基本的模块（即首先调试整 个系统的结构及各模块间的接口，确保其正确性） 特点： 整个实现过程分成若干个版本：首先实现系统的框架， 在此基础上逐步添加更低层次的剩余模块 每一个程序版本包含完整的程序模块，可以被编译、 链接和执行（尽管早期版本不能实现完整的系统功能） 在实现上层模块时，与这些模块有直接调用关系的下 层模块只作为“桩”（stub）出现（只有名字及参数 传递关系） 尽管“桩”的内部功能还没有实现，但可以测试系统 3 结构的正确性，保证接口的通畅
18
5.5 系统测试
据统计，一个较好的程序员交付的程序 中，错误率为1％；而一个水平低的程序 员编写的程序，可能每段语句都含有一 两个错误 软件系统的任何错误都有可能造成损失， 问题的关键是尽早发现和纠正这些错误
19
实例: Intel的pentium处理器
1994年发现浮点除法缺陷 2000年某型号处理器发现一个可能导致运行程序被挂 起的执行指令问题
– PowerBuilder。。。
数据库开发工具
– SQL Server, Oracle, SyBase, DB2, MySql，
Access等
6
5.4 编程风格
代码语句的书写规范
在书写代码时，应通过采用缩进格式使程序的
层次更加清晰 对于程序中需要重复出现的代码段，应将其用 独立模块（函数或过程）实现 尽量不使用强制转移语句goto 在复合语句中，要将‘{’和‘}’对齐在同一列 上，各自独占一行 …
1991年爱国者导弹防御系统由于系统时钟错 误积累造成跟踪系统失去精确度
20
5.5.1 测试的基本概念
测试定义1：使用人工或自动手段来运行或测定 某个系统的过程，其目的在于检验它是否满足规 定的需求或弄清预期结果与实际结果之间的差别 测试定义2：是为发现错误而执行程序的过程 一个成功的测试是指它成功地发现了一个尚未发 现的错误 测试能证明错误的存在，但不能证明错误不存在 测试的关键问题是如何设计测试用例，即设计一 批测试数据，通过有限的测试用例，在有限的研 制时间、研制经费的约束下，尽可能多地发现程 序中的错误
9
举例：复杂语句匹配关系的注释 while (a>10) { if (x>=y) { ............ if (x==y) { } else { } } /* if (x>=y) */ else { } } /* while (a>10) */
测试信息流
23
5.5.3 测试方法
静态测试 （人工代码评审）
软件测试 黑盒测试 动态测试 白盒测试
24
静态测试（人工测试）
指人工评审软件文档和程序（即code review）， 发现其中的错误。内容包括：检查代码和设计 是否一致、检查代码逻辑表达是否正确和完整 等 静态测试一旦发现错误就能确定问题的位置， 且能一次发现多处错误 经验表明，组织良好的人工测试可发现程序中 30％－70%的编码错误和逻辑设计错误
25
动态测试（机器测试）
指在计算机上直接用测试用例运行被测程序，从 而发现程序错误 黑盒测试（功能测试）：指在不考虑程序的内部 结构特性情况下，测试程序的外部特性，即通过 输入和输出的特性检测是否满足指定的功能 白盒测试（结构测试）：根据程序的内部结构和 逻辑来设计测试用例，对程序的路径和过程进行 测试，检查是否满足设计的需要
局部函数命名
命名规则：“有意义的名字” 有意义的名字：每个单词的首字母大写（第1个单词全小写） 而其余字母小写 例：static void dataProcess()
宏的命名
命名规则：“有意义的名字” 有意义的名字：要求全部大写，并且名字允许用下划线分隔 例：#define MAX_PWD_LEN 8
13标识符命名风格标识符– 包括常量名、变量名、函数名、文件名…
命名风格
把标识符的意义和表示方法结合起来 同一个开发团队应采用统一的命名风格
14
•
例：一种标识符命名风格 文件命名
文件名的构成如下： “功能模块名缩写”+“有意义的名字”+“.扩展名” 功能模块名缩写：用小写字母，并且要求短小 有意义的名字：由编程者确定，要求意义明确且每 个单词首字母大写 后缀：由点号加小写的文件扩展名 例如：PROC功能模块的某文件可以这样命名： procInit.cpp
5
5.3 常用开发工具
Microsoft系列开发工具
Visual Studio：Visual C++, Visual Basic，C#等
Borland系列开发工具
– Delphi, Borland C++ Builder, JBuilder
Java开发工具
– Eclipse
其他开发工具
26
5.5.4 测试用例设计
测试用例
“彻底地测试（穷举测试）”在实际的测试过程中是 不可行的
例：程序P有两个整型输入量 X、Y，输出量为Z，在32位机 上运行。所有的测试数据组（Xi，Yi）的数目为：
32 2 2 32
=
64 2
1毫秒执行1次，共需5亿年
因此只能在一定的开发周期内和一定的经济条件下 通过精心选择有代表性的测试用例，尽可能多地发 现错误
测试用例
28
白盒测试的测试用例设计
通过对程序内部结构和逻辑的分析来设计测试用例 依据：需求分析、程序清单 用例设计采用逻辑覆盖法：考虑测试数据执行（覆 盖）程序的逻辑程度 根据覆盖情况的不同，逻辑覆盖可分为：
语 句 覆 盖
判 定 覆 盖
条 件 覆 盖
判 定 条 件 覆 盖
条 件 组 合 覆 盖
7
/* 举例：缩进 */ void main() { int i;
for (i=0; i<20; i++) { if ( i>10) { } else { } }
}
8
代码注释的书写规范
注释行应接近整个代码的30%以上，以提高程序的可 读性 需要注释的地方： 1）每个模块（类）、函数开头要有注释 2）全局变量、模块变量、重要的局部变量（类属性） 要有注释 3）复杂语句（比如匹配关系）、功能关键语句要有注 释
32
判定覆盖(decision coverage)
又称分支覆盖，即设计若干个测试用例使得程序 的每个判断的取真分支和取假分支至少执行一次 例1的测试用例可设计为： A=3,B=0,X=3（覆盖acd） A=2,B=1,X=6（覆盖abe） 比语句覆盖程度稍强，因为通过了各个分支的测 试，各语句也都执行了 不能保证一定能查出判断条件中的错误：如不能 发现把第二个判断语句中的X>1错写成X<1
12
Doxygen注释风格介绍
Doxygen工具的作用: 从标有Doxygen风格注释的 源文件中生成HTML格式的文档
Doxygen注释风格（以Javadoc风格为例） 文档注释：以“/**”开始，以“*/”结尾（在类、 方法/函数、属性声明之前使用） 单行注释：以“//”开始（在方法/函数内部使 用）
测试不能证明所开发的系统没有错误，只能通过测试
来提高系统的可靠性和开发质量 如何设计合理的测试用例是测试阶段的关键技术问题
27
一个测试用例由两部分组成：
– 对程序进行测试的一组输入数据的描述 – 由这组输入数据所产生的程序的预期输出结
果的描述
Module -----------------------------------------------------------
g
16
局部变量命名：如果局部变量由一个或者多个有意
义的单词构成则要求每个单词的首字母大写（第1个 单词全小写）而其余字母小写
例： int i,j,k;
char dataBuffer[1024];
17
全局函数命名
+ “有意义的名字”
命名规则如下： “fn” + “功能模块名的缩写” + ”_” 有意义的名字：每个单词首字母大写 例： void fnPROC_Init()
第六部分 系统实现与维护
1
系统实现阶段的任务
实现阶段的任务是实现系统设计阶段提出的物理 模型，按实施方案完成一个可以实际运行的软件系统
1）硬件准备
购置、安装、调试硬件设备，如计算机主机、输入输 出设备、通信设备等
2）软件准备
购置、安装系统软件、数据库管理系统，编写应用程 序
3）数据准备
根据已确定的数据库物理模型进行数据的整理、录入， 从而为系统调试、运行提供真实的数据
•
}
11
语句注释
对定义的变量、宏、语句的功能等作必要的解释
例： int maxX, maxY; // The maximum resolution of the screen int errorCode; // store the error code #define MAX_PWD_LEN 6 // max length of password #define PI 3.14159 // Define a value for PI
5.1.2 自底向上的实现方法
自底向上实现方法：先实现结构图中的最下层 模块，逐步向上，最后实现顶层模块 特点： 需要编写驱动模块来测试底层模块的功能 整个系统直到最顶层模块被实现后才形成一个 完整的版本（从而系统的整体测试相对较晚）
4
5.2 面向对象的编程实现方法
方法一：先实现被其他类依赖的类（可根据 包图、类图和顺序图来识别类之间的依赖关 系），再实现依赖其他类的类 方法二：先实现依赖其他类的类，再实现被 依赖的类
10
函数头注释 例：
/** initialize the data process
•
* \param void • * \return 0 if initialization is OK, else return -1 • */ • int fnPROC_Init(void) • { /* program code */
A=2 OR X>1 d F
T e X=X+1
31
白盒测试的测试用例设计
语句覆盖(statement coverage)
选取足够多的测试数据，使得每个语句至少执 行一次 若例1选择测试用例为A=2,B=0,X=3,则程序通 过路径ace，每个语句都执行了一次 语句覆盖有可能发现不了判断条件中出现的错 误：例如该测试用例发现不了“第二个条件语 句中的X>1写成X>0”的错误
全局变量命名：全局可以被任何外部和内部模块
的函数使用 全局变量命名规则如下： + “功能模块名的缩写” + ”_” + “有意义的名字” ”g” 标示该变量为全局变量 功能模块名的缩写：全部大写并且要求尽量短小 有意义的名字：由一个或者几个有意义的单词构 成，且单词首字母大写 例：int gPROC_Handle;
路 径 覆 盖
弱
强
29
例1：被测程序
PROCEDURE TEST(VAR A,B,X : REAL); BEGIN IF (A>1 AND B=0) THEN X:= X/A; IF (A=2 OR X>1) THEN X:=X+1; END;
30
被测程序流程图
a
A>1 AND B=0 b F T c X=X/A
21
5.5.2 测试的基本原则
1. 测试应贯穿在开发的各阶段，尽早进行测试从而 尽快发现问题：软件测试对象 ＝ 文档 ＋ 程序 2. 测试队伍与研发队伍应分别建立：若由开发人员 来设计测试方案，则很容易根据自己的编程思路 来制定，具有局限性 3. 设计测试用例时，不仅要包括合理有效的输入条 件，也要包括不合理、无效的输入条件 4. 设计测试用例时不仅要确定输入数据，而且要 根据系统的功能确定预期的输出结果 5. 既要检查程序是否完成了它应做的工作，也要 检查它是否还做了它不应做的事情 6. 测试用例应长期保留，直到该程序被废弃。程 序修改之后，要利用它们进行回归测试 22
2
5.1 结构化的编程实现方法
5.1.1 自顶向下的实现方法
自顶向下实现方法：先实现结构图中的顶层模块，逐 步向下，最后实现下层最基本的模块（即首先调试整 个系统的结构及各模块间的接口，确保其正确性） 特点： 整个实现过程分成若干个版本：首先实现系统的框架， 在此基础上逐步添加更低层次的剩余模块 每一个程序版本包含完整的程序模块，可以被编译、 链接和执行（尽管早期版本不能实现完整的系统功能） 在实现上层模块时，与这些模块有直接调用关系的下 层模块只作为“桩”（stub）出现（只有名字及参数 传递关系） 尽管“桩”的内部功能还没有实现，但可以测试系统 3 结构的正确性，保证接口的通畅
18
5.5 系统测试
据统计，一个较好的程序员交付的程序 中，错误率为1％；而一个水平低的程序 员编写的程序，可能每段语句都含有一 两个错误 软件系统的任何错误都有可能造成损失， 问题的关键是尽早发现和纠正这些错误
19
实例: Intel的pentium处理器
1994年发现浮点除法缺陷 2000年某型号处理器发现一个可能导致运行程序被挂 起的执行指令问题
– PowerBuilder。。。
数据库开发工具
– SQL Server, Oracle, SyBase, DB2, MySql，
Access等
6
5.4 编程风格
代码语句的书写规范
在书写代码时，应通过采用缩进格式使程序的
层次更加清晰 对于程序中需要重复出现的代码段，应将其用 独立模块（函数或过程）实现 尽量不使用强制转移语句goto 在复合语句中，要将‘{’和‘}’对齐在同一列 上，各自独占一行 …
1991年爱国者导弹防御系统由于系统时钟错 误积累造成跟踪系统失去精确度
20
5.5.1 测试的基本概念
测试定义1：使用人工或自动手段来运行或测定 某个系统的过程，其目的在于检验它是否满足规 定的需求或弄清预期结果与实际结果之间的差别 测试定义2：是为发现错误而执行程序的过程 一个成功的测试是指它成功地发现了一个尚未发 现的错误 测试能证明错误的存在，但不能证明错误不存在 测试的关键问题是如何设计测试用例，即设计一 批测试数据，通过有限的测试用例，在有限的研 制时间、研制经费的约束下，尽可能多地发现程 序中的错误
9
举例：复杂语句匹配关系的注释 while (a>10) { if (x>=y) { ............ if (x==y) { } else { } } /* if (x>=y) */ else { } } /* while (a>10) */
测试信息流
23
5.5.3 测试方法
静态测试 （人工代码评审）
软件测试 黑盒测试 动态测试 白盒测试
24
静态测试（人工测试）
指人工评审软件文档和程序（即code review）， 发现其中的错误。内容包括：检查代码和设计 是否一致、检查代码逻辑表达是否正确和完整 等 静态测试一旦发现错误就能确定问题的位置， 且能一次发现多处错误 经验表明，组织良好的人工测试可发现程序中 30％－70%的编码错误和逻辑设计错误
25
动态测试（机器测试）
指在计算机上直接用测试用例运行被测程序，从 而发现程序错误 黑盒测试（功能测试）：指在不考虑程序的内部 结构特性情况下，测试程序的外部特性，即通过 输入和输出的特性检测是否满足指定的功能 白盒测试（结构测试）：根据程序的内部结构和 逻辑来设计测试用例，对程序的路径和过程进行 测试，检查是否满足设计的需要
局部函数命名
命名规则：“有意义的名字” 有意义的名字：每个单词的首字母大写（第1个单词全小写） 而其余字母小写 例：static void dataProcess()
宏的命名
命名规则：“有意义的名字” 有意义的名字：要求全部大写，并且名字允许用下划线分隔 例：#define MAX_PWD_LEN 8
13标识符命名风格标识符– 包括常量名、变量名、函数名、文件名…
命名风格
把标识符的意义和表示方法结合起来 同一个开发团队应采用统一的命名风格
14
•
例：一种标识符命名风格 文件命名
文件名的构成如下： “功能模块名缩写”+“有意义的名字”+“.扩展名” 功能模块名缩写：用小写字母，并且要求短小 有意义的名字：由编程者确定，要求意义明确且每 个单词首字母大写 后缀：由点号加小写的文件扩展名 例如：PROC功能模块的某文件可以这样命名： procInit.cpp
5
5.3 常用开发工具
Microsoft系列开发工具
Visual Studio：Visual C++, Visual Basic，C#等
Borland系列开发工具
– Delphi, Borland C++ Builder, JBuilder
Java开发工具
– Eclipse
其他开发工具
26
5.5.4 测试用例设计
测试用例
“彻底地测试（穷举测试）”在实际的测试过程中是 不可行的
例：程序P有两个整型输入量 X、Y，输出量为Z，在32位机 上运行。所有的测试数据组（Xi，Yi）的数目为：
32 2 2 32
=
64 2
1毫秒执行1次，共需5亿年
因此只能在一定的开发周期内和一定的经济条件下 通过精心选择有代表性的测试用例，尽可能多地发 现错误
测试用例
28
白盒测试的测试用例设计
通过对程序内部结构和逻辑的分析来设计测试用例 依据：需求分析、程序清单 用例设计采用逻辑覆盖法：考虑测试数据执行（覆 盖）程序的逻辑程度 根据覆盖情况的不同，逻辑覆盖可分为：
语 句 覆 盖
判 定 覆 盖
条 件 覆 盖
判 定 条 件 覆 盖
条 件 组 合 覆 盖
7
/* 举例：缩进 */ void main() { int i;
for (i=0; i<20; i++) { if ( i>10) { } else { } }
}
8
代码注释的书写规范
注释行应接近整个代码的30%以上，以提高程序的可 读性 需要注释的地方： 1）每个模块（类）、函数开头要有注释 2）全局变量、模块变量、重要的局部变量（类属性） 要有注释 3）复杂语句（比如匹配关系）、功能关键语句要有注 释
32
判定覆盖(decision coverage)
又称分支覆盖，即设计若干个测试用例使得程序 的每个判断的取真分支和取假分支至少执行一次 例1的测试用例可设计为： A=3,B=0,X=3（覆盖acd） A=2,B=1,X=6（覆盖abe） 比语句覆盖程度稍强，因为通过了各个分支的测 试，各语句也都执行了 不能保证一定能查出判断条件中的错误：如不能 发现把第二个判断语句中的X>1错写成X<1
12
Doxygen注释风格介绍
Doxygen工具的作用: 从标有Doxygen风格注释的 源文件中生成HTML格式的文档
Doxygen注释风格（以Javadoc风格为例） 文档注释：以“/**”开始，以“*/”结尾（在类、 方法/函数、属性声明之前使用） 单行注释：以“//”开始（在方法/函数内部使 用）
测试不能证明所开发的系统没有错误，只能通过测试
来提高系统的可靠性和开发质量 如何设计合理的测试用例是测试阶段的关键技术问题
27
一个测试用例由两部分组成：
– 对程序进行测试的一组输入数据的描述 – 由这组输入数据所产生的程序的预期输出结
果的描述
Module -----------------------------------------------------------
g
16
局部变量命名：如果局部变量由一个或者多个有意
义的单词构成则要求每个单词的首字母大写（第1个 单词全小写）而其余字母小写
例： int i,j,k;
char dataBuffer[1024];
17
全局函数命名
+ “有意义的名字”
命名规则如下： “fn” + “功能模块名的缩写” + ”_” 有意义的名字：每个单词首字母大写 例： void fnPROC_Init()
第六部分 系统实现与维护
1
系统实现阶段的任务
实现阶段的任务是实现系统设计阶段提出的物理 模型，按实施方案完成一个可以实际运行的软件系统
1）硬件准备
购置、安装、调试硬件设备，如计算机主机、输入输 出设备、通信设备等
2）软件准备
购置、安装系统软件、数据库管理系统，编写应用程 序
3）数据准备
根据已确定的数据库物理模型进行数据的整理、录入， 从而为系统调试、运行提供真实的数据
•
}
11
语句注释
对定义的变量、宏、语句的功能等作必要的解释
例： int maxX, maxY; // The maximum resolution of the screen int errorCode; // store the error code #define MAX_PWD_LEN 6 // max length of password #define PI 3.14159 // Define a value for PI
5.1.2 自底向上的实现方法
自底向上实现方法：先实现结构图中的最下层 模块，逐步向上，最后实现顶层模块 特点： 需要编写驱动模块来测试底层模块的功能 整个系统直到最顶层模块被实现后才形成一个 完整的版本（从而系统的整体测试相对较晚）
4
5.2 面向对象的编程实现方法
方法一：先实现被其他类依赖的类（可根据 包图、类图和顺序图来识别类之间的依赖关 系），再实现依赖其他类的类 方法二：先实现依赖其他类的类，再实现被 依赖的类
10
函数头注释 例：
/** initialize the data process
•
* \param void • * \return 0 if initialization is OK, else return -1 • */ • int fnPROC_Init(void) • { /* program code */
A=2 OR X>1 d F
T e X=X+1
31
白盒测试的测试用例设计
语句覆盖(statement coverage)
选取足够多的测试数据，使得每个语句至少执 行一次 若例1选择测试用例为A=2,B=0,X=3,则程序通 过路径ace，每个语句都执行了一次 语句覆盖有可能发现不了判断条件中出现的错 误：例如该测试用例发现不了“第二个条件语 句中的X>1写成X>0”的错误