本文详细介绍了软件工程的基础知识，包括软件危机的原因和解决方法，软件工程的定义和基本原理，以及软件生命周期的各个阶段。文章深入探讨了主要的软件过程模型，如瀑布模型和快速原型模型。此外，还涵盖了可行性研究、需求分析、总体设计、详细设计、系统实现与测试的关键点，如数据流图、数据字典、状态图、模块化设计、模块耦合和内聚、程序复杂度衡量以及软件测试的方法。整个内容旨在提供全面的软件工程理论和实践指导。
目录
第一章 软件工程概论
1. 软件危机的概念、产生原因、解决途径；
在计算机软件开发和维护过程中遇到的一系列严重问题。
(1）开发成本和进度估计不准
延迟交付、取消项目
（2）用户对已交付软件不满意
开发人员对用户信息交流不充分，产品不符合用户需求
（3）软件产品质量靠不住
软件产品保证技术（审查、复审、测试）未坚持不懈应
用软件开发全过程
（4）软件可维护性差
开发时未考虑，很多错误难以改正
（5）软件没有适当文档资料
文档资料应在软件开发过程中产生，保证最新
把系统化、规范化、可度量的途径应用于软件开发、运行和维护过程中；研究其实现途径
2. 软件工程的概念、基本原理；
把系统化、规范化、可度量的途径应用于软件开发、运行和维护过程中；研究其实现途径
软件工程技术
软件开发方法学
软件开发过程
软件工具和软件工程环境
软件工程管理
软件管理学
软件经济学
软件心理学
3. 软件生命周期；
软件从产生、发展到成熟、直至衰亡为止
组成：
软件定义 软件开发 软件维护
国标《计算机软件开发规范》，分8个阶段：可行性研究与计划，需求分析，总体设计，详细设计，实现（编码和单元测试），集成测试，确认测试，使用和维护
4. 主要的软件过程模型：瀑布模型、快速原型模型。
4.1 瀑布模型
特点：
- 1.阶段具有顺序性和依赖性
- 前一阶段结束后一阶段开始，前一个阶段输出文档，后一个阶段输入文档。
- 2.推迟实现观点
- 瀑布模型在编码前设置系统分析、系统设计，推迟程序物理实现，保证前期工作扎实。
- 3. 质量保证观点
- 瀑布模型每阶段坚持两个重要做法:
- 一是每阶段都必须完成完整、准确的文档。软件开发时人员间通信、运行时期维护的重要依据。
- 二是每阶段结束前对文档评审。
- 优点：
- 提高软件质量，降低维护成本，缓解软件危机。
- 缺点：
- 模型缺乏灵活性，无法解决需求不明确问题。用户不经过实践提出完整准确需求不切实际。
传统瀑布模型过于理想化，但人在工作过程中
不可能不犯错误，所以实际瀑布模型带反馈环
4.2 快速原理模型：
- 优点：
- 确定需求上优于瀑布模型（通过原型与用户交互）；
- 提供学习手段，通过开发原型和演示原型对开发者和使用者了解系统都有积极作用；
- 有的软件原型可以成为最终产品的一部分。
- 缺点：
- 快速建立的系统结构加连续修改可能导致产品质量低下原型系统的内部结构可能不好。
第二章 可行性研究
【考核内容】
可行性研究的任务、可行性研究过程；数据流图的概念及相关符号；数据字典的概念、内容、定义方法和用途。
【考试要求】
（1）理解软件项目可行性研究的必要性；
（2）掌握数据流图及数据字典的概念及用途。
1. 可行性研究的任务、可行性研究过程；
1. 1可行性研究的任务
1.2 可行性研究过程
2. 数据流图的概念及相关符号；
正方形（或立方体）：表示数据的源点或终点 人员、部门、计算机外部设备或传感器装置
圆角矩形（圆形）：代表变换数据的处理；一系列程序、单个程序或程序一个模块；人工处理过程。
开口矩形（两条平行横线）：代表数据存储 文件、文件一部分、数据库元素或记录一部分，可存在磁盘、磁带、磁鼓、主存、微缩胶片任何介质上。
箭头：表示数据流，即特定数据的流动方向。在处理之间有向流动的数据项或数据集合。
2.1 数据流图命名
（1）用名词，区别于控制流。
（2）代表整个数据流（数据存储）内容，不仅仅 反映某些成分。
（3）不用缺乏具体含义名字，如“数据”、“信息”。
2.2 处理命名
（1）用动宾词组，避免使用“加工”、“处理”等 笼统动词。
（2）应反映整个处理的功能，不是一部分功能。
（3）通常仅包括一个动词，否则分解。
2.3 数据源点/终点
不属于数据流图的核心内容，可能是人员、计算机 外部设备或传感器装置。采用它们在问题域中习惯使 用的名字（如“采购员”、“仓库管理员’等）。
3. 数据字典定义方法
对四类元素定义：数据流、数据元素、数据存储、处理
3.1 数据流的描述
数据流名：
- 说明：简要介绍作用即它产生的原因和结果。
- 数据流来源：即该数据流来自何方。
- 数据流去向：去向何处。
- 数据流组成：数据结构。
- 每个数据量流通量：数据量、流通量。
3.2 数据元素描述
数据元素名:
- 类型:数字（离散值、连续值），文字（编码类型）
- 长度:
- 取值范围: 相关的数据元素及数据结构：
3.3 数据存储的描述
数据存储名：
- 简述：存放的是什么数据。
- 输入数据:
- 输出数据:
- 数据文件组成:数据结构。
- 存储方式:顺序，直接，关键码。
- 存取频率:
3.4 处理描述
处理名:
- 处理编号:反映该处理的层次
- 简要描述:加工逻辑及功能简述
- 输入数据流:
- 输出数据流:
- 加工逻辑： 简述加工程序、加工顺序
4. 数据字典定义
定义数据方法：对数据自顶向下分解。
由数据元素组成数据的方式：
- 顺序： 以确定次序连接两个或多个数据元素；
- 选择： 从两个或多个可能元素中选一个；
- 重复： 把指定数据元素重复零次或多次；
- 可选： 一个数据元素可有可无的。
定义符号
第三章 需求分析
【考核内容】
需求分析的任务；实体联系图的作用、符号意义；数据规范化三个范式的定义；状态图的符号，需求验证的内容。
【考核要求】
（1）理解软件项目需求分析的内容；
（2）能够根据陈述绘制ER图；
（3）能够根据给定条件能判断一个关系属于第几范式。
1. 状态图的符号，需求验证的内容。
软件的行为模型：状态、事件，行为。
1.1 状态：被观察到的系统行为模式。
1.2 事件：引起状态转换的外界事件抽象。
1.3 行为：进入某状态所作动作
第四章 总体设计
【考核内容】
总体设计的概念、设计步骤；模块化的概念、作用，模块化程度与软件开发工作量的关系； Miller法则，模块独立性的重要性，模块耦合及其分类，模块内聚及其分类，模块设计的几条启发式规则及与之相关的概念（深度、宽度、扇出、扇入、作用域）；结构图的符号及其意义。
【考核要求】
（1）掌握总体设计的概念与设计步骤；
（2）理解软件总体设计中模块化的作用，模块化程度与软件开发工作量的关系；
（3）掌握Miller法则；
（4）理解5种模块耦合形式：数据耦合、控制耦合、特征耦合、公共耦合、内容耦合；
（5）理解7中模块内聚形式：功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚；
（6）掌握模块设计的启发式规则及相关概念。
1. 模块化
模块：“模块“又称”构件”一般指用一个名字。 调用的相邻程序元素序列。
模块化设计 (modular design) ： 按适当的原则把软件划分为一个个较小的、相关而又相对独立的模块。
2. 抽象
抽出事物的本质特性，暂不考虑细节。
3. 求精
求精是指为了能集中精力解决主要问题，尽量 推迟对细节问题的考虑，实际上是一个细化过程， 与抽象是互补的概念。 抽象使得设计者能够说明过程和数据，同时却 忽略底层细节； 求精帮助设计者在设计过程中揭示底层细节。
4. 信息隐藏
每个模块的实现细节对于其他模块来说是隐藏的 也就是说，模块中所包含的信息是不允许其他不需 要这些信息的模块访问的。
每个客户只能通过接口来了解该模块，而所有的 实现都隐蔽起来。
5. 模块独立
具有独立功能且和其他模块没过多作用。 两条理由：
- 容易分工合作。
- 容易测试和维护，修改工作量较小，错误传播范围小，扩充功能容易。
两个定性度量标准： 耦合和内聚。
6. 理解5种模块耦合形式
软件结构中不同模块间互连程度度量。
取决模块间接口复杂程度，通过接口数据。
追求尽可能松散耦合系统。
原则：尽量使用数据耦合，少用控制耦合，限制公共环境耦合， 完全不用内容耦合。
6.1 非直接耦合
两个模块分别能独立地工作不需要另一模块存在。（如上图1）
6.2 数据耦合
两模块通过参数交换数据信息。
6.3 特征耦合（控制耦合）
两模块通过参数交换控制信息（包括数字形式）
6.4 公共耦合
两个或多个模块通过一公共数据环境作用。
两种可能：
- 一模块送数据，另一模块取，等价数据耦合。
- 两模块既往公共环境送又从里面取，介于数据耦合和控制耦合之间。
6.5 内容耦合
以下情况发生为内容耦合：
- 一模块访问另一模块内部数据
- 一模块不通过正常入口转到另一模块内部
- 两模块有部分程序代码重叠（汇编程序）
- 一模块有多个入口。
7. 理解7中模块内聚形式
模块内各元素彼此结合紧密程度。
7.1 功能内聚
一模块中各部分是完成某一功能必不可少组成部分。如：矩阵乘法
7.2 顺序内聚
模块内处理元素同某功能密切相关，顺序执行。如：修改信息——查找再修改
7.3 通信内聚
一模块内各功能部分都使用相同输入数据，或产生相同输出数据。
7.4 过程内聚
模块内处理元素相关，特定次序执行。如把流程图中循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。
7.5 时间内聚
多为多功能模块，要求所有功能在同一时间内执行。如初始化模块和终止模块及紧急故障处理模块。
7.6 逻辑内聚
一模块完成功能在逻辑上属相同相似一类。
7.7 偶然内聚
模块内各部分间没有联系，即使有也很松散。
内聚程度
功能内聚：10分 顺序内聚：9分 通信内聚：7分 过程内聚：5分 时间内聚：3分 逻辑内聚：1分 偶然内聚：0分
8. 模块设计的启发式规则及相关概念
8.1 改进软件结构提高模块独立性
初步结构分解或合并，降低耦合提高内聚。
8.2 模块规模应该适中
过大分解不充分，但进一步分解不应降低模块独立性。过小开销大于有效操作，模块数目过多系统接口复杂。通常语句行数在50～100（一页纸），最多不超过500行。
8.3 参数适当（深度、宽度、扇出和扇入应适当）
深度：软件结构控制层数，标志一系统大小和复杂程度。
宽度：软件结构同一层模块数最大值，越大系统越复杂。
扇出： 一模块直接控制（调用）模块数，过大，模块复杂，过小不好、3－9。如：M扇出为3
扇入：有多少上级模块直接调用它，越大共享该模块上级模块越多。如：T扇入为4
8.4 模块作用域应在控制域内
作用域：受该模块内判定影响的所有模块集合。
控制域：模块本身及所有直接或间接从属它的模块集合。若模块作用域不在控制域内，会增大模块间控制耦合。
8.5 降低模块接口复杂程度
模块接口复杂是软件发生错误一主要原因。应使信息传递简单且和模块功能一致。
如：QUAD-ROOT(TBL,X) QUAD-ROOT(A,B,C,ROOT1,ROOT2)（第二种接口简单）
8.6 设计单入口、单出口模块
避免内容耦合。
8.7 模块功能可预测
输入数据相同，产生同样输出。模块功能防止过分受限。
第五章 详细设计（过程设计）
【考核内容】
程序流程图的符号，盒图的符号，PAD图的符号，判定表与判定树的作用与特点，程序复杂程度的定量度量。
【考核要求】
（1）能够根据陈述绘制相应处理的程序流程图、盒图、PAD图、判定表、判定树；
（2）掌握程序复杂程度的两种定量度量方法：程序图和环域复杂度。
1. 过程设计任务
- 确定模块算法
- 确定模块使用数据结构
- 确定模块接口（系统外部接口、用户界面、内部模块间接口细节、输入数据和输出数据）
2. 结构化程序设计
结构化程序设计技术是过程设计一关键技术。
- 经典定义：程序代码通过顺序、选择、循环三种控制结构连接，单入口单出口。（不使用goto语句）
- 扩展定义：可限制使用GOTO语句、DO_UNTIL和DO_CASE
- 修正定义：LEAVE和BREAK，可从循环中转移出来。
3. 结构化程序设计工具
3.1 程序流程图
历史最悠久、使用最广泛的过程设计工具。
优点：对控制流程描绘直观，便于初学者掌握。
缺点：
- 不是逐步求精好工具，过早考虑控制流程，非整体结构
- 用箭头代表控制流，程序员随意转移控制；
- 不易表示数据结构和调用关系。
- 顺序型：几个连续的加工依次序排列
- 选择型：由某个判定的取值决定选择两个加工中一个。
- 当型循环型：当循环控制条件成立时，重复执行特定的加工。
- 直到型循环型：重复执行特定的加工，直到循环控制条件成立时。
- 多情况选择型：列出多种加工情况根据控制变量的取值，选择执行其一
流程图标准化图符
3.2 N-S图（盒图）
特点：
- 功能域（一特定控制结构的作用域）明确；
- 不可能任意转移控制；
- 容易确定局部和全程数据的作用域；
- 容易表现嵌套关系，也可表示模块的层次结构。
3.3 PAD图
优点：
- 使用PAD图设计的程序必然是结构化程序；
- PAD图描绘的程序结构十分清晰；
- 用PAD图表现程序逻辑，易读、易懂、易记；
- 容易将PAD图转换成高级语言源程序；
- 支持自顶向下逐步求精。
3.4 判定表
能清晰表示复杂的条件组合与应做动作间对应关系。
四部分:
- 左上部列出所有条件；
- 左下部所有可能做的动作；
- 右上部表示各种条件组合的一矩阵；
- 右下部是和每种条件组合相对应的动作。
3.5 判定树
判定表变种，表示复杂条件组合与应做动作间对应关系。
优点： 形式简单，易看出含义，易于掌握和使用。
缺点： 简洁性不如判定表，相同数据元素重复写多遍， 越接近叶端重复次数越多。
3.6 过程设计语言(PDL)
伪码，用正文形式表示数据和处理过程设计工具。
PDL具有严格关键字外部语法，定义控制结构和数据 结构；
PDL表示实际操作和条件的内部语法灵活自由，适应 各种工程项目需要。
4. 程序复杂度
介绍使用比较广泛的McCabe方法。
4.1 流图
根据过程设计结果画出相应流图 。流图描述程序控制流，基本图形符号如下图所示。
4.2 计算流图的环形复杂度
三种方法：
- V（G）＝区域数
- V（G）＝E-N＋2 ，E为流图中边数，N为流图中节点数
- V（G）＝P＋1 ， P为判定点数
第六章 系统实现与测试
【考核内容】
编程语言的选择标准，良好的编程风格应遵循的规则，软件测试的定义，测试方法的种类（黑盒与白盒）和要求，测试的种类（单元测试、集成测试、确认测试）及其对应的阶段与对象，测试与调试的区别。
【考核要求】
（1）理解良好的编程风格应遵循的规则；
（2）掌握软件测试的概念及测试步骤；
（3）掌握两类常用软件测试方法：黑盒测试法与白盒测试法。
1. 理解良好的编程风格应遵循的规则
2. 软件测试的定义
- 测试是为了发现程序中的错误而执行程序的过程；
- 好的测试方案是极有可能发现迄今尚未发现的尽可能多的错误的测试；
- 成功的测试是发现了迄今尚未发现的错误的测试。
3. 软件测试准则
- 所有测试应能追溯到用户需求，测试的目的是发现错误，其中最严重的是不能满足用户需求的错误。
- 应尽早地和不断地进行软件测试。
不应把软件测试仅看作是软件开发一独立阶段，应把它贯穿到软件开发各阶段中。 - 充分注意测试中群集现象（Pareto原理）。
测试后程序中残存错误数与程序中已发现错误数目成正比，80％错误与20％模块有关。 - 测试应从小规模开始，逐步进行大规模测试。
单个模块，逐步集成。 - 不能做到穷举测试。
例 穷举测试：程序所有可能执行路径都检查遍。
- 第三方测试原则 。
从心理学角度考虑。
4. 测试步骤
4.1 单元测试
模块通过编译的语法检查后进入单元测试
-
模块接口
数据是否正确进出模块。 -
局部数据结构
局部数据的说明、初始化、默认值是否有问题。 -
重要执行路径
重要执行路径是否有错误计算、不正确比较或不适当控制流。 - 出错处理通路
- 错误描述是否难于理解；
- 记下错误是否与实际遇到错误不同；
- 错误处理之前，错误条件已引起系统干预；
- 错误处理不正确；
- 描述错误信息不足以帮助确定错误位置
- 边界条件
最重要，软件容易在边界上失效。
测试方法
- 代码审查（人工）
先由编写人非正式进行，再由审查小组正式进行，可查30％到70％设计错误和编码错误。- 程序编写者讲解，审查小组审查；
- 预排演。
- 计算机测试
需要辅助模块模拟与被测模块相联模块，两种：- 驱动模块──相当被测模块主程序。接收测试数据，传送 给被测模块，再输出测试结果。
- 桩模块 ──存根模块。代替被测模块调用的子模块。
4.2 集成测试
测试与接口有关问题：
-
穿越接口数据是否丢失；
-
一模块功能是否对另一模块功能产生不利影响；
-
各子功能组合起来，能否达到预期的父功能；
-
全局数据结构是否有问题；
-
单个模块误差累积起来，是否会放大等。
1.非渐增式集成
把所有模块一次组装进行测试。
2.渐增集成
将模块逐步组装成较大系统
- 自顶向下集成；
- 自底向上集成：
- 混合策略：
改进的自顶向下测试方法：基本用自顶向下方法，早期用自底向上测试关键模块。
混合法：软件结构上层模块用自顶向下，下层用自底向上。
3.回归测试
重新执行已作过测试的某子集，保证变化没带来非预期副作用。回归测试集：
- 检测软件全部功能的代表性测试用例；
- 专门针对可能受修改影响的软件功能附加测试；
- 针对被修改过软件功能测试
4.3 系统测试
使软件和其它系统元素（硬件、数据库等）结合测试
用于系统测试的测试类型:（1）恢复测试（2）安全性测试（3）强度测试（4）性能测试
(1)恢复测试
以不同方式强制软件出现故障，检测软件能否恰当完成恢复
- 自动恢复:检测重新初始化、数据恢复、重新启动等是否正确。
- 人工干预恢复:检测平均恢复时间是否在允许范围内。
(2)安全性测
试突破软件安全保护机构的安全保密措施，检验系统预防机制的漏洞。
- 测试者扮演试图攻击系统角色：
- 通过外部手段获取密码；
- 通过客户软件攻击系统；
- 控制系统使其他人无法访问；
- 引发系统错误，期望在系统恢复中侵入系统等。
(3)强度测试
检验系统能力最高达到实际限度, 让系统处于资源异常数量、异常频率、异常批量条件下测试系统承受能力。一般比平常限度高5-10倍的限度做测试用例。
(4)性能测试
软件运行性能与性能要求比较，检验是否达到性能要求规格
4.4 验收测试（确认测试）
- 系统测试后，客户再验收测试。
- 确认测试以需求规格说明书为测试基础；采用黑盒法。
α测试：用户对即将面市软件产品（称α版本）进行测试，开发者坐在用户旁边，随时记下错误情况和使用中问题，是受控环境下测试。
目的： 评价软件功能、可使用性、可靠性、性能、界面。
β测试：多个用户在实际使用环境下进行的测试。用户与公司签定支持产品预发行合同，使用产品，并返回错误信息。是在开发者无法控制的环境下进行的软件现场应用。
目的： 产品的支持性。
5. 软件测试方法-黑盒测试
如果知道产品应具有功能，可通过测试来检验是否每个功能都能正常使用。
6. 软件测试方法-白盒测试
如果知道产品内部工作过程可通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
7. 白盒测试技术
7.1 逻辑覆盖
1. 语句覆盖
选择测试数据，使被测程序中每个语句至少执行一次
2. 判定覆盖
每个语句至少执行一次，每个判定的真假分支至少执行一次。
3.条件覆盖
每个语句至少执行一次，判定表达式每个条件取各种可能结果
4. 判定/条件覆盖
取足够多测试数据，使判定表达式每个条件都取各种可能值，且每个判定表达式也都取到各种可能结果。
5. 条件组合覆盖
选足够多的数据，使每个判定表达式中条件的各种组合都至少执行一次
8. 控制结构测试
8.1 基本路径测试
Tom McCabe提出的一种白盒测试技术
-
根据过程设计结果画出相应流图
-
计算流图的环形复杂度
-
确定线性独立路径的基本集合
-
独立路径：至少包含一条在定义该路径之前不曾用过的边。
-
环形复杂度为独立路径基本集的上界。
-
-
设计测试用例覆盖基本集合的路径
例：计算不超过100个在规定值域内有效数的平均值；同时计算有效数字的综合和个数。用PDL描述的如图。
注意：一些独立路径无法独立测试（本例路径1），程序的正常流程不能形成独立执行该路径所需的数据组合（路径1，需要满足total.valid>0），这种情况下这些路径必须作为其他路径的一部分来测试。
8.2 循环测试
分四种：
（1）简单循环
- 零次循环：从循环入口直接跳到循环出口。
- 一次循环：查找循环初始值方面的错误。
- 二次循环：检查在多次循环时才能暴露的错误。
- m次循环：此时的m＜n。
- 最大次数循环、比最大次数多一次循环、比最大次数少一次的循环。
（2）嵌套循环
- 从最内层循环开始，置所有其它层循环为最小值
- 对最内层循环做简单循环的全部测试。
- 逐步外推，测试时保持所有外层循环变量取最小值，其它嵌套内层循环变量取“典型”值。
- 反复进行，直到所有各层循环测试完毕。
（3）连锁循环
- 各个循环互相独立，可用与简单循环相同方法进行测试。
- 几个循环不是互相独立，需要使用测试嵌套循环。
（4）非结构化循环
使用结构化程序设计方法重新设计
9. 黑盒测试技术
黑盒着重测：软件功能
黑盒发现错误类型：
- 功能不正确或遗漏
- 界面错误
- 数据结构或外部数据库访问错误
- 性能错误
- 初始化或终止错误
9.1 等价类划分
把程序的输入域划分成若干数据类，从每一数据类选取少数有代表性数据做为测试用例。
在各数据类中，各输入数据对揭露程序中的错误等效。
等价类划分原则：
- 输入条件规定范围，定义一有效等价类和两无效等价类。
例：输入条件:“…… 项数可以从1到999 ……” - 输入条件是布尔量，一个有效等价类和一个无效等价类。
- 规定输入数据一组值，程序对每个输入值分别进行处理。每个输入值确立一有效等价类，针对这组值确立一个无效等价类。
例：教工分房方案中，按教授、副教授、讲师、助教分别计分。 有效类4个；无效类1个。 - 规定输入数据必须遵守规则，定义一有效等价类（符合规则）和若干无效等价类（从不同角度违反规则）。
例：Pascal语言规定“一个语句必须以分号‘;’结束”。 这时，可以确定一个有效等价类“以‘;’结束”，若干个无效等价类：以‘:’结束、以‘,’结束等。 - 已划分等价类中各元素在程序中处理方式不同，将等价类进一步划分更小等价类。
9.1.1 划分等价类
- 有效等价类：合理，有意义输入数据构成集合。
- 无效等价类：不合理，无意义输入数据构成的集合。
9.1.2 确立测试用例
建立等价类表，列出所有划分出等价类:
- 为每一等价类规定一唯一编号；
- 设计一新测试用例，尽可能多覆盖尚未被覆盖有效等价类（防止冗余），重复，直到所有有效等价类被覆盖；
- 设计一新测试用例，仅覆盖一尚未被覆盖无效等价类（防止漏测），重复，直到所有无效等价类被覆盖。
9.2 边界值分析
- 等价类划分补充。
- 确定边界情况；
- 选正好等于边界值做测试数据；
- 选临近边界合法数据,刚超过边界非法数据。
常见边界值：
边界选择原则：
- 输入条件规定了取值范围，则以该范围作为边界；
例：重量10-50kg的邮件……，选择边界值 10、50、10.01、49.99、9.99及50.01。 - 输入条件规定值的个数，则以个数为边界；
例：“某输入文件可包含1至255个记录……” 应选取1、255、0及256。 - 针对规格说明的每个输出条件，使用原则（1）和（2）；
- 如果规格说明给出的输入或输出域是有序集合（如有序表、顺序文件等），则选取集合中特定次序的元素作为边界，如第一个、最后一个元素等；
- 如果程序中使用了一个内部数据结构，则应选择该结构的边界上的值，如数组、链表等；
- 分析规格说明，找出其它可能边界条件。
9.3 错误推测法
靠经验和直觉推测程序可能存在错误，有针对性编写检查这些错误的测试用例。
注意：
- 输入数据或输出数据为零
- 输入或输出数目为零（如表空或只1项）
- 缺省值
- 空白
- 空值
- 多个数据的组合效应
- 错误的群集现象
10. 测试与调试的区别
软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。
调试活动：
- 确定程序错误的性质和位置。
- 修改程序，排除错误。
10.1 调试步骤
- 从错误现场入手，确定程序出错位置；
- 找错误的内在原因；
- 找到则排除错误，回归测试。
- 否则，加测试用例证明猜测原因。
10.2 调试方法
-
强行排错
-
将内存内容打印出来分析。
-
程序特定部位设置打印语句。各关键变量改变部位、重要分支部位等，监视重要变量变化。
-
自动调试工具。程序语言调试功能或专门交互式调试工具，不必修改程序。如设置断点，观察程序断点处状态，包括变量、表达式值等。
-
- 回溯法排错(小程序常用）
确定最先发现“症状”位置。人工沿程序控制流程向回追踪源代码，直到找到错误根源或确定错误产生范围。
扫一扫
6169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
