单元测试用例
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第5章 单元测试 第6章 集成测试和系统测试 第7章 验收测试 第8章 面向对象软件的测试 第9章 基于应用服务器的测试 第10章 软件本地化测试 第11章 软件测试自动化
第五章 单元测试
5.1 什么是单元测试 5.2 单元测试的目标和任务 5.3 静态测试 5.4 驱动程序和桩程序 5.5 调试与评估 5.6 单元测试的管理 5.7 单元测试工具
对于没有被运行的代码
对于没有被运行到的代码一定要做检查，很可能会从中发现问题， 并进而补充遗漏的测试用例。
有些函数如分配内存的malloc()等操作一般不会失败，所以它的 返回值校验分支中的代码通常不会被执行到；
资源释放操作代码没有被运行，比如内存释放、锁的释放、句 柄关闭等操作没有被执行到，通常意味着程序中可能有资源泄 露。这一类未执行代码一定要小心检查；
任务３： 模块接口测试
检查模块接口是否正确，checklist:
输入的实际参数与形式参数是否一致。
个数、属性、量纲
调用其他模块的实际参数与被调模块的形参是否一致。
个数、属性、量纲
全程变量的定义在各模块是否一致。 外部输入、输出
文件、缓冲区、错误处理
其它
任务４： 模块边界条件测试
单元测试 3小时
集成测试
开发人员过于自信,后期复杂
度高,发现解决BUG困难.
系统测试
6小时 12小时
检查代码是否符合设计和规范
举例----单元测试的必要性
假定在开发一个网站程序。将整个程序设计为三 层：数据访问层、业务逻辑层和表现层。首先是编写 数据访问层，如果没有进行单元测试，那么就得等到 业务逻辑层和表现层开发完毕后才能打开页面进行测 试。而这中间，业务逻辑层要调用数据访问层，表现 层要调用业务逻辑层的代码。如果通过页面发现某个 功能没有通过，就需要进行调试，调试时要一步一步 地跟踪代码，好不容易找到bug所在了，原来是数据访 问的一个方法里出了问题，把该方法改好了，编译不 通过！看来还得修改另外两层的代码，好，把代码都 改好了，再次打开页面进行测试，糟糕还是没通过。 上面的过程再来一次……
上面这种方式的缺点可以总结为：
为何要进行单元测试?
错误难以定位：每次要打开页面、输入值、调试，单元测试可能也需 要这些过程，但其工作量则会小很多。
执行时间长：较之单元测试，上面的方式显然耗时得多。 代码覆盖：可以理解的是，涉及的代码层次越多，就越是难以确定被
测代码和测试值之间的关系。我们要覆盖到所有的数据访问层的代码 ，就要花费很大的精力。 在应用了单元测试后，可以快速定位错误，执行的时间也要短得多，代 码覆盖也更容易进行。 如果一开始就对数据访问层和业务逻辑层进行了良好的单元测试，那么 接下来表现层的开发就顺利得多了，可以编写后面的代码。一旦出了 问题，也很容易定位和修改。
代价就越低
5.2 单元测试的目标和任务
目标: 单元模块被正确编码
信息能否正确地流入和流出单元； 在单元工作过程中，其内部数据能否保持其完整性，
包括内部数据的形式、内容及相互关系不发生错误， 也包括全局变量在单元中的处理和影响。 在为限制数据加工而设置的边界处，能否正确工作。 单元的运行能否做到满足特定的逻辑覆盖。 单元中发生了错误，其中的出错处理措施是否有效。
检查临界数据处理的正确性
Checklist: 普通合法数据的处理。 普通非法数据的处理。 边界值内合法边界数据的处理。 边界值外非法边界数据的处理。 其它
任务5：模块的各条错误处理通路测试
预见、预设的各种出错处理是否正确有效。
Checklist: 输出的出错信息难以理解。 记录的错误与实际不相符。 程序定义的出错处理前系统已介入。 异常处理不当。 未提供足够的定位出错的信息。 其它
任务１： 模块独立执行通路测试
检查每一条独立执行路径的测试。保证每条语句 被至少执行一次。
Checklist: 误解或用错了运算符优先级。 混合类型运算。 变量初值错 。 精度不够 。 表达式符号错 。 其它
变量初值错-----举例
函数说明：当i_flag=0；返回 i_countห้องสมุดไป่ตู้100 当i_flag=1；返回 i_count +10 否则 返回 i_count +20
输入参数：int i_count ， int i_flag 输出参数： int i_return; 代码： 1 int Test(int i_count, int i_flag) 2{ 3 int i_temp = 0;
任务2： 模块局部数据结构测试
检查局部数据结构完整性
Checklist: 不适合或不相容的类型说明。 变量无初值。 变量初始化或默认值有错。 不正确的变量名或从来未被使用过。 出现上溢或下溢和地址异常。 其它
5.1 什么是单元测试
测试的4个阶段： 单元测试集成测试 系统测试验收测试
按阶段进行测试是一种基本的测试策略
单元测试的定义
定义:
单元测试是对软件基本组成单元进行的测试。
时机:
一般在代码完成后由开发人员完成,QA人员辅助.
概念:
模块, 组件, 单元
为何要进行单元测试?
尽早发现错误
错误发现越早,成本越低.
单元测试的背景
开发流程时间表与修改Bug代价的关系图
修 改 代 价
开发早期
开发结束
单元测试的背景（续）
编程过程中，每写1000行代码会犯150个错误 编程与编译运行结束后，每100行代码中大约
残留有1-3个Bug 寻找与修改程序错误的代价占总体开发投资的
40%-80% Bug在整个研发流程中被发现的越早，修改的
软件测试方法和技术
第2版
第5章 单元测试
第4章 回顾
4.1 测试过程模型 V模型、W模型、TMap
4.2 测试过程改进模型 TMM、TPI、CTP、STEP
4.3 软件测试标准和规范 4.4 建立软件测试管理和评判体系
第二篇 软件测试的技术
在实际项目的测试过程中，我们会面对许多复杂的问题和 具体的困难，不仅要采用前面所学的方法，还要拥有很好 的技术，熟悉业务领域知识，深入系统架构、设计模式和 开发框架，灵活运用测试工具，才能真正解决问题。
第五章 单元测试
5.1 什么是单元测试 5.2 单元测试的目标和任务 5.3 静态测试 5.4 驱动程序和桩程序 5.5 调试与评估 5.6 单元测试的管理 5.7 单元测试工具
对于没有被运行的代码
对于没有被运行到的代码一定要做检查，很可能会从中发现问题， 并进而补充遗漏的测试用例。
有些函数如分配内存的malloc()等操作一般不会失败，所以它的 返回值校验分支中的代码通常不会被执行到；
资源释放操作代码没有被运行，比如内存释放、锁的释放、句 柄关闭等操作没有被执行到，通常意味着程序中可能有资源泄 露。这一类未执行代码一定要小心检查；
任务３： 模块接口测试
检查模块接口是否正确，checklist:
输入的实际参数与形式参数是否一致。
个数、属性、量纲
调用其他模块的实际参数与被调模块的形参是否一致。
个数、属性、量纲
全程变量的定义在各模块是否一致。 外部输入、输出
文件、缓冲区、错误处理
其它
任务４： 模块边界条件测试
单元测试 3小时
集成测试
开发人员过于自信,后期复杂
度高,发现解决BUG困难.
系统测试
6小时 12小时
检查代码是否符合设计和规范
举例----单元测试的必要性
假定在开发一个网站程序。将整个程序设计为三 层：数据访问层、业务逻辑层和表现层。首先是编写 数据访问层，如果没有进行单元测试，那么就得等到 业务逻辑层和表现层开发完毕后才能打开页面进行测 试。而这中间，业务逻辑层要调用数据访问层，表现 层要调用业务逻辑层的代码。如果通过页面发现某个 功能没有通过，就需要进行调试，调试时要一步一步 地跟踪代码，好不容易找到bug所在了，原来是数据访 问的一个方法里出了问题，把该方法改好了，编译不 通过！看来还得修改另外两层的代码，好，把代码都 改好了，再次打开页面进行测试，糟糕还是没通过。 上面的过程再来一次……
上面这种方式的缺点可以总结为：
为何要进行单元测试?
错误难以定位：每次要打开页面、输入值、调试，单元测试可能也需 要这些过程，但其工作量则会小很多。
执行时间长：较之单元测试，上面的方式显然耗时得多。 代码覆盖：可以理解的是，涉及的代码层次越多，就越是难以确定被
测代码和测试值之间的关系。我们要覆盖到所有的数据访问层的代码 ，就要花费很大的精力。 在应用了单元测试后，可以快速定位错误，执行的时间也要短得多，代 码覆盖也更容易进行。 如果一开始就对数据访问层和业务逻辑层进行了良好的单元测试，那么 接下来表现层的开发就顺利得多了，可以编写后面的代码。一旦出了 问题，也很容易定位和修改。
代价就越低
5.2 单元测试的目标和任务
目标: 单元模块被正确编码
信息能否正确地流入和流出单元； 在单元工作过程中，其内部数据能否保持其完整性，
包括内部数据的形式、内容及相互关系不发生错误， 也包括全局变量在单元中的处理和影响。 在为限制数据加工而设置的边界处，能否正确工作。 单元的运行能否做到满足特定的逻辑覆盖。 单元中发生了错误，其中的出错处理措施是否有效。
检查临界数据处理的正确性
Checklist: 普通合法数据的处理。 普通非法数据的处理。 边界值内合法边界数据的处理。 边界值外非法边界数据的处理。 其它
任务5：模块的各条错误处理通路测试
预见、预设的各种出错处理是否正确有效。
Checklist: 输出的出错信息难以理解。 记录的错误与实际不相符。 程序定义的出错处理前系统已介入。 异常处理不当。 未提供足够的定位出错的信息。 其它
任务１： 模块独立执行通路测试
检查每一条独立执行路径的测试。保证每条语句 被至少执行一次。
Checklist: 误解或用错了运算符优先级。 混合类型运算。 变量初值错 。 精度不够 。 表达式符号错 。 其它
变量初值错-----举例
函数说明：当i_flag=0；返回 i_countห้องสมุดไป่ตู้100 当i_flag=1；返回 i_count +10 否则 返回 i_count +20
输入参数：int i_count ， int i_flag 输出参数： int i_return; 代码： 1 int Test(int i_count, int i_flag) 2{ 3 int i_temp = 0;
任务2： 模块局部数据结构测试
检查局部数据结构完整性
Checklist: 不适合或不相容的类型说明。 变量无初值。 变量初始化或默认值有错。 不正确的变量名或从来未被使用过。 出现上溢或下溢和地址异常。 其它
5.1 什么是单元测试
测试的4个阶段： 单元测试集成测试 系统测试验收测试
按阶段进行测试是一种基本的测试策略
单元测试的定义
定义:
单元测试是对软件基本组成单元进行的测试。
时机:
一般在代码完成后由开发人员完成,QA人员辅助.
概念:
模块, 组件, 单元
为何要进行单元测试?
尽早发现错误
错误发现越早,成本越低.
单元测试的背景
开发流程时间表与修改Bug代价的关系图
修 改 代 价
开发早期
开发结束
单元测试的背景（续）
编程过程中，每写1000行代码会犯150个错误 编程与编译运行结束后，每100行代码中大约
残留有1-3个Bug 寻找与修改程序错误的代价占总体开发投资的
40%-80% Bug在整个研发流程中被发现的越早，修改的
软件测试方法和技术
第2版
第5章 单元测试
第4章 回顾
4.1 测试过程模型 V模型、W模型、TMap
4.2 测试过程改进模型 TMM、TPI、CTP、STEP
4.3 软件测试标准和规范 4.4 建立软件测试管理和评判体系
第二篇 软件测试的技术
在实际项目的测试过程中，我们会面对许多复杂的问题和 具体的困难，不仅要采用前面所学的方法，还要拥有很好 的技术，熟悉业务领域知识，深入系统架构、设计模式和 开发框架，灵活运用测试工具，才能真正解决问题。