测试模型的选择
- V模型:强调了在整个项目开发中需要经历的不同测试级别,但忽视了测试的对象不仅仅是程序
- W模型:在以上方面进行了补充,明确指出应对需求、设计进行测试
- 但是V模型和W模型都没有将一个完整的测试过程抽象出来,成为一个独立的流程,这并不适合当前软件开发中广泛应用的迭代模型
- H模型:明确指出测试的独立性,也就是说只要测试条件成熟了,就可以开展测试
- 在测试实践中,我们采用的方法是:以W模型作为框架,及早的、全面的开展测试。同时灵活运用H模型独立测试的思想,在达到恰当的就绪点时就应该开展独立的测试工作,同时将测试工作进行迭代,最终保证完成测试目标。
- Rup测试模型:尽早开始,连续测试
软件测试阶段组成
单元测试
- 单元测试是对最小的可测试软件元素(单元)实施的测试,它所测试的内容包括单元的内部结构(如逻辑和数据流)以及单元的功能和可观测的行为,确保它作为一个单元能正常地工作
- 面向对象的软件开发:以Class(类)作为测试的最小单元
- 结构化的软件开发: 以模块(函数、过程)作为测试的最小单元
- 目的
- 验证单元满足功能、性能和接口等的要求
- 采用的技术
- 静态分析
- 代码审查
- 白盒动态测试
- 功能测试
- 测试的充分性由各种测试覆盖率来度量
- 测试内容主要针对下列模块的五个基本特性进行
- 模块接口
- 对通过被测模块的数据流进行测试
- 局部数据结构
- 不正确或不一致的数据类型说明
- 使用尚未赋值或尚未初始化的变量
- 错误的初始值或错误的缺省值
- 变量名拼写错或书写错
- 全局数据对模块的影响
- 重要的执行路径
- 出错处理路径
- 出错的描述是否难以理解
- 出错的描述是否能够对错误定位
- 显示的错误与实际的错误是否相符
- 对错误条件的处理正确与否
- 在对错误进行处理之前,错误条件是否已经引起系统的干预等
- 影响以上各点的边界条件
- 数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性
- 如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素
- 模块接口
集成测试
- 依据软件设计确定的软件结构,按照软件集成“工序”,把各个软件单元逐步集成为完整的软件系统,并不断发现和排除错误,以保证联接、集成的正确性
- 集成测试的内容
- 软件单元的接口测试
- 软件部件的功能、性能测试
- 全面数据结构测试
- 必要的运行时间、存贮空间、计算精度测试
- 边界条件和非法输入的测试
- 单元测试的环境
- 模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块
- 驱动模块 (driver)
- 桩模块 (stub) ── 存根模块
- 模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块
- 集成测试的要求
- 必须对有调用关系的软件单元之间的所有调用进行测试,验证每个调用接口的完整性和一致性
- 应对软件进行正确处理的能力的经受错误影响的能力进行测试
- 应测试在各种外部输入下,从外部接口采集和发送数据的能力,包括对正确数据及状态的处理,对接口错误、数据错误、协议错误的识别及处理
- 软件集成策略
- 非增量方式
- 先测试好每一个软件单元,然后一次组装在一起再测试整个程序
- 增量方式
- 逐步把下一个要被组装的软件单元或部件,同已测好的软件部件结合起来测试。
- 增量方式主要包括自顶向下、自底向上、自顶向下与自底向上相结合等方法。
- 优点
- 增量方式
- 增量方式占用人工较少
- 增量方式可以较早地发现模块接口错误
- 增量方式容易排错
- 增量方式测试效果好,比较彻底
- 非增量方式
- 非增量方式占用机器时间较少
- 非增量方式有利于并行开发
- 增量方式
- 非增量方式
系统测试
- 软件与与系统中其它的软、硬件对接并测试其接口的过程
- 系统测试的目的
- 在真实的系统工作环境下检验软件是否能与系统正确连接,并确认软件是否与用户需求(系统需求)一致
- 系统测试内容
- 安装性测试
- 功能测试
- 性能测试
- 操作测试
- 外部接口测试
- 性能强度测试
- 试图发现的问题
- 是否有不正确或遗漏了的功能
- 是否有多余的功能
- 界面是否有错误
- 接口是否正确
- 性能指标是否满足要求
- 是否存在初始化和终止错误
回归测试
- 一种选择性重新测试,目的是检测系统或系统组成部分在修改期间产生的缺陷,用于验证已进行的修改并未引起不希望的有害效果,或确认修改后的系统或系统组成部分仍满足规定的要求
- 步骤
- 识别出软件中被修改的部分
- 从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0
- 依据一定的策略从T0中选择测试用例测试被修改的软件
- 如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分
- 用T1执行修改后的软件
- 要点
- 各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。
- 回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。