测试设计培训教材之一
软件测试的一些基本知识
北研测试部董选明
1999.5.25
本教材主要内容:
Ÿ软件测试的定义
Ÿ软件测试的目标和原则
Ÿ测试信息流程
Ÿ测试与开发各阶段的关系
Ÿ测试与开发的并行性
Ÿ系统和需求分析方法
Ÿ软件测试的策略
·软件测试的过程
·单元测试
·单元测试的内容
·单元测试的环境和步骤
·集成测试
·集成测试应该考虑的问题
·集成的方式
·确认测试
·有效性测试
·α测试和β测试
·验收测试
·测试的步骤与相应的测试种类
1.软件测试的定义
软件测试就是在软件投入运行前,对软件需求分析,设计规格说明和编码的最终复查,是软件质量保证的关键步骤
定义1:软件测试是为了发现错误而执行程序的过程.
定义2:软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据极其预期的输出结果）,并利用这些测试用例去运行程序,以发现程序错误的过程.
软件测试在软件生存周期中横跨两个阶段:
单元测试阶段:编写出每个模块之后就对它做必要的测试.
综合测试阶段:结束单元测试后进行的测试,如系统测试,验收测试.
软件生存周期: 制定计划; 需求分析和定义; 软件设计; 程序编码; 软件测试; 运行/维护.
软件测试的对象: 软件测试不等于程序测试. 软件测试是贯穿于软件定义和开发的整个期间. 因此, 需求分析, 概要设计, 详细设计以及程序编码等各个阶段所得到的文档, 包括需求规格说明, 概要设计规格说明,详细设计规格说明以及源程序, 都是软件测试的对象.
2.测试的目的和原则
测试的目的是寻找错误,并且是尽最大可能找出最多的错误.这就涉及到如何合理的设计测试用例.在选取测试用例时,考虑那些易于发现程序错误的数据.Grenford J. Myers 就软件测试目的提出以下观点:
(1) 测试是程序的执行过程,目的在于发现错误;
(2) 一个好的测试用例在于发现至今未发现的错误;
(3) 一个成功的测试是发现了至今未发现的错误的测试.
根据上面的测试目的, 软件测试的原则应该是:
(1). 应把"尽早地和不断地进行软件测试"作为软件开发和测试人员的座右铭.
(2). 测试用例应由测试输入数据和与之对应的预期结果组成.
(3). 在程序提交测试后,程序员应避免检查自己的程序.
(4). 在设计测试用例时,应当包括合理的输入条件和不合理的输入条件.
(5). 充分注意测试中的群体现象.
(6). 严格执行测试计划,排除测试的随意性.
(7). 应当对每一个测试结果做全面检查.
(8). 妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便.
3.测试信息流程
测试信息流如下图示, 测试过程需要三类输入:
软件配置: 包括软件需求规格说明, 软件设计规格说明, 源代码等.
测试配置: 包括测试计划, 测试用例, 测试驱动程序等.
测试工具: 为了提高软件测试效率, 可采用测试工具支持测试工作. 其作用就是为测试的实施提供某种服务,以减轻完成测试任务的手工劳动. 例如, 测试数据自动生成程序, 驱动测试的测试数据库等.
4.测试与开发各阶段的关系
5.测试与开发的并行性
一旦软件的需求得到确认并通过了评审, 概要设计工作和测试计划制定设计工作就要并行进行. 如果系统模块结构已经建立, 对各个模块的详细设计, 编码, 单元测试等工作又可以并行进行. 待每个模块完成后, 可进行组装测试, 系统测试.
6.系统和需求分析方法
这里简单介绍一下测试用例设计中要用到的一些分析方法.结构化分析方法和打通系统动态分析方法.许多系统分析方法,需求分析和软件设计方法及工具在测试设计中同样适用.
(1)结构化分析(SA)方法
结构化分析是面向数据流进行需求分析的方法. 结构化分析方法也已渗透到面向对象分析技术(OOT)等方法中. 它适合与数据处理类型软件的需求分析. 由于用图来表达需求, 显得清晰, 简明,易于学习和掌握. 结构化分析方法就是用抽象模型的概念,按照软件内部数据传递,变化的关系,自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止. 根据DeMarco的论述, 结构化分析方法采用一下几个工具: 数据流图, 数据词典, 结构化英语,判定表和判断树. 其中判定表就是我们后面要用到的工具.
(2)系统动态分析
为了直观地分析系统的动作, 从特定的视点出发描述系统的行为,需要采用动态分析的方法.常用的动态分析方法有:状态迁移图,时序图,Petri网等.状态迁移图是描述系统的状态如何相应外部的信号进行推移的一种图形表示.状态迁移图（表）我们在设计测试用例时要用到.
7.软件测试的策略
测试过程可按5个步骤: 单元（模块）测试, 组装（集成或子系统）测试,确认（有效性）测试 ,系统
测试和验收（用户）测试.下面为测试过程流程.
7.1.单元测试
又称模块测试.是最小单位测试. 模块分为程序模块和功能模块. 功能模块指实现了一个完整功能的模块(单元). 一个完整的程序单元具备输入,加工和输出三个环节.而且 每个程序单元都应该有正规的规格说明,使之对其输入, 加工和输出的关系作出明确的描述. 单元测试是集中对源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能.其目的是在于发现各模块内部可能存在的各种错误.单元测试需要从程序的内部结构出发设计测试用例.多各模块可以并行进行单元测试.
单元测试不仅要基于白盒测试,也要基于黑盒测试.
7.1.1.单元测试的内容(即要解决的问题)
测试者要依据详细设计说明书和源程序清单, 了解模块的I/O条件和模块的逻辑结构. 主要采用白盒测试的测试用例, 辅之以黑盒测试的测试用例, 使之对任何合理和不合理的输入,都能鉴别和响应. 要求对所有的局部和全局的数据结构,外部接口和程序代码的关键部分,都要进行桌面检查和代码审查. 在单元测试中, 需要对下面五个方面的内容进行检查:
(1) 模块接口: 测试模块的数据流. 如果数据不能正确地输入和输出,就谈不上进行其它测试. 因此,对模块接口需要如下的测试项目: 调用所测模块时的输入参数与模块的形式参数在个数,属性,顺序上是否匹配; 所测模块调用子模块时, 它输入给子模块的参数与子模块中的形式参数在个数,属性,顺序上是否匹配; 是否修改了只做输入用的形式参数; 输出给标准函数的参数在个数, 属性, 顺序上是否正确; 全局量的定义在个模块中是否一直; 限制是否通过形式参数来传送.
(2) 局部数据结构测试: 模块的局部数据结构是最常见的错误来源, 应设计测试用例以检查以下各种错误: 检查不正确或不一致的数据类型说明; 使用尚未赋值或尚未初始化的变量; 错误的初始值或错误的缺省值; 变量名拼写错误或书写错误; 不一致的数据类型.
(3) 路径测试: 对基本执行路径和循环进行测试会发现大量的错误. 设计测试用例查找由于错误的计算, 不正确的比较或不正常的控制流而导致的错误.
常见的不正确计算有: 运算的优先次序不正确或误解了运算的优先次序; 运算的方式错误(即运算的对象彼此在类型上不相容; 算法错误; 初始化不正确; 运算精度不够; 表达式的符号表示不正确等.
常见的比较和控制流错误有: 不同数据类型量的比较; 不正确的逻辑运算符或优先次序; 因浮点运算精度问题而造成的两值比较不等; 关系表达式中不正确的变量和比较符; "差1 错", 即不正确的多循环或少循环一次; 错误的或不可能的循环终止条件; 当遇到发散的迭代时不能终止的循环; 不适当地修改了循环变量等. 根据白盒测试和黑盒测试用例设计方法设计测试例.
(4) 错误处理测试: 比较完善的模块设计要求能预见出错的条件, 并设置适当的出错处理., 以便在程序出错时,能对出错程序重新做安排,保证其逻辑上的正确性. 这种出错处理也是模块功能的一部分. 表明出错处理模块有错误或缺陷的情况有: 出错的描述难以理解; 出错的描述不足以对错误定位和确定出错的原因; 显示的错误与实际的错误不符; 对错误条件的处理不正确; 在对错误进行处理之前, 错误条件已经引起系统的干预等.
(5) 边界测试: 边界上出现错误的是常见的. 在n 次循环的第 n 次, 取最大最小值时容易发生错误. 特别要注意数据流, 控制流中刚好等于, 大于, 小于确定的比较值时出现错误的可能性.
7.1.2.单元测试的环境和步骤:
何时进行单元测试? 单元测试在编码阶段进行. 在源程序代码编制完成, 经过评审何验证, 确认没有语法错误之后, 就可以开始进行单元测试的测试用例设计. 要利用软件设计文档, 设计可以验证程序功能, 找出程序错误的多个测试用例. 对于每一组输入,应该有预期的正确结果. 在单元测试时, 如果模块不是独立的程序, 需要辅助测试模块. 有两种辅助模块:
驱动模块: 所测模块的主程序. 它接收测试数据,把这些数据传递给所测试模块,最后再输出实测结果. 当被测试模块能完成一定功能时, 也可以不要驱动模块.
桩模块(STUB): 用来代替所测模块调用的子模块.
被测试模块, 驱动模块和桩模块共同构成了一个测试环境.
7.2.集成测试(Integrated Testing )
也称组装测试, 联合测试, 子系统测试, 部件测试.
7.2.1.集成测试应该考虑的问题:
(1) 在把各个模块连接起来的时候, 穿越模块接口的数据是否会丢失;
(2) 一个模块的功能组合起来是否会对另一个模块的功能产生不利的影响;
(3) 各个子功能模块组合起来,能否达到预期要求的父功能;
(4) 全局数据结构是否有问题;
(5)单个模块的误差累积起来,是否会放大,从而达不到能接收的程度.
7.2.2.集成的方式
选择什么样的方式把模块组装起来形成一个可运行的子系统, 直接影响到模块测试用例的形式, 所用测试工具的类型,模块编号的次序和测试顺序,以及生成测试用例的费用和调度的费用. 通常有两种集成方式: 一次性集成方式和增殖式集成方式.
(1) 一次性集成方式: 也称整体组装. 首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统.
(2) 增殖式集成方式: 也称渐增式组装. 首先对一个个模块进行单元测试,然后将这些模块逐步组装成较大的系统,在组装的过程中, 边连接边测试,以发现连接过程中产生的问题,最后通过增殖逐步组装成为要求的软件系统. 增殖式集成方式有三种实现方式: 自顶向下的增殖方式, 自底向上的增殖方式和混合增殖方式. (具体操作以后再讲).
7.3.确认测试(Validation Testing)
也称有效性测试. 如果加入用户信息, 也称验收测试. 基于需求规格说明书和用户信息, 验证软件的功能和性能及其它特性. 确认测试步骤:
(1) 进行有效性测试: 有效性测试是在模拟的环境(可能就是开发环境)下,应用黑盒测试的方法, 验证所测试软件是否满足需求规格说明书列出的需求. 因此需要制定测试计划,测试步骤,测试种类, 测试用例.
(2) 软件配置复查:
(3)α测试和β测试: α测试是由一个用户在开发环境下进行的测试.也可以是开发机构内部的用户在模拟实验环境下进行的测试. 用户操作. 其测试目的是评价软件产品的FLURPS(即功能, 局域化, 可使用性,可靠性,性能和支持). 尤其是产品的界面和特色. 是β测试在多用户, 实际操作环境下进行. 主要衡量软件的FLURPS, 特别是支持性.
（3）验收测试（Acceptance Testing）:以用户为主, 开发人员,测试人员, QA人员 参加的测试.
7.4.系统测试
系统测试将是通过确认测试软件,作为整个基于计算机系统的一个元素,与计算机硬件, 外设, 某些支持软件, 数据和人员等系统元素结合起来,在实际运行环境下, 对计算机系统进行以系列的组装和确认测试. 系统测试目的是在于通过与系统的需求定义做比较,发现软件与系统定义不符合或与子矛盾的地方. 系统测试用例应根据需求发现说明书来设计,并在实际运行环境下运行.
7.5.测试的步骤及相应的测试种类
软件测试实际上是由一系列不同的测试组成. 如下表示各个关系.
