第六章 编码与测试

6.1 编码 编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。

选择程序设计语言的主要实用标准： (1) 系统用户的要求。 (2) 可以使用的编译程序。 (3) 可以得到的软件工具。 (4) 工程规模。 (5) 程序员的知识。 (6) 软件可移植性要求。 (7) 软件的应用领域。 选择语言主要的实用标准： (1) 系统用户的要求。如果所开发的系统由用户负责维护，用户通常要求用他们熟悉的语言书写程序。 (2) 可以使用的编译程序。运行目标系统的环境中可以提供的编译程序往往限制了可以选用的语言的范围。 (3) 可以得到的软件工具。如果某种语言有支持程序开发的软件工具可以利用，则目标系统的实现和验证都变得比较容易。 (4) 工程规模。如果工程规模很庞大，现有的语言又不完全适用，那么设计并实现一种供这个工程项目专用的程序设计语言，可能是一个正确的选择。 (5) 程序员的知识。虽然对于有经验的程序员来说，学习一种新语言并不困难，但是要完全掌握一种新语言却需要实践。如果和其他标准不矛盾，那么应该选择一种已经为程序员所熟悉的语言。 (6) 软件可移植性要求。如果目标系统将在几台不同的计算机上运行，或者预期的使用寿命很长，那么选择一种标准化程度高、程序可移植性好的语言就是很重要的。 (7) 软件的应用领域。所谓的通用程序设计语言实际上并不是对所有应用领域都同样适用。因此，选择语言时应该充分考虑目标系统的应用范围。

2 程序设计风格 程序实际上也是一种供人阅读的文章，有一个文章的风格问题。应该使程序具有良好的风格。 源程序文档化 数据说明 语句结构 输入／输出方法

（1）源程序文档化 标识符的命名 注释 程序的视觉组织

★ 符号名的命名 符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。 标识符命名应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

★ 符号名的命名 名字不是越长越好，应当选择精炼的意义明确的名字。必要时可使用缩写名字。 不同语言的命名规则不同!

夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。 ★ 程序的注释 夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。 注释决不是可有可无的。 一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。 注释分为序言性注释和功能性注释。

序言性注释 通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。 序言性注释包括： 有关本模块功能和目的的说明； 开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。 主要算法； 接口说明：包括调用形式，参数描述，子程序清单； 有关数据描述：重要的变量及其用途，约束或限制条 件，以及其它有关信息；

功能性注释嵌在源程序体中，描述语句或程序段将要完成的主要功能 要点 描述一段程序，而不是每一个语句； 用缩进和空行，使程序与注释容易区别； 注释要正确。 功能性注释嵌在源程序体中，描述语句或程序段是在做什么工作，或是执行了下面的语句会怎么样，而不要解释下面怎么做。

移行也叫做向右缩进，使程序完全分清层次关系。（缩进多少视语言而定） ★ 视觉组织 空格、空行和移行 运算符和操作符用空格分开 自然的程序段之间可用空行隔开 移行也叫做向右缩进，使程序完全分清层次关系。（缩进多少视语言而定） 对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行 空格、空行和移行犹如写文章在Word中排版

★ 视觉组织 空格、空行和移行 例如，两重选择结构嵌套，写成下面的移行形式，层次就清楚得多。 ★ 视觉组织 空格、空行和移行 例如，两重选择结构嵌套，写成下面的移行形式，层次就清楚得多。 IF（…） THEN IF（…） THEN …… ELSE …… ENDIF …… ELSE …… ENDIF 对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行。使程序的逻辑结构更加清晰。

(2) 数据说明 ① 常量说明 在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。 (2) 数据说明 在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。 数据说明的次序应该标准化。有次序易查阅，能加速测试、调试和维护的过程。 例如：数据说明 数据类型说明 ① 常量说明 ② 简单变量类型说明 ③ 数组说明 ④ 公用数据块说明 ⑤ 所有的文件说明 ① 整型量说明 ② 实型量说明 ③ 字符量说明 ④ 逻辑量说明

b. 当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。 例如，把 integer size, length, width, cost, price 写成 integer cost, length, price , size, width c. 如果设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现这个数据结构的方法和特点。

构造语句时应该遵循的原则是:简单而直接 if ( !( char ＜ 0 || char ＞ 9 ) ) （3）语句构造 △ 不要为了节省空间而把多个语句写在同一行； △ 尽量减少对“非”条件的测试； if ( !( char ＜ 0 || char ＞ 9 ) ) 如何修改？ if ( char >= 0 && char <= 9 ) 不要让读者绕弯子想。 △ 避免大量使用循环嵌套和条件嵌套； △ 利用括号使逻辑表达式或算术表达式的运算次序清晰

在设计和编写程序时应该考虑下述有关输入输出风格的规则： （4）输入输出 在设计和编写程序时应该考虑下述有关输入输出风格的规则： △ 对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性； △ 检查输入项的各种重要组合的合法性，必要时报告输入状态信息； △ 使得输入的步骤和操作尽可能简单，并保持简单的输入格式； 增加数据时：非空检查、PK或FK检查、数据有效性检查

