软件测试策略.ppt
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
通常，把模块组装成为系统的方式有两种 一次性组装方式(big bang)
对基本执行路径和循环进行测试可以发现大 量的路径错误。
(4) 错误处理测试
出错的描述是否难以理解 出错的描述是否能够对错误定位 显示的错误与实际的错误是否相符 对错误条件的处理正确与否 在对错误进行处理之前，错误条件是否已经
引起系统的干预等
(5) 边界测试
注意数据流、控制流中刚好等于、大于或小 于确定的比较值时出错的可能性。对这些地 方要仔细地选择测试用例，认真加以测试。
组装测试（Integrated Testing）
组装测试 (集成测试、联合测试）
通常，在单元测试的基础上，需要将所有模 块按照设计要求组装成为系统。如需要考虑 以下的问题：
✓一个模块的功能பைடு நூலகம்否会对另一个模块的功 能产生不利的影响
✓各个子功能组合起来，能否达到预期要求 的父功能
组装测试（Integrated Testing）
单元测试的主要手段 ：
1、代码审查(code inspection) Walk-through: 例如 Lucent Technologies 的测
试策略，是由三人一组(包括 author, reader, 和 recorder)，逐行检查源代码。
Rehearsal：由人扮演computer，模拟执行情况
如果一个模块要完成多种功能，可以将这个 模块看成由几个小程序组成。必须对其中的 每个小程序先进行单元测试要做的工作，对 关键模块还要做性能测试。
对支持某些标准规程的程序，更要着手进行 互联测试。有人把这种情况特别称为模块测 试，以区别单元测试。
主要测试以下五个方面：
1、模块接口：
内部检查：传输参数的数目、属性、单位、次 序是否匹配；全程变量的定义是否一致；只做输 入的变元有无被修改，等等。
如果对模块运行时间有要求的话，还要专门 进行关键路径测试，以确定最坏情况下和平 均意义下影响模块运行时间的因素。
2. 单元测试的步骤
模块并不是一个独立的程序，在考虑测试 模块时，同时要考虑它和外界的联系，用 一些辅助模块去模拟与被测模块相联系的 其它模块。
驱动模块 (driver)
桩模块 (stub) ── 存根模块
确认测试则是要检查已实现的软件是否满足 了需求规格说明中确定了的各种需求，以及 软件配置是否完全、正确。
系统测试把已经经过确认的软件纳入实际运 行环境中，与其它系统成份组合在一起进行 测试。
单元测试 (Unit Testing)
单元测试又称模块测试，是针对软件设计 的最小单位 ─ 程序模块，进行正确性检验 的测试工作。其目的在于发现各模块内部 可能存在的各种差错。
–（1）软件测试不能发现代码风格不统一的问题，而代 码审查则很容易做到； –（2）有经验的人可以一目十行地审查代码，很快就能 抓住一些Bug（主要是常见的Bug）。 开发小组在执行代码审查之前要制定“代码审查表”， 从编程规范中提取最重要的规则。 为了提高代码审查效率，检查者不必给每一个检查项填 写结论，凡是正确的就跳过去，仅仅记录缺陷就行了。
计算次序问题
不同类型混合运算（例：比较类型不同的量）
初值设置错误
精度问题（例：精度不够导致两变量不可能相等， 而程序中等待相等条件的出现）
表达式错误
循环终止条件错误(例：次数差1，或陷入死循环)
4、出错处理通路： 预见出现错误的条件，设置处理。较常见
的问题有： 输出的错误信息难以理解，不能确定错误位置 描述的错误与实际错误不符 处理之前系统已经干预 处理不正确
单元测试需要从程序的内部结构出发设计 测试用例。多个模块可以平行地独立进行 单元测试。
1. 单元测试的内容
在单元测试时，测试者需要依据详细设计 说明书和源程序清单，了解该模块的I/O条 件和模块的逻辑结构，主要采用白盒测试 的测试用例，辅之以黑盒测试的测试用例 ，使之对任何合理的输入和不合理的输入 ，都能鉴别和响应。
外部检查：打开、结束、关闭文件的操作；文 件和属性；I\O错误处理；输出拼写，等等。
2、局部数据结构：
数据说明(declaration)；初始化与缺省值的设 置；变量名拼写；数据类型的相容性；上\下溢出 及地址异常，等等。
3、重要的执行通路：
由于穷尽测试不可能，故通常针对最常见的错误 设计测试方案。较常见的错误有：
软件测试策略 测试流程图
软件测试策略
测试过程按4个步骤进行，即单元测试、组装 测试、确认测试和系统测试。
开始是单元测试，集中对用源代码实现的每 一个程序单元进行测试，检查各个程序模块 是否正确地实现了规定的功能。
软件测试策略
组装测试把已测试过的模块组装起来，主要 对与设计相关的软件体系结构的构造进行测 试。
(2) 局部数据结构测试
不正确或不一致的数据类型说明 使用尚未赋值或尚未初始化的变量 错误的初始值或错误的缺省值 变量名拼写错或书写错 不一致的数据类型 全局数据对模块的影响
(3) 路径测试
选择适当的测试用例，对模块中重要的执行 路径进行测试。
应当设计测试用例查找由于错误的计算、不 正确的比较或不正常的控制流而导致的错误 。
(1) 模块接口测试
在单元测试的开始，应对通过被测模块的数 据流进行测试。测试项目包括：
调用本模块的输入参数是否正确； 本模块调用子模块时输入给子模块的参数
是否正确； 全局量的定义在各模块中是否一致；
在做内外存交换时要考虑：
文件属性是否正确； OPEN与CLOSE语句是否正确； 缓冲区容量与记录长度是否匹配； 在进行读写操作之前是否打开了文件； 在结束文件处理时是否关闭了文件； 正文书写／输入错误， I／O错误是否检查并做了处理。
优点: 一次审查可发现多个错误，不必改一个测一个。
2、制做测试软件：Stub （存根）和 Driver（驱动） 软件的编写，属额外开支。模块高内聚可简化这 一过程。
代码审查通常在开发人员之间开展，用眼睛检查代码是 否符合编程规范。为什么有了软件测试，还要代码审查？
因为代码审查有一些独到的优点，可以弥补软件测试的 不足：
对基本执行路径和循环进行测试可以发现大 量的路径错误。
(4) 错误处理测试
出错的描述是否难以理解 出错的描述是否能够对错误定位 显示的错误与实际的错误是否相符 对错误条件的处理正确与否 在对错误进行处理之前，错误条件是否已经
引起系统的干预等
(5) 边界测试
注意数据流、控制流中刚好等于、大于或小 于确定的比较值时出错的可能性。对这些地 方要仔细地选择测试用例，认真加以测试。
组装测试（Integrated Testing）
组装测试 (集成测试、联合测试）
通常，在单元测试的基础上，需要将所有模 块按照设计要求组装成为系统。如需要考虑 以下的问题：
✓一个模块的功能பைடு நூலகம்否会对另一个模块的功 能产生不利的影响
✓各个子功能组合起来，能否达到预期要求 的父功能
组装测试（Integrated Testing）
单元测试的主要手段 ：
1、代码审查(code inspection) Walk-through: 例如 Lucent Technologies 的测
试策略，是由三人一组(包括 author, reader, 和 recorder)，逐行检查源代码。
Rehearsal：由人扮演computer，模拟执行情况
如果一个模块要完成多种功能，可以将这个 模块看成由几个小程序组成。必须对其中的 每个小程序先进行单元测试要做的工作，对 关键模块还要做性能测试。
对支持某些标准规程的程序，更要着手进行 互联测试。有人把这种情况特别称为模块测 试，以区别单元测试。
主要测试以下五个方面：
1、模块接口：
内部检查：传输参数的数目、属性、单位、次 序是否匹配；全程变量的定义是否一致；只做输 入的变元有无被修改，等等。
如果对模块运行时间有要求的话，还要专门 进行关键路径测试，以确定最坏情况下和平 均意义下影响模块运行时间的因素。
2. 单元测试的步骤
模块并不是一个独立的程序，在考虑测试 模块时，同时要考虑它和外界的联系，用 一些辅助模块去模拟与被测模块相联系的 其它模块。
驱动模块 (driver)
桩模块 (stub) ── 存根模块
确认测试则是要检查已实现的软件是否满足 了需求规格说明中确定了的各种需求，以及 软件配置是否完全、正确。
系统测试把已经经过确认的软件纳入实际运 行环境中，与其它系统成份组合在一起进行 测试。
单元测试 (Unit Testing)
单元测试又称模块测试，是针对软件设计 的最小单位 ─ 程序模块，进行正确性检验 的测试工作。其目的在于发现各模块内部 可能存在的各种差错。
–（1）软件测试不能发现代码风格不统一的问题，而代 码审查则很容易做到； –（2）有经验的人可以一目十行地审查代码，很快就能 抓住一些Bug（主要是常见的Bug）。 开发小组在执行代码审查之前要制定“代码审查表”， 从编程规范中提取最重要的规则。 为了提高代码审查效率，检查者不必给每一个检查项填 写结论，凡是正确的就跳过去，仅仅记录缺陷就行了。
计算次序问题
不同类型混合运算（例：比较类型不同的量）
初值设置错误
精度问题（例：精度不够导致两变量不可能相等， 而程序中等待相等条件的出现）
表达式错误
循环终止条件错误(例：次数差1，或陷入死循环)
4、出错处理通路： 预见出现错误的条件，设置处理。较常见
的问题有： 输出的错误信息难以理解，不能确定错误位置 描述的错误与实际错误不符 处理之前系统已经干预 处理不正确
单元测试需要从程序的内部结构出发设计 测试用例。多个模块可以平行地独立进行 单元测试。
1. 单元测试的内容
在单元测试时，测试者需要依据详细设计 说明书和源程序清单，了解该模块的I/O条 件和模块的逻辑结构，主要采用白盒测试 的测试用例，辅之以黑盒测试的测试用例 ，使之对任何合理的输入和不合理的输入 ，都能鉴别和响应。
外部检查：打开、结束、关闭文件的操作；文 件和属性；I\O错误处理；输出拼写，等等。
2、局部数据结构：
数据说明(declaration)；初始化与缺省值的设 置；变量名拼写；数据类型的相容性；上\下溢出 及地址异常，等等。
3、重要的执行通路：
由于穷尽测试不可能，故通常针对最常见的错误 设计测试方案。较常见的错误有：
软件测试策略 测试流程图
软件测试策略
测试过程按4个步骤进行，即单元测试、组装 测试、确认测试和系统测试。
开始是单元测试，集中对用源代码实现的每 一个程序单元进行测试，检查各个程序模块 是否正确地实现了规定的功能。
软件测试策略
组装测试把已测试过的模块组装起来，主要 对与设计相关的软件体系结构的构造进行测 试。
(2) 局部数据结构测试
不正确或不一致的数据类型说明 使用尚未赋值或尚未初始化的变量 错误的初始值或错误的缺省值 变量名拼写错或书写错 不一致的数据类型 全局数据对模块的影响
(3) 路径测试
选择适当的测试用例，对模块中重要的执行 路径进行测试。
应当设计测试用例查找由于错误的计算、不 正确的比较或不正常的控制流而导致的错误 。
(1) 模块接口测试
在单元测试的开始，应对通过被测模块的数 据流进行测试。测试项目包括：
调用本模块的输入参数是否正确； 本模块调用子模块时输入给子模块的参数
是否正确； 全局量的定义在各模块中是否一致；
在做内外存交换时要考虑：
文件属性是否正确； OPEN与CLOSE语句是否正确； 缓冲区容量与记录长度是否匹配； 在进行读写操作之前是否打开了文件； 在结束文件处理时是否关闭了文件； 正文书写／输入错误， I／O错误是否检查并做了处理。
优点: 一次审查可发现多个错误，不必改一个测一个。
2、制做测试软件：Stub （存根）和 Driver（驱动） 软件的编写，属额外开支。模块高内聚可简化这 一过程。
代码审查通常在开发人员之间开展，用眼睛检查代码是 否符合编程规范。为什么有了软件测试，还要代码审查？
因为代码审查有一些独到的优点，可以弥补软件测试的 不足：