3 软件测试技术 20151229

1. 北京航空航天大学 计算机学院 School of Computer Science and Engineering,Beihang University Software Testing Techniques -- 软件测试技术 刘超 北京航空航天大学软件工程研究所 2015年12月 版权所有,未经许可不得以任何方式复制和传播 刘超:liuchao@buaa.edu.cn 电话: (10)82317496
2. 软件测试的目的 • 证明程序的正确性 -- 除非仅处理有限种情况 • 检查系统是否满足需求 -- 期望目标 • 发现程序错误 -- 直接目标
3. 软件测试的重要性 • • • • • • 软件质量的重要性 -- 不言而喻 软件质量保证的难度 -- 众所周知 现实问题 工程问题 理论问题 保证和提高软件质量 -- 两种途径 尽量在开发期间减少错误 通过分析和测试发现和纠正错误 错误 好的开发方法和技术 -- 关键 测试 -- 不可缺少 开发过程
4. 软件测试的重要性 • 软件测试是保证软件质量和可靠性的关键技术手段 • 在软件开发的瀑布模型中,软件测试被视为是紧随代码实 现之后、揭示软件中的错误、保证和提高软件质量的重要 阶段 • 在其它各种软件工程开发模型中,如快速原型、螺旋模型 、以及面向对象的软件开发模型等,也都明确确认了软件 测试的重要性和不可取代的地位。
5. 测试用例 • • • • • 发现错误可能性大的输入数据/操作 结果是可判定的 测试的执行过程和结果是可再现的 一个好的测试用例在于能够发现至今尚未发现的错误 一个成功的测试是发现了至今为发现的错误的测试
6. 测试的手段 • 静态分析 – 人工走查 – 逆向分析 + 如:引用分析、算法分析等 • 动态执行 – 功能测试(黑盒子): + 等价类、因果图、边界、强度等 – 结构测试(白盒子): + 语句测试、分支测试、条件测试、路径测试等
7. 功能测试 需求说明 产生 测试用例 被测程序 比较 输出 测试结果
8. 黑盒子测试 -- 基本测试策略 • • • • • • • • • • 正常情况 非正常情况 边界情况 非法情况 极端情况(强度测试) 性能测试 兼容性 用户友好性 ... 测试准则: 何时结束? 覆盖度? 等价类划分 因果图: – 例: 命令行 cmdname arg1 arg2 ...
9. 软件可靠性 • 软件可靠性是软件在给定的时间间隔及给定的环境条件下 ,按设计要求,成功地运行程序的概率。 • 平均失效等待时间: n MTTF = 1/n ti • 失效率为常数时, i=1 MTTF = 1/失效率 • 两次相继失效的平均时间 – 当n很大时,第n次和第n+1次失效之间的平均时间, 对于失效率为常数且修复时间很短的情况: MTBF = MTTF
10. 结构测试-程序的内部逻辑 源程序 分析 测试用例 被测程序 覆盖情况分析 执行路径
11. 白盒子测试 • 静态分析 – 控制流分析 + 模块调用/被调用关系 + 模块控制流程图 – 数据流分析 + 变量的定义 赋值与引用情况 – 复杂度分析 + 圈复杂度(Cyclematic Complexity,McCabe) + 科学复杂度(Science Complexity,Halstead) – 源代码走查(Walkthrough/Inspection)
12. 白盒子方法:动态测试 • 运行程序,并覆盖程序中的基本控制结构 • 测试覆盖准则 if( x != 0 )/* 错! 应为 x==0 */ – SC1:语句覆盖测试 x = 1; – SC2:分支覆盖测试 z = y/x; • 其它: while( i < n ) – 逻辑路径:循环--进入/不进入循环体 s += a[ i ]; – 条件覆盖 if( x>0 && y > 0 x<0 && y<0 ) z = x * y; else z = - x * y;
13. 结构测试覆盖准则之间的关系 • • • • • • 语句覆盖 判定覆盖(分支覆盖) 条件覆盖 判定/条件覆盖 多重条件(条件组合)测试 路径覆盖(逻辑路径)
14. 单元测试 驱动模块 被测模块 桩模块1 桩模块2
15. McCabe圈复杂度 • 对于一个单入口、单出口的连通图: 圈复杂度 = 弧数 - 结点数 + 2 圈复杂度 = 分支点数 + 1
16. 例1 PushingBox • 函数过于复杂! • 都少个分支?
17. 例2 学生注册系统SRS (Student Registration System) 我们承担了开发一个学生注册系统的项目(SRS)。该系统 允许学生在大学的校园网络上进行在线注册每一个学期的课程, 也可以用于跟踪学生的学习进展,直到其获得学位。 当学生被大学录取后,学生便需在SRS中建立学习计划,即 确定为满足特定学位程序所需要的课程,并选择一位导师。SRS 要检验学生所提出的学习计划是否满足他/她所修学位的要求。 一旦建立了学习计划,则在以后每个学期的注册期间,学生 都可以在线查看课程计划,选择要选修的课程,如果课程有多名 教授讲授,则还可以指定期望的课程班和授课时间(每周星期几 ,每天什么时间听课)。
18. SRS要检查对学生选择的课程进行必要条件的检查: (1)参考学生已完成课程的成绩单(学生随时可以查看自己 的成绩单),检查学生是否已经通过所选课程的预修课程, 并取得必要的成绩; (2)该课程满足该学生学习计划要求之一; (3)该课程班中仍有空位。 只有当上述三个条件都满足时,学生的选课请求才被接受。
19. 问题1: SRS的“单元测试”(类及其方法) • • • • 功能? 接口? 继承? 多态? Course courseNo courseName Person credits prerequisite ScheduleOfClasses {abstract} scheduleSection() * semester - name: addPrerequisite() String hasPrerequisite() - ssn: String 1 * offered as * Section sectionNo attends dayOfWeek Professor Student major * * timeOfDay title degree Room department TranscriptEntry password seatingCapacity agreeToTeach() addSection() grade enroll() 1 dropSection() drop() isEnrolledIn() postGrade() 1 confirmSeatAvailability maintains 1 Transcript * verifyCompletion() teaches
20. public abstract class CollectionWrapper { // attributes omitted public boolean initializeObjects(String pathToFile, boolean primary) { // variables omitted try { // Open the file. bIn = new BufferedReader(new FileReader(pathToFile)); line = bIn.readLine(); while (line != null) { if (primary) parseData(line);// for basic format of the line else parseData2(line);// for the second format of the line line = bIn.readLine(); } bIn.close(); } catch (FileNotFoundException f) { outcome = false; } catch (IOException i) { outcome = false; } return outcome; } public abstract void parseData(String line); public abstract void parseData2(String line); } 问题2:白盒测试 • 语句覆盖 • 分支覆盖 • 异常处理? • 多态影响?
21. 问题3:软件集成测试 • 功能 – 用户操作 • 安装 – 环境 • 性能 • 安全
22. 问题4:基于需求的测试? • 用例: – 使用者?典型使用场景?可能的、异常的场景? 注册课程 学生 公布成绩 教授 查询成绩 确定学生选修的课程 收费系统
23. 测试的代价 • 开发费用的40-60%, 甚至80% !!?? • 为什么? – – – – – – – 有多少测试项? 有多少运行平台? 硬件/软件环境 环境设置 环境变化 测试周期: 测试准备 测试实施 回归测试 测试资源: 人力 设备 场地 消耗 ...
24. 测试的“心理”障碍 • 涉及的人 – 测试人员(QE&QA) 开发人员 设计人员 管理人员 – 用户 • 不同人的心理 • 不同人之间的交流和沟通中的主要障碍 – – – – 角色差异 心理差异 专业背景差异 "文化"背景差异
25. 软件测试过程与方法 • • • • • • • • 软件质量问题 软件测试的目的 软件测试的手段 软件测试的代价 软件测试的"心理学"问题 软件测试阶段性与过程性 过程的控制与管理 软件测试的自动化技术和工具
26. 软件测试的基本原则 • 执行结果的可预见性(和可描述的) • 第三者测试原则: Users, Developpers, Testes(Quality Engineers) – programmers – development units <--> • • • • • • <--> testers QE(QA) units 彻底检查每一个测试结果 非法的和非预期的情况的测试 做了该做的,没做不该做的 测试用例的保存、积累和重用 总假定程序是有错的 一段程序中存在的错误数与其中已发现的错误数成正比
27. 软件测试的基本任务与时机 • 测试的任务 – 运行环境? 程序执行? 测试用例? 测试步骤? 结果采集 和记录? 结果分析? 错误报告? 错误定位? • 测试的时机 – 编程之后 – 编程期间 ? – 编程之前 ?
28. 软件测试的阶段性 需求分析 评审的依据? 设计 实现 问题: - 缺乏计划 - 缺乏依据 准则 - 随机性大 - 可重复性差 - 不可重用 测试 测试什么? 何时了? 怎么测?
29. 软件测试过程 • 一种简单实用的软件测试过程模型POCERM • 测试过程中必需的基本测试活动及其产生的结果 – 拟定软件测试计划(Plans) – 编制软件测试大纲(Outlines) – 设计和生成测试用例(test Case generation) – 实施测试(Execution) – 生成软件测试报告(software testing Reports) – 软件问题报告SPR(Software Problem Report) – 测试结果报告(test result Reports) – 对整个测试过程进行有效的管理(Management)
30. 软件开发与软件测试间的协同 开 发 过 程 需求分析 概要设计 详细设计 编码实现 缺陷修复 提交测试版 提交或更新需求和设计制品 协同管理 提交软件问题(缺陷)报告 测 详细测试计划 测试需求分析与 概要计划 测 试 过 程 缺陷报告 测试大纲设计 测试用例生成 实施测试 测试实施计划 质量与进度 评估 结果分析 反馈
31. 常见的测试过程 改错 软件开发 ?出厂 找用例 测试
32. 基本特性 •计划性:任务 人员 设备 时间 相关... •平行性:开发 编码 测试 再测试 •完整性:计划+大纲+用例+SPRs+... •重用性:测试 再测试 回归测试 升级 多平台.. •可重复性:SPRs 用例 大纲 -> 再现BUGs •周期性:test cycles, regression, update •可管理性: well structured and organized QE group + well planned and prepared task
33. 软件质量工程 • 软件开发是一项集体的 工程性的工作 – 人 设备 场地 资金 进度等 • 沟通(Communication)与协同工作 – 人与人 部门与部门之间 – 及时交流情况 – 确认理解一致 – 充分研讨 "问题" – 问题记录与追踪 • 软件测试是软件开发的一部分
34. 软件测试过程控制与管理 --软件测试的一些基本原则(补充) • 测试必须是有计划的: 任务、时间、人员、设备、经费、方 法与工具、问题等 • 测试必须是有组织的 • 测试必须是有准备的 • 测试必须是有记录的 测试是一项非常复杂的、创造性的和需要高度智慧的挑战性 任务。
35. 软件测试阶段性 • 单元测试: – 静态分析: 结构分析 复杂度分析 代码走查 – 白盒子测试:语句覆盖 分支覆盖 ... – 黑盒子测试: 合法 非法 边界 极端 … • • • • • • 组合测试: 功能 性能 界面/接口(黑盒子) 集成测试: 功能 性能 界面 兼容 (黑盒子) 系统测试: 嵌入式系统 ...(黑盒子) BETA测试: 用户测试及试用(黑盒子) 验收测试: 对软件质量保证无直接贡献 测试的验收: 过程 方法 内容 结果 ...
36. 软件测试的周期性 串行方式: 开发者: 测试周期 改错 测试周期 改错 … ... 并行方式: 开发者: 开发/改错 开发/改错 开发/改错 测试者: 测试周期1 测试周期2 … 回归测试1 … ... 功能冻结 最终回归测试 代码冻结
37. 三个测试期和两个里程碑 160 140 120 100 80 60 40 20 0 1 2 3 初测期 4 5 6 7 8 细测期 9 10 11 12 13 14 15 16 17 18 19 功能冻结 回归测试期 功能冻结
38. 软件质量与测试 测试覆盖率 软件质量 软件问题数
39. 软件集成测试的三个阶段 • 初测期: – 主要功能和关键的执行路径,排除主要障碍 • 细测期: – 依据测试计划和测试大纲 – 逐一测试大大小小的功能、方方面面的特性、性能、 用户界面、兼容性、可用性等等 – 预期可发现大量不同性质、不同严重程度的错误和问 题 • 回归测试期: – 系统已稳定,一轮测试中发现的错误已十分有限 – 复查已知错误的纠正情况,确认未引发任何新的错误 • 终结回归测试(Final Regression)
40. 软件集成测试的两个重要的里程碑 • 功能冻结(Function/Feature Freeze):标志着整个系统的 集成工作已经完成,系统的功能、性能、界面、兼容性等 均已经过测试,符合设计要求,确认系统功能和其他特性 均不再做任何改变; • 代码冻结(Code Freeze): – 理论上,无错误时冻结程序代码 – 实际上,代码冻结只是标志着系统的当前版本的质量 已经达到预期的要求,冻结程序的源代码,不再对其 做任何修改。显然,这个里程碑是设置在软件通过了 终结回归测试之后。
41. 软件测试计划 • 概要测试计划 • 详细测试计划 • 测试实施计划
42. 概要测试计划 • • • • 在软件开发初期,即需求分析阶段制定 定义被测试对象和测试目标 确定测试阶段和测试周期的划分 制定测试人员、软硬件资源和测试进度等方面的计划, 任 务与分配与责任划分 • 规定软件测试方法、测试标准,比如, – 语句覆盖率需达到95% – 三级以上的错误改正率需95% – 所有决定不改正的"轻微"错误都必须经过专门的质量评审委员会 同意 • 支持环境和测试工具等 • 待解决的问题等
43. 详细测试计划 • 针对子系统在特定的测试阶段所要进行的测试工作制定详 细计划 • 详细规定了测试小组的各项测试任务、测试策略、任务分 配和进度安排等
44. 测试人员的测试实施计划 • 测试者或测试小组的具体的测试实施计划 • 规定了测试者负责测试的内容、测试强度和工作进度 • 整个软件测试计划的组成部分,是检查测试实际执行情况 的重要依据 • 主要内容: – 计划进度和实际进度对照表 – 测试要点 测试策略 ... – 尚未解决的问题和障碍
45. 软件测试大纲 • • • • • 软件测试的依据 测试项目 测试步骤 测试完成的标准 无论是自动测试还是手动测试,都必须满足测试大纲的要 求。
46. 软件测试大纲的本质 • 从测试的角度对被测对象的功能和各种特性的细化和展开。 比如, – 针对系统功能的测试大纲是基于软件质量保证人员对系 统需求规格说明书中有关系统功能定义的理解,将其逐 一细化展开后编制而成的。 – 测试大纲不仅是软件开发后期测试的依据,而且在系统 的需求分析阶段也是质量保证的重要文档和依据。
47. 软件测试用例 • 实施一次测试而向被测系统提供的输入数据、操作或各种环 境设置 • 对交互式系统,软件交互执行过程的控制也是一种测试用例 • 测试用例的设计与生成是依据测试大纲对其中每个测试项目 的进一步实例化。比如, – 对于一个输入项的测试,应当设计一组测试数据,包括 合法的、边界的和非法的数据等。
48. 测试用例生成的基本原则 • 测试用例的代表性:能够代表并覆盖各种合理的和不合理 、合法的和非法的、边界的和越界的、以及极限的输入数 据、操作和环境设置等; • 测试结果的可判定性:即测试执行结果的正确性是可判定 的; • 测试结果的可再现性:即对同样的测试用例,系统的执行 结果应当是相同的。
49. 交互式软件的测试用例的生成 测试用例空间 T=D0xD1x(*(D2xD3)+D4)xD5xD6 D4 D0 D1 D5 D2 D6 D3 t:d0 d1 d2 d3 d2 d3 d5 d6 控制点或输入点 控制转移
50. 交互式软件的测试用例的生成 • 测试用例 – 测试步骤: 控制点的序列 (测试大纲) – 代表值: 每个控制点上的每一项输入或操作(测试数据) • 覆盖准则 – – – – 准则1: 控制点覆盖 准则2: 转移边覆盖 准则3: 典型路径覆盖 准则4: 代表值覆盖
51. 测试的实施 • 手工测试与自动测试 • 测试优先级 • 软件问题报告SPR – SPR的生存周期: + 状态:new,open,pending,close,... + 子状态:fix,defer,NPTF,Not a Bog, Transfer,... • 测试状态报告 – 进度 问题 调整 ... • QE与Developers之间的通讯
52. 北航软件工程研究所 • 软件测试过程管理平台QESuite – – – – 异地群组协同工作平台 软件测试计划、测试大纲和测试用例的管理 软件问题报告的记录、追踪与控制 软件测试过程的控制与管理
54. 软件测试过程(POCERM-II)
55. 软件团队异地协同工作模式 团队协作 异地协同
56. QESuite的功能架构 测试用例 管理模块 SPR存储 测试用例存储 SPR处理工作流 SPR管理模 块 测试用例评审 SPR处理动作追踪 测试用例执行工作流 测试任务管理 测试环境配置管理 测试执行结果跟踪 公共模块 用例执行/SPRs 统计/图表 人员分配 测试任务 管理模块 存档 待测试系统划分管理 Cases/SPRs 双向转换 公共信息管理 测试计划 管理模块
57. 基于功能域分解的测试用例库管理 • 树状结构的功能分类管理可以满足大型软件的测试要求。 可以方便地为功能分类指 派相关的开发与测试人员 树状结构的功能分类树可 以轻松表示大型软件的系 统划分
58. 测试用例存储管理 测试用例的数据库存储方式 使企业脱离了传统的纸张和 电子文档方式,便于测试用 例的共享和交流与管理。 QESuite为测试用例的存储 管理提供了丰富的视图
59. 测试用例执行状态监控 QESuite可以对测试用例在各 种不同的环境配置,不同的 测试版本与测试阶段下的执 行结果进行跟踪和管理。
60. 软件问题报告生命周期管理 各种不同类型的人员可以从 不同的视图中得到软件问题 报告的不同分类信息,方便 了软件问题的处理! QESuite全力支持开发和测 试部门的协同工作,可实现 开发测试部门工作分配的流 程化,方便快捷!
61. 软件问题报告
62. 软件问题报告的生命周期
63. 测试执行报告及测试结果的追踪 测试用例的历次执行结果和 发现的问题都可以方便地进 行查看与追踪!
64. 测试用例及其关联性 复杂的多层级的多对多关联 关系! 测试需求 {hierarchy} 功能域 * * 测试用例 * * 被测软件配置 * 测试任务 * * 问题报告 * 执行报告
65. 北航软件工程研究所 • C++/Java软件分析与测试工具系列 – – – – 类图、程序结构图、程序流程图 语句覆盖测试和分支覆盖测试 ANSI C++、MS VC++/Windows、GNU C++/Linux Java
66. C++/Java软件分析与测试工具
67. 分析与测试报告
68. 软件问题时间分布图 60 50 40 程序错 转移 多语言接口 移植版 30 20 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
69. 软件问题发现与解决延迟图(2009/10/29) 250 200 150 软件问题发现数 软件问题解决数 平均延迟天数 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
70. 练习:测试—文件名 • 定义 • • • • • FileFullName ::= [Path]Filename Path::= [/ ./ ../]{Filename/} Filename::= {Number Letter SpecialCharacter}+ Letter::=英文 中文 … SpecialCharacter::=<space> . … x( / …) 长度 类型(.后缀) 选择( ) 文件:存在,不存在,只读,… {文件内容:空,超大,合法,非法,…}
71. 总结 • 软件测试实际上是一个相当复杂的软件质量保证工程 • 软件测试过程POCERM突出描述了软件测试的过程性,以 及计划、大纲和软件问题报告等一系列文档的重要性。 • 测试的基本准则:覆盖率 • 测试自动化 -- 工具支持