△ 应允许缺省值； △ 在交互式输入输入时，要在屏幕上使用提示符明确提示交互输入的要求，指明可使用选择项的种类和取值范围。

程序的效率是指程序的执行速度及程序所需占用的内存的存储空间。 （5）程序效率 程序的效率是指程序的执行速度及程序所需占用的内存的存储空间。

程序效率的几条准则： 软件效率以需求为准 效率属于什么性质需求？ 性能需求 好的设计可以提高效率 程序的效率与程序的简单性相关，不要牺牲程序的清晰性和可读性来不必要地提高效率。

效率问题 (1) 程序运行时间 (2) 存储器效率

(1) 程序运行时间 源程序的效率直接由详细设计阶段确定的算法的效率决定，但是，写程序的风格也能对程序的执行速度和存储器要求产生影响。

在把详细设计结果翻译成程序时，总可以应用下述规则： (1) 程序运行时间 在把详细设计结果翻译成程序时，总可以应用下述规则： △ 研究嵌套的循环，以确定是否有语句可以从内层往外移； △ 不要混合使用不同的数据类型； △ 尽量使用整数运算和布尔表达式； △ SQL优化及使用存储过程； △ 多if语句的优化。 在效率是决定性因素的应用领域，尽量使用有良好优化特性的编译程序，以自动生成高效目标代码 Foreach in语句 DataSet和DataReader

(2) 存储器效率 采用结构化程序设计，将程序功能合理分块，使每个模块或一组密切相关模块的程序体积大小与每页的容量相匹配，可减少页面调度，减少内外存交换，提高存储效率。 选择可生成较短目标代码且存储压缩性能优良的编译程序，有时需采用汇编程序。

6.2 软件测试基础 软件开发过程必须伴有质量保证活动。 软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。 6.2 软件测试基础 软件开发过程必须伴有质量保证活动。 软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。 软件产品最大的成本是检测软件错误、修正软件错误的成本。 在整个软件开发中，测试工作量一般占30%～ 40%，甚至≥50%。

表面看来，软件测试的目的与软件工程所有其他阶段的目的都相反。 暴露问题并不是软件测试的最终目的，发现问题是为了解决问题！

软件测试的问题 软件缺陷是什么？ 谁执行测试？ 开发者？ 单独的测试人员？ 两方面人员？ 测试什么？ 每个部分都测试？ 测试软件中高风险部分？ 什么时候测试？ 怎样测试？ 测试应进行到什么程度？

缺陷 (bug) 缺点 (defect) 谬误 (fault) 问题 (problem) 错误 (error) 异常 (anomaly) 软件缺陷是什么 --- 描述软件失败的术语 缺陷 (bug) 缺点 (defect) 谬误 (fault) 问题 (problem) 错误 (error) 异常 (anomaly) 偏差 (variance) 失败 (failure)

国外公司一般的开发人员与测试人员是1：1 Exchange 2000 和 Windows 2000 的人员结构 Exchange 2000 项目经理 25人 约 250人 开发人员 140人 约 1700人 测试人员 350人 约 3200人 开发人员/测试人员 1:2.5 1: 1.9 国外公司一般的开发人员与测试人员是1：1

软件测试人员 测试工具软件开发工程师 (Software Development Engineer in Test，简称SDE/T) 软件测试工程师 (Software Test Engineer ，简称STE)

负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性，并写出相应的测试规范和测试案例 负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。 STE SDE/T 负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性，并写出相应的测试规范和测试案例

黑盒测试 白盒测试 单元测试 累计综合测试 集成测试 功能测试 系统测试 端到端测试 健全测试 衰竭测试 接受测试 负载测试 强迫测试 测试设计中需要考虑的22种测试类型 黑盒测试 白盒测试 单元测试 累计综合测试 集成测试 功能测试 系统测试 端到端测试 健全测试 衰竭测试 接受测试 负载测试 强迫测试 性能测试 可用性测试 安装/卸载测试 恢复测试 兼容测试 安全测试 比较测试 Alpha测试 Beta测试 黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。 　 　　白盒测试：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。 　 　　单元测试：最微小规模的测试；以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构； 还可能需要开发测试驱动器模块或测试套具。 　 　　累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来； 这种测试可由程序员或测试员来做。 　 　　集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。 　 　　功能测试：用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作（自然他能用于测试的各个阶段）。 　 　　系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。 　 　　端到端测试：类似于系统测试；测试级的“宏大”的端点；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。 　 　　健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。 　 　　衰竭测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。 　 　　接受测试：基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。 　 　　负载测试：测试一个应用在重负荷下的表现，例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。 　 　　强迫测试：在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。 　 　　性能测试：在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”（和其他类型的测试）应在需求文档或质量保证、测试计划中定义。 　 　　可用性测试：对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。 　 　　安装/卸载测试：对软件的全部、部分或升级安装/卸载处理过程的测试。 　 　　恢复测试：测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。 　 　　安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。 　 　　兼容测试：测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。 　 　　比较测试：与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。 　 　　Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。 　 　　Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成

