软件测试与质量保证 概述课件

《软件测试与质量保证 概述课件》由会员分享，可在线阅读，更多相关《软件测试与质量保证 概述课件（59页珍藏版）》请在金锄头文库上搜索。

1、单元测试,马永征 2004.6.15,Outline,软件测试概述 单元测试 单元测试工具Junit（Eclipse）,软件测试概述,内容,软件测试 定义、目的和作用 衡量标准 软件测试要素 测试技术 测试过程,软件测试,概况 定义：为了发现程序的错误而执行程序的过程 软件测试是SQA的重要手段，属于软件工程领域 目前状况 软件测试的实践性大于理论性 软件测试理论体系尚不成熟 软件测试工具尚不成熟 软件测试效果对于个人的依赖性比较大,软件测试,目的 为了寻找错误，并尽可能地为修正错误提供更多的信息 为了证明软件有错误，而不证明软件没有错误 作用 发现并管理缺陷 度量质量 评价工作效率和效果 预

2、期项目风险,内容,软件测试 定义、目的和作用 衡量标准 软件测试要素 测试技术 测试过程,软件测试,衡量标准 多 能够找到尽可能多的、以至于所有的BUG 快 能够尽可能早地发现最严重的BUG 好 找到的BUG是关键的、用户最关心的 找到BUG后能够重现找到的BUG，并为修正BUG提供尽可能多的信息 省 能够用最少的时间、人力和资源发现BUG 测试的过程和数据可以重用,内容,软件测试 定义、目的和作用 衡量标准 软件测试要素 测试技术 测试过程,测试技术,不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态分析技术。,实际运行程序，并通过观察程序运行的实际结

3、果来发现错误的软件测试技术。,在不知道程序内部结构，只知道程序规格的情况下采用的测试技术或策略。,在知道程序内部结构的情况下采用的测试技术或策略。,开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。,开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,针对要求的程序功能，按照规范的流程进行的测试。,针对要求的程序功能以外的其他要求，包括性能、安全、配置、负

4、载等指标，按照规范的流程进行的测试。,针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的、按照经验进行的随机测试。,程序修改或者版本更新以后，为了确保以前正确的功能和其他指标仍旧正确，而重新进行的测试。,在测试过程中，选择足够的测试用例，使得每一个可执行语句至少被执行一次。,在测试过程中，选择足够的测试用例，使得程序中的每一个分支判断的每一种可能结果都至少被执行一次。,在测试过程中，选择足够的测试用例，使得程序中的每一条可能执行的路径都至少执行一次。,内容,软件测试 定义、目的和作用 衡量标准 软件测试要素 测试技术 测试过程,测试过程,规格定义,设计,编码,系统测试,集成测试,单

5、元测试,用户需求,验收测试,回 归 测 试,配置管理,缺陷跟踪,测试过程,单元测试：Unit Testing 目标： 检验程序最小单元有无错误 接口、数据结构、边界、覆盖、逻辑 检验单元编码与设计是否吻合 时机： 编码完成后，首先要实施的测试 方法： 静态测试 白盒测试 责任： 开发工程师,测试过程,集成测试：Integration Testing 目标： 检验组成系统的模块接口有无错误 代码实现的系统设计与需求定义是否吻合 时机： 主要的单元测试完成后，经常与单元测试同步进行 方法： 黑盒测试 责任： 开发工程师 测试工程师,测试过程,系统测试：System Testing 目标： 检验组成

6、整个系统的代码、以及系统的软硬件配合有无错误 代码实现的系统与用户需求是否吻合 检验系统的文档等各种是否完整、有效 模拟验收测试的要求，检查系统是否符合用户的验收标准 时机： 多数集成测试完成后 方法： 黑盒测试 责任： 测试工程师,测试过程,系统测试：System Testing 稳定期测试 目标： 度量是否可以结束测试 时机： 传统的系统测试完成后 方法： 黑盒测试 责任： 测试工程师,测试过程,验收测试：Acceptance Testing 目标： 使客户验收签字 系统是否符合事先约定的验收标准 时机： 系统测试完成后，在项目组看来开发和测试工作已经全部完成，可以交付使用 方法： 黑盒测

7、试 责任： 产品经理或其他高级经理 开发工程师 测试工程师 用户,测试过程,回归测试：Regression Testing 目标： 验证程序修改或者版本更新以后，以前正确的功能和其他指标仍旧正确。 时机： 每次错误修改之后，或者版本更新之后 方法： 白盒测试/黑盒测试 责任： 开发工程师 测试工程师,测试过程,缺陷跟踪：Defect Tracing 目标： 确保所有发现的错误被正确记录、分发、评估、关闭、统计 时机： 从错误发现开始到错误关闭为止，每次错误状态修改之后 方法： 缺陷跟踪系统 责任： 开发工程师 测试工程师 测试经理 用户,单元测试,内容,单元测试 目标 任务 单元测试技术 静态

8、分析 测试设计 单元测试流程 管理流程 测试文档,单元测试,概况 定义： 检验程序最小单位有无错误。一般在编码之后，由开发人员完成。 单元：软件开发中的最小的独立部分 C语言中的单元：函数或者是子过程 C+语言中的单元：类 目前状况： 实施效果非常好，但是实施阻力比较大(主要是人员和管理因素)，一般只在关键的程序单元中实施 有比较系统的理论和方法，但也依赖于系统的特殊性和开发人员的经验 有大量的辅助工具，开发人员也经常自己开发测试代码和测试工具 主要使用白盒测试和静态分析，也使用黑盒测试,单元测试,目标 1、检查代码实现是否符合设计 不能检查设计是否正确 2、尽早发现错误 Microsoft

