单元测试
1、 单元的基本属性:
1) 明确的功能
2) 可定义的规格
3) 与其他单元接口的清晰划分
2、 单元测试的目的:
在于发现各模块内部可能存在的各种错误,主要是基于白盒测试。
a) 验证代码是与设计相符合的;
b) 发现设计和需求中存在的错误;
c) 发现在编码过程中引入的错误。(和设计不相符或和设计相符,但是由于
编码疏漏引起)
3、 单元测试关注的重点:
出错处理[XHC1] 、单元接口、局部数据结构、独立路径、边界条件
4、 单元测试的主要关注点:
1) 参数的属性、顺序、个数是否与LLD一致
2) 不能修改只做输入用的形参,否则可能导致数据的错误修改
3) 约束条件是否通过形参来传送
4、 驱动和桩的功能:
1) 驱动单元:被测函数的主函数,能接受输入数据,输出实际测试结果
2) 桩单元:用来代替所测单元调用的子单元
5、 单元测试策略:
孤立的测试策略、自顶向下、自底向上的单元测试策略
1) 孤立的测试策略:
· 方法:不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和驱动模块。每个模块进行独立的单元测试。
· 优点:该方法是最简单,最容易操作的。可以达到高的结构覆盖率。该方法是纯粹的单元测试。
· 缺点:桩函数和驱动函数工作量很大,效率低。
2) 自顶向下的单元测试策略:
· 方法:先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块。其次对第二层进行测试,使用上面已测试的单元做驱动模块。如此类推直到测试完所有模块。
· 优点:可以节省驱动函数的开发工作量,测试效率较高。
· 缺点:随着被测单元一个一个被加入,测试过程将变得越来越复杂,并且开发和维护的成本将增加。
3) 自底向上的单元测试策略:
· 方法:先对模块调用层次图上最低层的模块进行单元测试,模拟调用该模
块的模块做驱动模块。然后再对上面一层做单元测试,用下面已被
测试过的模块做桩模块。以此类推,直到测试完所有模块。
· 优点:可以节省桩函数的开发工作量,测试效率较高。
· 缺点:不是纯粹的单元测试,底层函数的测试质量对上层函数的测试将产
生很大的影响。
5、 单元测试的四个阶段:· 测试计划:完成单元测试计划;
· 测试设计:完成单元测试方案;
· 测试实现:完成单元测试用例、单元测试规程、单元测试脚本及数据文件;
· 测试执行:执行单元测试用例,修改发现的问题并进行回归测试,提交单元测试报告。
集成测试
1. 集成测试的目的:确保各组件组合在一起后能够按照既定意图写作运行,并确保增量的行为正确(属于灰盒测试)
1) 验证接口是否与设计相符
2) 发现设计和需求中存在的错误
2. 集成测试关注的重点:单元间的接口、集成后的功能
3. 集成测试的层次:模块内集成、子系统内集成、子系统间集成
4. 集成测试策略:
2) 自顶向下集成
3) 自底向上集成
4) 三明治(混合式)集成
5) [XHC2] 基干集成
6) 分层集成
8) 基于消息的集成
9) [XHC3] 基于进度的集成
10) 基于风险的集成
5. 各种集成测试策略的优缺点:
| 优点 | 缺点 | 适用范围 |
大爆炸集成 | 1.只要极少数的驱动和桩 2.可并行工作,人力、物力资源利用率较高 | 1.一次运行成功的可能性不大 2.定位和修改错误比较困难 3.会有很多接口错误进入到系统测试 | 1.维护型项目(增强型) 2.每个函数都经过了充分单元测试的小规模系统(特别是接口函数) |
自顶向下 | 1.较早验证了主要的控制点和判断点 2.选用按深度方向组装的方式,可首先实现和验证一个完整的软件功能 3.功能可行性较早得到证实(带来信心) 4.最多只需一个驱动,减少驱动开发费用 5.支持故障隔离 | 1.桩的开发和维护成本大 2.底层组件行为的验证被推迟了 3.底层组件的测试不充分 | 1.产品控制结构比较清晰和稳定 2.产品高层接口变化较小 3.产品底层接口未定义或经常可能被修改 4.产品控制组件具有较大的技术风险,需要尽早被验证 5.希望尽早看到产品的系统功能行为 |
自底向上 | 1.允许对底层组件行为的早期验证 2.工作初期可以并行进行集成 3.减少了桩的工作量 4.支持故障隔离 | 1.驱动的开发和维护成本高 2.对高层的验证被推迟到了最后,设计上的错误不能被及时发现 | 1.底层接口比较稳定、变动较少的产品 2.高层接口变化较频繁的产品 3.底层组件较早被完成的产品 |
三明治集成 | 集合了自顶向下和自底向上策略的优点 | 中间层在被集成前测试不充分 | 大部分软件开发项目 |
基干集成 | 具有三明治集成的优点 | 1.必须对系统的结构和相互依存性进行仔细分析 2.必须开发驱动和桩 3.有些接口可能测试不充分 | 大型复杂项目 |
基于功能集成/基于消息集成 | 1.可尽快看到关键功能的实现,并验证正确性 2.进度上要短 3.可减少驱动的开发 | 1.对有些接口测试不充分,会丢失许多接口错误 2.可能会有较大的冗余测试 |
|
基于进度集成 | 1.具有比较高的并行度 2.能有效缩短项目开发的进度 | 1.许多接口要到后期才能验证,无法发现有效的接口问题 2.桩和驱动开发工作量大 3.由于进度,组件很不稳定且会不断变动,导致测试的重复和浪费 | 进度优先级高于质量的项目 |
基于风险集成 | 最具有风险的组件最早进行验证,有助于系统的快速稳定 | 需要对各组件的风险有一个清晰的分析 |
|
系统测试
1. 系统测试目的:
1) 通过与需求做比较,发现与系统定义不符合或与之矛盾的地方
2) 系统测试的用例应根据需求分析说明书来设计,并在实际使用环境下运行
2. 系统测试对象
1) 软硬件集合在一起的系统
2) 验证时应尽可能模拟实际的运行环境与条件
3. 系统测试常用类型:功能、性能、压力、容量、安全性、GUI、可用性、安装、配置、异常(恢复性)、备份、健壮性、文档、在线帮助、网络、稳定性测试
4. 功能测试:
1) 概念:根据产品的SRS和测试需求列表,验证产品的功能实现是否符合产品的需求规格
2) 目标:为了发现以下几类错误
a) 是否有不正确或遗漏了的功能
b) 功能实现是否满足用户需求和系统设计的隐藏需求
c) 输入能否正确接受?能否正确输出结果?
5. 性能测试:
1) 概念:用来测试软件在集成系统中的运行性能
2) 目标:度量系统相对于预定义目标的差距
3) 工具:LoadRunner、WebLoad、SilkPerformer
4) 重要性:a) 性能是质量的重要组成部分
b) 给用户树立良好形象
c) 节省成本的重要手段
6. 性能测试的关键:有效的协调、正确的模型、瓶颈的定位、合理的建议
7. 性能需求五大特性:需求行、代表性、完整性、可测试性、可用性
8. 压力测试:关注稳定性和破坏性
1) 目的:调查系统在其资源超负荷的情况下的表现
2) 目标:通过极限测试方法,发现系统在极限或恶劣环境中自我保护能力,主要验证系统的可靠性。
9. 容量测试:
1) 目的:使系统承受超额的数据容量来发现它是否能够正确处理
2) 关注点:a) 整体的业务流量(一般关注静态容量)
b) 数据库的容量
c) 最大文件数目
d) 最大事务数
10. 安全性测试:口令认证、加解密技术、权限管理、安全日志
11. GUI测试:
1) 关注点:界面实现与界面设计的吻合情况、确认界面处理的正确性
2) 对象:简单界面元素、组合类界面元素、完整界面(窗口)
3) 内容:外观、界面元素行为、布局、友好功能
12. 可用性测试:关注点:
1) 过分复杂的功能或指令
2) 困难的安装过程
3) 错误信息过于简单
4) 用户被迫去记住太多的信息
5) 语法、格式和定义不一致
13. 配置测试:
概念:测试系统在各种软硬件配置、不同的参数配置下系统具有的功能和性能
目标:验证全部配置的可操作性和有效性,特别需要对最大配置、最小配置或特殊配置进行测试
14. 异常测试:
概念:又叫系统容错和可恢复性测试,通过人工干预手段使系统产生软、硬件异常,通过验证系统异常前后的功能和运行状态,达到检验系统的容错、排错和恢复的能力。它是系统可靠性评价的重要手段。
容错处理:系统自动处理、人工干预处理
系统可靠性指标:平均失效时间间隔(MTBF)、平均恢复时间(MTTR)
系统可靠性设计技术:
1) 避开错误
2) 容错技术:结构冗余(动、静态)、信息冗余、时间冗余、硬件冗余、附加冗余技术
15. 健壮性测试:Robustness Testing
用于测试系统在出现故障时,是否能够自动恢复或忽略故障继续运行
16. 网络测试:
概念:在网络环境下和其他设备对接,进行系统功能、性能与指标方面的测试,保证设备对接正常。
内容:考察系统的处理能力、系统兼容性、系统稳定可靠性及用户使用等方面。
1) 一致性测试:检测系统与协议规范符合程度
2) 性能测试:检测协议实体或系统的性能指标
3) 互操作性测试:
4) 坚固性测试:检测协议实体或系统在各种恶劣环境下运行的能力
17. 系统稳定性测试:
目的是评价系统在一定负荷情况下、长时间的运行情况。