6.2.1 软件测试的目标 (1) 预防错误: 几乎不可实现 (2) 发现错误

6.2.1 软件测试的目标 G.Myers: (1) 测试是为了发现程序中的错误而执行程序的过程； 6.2.1 软件测试的目标 G.Myers: (1) 测试是为了发现程序中的错误而执行程序的过程； (2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3) 成功的测试是发现了至今为止尚未发现的错误的测试。

测试的目的 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷 证明软件的功能和性能与需求说明相符合

从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误。 6.2.2 软件测试准则 （1） 所有测试都应该能追溯到用户需求。 从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误。

软件开发面临的实际问题 项目开发前 分析员的理 解、设想

软件开发面临的实际问题 分析员 的描述

软件开发面临的实际问题 完成的设计

软件开发面临的实际问题 程序员做出的产品

软件开发面临的实际问题 现场的安装

软件开发面临的实际问题 用户原来的设想

(2) 尽早地和不断地进行软件测试 6.2.2 软件测试准则 概要设计--测试计划 详细设计--测试用例 注意：软件测试不等于程序测试 6.2.2 软件测试准则 (2) 尽早地和不断地进行软件测试 概要设计--测试计划 详细设计--测试用例 注意：软件测试不等于程序测试 据美国一家公司统计，查出的软件错误中，属于需求分析和软件设计的错误约占 64%，属于程序编写的错误仅占 36%。程序编写的许多错误是“先天的”。

需求分析 测试与开发前期工作的关系 概要设计 详细设计 编 码 单元测试 集成测试 确认测试 系统测试

(3) pareto原则(80/20法则)：测试发现的错误中的80%很可能是由程序中20%的模块造成的。 6.2.2 软件测试准则 (3) pareto原则(80/20法则)：测试发现的错误中的80%很可能是由程序中20%的模块造成的。 (4) 应该从“小规模”测试开始，并逐步进行“大规模”测试。

6.2.2 软件测试准则 （5）测试用例构成 --输入数据和预期的输出结果 --合理的输入和不合理的输入数据 （6）穷举测试是不可能的 所谓穷举测试就是把程序所有可能的执行路 径都检查一遍的测试。

=2 X2 X2 ≈3X10 黑盒测试 执行时间: 设测试一次需1ms 例:输入 三条边长 可采用的测试用例数 (设字长16位) 例:输入 三条边长 可采用的测试用例数 (设字长16位) 执行时间: 设测试一次需1ms 共需一万年. 黑盒测试 =2 X2 X2 ≈3X10 16 14

（7）为了达到最佳的测试效果，应该由独立的第三方从事测试工作 6.2.2 软件测试准则 （7）为了达到最佳的测试效果，应该由独立的第三方从事测试工作 （8）程序修改后要回归测试 （9）应长期保留测试用例，直至系统废弃

6.2.3 测试方法 人工测试方法 静态测试方法 计算机辅助静 态分析方法 软件测试的 策略和方法 白盒测试方法 动态测试方法 黑盒测试方法

基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。 静态测试： 基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。 静态测试约可找出30～70%的逻辑设计错误. 对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括： 是否符合标准和规范； 通过结构分析、流图分析、符号执行指出软件缺陷。

通过运行软件来检验软件的动态行为和运行结果的正确性。 动态测试： 通过运行软件来检验软件的动态行为和运行结果的正确性。 动态测试的两个基本要素： 被测试程序 测试数据（测试用例） 动态测试方法： (1) 选取定义域有效值,或定义域外无效值； (2) 对已选取值决定预期的结果； (3) 用选取值执行程序； (4) 执行结果与预期的结果相比,不吻和程序有错。

如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行 ---- 1、白盒测试 (White Box Testing) 2、黑盒测试 (Black Box Testing) 动态测试技术 如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行 ---- 称为白盒测试。 如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用 ---- 称为黑盒测试。

白盒测试 的内容 对程序模块的所有独立 执行路径至少测试一次 对所有的逻辑判定，取 “真”与取“假”的两种情况 都能至少测试一次。 在循环的边界和运行边 界限内执行循环体 测试内部数据结构的有 效性。