9、applications 10-20 defects/KLOC during unit testing 0.5 defects/KLOC after release 性价比最好,内容,单元测试 目标 任务 单元测试技术 静态分析 测试设计 单元测试流程 管理流程 测试文档,单元测试,任务1、模块接口测试 检查进出模块的数据是否正确 Checklist： 模块的实际输入与定义的输入是否一致 个数、类型、顺序 模块中对于非内部/局部变量是否合理使用 使用其他模块时，是否检查可用性和处理结果 使用外部资源时，是否检查可用性并及时释放资源 内存、文件、硬盘、端口等 其他,单元测试,任务2、模块局部数据

10、结构测试 检查局部数据结构能否保持完整性 Checklist： 变量从来没有被使用 可能别的地方使用了错误的变量名 变量没有初始化 错误的类型转换 数组越界 非法指针 变量或函数名称拼写错误 使用了外部变量或函数 其他,单元测试,任务3、模块边界条件测试 检查临界数据是否正确处理 Checklist： 普通合法数据是否正确处理 普通非法数据是否正确处理 边界内最接近边界的(合法)数据是否正确处理 边界外最接近边界的(非法)数据是否正确处理 其他,单元测试,任务4、模块独立执行通路(路径)测试 检查由于计算错误、判定错误、控制流错误导致的程序错误 Checklist： 死代码 错误的计算优先级

11、精度错误 比较运算错误 赋值错误 表达式的不正确符号 、=；=、=、!= 循环变量的使用错误 错误赋值 其他,单元测试,任务5、模块内部错误处理测试 检查内部错误处理设施是否有效 Checklist： 是否检查错误出现 资源使用前后 其他模块使用前后 出现错误，是否进行错误处理 抛出错误 通知用户 进行记录 错误处理是否有效 在系统干预前处理 报告和记录的错误真实详细 其他,内容,单元测试 目标 任务 单元测试技术 静态分析 测试设计 单元测试流程 管理流程 测试文档,单元测试技术,静态分析 定义： 不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态测试

12、技术。 方法： 走查：WalkThrough 审查：Inspection 评审：Review,Michael Fagan IBM(1976),单元测试技术,静态分析-走查 定义： 开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。 经验： 限时 避免跑题 参加人员 经验丰富的开发人员 和本模块相关的开发人员 本项目组的新人 由本模块的开发者进行讲解、回答问题并记录 不要现场修改 检查要点 逻辑错误 代码标准/规范/风格,单元测试技术,静态分析-审查 定义： 开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。

13、经验： 以会议的形式，制定会议目标、流程和规则，结束后要编写报告 参加人员 经验丰富的开发人员 和本模块相关的开发人员 本项目组的新人 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录 不要现场修改 检查要点 设计需求 代码标准/规范/风格,单元测试技术,静态分析-评审 定义： 开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。 经验： 以会议的形式，制定会议目标、流程和规则，结束后要编写报告。相关资料要在会议前下发并阅读。 参加人员

14、经验丰富的开发人员 和本模块相关的开发人员 测试组和相关人员 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录 不要现场修改 检查要点 设计需求 代码标准/规范/风格 文档的完整性和一致性,内容,单元测试 目标 任务 单元测试技术 静态分析 测试设计 单元测试流程 管理流程 测试文档,单元测试技术,测试设计 定义： 依据模块的内部结构，设计测试用例的过程。 主要采用白盒测试技术，关注逻辑覆盖 原则： 1、保证没有死代码 保证一个模块中的每个独立路径都可能被使用到 2、保证对所有的逻辑值都测试true和false 3、在上下边界和合法的范围

15、内运行所有的循环 4、确保内部数据结构的有效性和完整性,单元测试技术,测试设计 逻辑覆盖测试方法： 1、语句覆盖 选择足够的测试用例，使得程序中每一条可执行语句至少被执行一次。 2、判定覆盖 选择足够的测试用例，使得程序中每一个分支判断的每一种可能结果(主要指switch-case情况)都至少被执行一次。判定覆盖也叫分支覆盖。 3、条件覆盖 选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的可能结果都至少被执行一次。,单元测试技术,测试设计 逻辑覆盖测试方法： 1、语句覆盖 2、判定覆盖 3、条件覆盖 4、判定/条件覆盖 选择足够的测试用例，使得同时满足判定覆盖和条件覆盖。 5、条件

16、组合覆盖 选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次。 6、路径覆盖 选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。,单元测试技术,测试设计 逻辑覆盖测试方法：,内容,单元测试 目标 任务 单元测试技术 静态分析 测试设计 单元测试流程 管理流程 测试文档,单元测试流程,管理流程 主要指动态测试应用流程,针对测试目标，规定测试任务、资源分配、人员角色、进度安排等。,根据测试计划，设计测试用例，包括：测试步骤、测试场景、测试代码、测试数据(包括预期结果)。,根据测试计划，配置测试环境，并手动或者自动执行测试设计。,根据测试计划，忠实地记录测试执行的过程和结果。,分析测试记录，如果发现与预期结果不同，确定并重现缺陷。,检查测试设计是否全部执行完毕，缺陷是否全部关闭。,记录、分发、评估、关闭缺陷报告。,分析测试过程和缺陷报告，评估测试质量和测试效果，给出是否通过测试的建议。,内容,单元测试 目标 任务 单元测试技术 静态分析 测试设计 单元测试流程 管理流程 测试文档,单元测试流程,测试文档 主要指