软件 黑盒测试(Black Box Testing) 已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 的内容 Alpha/Beta Testing 1、Alpha/Beta Testing 测试：是指产品在正式发布之前往往要先发布一些测试版，让用户能够反馈出相关信息或者找到存在的 Bug ，以便在正式版中得到解决。 2、菜单/帮助测试：大家千万不要以为这项测试不值得进行，其实，在软件产品开发的最后阶段，文档里发现的问题往往是最多的。因为在软件测试过程中，开发人员修复测试人员发现的 Bug ，而且可能会对软件的一些功能进行修改，因而在软件开发和测试的过程中，所有的功能和特性都不是固定不变的，都会进行调整。所以，一般来说，直到软件 （产品发布 称为ship） 时才编写软件的帮助文档，这样才能保证帮助文件的内容与软件功能相符。 当我们在做帮助文件测试的时候，应该装做什么都不懂，就按帮助文件提供的步骤去做，看看该文件是否正确。 例如，在微软的软件测试人员中就有一位曾经是家庭主妇来担当测试人员。当时这位主妇已经四十多岁了，是一位军官的妻子，三个孩子的母亲，她只读到高中毕业，连大专也没有上过。她使用计算机的水平也非常初级，而且还是跟着自己的女儿学的。后来她在家闲着无聊，就决定出来找工作，而且居然跑到微软来应聘了。但是她这个人的思维有点怪，怪点子很多，能够很快地发现一些问题，比如她在测试 IE 产品时就找出了好几个 Bug ，其实她是完全凭着感觉来找 Bug 的。 在三个月后，她的测试水平已经非常专业了，以至于被微软转为正式职员，并担当了测试组长了。 3、发行测试：在软件正式发行前，产品要经过非常仔细地测试。除了专门的测试人员外，还需要几千个甚至几十万个其他用户与合作者通过亲自使用来对产品进行策划 ，然后将错误信息反馈给我们，到了发行测试这一步，如果出现非改不可的 Bug ，就必须推迟软件的发行。有的时候，也可能推到几个月后，在此其间需要对软件重新进行全面的测试，这样将消耗大量的时间和人力物力。 例如，在微软曾经有过这样一个案例，在他们测试一个浏览 Web 页面时，要求要 5万个用户同时浏览一个 Web 页面，以保证网站的服务器(Server) 不会死机。一般来说，要找到 5万个用户同时打开一个网页是不现实的，就算能够找到 5万个测试者， 成本也是非常高的，后来他们便利用了测试工具来完成这个测试。 4、回归测试(Regression Testing)：回归测试的目的，就是保证以前已修复的 Bug 在软件 Ship (产品发布) 以前不会再出现。实际上，许多Bug 都在回归测试时发现的。在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能又回来了，有的 Bug 经过修改之后可能又产生了新的Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。 菜单/帮助测试 发行测试 回归测试

2. 子系统测试 --- 局部 3. 系统测试 --- 集成 4. 验收测试 --- 用户参与 5. 平行运行 --- 新旧共存 6.2.4 测试步骤 大型软件系统的测试过程基本上由下述几个步骤组成： 1. 模块测试 --- 单元 2. 子系统测试 --- 局部 3. 系统测试 --- 集成 4. 验收测试 --- 用户参与 5. 平行运行 --- 新旧共存 1. 模块测试 在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。 2. 子系统测试 子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。 3. 系统测试 系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。 不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。 4. 验收测试 验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。验收测试也称为确认测试。 5. 平行运行 关系重大的软件产品在验收之后往往并不立即投入生产性运行，而是要再经过一段平行运行时间的考验。所谓平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。这样做的具体目的有如下几点： (1) 可以在准生产环境中运行新系统而又不冒风险； (2) 用户能有一段熟悉新系统的时间； (3) 可以验证用户指南和使用手册之类的文档； (4) 能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。

6.2.5 测试阶段的信息流 测试计划 需求规格说明书 软件设计说明书 被测源程序 软件配置 结果 排错 分析 测试 测试用例 (测试数据) 6.2.5 测试阶段的信息流 需求规格说明书 软件设计说明书 被测源程序 软件配置 改正的 软件 结果 分析 排错 错误 测试结果 测试 测试计划 测试用例 (测试数据) 测试驱动程序 预测的 可靠性 测试配置 可靠性 分析 出错率 数据 预期结果 测试工具 测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等。

软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。因此，需求分析、概要设计、详细设计以及程序编码等所得到的文档资料，都应成为软件测试的对象。

软件开发过程是一个自顶向下、逐步细化的过 程，而测试则是依相反的顺序安排的，自底向上、逐步集成的过程。低一级为上一级测试准备条件。 测试与软件开发阶段的关系 软件开发过程是一个自顶向下、逐步细化的过 程，而测试则是依相反的顺序安排的，自底向上、逐步集成的过程。低一级为上一级测试准备条件。 ① ② ③ 需求分析 设 计 编 码 确认测试 集成测试 单元测试 ③ ② ①

1. 模块接口 2. 局部数据结构 3. 重要的执行通路 参数的数目、次序、属性是否一致； 6.3 单元（模块）测试-测试重点 1. 模块接口 参数的数目、次序、属性是否一致； 2. 局部数据结构 局部数据说明、初始化、默认值等方面的错误。 3. 重要的执行通路 选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。

4. 出错处理思路 5. 边界条件 6.3 单元（模块）测试-测试重点 (1) 对错误的描述是难以理解的； 6.3 单元（模块）测试-测试重点 4. 出错处理思路 (1) 对错误的描述是难以理解的； (2) 记下的错误与实际遇到的错误不同； (3) 对错误的处理不正确； (4) 描述错误的信息不足以帮助确定造成错误的位置。 5. 边界条件 边界测试是单元测试中最后的也可能是最重要的任务，软件常常在它的边界上失效。

由审查小组,人工测试源程序称为代码审查。可以查出30%～70%的逻辑设计错误和编码错误。 6.3 单元（模块）测试-代码审查 由审查小组,人工测试源程序称为代码审查。可以查出30%～70%的逻辑设计错误和编码错误。 审查的步骤： 小组成员先研究设计说明书，力求理解这个设计。 由设计者扼要地介绍他的设计。 审查会上程序的编写者逐个语句地解释是怎样用程序代码实现这个设计的。 审查会上对照程序设计常见错误，分析审查这个程序。 当发现时，记录错误，继续审查。

模块并不是一个独立的程序，要运行它就必须为其开发驱动软件和(或)存根（桩）软件。 6.3 单元（模块）测试-计算机测试 模块并不是一个独立的程序，要运行它就必须为其开发驱动软件和(或)存根（桩）软件。 驱动程序也就是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块，并且印出有关的结果。 存根（桩）程序代替被测试的模块所调用的模块，也称为“虚拟子程序”。它使用被它代替的模块的接口，可能做最少量的数据操作，印出对入口的检验或操作结果，并且把控制归还给调用它的模块。

集成测试 是测试和组装软件的系统化技术，其主要目标是发现与接口有关的问题。 6.4 集成测试 集成测试 是测试和组装软件的系统化技术，其主要目标是发现与接口有关的问题。

1、非渐增式测试方法，即：先分别测试每个模块，再把所有模块一起集成进行测试。 6.4 集成测试 集成测试有两种方法。 1、非渐增式测试方法，即：先分别测试每个模块，再把所有模块一起集成进行测试。 2、渐增式测试，即：先把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。 这种每次增加一个模块的方法实际上同时完成单元测试和集成测试，目前在进行集成测试时普遍采用渐增式测试方法。

回归测试是指重新执行已经做过的测试的某个子集，以保证修改变化没有带来非预期的副作用。 6.4.3 回归测试 回归测试是指重新执行已经做过的测试的某个子集，以保证修改变化没有带来非预期的副作用。 （1）针对可能受修改影响的软件功能的附加测试； （2） 针对被修改过的软件成分的测试。 在集成测试过程中，回归测试用例的数量可能变得非常大。因此，应该把回归测试集设计成只包括可以检测程序每个主要功能中的一类或多类错误的那样一些测试用例。一旦修改了软件之后就重新执行检测程序每个功能的全部测试用例，是低效而且不切实际的。

确认测试也称为验收测试，它的目标是验证软件的有效性。 有效性：软件的功能和性能如同用户所合理期待的那样。 6.5 确认测试 确认测试也称为验收测试，它的目标是验证软件的有效性。 有效性：软件的功能和性能如同用户所合理期待的那样。 需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理期望，因此是软件有效性的标准，也是进行确认测试的基础。

确认测试必须有用户积极参与，或者以用户为主进行。 确认测试通常使用黑盒测试法。 满足所有功能要求，能达到每个性能要求，文档资料是准确而完整的，此外，还应该保证软件能满足其他预定的要求（例如，安全性、可移植性、兼容性和可维护性等）。

---- 软件配置：软件需求规格说明、软件设计规格说明、源代码等。 复查的目的是保证软件配置的所有成分都齐全，文档与程序完全一致。 6.5.2 软件配置复查 确认测试的一个重要内容是复查软件配置。 ---- 软件配置：软件需求规格说明、软件设计规格说明、源代码等。 复查的目的是保证软件配置的所有成分都齐全，文档与程序完全一致。 确认测试过程中还应该严格遵循用户指南及其他操作程序，以便检验这些使用手册的完整性和正确性。

Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。 6.5.3 Alpha和Beta测试 Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。 Beta测试由软件的最终用户们在一个或多个客户场所进行。Beta测试是软件在开发者不能控制的环境中的“真实”应用。 如果软件是专为某个客户开发的，可以进行一系列验收测试，以便用户确认所有需求都得到满足了。验收测试是由最终用户而不是系统的开发者进行的。事实上，验收测试可以持续几个星期甚至几个月，因此能够发现随着时间流逝可能会降低系统质量的累积错误。 如果一个软件是为许多客户开发的（例如，向大众公开出售的盒装软件产品），那么，让每个客户都进行正式的验收测试是不现实的。在这种情况下，绝大多数软件开发商都使用被称为Alpha测试和Beta测试的过程，来发现那些看起来只有最终用户才能发现的错误。

如 何 测 试 ？ 关键技术 ---- 设计测试方案。 测试方案 ---- 包括：具体的测试目的，应该输入的测试数据和预期的结果。 如 何 测 试 ？ 关键技术 ---- 设计测试方案。 测试方案 ---- 包括：具体的测试目的，应该输入的测试数据和预期的结果。 测试数据和预期的输出结果称为测试用例。其中最困难的问题是设计测试用的输入数据。

发现（测试）什么错误？ 软件错误分类 功能错(需求分析错误) 软件结构错 数据错 编码错 软件集成错 测试定义与测试执行错误

(1) 语句覆盖 (2)判定覆盖 逻辑覆盖 ---- 是以程序内部的逻辑结构为基础的设计测试用例的技术。 6.6 白盒测试技术 逻辑覆盖 ---- 是以程序内部的逻辑结构为基础的设计测试用例的技术。 (1) 语句覆盖 (2)判定覆盖 (3)条件覆盖 (4)判定/条件覆盖 (5)条件组合覆盖 (6)点覆盖 (7)边覆盖 (8)路径覆盖

逻辑覆盖测试的5种标准 发现错误 的能力 标 准 含 义 1(弱) 语句覆盖 每条语句至少执行一次 2 判定覆盖 每一判定的每个分支至少执行一次 3 条件覆盖 每一判定中的每个条件，分别按“真”、 “假”至少各执行一次 4 判定/条件覆盖 同时满足判定覆盖和条件覆盖的要求 5 (强) 条件组合覆盖 求出判定中所有条件的各种可能组合 值，每一可能的条件组合至少执行一次

a c b e d 只需设计一个测试用例: 输入数据：A=2， B=0， X=4 即达到了语句覆盖。 F T F T 1、语句覆盖 使程序中每个语句至少执行一次。 只需设计一个测试用例: 输入数据：A=2， B=0， X=4 即达到了语句覆盖。 开始 a F (A>1) AND (B=0) T c b X=X/A F T (A=2) OR (X>1) e 语句覆盖是最弱的 逻辑覆盖 （如：AND 写成 OR，X>1 写成 X <1,查不出来） d X=X+1 返回

a c b e d F T F T 2、 判定覆盖(分支覆盖) 使每个判定的真假分支都至少执行一次 开始 可设计两组测试用例: A=3，B=0 ，X=3 可覆盖c、d分支 A=2，B=1 ，X=1 可覆盖b、e分支 两组测试用例可覆盖所有判定的真假分支 a F (A>1) AND (B=0) T c b X=X/A F T (A=2) OR (X>1) e d X=X+1 判定覆盖仍是弱的逻辑覆盖，只覆盖了全部路径的一半。 返回

a c b e d F T F T 3、条件覆盖 使每个判定的每个条件的可能取值至少执行一次 开始 返回 满足条件:T1,T1, 第一判定表达式: 设条件 A>1 取真 记为T1 假 T1 条件 B=1 取真 记为T2 假 T2 第二判定表达式: 设条件 A=2 取真 记为T3 假 T3 条件 X>1 取真 记为T4 假 T4 开始 a F (A>1) AND (B=0) T c b X=X/A F (A=2) OR (X>1) T e d X=X+1 返回

测试用例 通过 满足的 覆盖 A B X 路径 条件 分支 1 0 3 abe T1,T2,T3,T4 b,e 2 1 1 abe T1,T2,T3,T4 b,e 两个测试用例覆盖了四个条件八种可能取值。 未覆盖c、d分支，不满足判定覆盖的要求. 条件覆盖不一定包含判定覆盖 判定覆盖也不一定包含条件覆盖

a c b e d F T F T 4 判定/条件覆盖 开始 返回 选取足够多的 测试用例，使判断 满足条件:T1,T1, 中的每个条件的所 4 判定/条件覆盖 选取足够多的 测试用例，使判断 中的每个条件的所 有可能取值至少执 行一次，同时每个 判断本身的所有可 能判断结果至少执 行一次. 满足条件:T1,T1, T2,T2 T3,T3 T4,T4 开始 a F (A>1) AND (B=0) T c b X=X/A F T (A=2) OR (X>1) e d X=X+1 返回

测试用例 通过 满足的条件 覆盖 A B X 路径 分支 2 0 4 ace T1,T2,T3,T4 c,e 1 1 1 abd T1,T2,T3,T4 b,d 能同时满足判定、条件两种覆盖标准的取值

5、条件组合覆盖 所有可能的条件取值组合至少执行一次 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 测试用例 通过 满足的 覆盖 A B X 路径 条件 分支 2 0 4 ace T1,T2,T3,T4 c,e 2 1 1 abe T1,T2,T3,T4 b,e 1 0 2 abd T1,T2,T3,T4 b,d 1 1 1 abd T1,T2,T3,T4 b,d

6.6.2 控制结构测试 1. 基本路径测试 2. 条件测试 3. 循环测试 请自学！多学一些总是有好处的！

6.7 黑盒测试技术 黑盒测试着重测试软件功能。 黑盒测试力图发现下述类型的错误： ①功能不正确或遗漏了功能； ②界面错误； ③数据结构错误或外部数据库访问错误； ④性能错误； ⑤初始化和终止错误。 黑盒测试技术：等价划分法、边界值分析法、错误推测法、因果图法等。

把所有可能的输入数据划分成若干个等价的子集，使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同. 1 等价类划分法（等价分配） 把所有可能的输入数据划分成若干个等价的子集，使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同. 可从每个子集中选取一组数据来测试程序

例:某报表处理系统要求用户输入处理报表的日期,日期限制在2003年1月至2008年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。系统日期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月。 如何用等价类划分法设计测试用例,来测试程序的日期检查功能？

如何划分等价类？ 有效等价类(合理等价类) 无效等价类(不合理等价类) 划分等价类的标准： 覆盖 不相交 代表性

划分等价类的规则 (1)如果输入条件规定了取值范围，可定义一个有效等价类和两个无效等价类。 例 输入值是学生成绩，范围是0～100 例 输入值是学生成绩，范围是0～100 0 100 无效等价类 成绩<0 有效等价类 0≤成绩≤100 无效等价类 成绩>100 (2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类。

用等价类划分法设计测试用例步骤： (1)形成等价类表，每一等价类规定一个唯一的编号； (2)设计一测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一 步骤，直到所有有效等价类均被测试用例所覆盖； (3)设计一新测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖

第一步：等价类划分 “报表日期”输入条件的等价类表 输入条件 有效等价类 无效等价类 有非数字字符 (4) 报表日期的 输入条件 有效等价类 无效等价类 有非数字字符 (4) 少于6个数字字符 (5) 多于6个数字字符 (6) 报表日期的 类型及长度 6位数字字符(1) 在2003～2008 之间 (2) 小于2003 (7) 大于2008 (8) 年份范围 小于1 (9) 大于12 (10) 月份范围 在1～12之间(3)

对编号为1,2,3的3个有效等价类用一个测试用例覆盖： 第二步：为有效等价类设计测试用例 对编号为1,2,3的3个有效等价类用一个测试用例覆盖： 测试数据 期望结果 覆盖范围 200306 输入有效 等价类(1)(2)(3) (1)6位数字字符 (2)年在2003～2008之间 (3)月在1～12之间

测试数据 期望结果 覆盖范围 第三步：为每一个无效等价类设至少设计一个测试用例 003MAY 输入无效 等价类(4) 20035 输入无效 测试数据 期望结果 覆盖范围 003MAY 输入无效 等价类(4) 20035 输入无效 等价类(5) 2003005 输入无效 等价类(6) 200105 输入无效 等价类(7) 200905 输入无效 等价类(8) 200300 输入无效 等价类(9) 200313 输入无效 等价类(10) 本例的10个等价类至 少需要8个测试用例 不能出现相同 的测试用例

等价类划分即把输入空间分解成一系列子域，软件在一个子域内的行为应是等价的。 软件错误分为两类： 计算错误 域错误 针对计算错误的测试方法 针对域错误的测试方法:测试域边界 划定的正确性

2 边界值分析法 边界值分析法与等价类划分法区别 (1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。 (2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况 测试内点 被测试 子 域 测试外点

软件边界与悬崖很类似 如果在悬崖峭壁边可以自信地安全行走，平地就不在话下。 如果软件在能力达到极限时能够运行，那么在正常情况下就不会出什么问题。

边界条件类型 还要考虑数据类型的特征: 如果软件测试问题包含确定的边界,那么数据类型可能是: 第一个/最后一个 最小值/最大值 数值 开始/完成 空/满 最慢/最快 相邻/最远 超过/在内 …… 如果软件测试问题包含确定的边界,那么数据类型可能是: 数值 字符 位置 数量 速度 地址 尺寸 ……

测试边界线 测试临近边界的合法数据,以及刚超过边界的非法数据. 越界测试通常简单地加1或很小的数 (对于最大值)和减1或很小的数(对于最小值).

“报表日期（ 6位数字字符）”边界值分析法测试用例 输入 条件 测试用例说明 测试数据 期望结果 选取理由 1个数字字符 5个数字字符 7个数字字符 有1个非数字字符 全部是非数字字符 6个数字字符 5 20035 2003005 2003.5 MAY--- 200305 显示出错 输入有效 仅有1个合法字符 比有效长度少1 比有效长度多1 只有1个非法字符 6个非法字符 类型及长度均有效 报表日 期的类 型及长 度 在有效范围 边界上选取 数据 200301 200812 200300 200813 输入有效 显示出错 最小日期 最大日期 刚好小于最小日期 刚好大于最大日期 日期 范围 月份为1月 月份为12月 月份<1 月份>12 200301 200312 200300 200313 输入有效 显示出错 最小月份 最大月份 刚好小于最小月份 刚好大于最大月份 月份 范围

有效等价类和用来测试getNumDaysInMonth()方法所选的有效输入 月份输入值 年份输入值 1901 一个月有31天,非闰年 7(七月) 一个月有31天, 闰年 1904 7(七月) 1901 一个月有30天,非闰年 6(六月) 6(六月) 1904 一个月有30天, 闰年 一个月为28或29天,非闰年 2(二月) 1901 一个月为28或29天, 闰年 2(二月) 1904

等价类 月份输入值 年份输入值 2(二月) 可以被400整除的闰年 2000 可以被100整除的非闰年 2(二月) 1900 非正数无效月份 用来测试getNumDaysInMonth()方法的附加边界值 等价类 月份输入值 年份输入值 2(二月) 可以被400整除的闰年 2000 可以被100整除的非闰年 2(二月) 1900 非正数无效月份 1291 正数无效月份 13 1315

3 错误推测法(error guessing) 根据经验、直觉和预感来进行测试 例如： 一定要考虑建立处理下列等价类: 缺省值 空白 空值 零值 无输入条件 在已经找到软件缺陷的地方再找找

6.8 调 试 调试（也称为纠错）作为成功测试的后果出现，也就是说，调试是在测试发现错误之后排除错误的过程。 6.8 调 试 调试（也称为纠错）作为成功测试的后果出现，也就是说，调试是在测试发现错误之后排除错误的过程。 虽然调试应该而且可以是一个有序过程，但是，目前它在很大程度上仍然是一项技巧。 调试就是把症状和原因联系起来的尚未被人深入认识的智力过程。

6.8.1 调试过程 调试是软件开发过程中最艰巨的脑力劳动。调试工作如此困难，可能心理方面的原因多于技术方面的原因 6.8.1 调试过程 调试是软件开发过程中最艰巨的脑力劳动。调试工作如此困难，可能心理方面的原因多于技术方面的原因 调试过程从执行一个测试用例开始，评估测试结果，如果发现实际结果与预期结果不一致，则这种不一致就是一个症状，它表明在软件中存在着隐藏的问题。调试过程试图找出产生症状的原因，以便改正错误。 调试过程总会有以下两种结果之一： ①找到了问题的原因并把问题改正和排除掉了； ②没找出问题的原因。在后一种情况下，调试人员可以猜想一个原因，并设计测试用例来验证这个假设，重复此过程直至找到原因并改正了错误。

6.8.2 调试途径 无论采用什么方法，调试的目标都是寻找软件错误的原因并改正错误。通常需要把系统地分析、直觉和运气组合起来，才能实现上述目标。 一般说来，有下列3种调试途径可以采用： 1、蛮干法 --- 逐点（单步）跟踪 2、回溯法 --- 从出错处向上追朔 3、原因排除法 --- 对分查找法、归纳法和演绎法 1. 蛮干法 蛮干法可能是寻找软件错误原因的最低效的方法。仅当所有其他方法都失败了的情况下，才应该使用这种方法。按照“让计算机自己寻找错误”的策略，这种方法印出内存的内容，激活对运行过程的跟踪，并在程序中到处都写上WRITE（输出）语句，希望在这样生成的信息海洋的某个地方发现错误原因的线索。虽然所生成的大量信息也可能最终导致调试成功，但是，在更多情况下这样做只会浪费时间和精力。在使用任何一种调试方法之前，必须首先进行周密的思考，必须有明确的目的，应该尽量减少无关信息的数量。 2. 回溯法 回溯是一种相当常用的调试方法，当调试小程序时这种方法是有效的。具体做法是，从发现症状的地方开始，人工沿程序的控制流往回追踪分析源程序代码，直到找出错误原因为止。但是，随着程序规模扩大，应该回溯的路径数目也变得越来越大，以至彻底回溯变成完全不可能了。 3. 原因排除法 对分查找法、归纳法和演绎法都属于原因排除法。 对分查找法的基本思路是，如果已经知道每个变量在程序内若干个关键点的正确值，则可以用赋值语句或输入语句在程序中点附近“注入”这些变量的正确值，然后运行程序并检查所得到的输出。如果输出结果是正确的，则错误原因在程序的前半部分；反之，错误原因在程序的后半部分。对错误原因所在的那部分再重复使用这个方法，直到把出错范围缩小到容易诊断的程度为止。 归纳法是从个别现象推断出一般性结论的思维方法。使用这种方法调试程序时，首先把和错误有关的数据组织起来进行分析，以便发现可能的错误原因。然后导出对错误原因的一个或多个假设，并利用已有的数据来证明或排除这些假设。当然，如果已有的数据尚不足以证明或排除这些假设，则需设计并执行一些新的测试用例，以获得更多的数据。 演绎法从一般原理或前提出发，经过排除和精化的过程推导出结论。采用这种方法调试程序时，首先设想出所有可能的出错原因，然后试图用测试来排除每一个假设的原因。如果测试表明某个假设的原因可能是真的原因，则对数据进行细化以准确定位错误。 上述3种调试途径都可以使用调试工具辅助完成，但是工具并不能代替对全部设计文档和源程序的仔细分析与评估。

6.9 软件可靠性 6.9.1 基本概念 软件可靠性的定义 2. 软件的可用性 6.9.2 估算平均无故障时间的方法

测试计划（GB8567—88） 测试分析报告（GB8567—88）

作业 P184页第4题