软件测试策略.ppt
合集下载
软件测试知识PPT(共23张PPT)
白盒测试
• ①白盒测试法需要了解程序内部的结构，测试用例是根据程序的内部逻辑来 设计的。白盒测试法主要用于软件的单元测试。
• ②白盒测试的基本原则是：保证所测模块中每一个独立路径至少执行一次； 保证所测模块所有判断的每一个分支至少执行一次；保证所测模块每一个循 环都在边界条件和一般条件下至少执行一次；验证所有内部数据结构的有效 性。
• ③白盒测试法常用的技术是逻辑覆盖。主要的覆盖标准有6 种，即强度由低到 高依次是：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合 覆盖、路径覆盖。
• I. 语句覆盖
• 指选择足够的测试用例，使被测语句的每个语句至少执行一次。
• II.判定覆盖 • 指选择足够的测试用例，使每个判定的所有可能结果至少出现一次。 • III.条件覆盖
需求分析 确认测试
软件设计 集成测试
编码 单元测试
需求分 析说明
书
概要设 计说明
书
详细设 计说明
书
源程ቤተ መጻሕፍቲ ባይዱ 代码
单元测 试
集成测 试
确认测 试
• 单元测试：也称模块测试，主要发现编码和详细设计中产生的错误，通常采用白盒
测试。放在编码阶段，由程序员自己来完成，检查它是否实现了详细设计说明书中 规定的模块功能和算法。其测试计划是在详细设计阶段完成。单元测试的测试计划 是在详细设计阶段完成。
次。
• VI. 路径覆盖
• 指选择足够的测试用例，使流程图中的每条路径至少经过一次。
黑盒测试
• ①黑盒测试，是对软件已经实现的功能是否满足需求进行测试和验证。 黑盒测试不关心程序内部的逻辑，只是根据程序的功能说明来设计测试 用例。黑盒测试法主要用软件确认测试。
软件测试PPT课件
显然，满足条件组合覆盖标准的测试用例一 定也满足断定覆盖、条件覆盖、断定/条件覆盖、 语句覆盖标准。
断定a中条件结果的所有可能组合： ①A>1，B=0 ; ② A>1，B ≠ 0; ③A≤ 1，B=0 ; ④ A ≤ 1，B ≠ 0 断定c中条件结果的所有可能组合： ⑤ A=2， x>1; ⑥ A=2，x ≤ 1 ; ⑦ A ≠ 2 ，x>1; ⑧ A ≠ 2 ，x ≤ 1
• 黑盒测试可用于各种测试，它试图发现以下类型 的错误：
• 不正确或遗漏的功能
• 接口错误，如输入/输出参数的个数、类型等
• 数据构造错误或外部信息访问错误
• 性能错误
• 初始化和终止错误
10.2 白盒测试
常用的白盒测试方法有： 逻辑覆盖测试 根本途径覆盖测试 数据流测试 循环测试
逻辑覆盖测试
逻辑覆盖主要考察使用测试数据运行被测 程序时对程序逻辑的覆盖程度。通常希望选择 最少的测试用例来满足所需的覆盖标准。主要 的覆盖标准有：
10.1 软件测试根底
一、软件测试的目的
➢ 测试是一个为了发现错误而执行程序的过程 ➢ 一个好的测试用例是指很可能找到迄今为至尚未发
现的错误的测试用例 ➢ 一个成功的测试是指提醒了迄今为至尚未发现的错
误的测试 ➢ 根据这个测试目的，应该排除对测试的错误观
点，设计适宜的测试用例，用尽可能少的测试用例， 来发现尽可能多的软件错误。
测试数据 x=4,A=2,B=0
预期结果 x=3
s
at
f
b
ct
f
d
e
a: (A>1) and (B=0)
c: (A=2) or
(x>1)
断定覆盖
断定a中条件结果的所有可能组合： ①A>1，B=0 ; ② A>1，B ≠ 0; ③A≤ 1，B=0 ; ④ A ≤ 1，B ≠ 0 断定c中条件结果的所有可能组合： ⑤ A=2， x>1; ⑥ A=2，x ≤ 1 ; ⑦ A ≠ 2 ，x>1; ⑧ A ≠ 2 ，x ≤ 1
• 黑盒测试可用于各种测试，它试图发现以下类型 的错误：
• 不正确或遗漏的功能
• 接口错误，如输入/输出参数的个数、类型等
• 数据构造错误或外部信息访问错误
• 性能错误
• 初始化和终止错误
10.2 白盒测试
常用的白盒测试方法有： 逻辑覆盖测试 根本途径覆盖测试 数据流测试 循环测试
逻辑覆盖测试
逻辑覆盖主要考察使用测试数据运行被测 程序时对程序逻辑的覆盖程度。通常希望选择 最少的测试用例来满足所需的覆盖标准。主要 的覆盖标准有：
10.1 软件测试根底
一、软件测试的目的
➢ 测试是一个为了发现错误而执行程序的过程 ➢ 一个好的测试用例是指很可能找到迄今为至尚未发
现的错误的测试用例 ➢ 一个成功的测试是指提醒了迄今为至尚未发现的错
误的测试 ➢ 根据这个测试目的，应该排除对测试的错误观
点，设计适宜的测试用例，用尽可能少的测试用例， 来发现尽可能多的软件错误。
测试数据 x=4,A=2,B=0
预期结果 x=3
s
at
f
b
ct
f
d
e
a: (A>1) and (B=0)
c: (A=2) or
(x>1)
断定覆盖
测试方案(测试策略)PPT教学课件
采购收 货
作废出 货
采购退 货
进货成本 调整
销售成本 管理
Y
退货进 仓
生产管 理
生产计 划
原料仓 库
外发加 工
生产加 工
原料 够用?
N
生产补 料
N QC
Y 半成品库
产品组装
废品库 N
QC Y
供材
料? Y
N
生产加工
Q C
Y
10
PPTWatching
11
等相关内容。
2020/12/11
3
确定测试策略的原则：
2. 定义测试计划（测试策略=测试需求+测试方法，测试环 境，测试工作进度表）： 可以包括以下内容：16种的测试类型： 初始化测试，功能测试、
界面测试，安全测试，容错测试，接口（业务流程）测试、性能测试、并发 测试、负载测试、配置（兼容性）测试，恢复测试，安装测试，文档测试， 可用性测试等。
2020/12/11
5
确定测试策略的步骤：
5. 分析被测系统，编写测试需求 反复检查并理解各种信息(数据等)，和相关人员沟通和交流，理解他们的
需求。可以按照以下步骤执行： 1）确定软件提供的主要业务 2）对每个用户的日常数据处理业务（商业业务），确定完成该任务所要
进行的工作,前置条件,约束条件。 3）确定数据的计算及其结果。 4）对于对时间有要求的业务处理过程，确定所要的时间和条件。这些条
管理功能，如启动和退出程序； 配置功能，如设置打印机； 操作员的爱好，如字体、颜色； 应用功能，如访问email或者显示时间和日期等。
2020/12/11
7
确定测试策略的步骤
9）确定安装过程，包括常用的典型安装、自定义定制安装、升级 安装。
2024软件测试管理PPT软件测试管理
•软件测试概述•软件测试管理核心要素•软件测试流程优化与实践•团队协作与沟通技巧提升目•质量保证体系建立与完善•总结回顾与未来展望录定义目的分类单元测试、集成测试、系统测试、验收测试等。
方法黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手工测试、自动化测试等。
其中，黑盒测试主要关注软件的功能和界面，白盒测试主要关注软件的内部结构和逻辑，灰盒测试则介于两者之间。
静态测试主要通过代码审查、走查等方式进行，动态测试则需要实际运行软件并输入相应的测试数据。
手工测试需要测试人员手动执行测试用例，而自动化测试则通过自动化测试工具或脚本来执行测试用例。
测试计划制定与执行根据软件需求和开发计划，确定测试的范围、重点和目标。
编写详细的测试计划，包括测试资源、进度、风险等方面。
按照测试计划执行测试工作，确保测试的有效性和全面性。
对测试进度和结果进行实时监控，根据实际情况调整测试计划。
明确测试目标制定测试计划执行测试计划监控与调整测试用例设计与评审01020304设计测试用例评审测试用例完善测试用例维护测试用例缺陷跟踪缺陷报告编写缺陷分析缺陷预防缺陷跟踪与报告编写风险评估与应对措施风险评估制定应对措施监控风险风险报告自动化测试技术应用自动化测试框架搭建选择适合的自动化测试工具，如Selenium、Appium等，搭建稳定高效的自动化测试框架。
测试用例设计与执行基于需求文档和设计文档，编写全面的测试用例，并通过自动化测试工具执行测试用例。
测试结果分析与报告对自动化测试结果进行分析，生成详细的测试报告，及时反馈问题并协助开发团队定位修复缺陷。
明确系统性能指标，如响应时间、吞吐量、并发用户数等。
性能测试需求分析性能测试场景设计性能测试执行与监控性能测试结果分析根据需求分析结果，设计不同的性能测试场景，如压力测试、负载测试、稳定性测试等。
使用性能测试工具，如LoadRunner 、JMeter 等，执行性能测试场景，并实时监控性能指标。
软件测试完整ppt课件
目录 首页 上页 下页 末页
第10章 软件测试
7
有关软件测试的错误观点
“软件测试是为了证明程序是正确的，即测 试能发现程序中所有的错误”。事实上这是不可 能的。要通过测试发现程序中的所有错误，就要 穷举所有可能的输入数据。
例：程序P有两个整型输入量 X、Y，输出量为Z，
在32位机上运行。所有的测试数据组（Xi，Yi）的 数目为：232×232= 264，1毫秒执行1次，共需5亿
目录 首页 上页 下页 末页
第10章 软件测试
6
10.1 软件测试基础
一、软件测试的目的
➢ 测试是一个为了发现错误而执行程序的过程 ➢ 一个好的测试用例是指很可能找到迄今为至尚未发
现的错误的测试用例 ➢ 一个成功的测试是指揭示了迄今为至尚未发现的错
误的测试 根据这个测试目的，应该排除对测试的错误观点，设 计合适的测试用例，用尽可能少的测试用例，来发现 尽可能多的软件错误。
12
评审（Review）
评审是由若干开发人员、项目经理、测试人员、用 户或领域专家等组成一个会审小组，通过阅读、讨论和争 议，对工作制品进行静态分析的过程。
类型：需求评审、设计评审和代码评审。
•评审过程
–小组负责人先把需求规格说明、设计说明或程序代 码及有关要求、规范等分发给小组成员，作评审依据；
–在充分阅读有关材料后召开评审会议，主要开发人 员进行讲解，其他成员提出问题并展开讨论，审查是否存 在错误；
d — 定义 r — 引用 u — 未引用
R：duuuuu 只定义不用 S：uruuur 未定义引用 Y：uuddru 连续定义
目录 首页 上页 下页 末页
第10章 软件测试
16
审查（Inspection）
软件测试的策略培训课件
修复率达到标准
2020/1/14
20
1 软件测试的策略——单元测试
• 单元测试针对的程序规模较小，易于 查错
• 发现错误后容易确定错误的位置，易 于排错
• 多个模块可以并行测试
2020/1/14
21
1 软件测试的策略
• 单元测试 • 集成测试 • 系统测试
2020/1/14
22
1 软件测试的策略——集成测试
• 集成测试 • 在单元测试的基础上，测试单元组装
时是否出现问题
• 集成测试需求所确定的是对某一集成工 作版本的测试的内容，即测试的具体对 象
• 集成测试需求主要来源于设计模型 （Design Model）和集成构件计划 （Integration Build Plan）
2020/1/14
23
1 软件测试的策略——集成测试
35
谢谢！
2020/1/14
36
2020/1/14
12
1 软件测试的策略——单元测试
• 局部数据结构测试
不正确或不一致的数据类型说明 错误的初始值或错误的缺省值 使用尚未赋值或尚未初始化的变量 变量名拼写错误或书写错误 不一致的数据类型 除局部数据之外的全局数据对模块的影响也
需要查清
2020/1/14
13
1 软件测试的策略——单元测试
被测模块 单元 测试
……
被测模块
2020/1/14
单元 测试
已集成的 已确认的
集成 模块 系统 模块 验收
测试
测试
测试 可交付的
软件
已测试的 模块
5
1 软件测试的策略
• 单元测试 • 集成测试 • 系统测试
2020/1/14
2020/1/14
20
1 软件测试的策略——单元测试
• 单元测试针对的程序规模较小，易于 查错
• 发现错误后容易确定错误的位置，易 于排错
• 多个模块可以并行测试
2020/1/14
21
1 软件测试的策略
• 单元测试 • 集成测试 • 系统测试
2020/1/14
22
1 软件测试的策略——集成测试
• 集成测试 • 在单元测试的基础上，测试单元组装
时是否出现问题
• 集成测试需求所确定的是对某一集成工 作版本的测试的内容，即测试的具体对 象
• 集成测试需求主要来源于设计模型 （Design Model）和集成构件计划 （Integration Build Plan）
2020/1/14
23
1 软件测试的策略——集成测试
35
谢谢！
2020/1/14
36
2020/1/14
12
1 软件测试的策略——单元测试
• 局部数据结构测试
不正确或不一致的数据类型说明 错误的初始值或错误的缺省值 使用尚未赋值或尚未初始化的变量 变量名拼写错误或书写错误 不一致的数据类型 除局部数据之外的全局数据对模块的影响也
需要查清
2020/1/14
13
1 软件测试的策略——单元测试
被测模块 单元 测试
……
被测模块
2020/1/14
单元 测试
已集成的 已确认的
集成 模块 系统 模块 验收
测试
测试
测试 可交付的
软件
已测试的 模块
5
1 软件测试的策略
• 单元测试 • 集成测试 • 系统测试
2020/1/14
《软件测试培训》PPT课件
定义目标 确定策略 确定方法 建立环境 执行计划 一步步验证 执行完毕？ 没有改正 继续执行
2021/3/26
4
谁参与测试？
用户方代表 软件最终使用者 软件开发人员 软件测试人员 高层经理的支持 过程保证人员（SQA）
2021/3/26
5
什么试缺陷？
缺陷：最终产品同用户的期望不一致 缺陷的分类
校验程序的开发是否依照已定义的标准，流程和操作 方式进行的。
如何去使用
将文档/程序同标准相比较 比较有效的方法是检查过程
例子
代码互查（一行一行）
什么时候使用
依赖于管理的需要
2021/3/26
51
安全性测试
目标
安全性的缺陷很难被发现。 大多数的情况下组织能够防止一般性的破坏者。
2021/3/26
14
续……
软件方面
使用了不完全的或者不正确的判定标准来设计软 件。
错误的处理了用户的非法操作 忽略了对关键数据的输出检查
数据问题
出现了不完整的数据，不正确的数据，过期的数 据
2021/3/26
15
测试效果的好坏是组织级的问题
有效的测试最好由一个独立的团队来实施。
便于确定工作目标 便于人员的培养与升迁 利于团队建设 对质量的忠诚度高 利于新技术，新方法的产生和推广 工作职责明确
版本
2021/3/26
26
QC和QA
质量控制
验证产品的正确性，当发现与设计不一致的时 候进行纠正。
质量保证
充当支持执行全面质量管理的角色
2021/3/26
27
测试涉及的定义和概念
缺陷
与需求规格说明书不一致的地方。
静态检查
软件测试测试原理PPT课件
测试的文档基础
测试责任主体 测 试 重 点
静态测试 各类文档
检查小组
各方面
白盒测试 软件详细设计文档
开发人员
白盒测试 软件概要设计文档
独立测试组
黑盒测试 白盒测试 黑盒测试
软件需求规格说明书
系统的子系统设计文 档
系统规格说明书
独立测试组 独立测试组 独立测试组
软件单元设计 配置项设计/构 架 配置项需求
黑盒测试
优点 局限性
●黑盒测试用例与程序如何实现无关 ●测试用例的设计与程序的开发可以 并行进行。
●输入条件多、组合复杂、数据量大， 不可能做到穷举测试。 ●因只选择部分输入构成测试用例， 黑盒测试是很有可能存在漏洞的。
第36页/共70页
• 白盒测试是将黑盒子打开，研究源
白
代码和程序内部的逻辑结构。白盒 测试的依据是程序代码。
• 代码中常存在内存泄露的问题，尤其是C/C++程序，白盒测试可 以方便地发现内存泄露的问题，且是直接定位缺陷，而黑盒测试 只能通过长时间运行程序，并仔细地检查用例执行结果，才能发 现这类问题。
第38页/共70页
白盒测试
• 无法穷举：程序中的逻辑路径太多，
常常要面对路径爆炸的问题。例如，
局
有的代码可能不到100行，却具有5 20条可能的路径，若每条路径设计
2.1测试原则
从用户的角度出发
希望通过软件测试能 充分暴露软件中存在
的问题和缺陷
从开发者的角度 出发
希望测试能表明软件产品 不存在错误，已经正确地
实现了用户的需求
两种测试原则
第1页/共70页
1．所有的测试都应追溯到用户需求
测
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
确认测试则是要检查已实现的软件是否满足 了需求规格说明中确定了的各种需求，以及 软件配置是否完全、正确。
系统测试把已经经过确认的软件纳入实际运 行环境中，与其它系统成份组合在一起进行 测试。
单元测试 (Unit Testing)
单元测试又称模块测试，是针对软件设计 的最小单位 ─ 程序模块，进行正确性检验 的测试工作。其目的在于发现各模块内部 可能存在的各种差错。
单元测试的主要手段 ：
1、代码审查(code inspection) Walk-through: 例如 Lucent Technologies 的测
试策略，是由三人一组(包括 author, reader, 和 recorder)，逐行检查源代码。
Rehearsal：由人扮演computer，模拟执行情况
外部检查：打开、结束、关闭文件的操作；文 件和属性；I\O错误处理；输出拼写，等等。
2、局部数据结构：
数据说明(declaration)；初始化与缺省值的设 置；变量名拼写；数据类型的相容性；上\下溢出 及地址异常，等等。
3、重要的执行通路：
由于穷尽测试不可能，故通常针对最常见的错误 设计测试方案。较常见的错误有：
对基本执行路径和循环进行测试可以发现大 量的路径错误。
(4) 错误处理测试
出错的描述是否难以理解 出错的描述是否能够对错误定位 显示的错误与实际的错误是否相符 对错误条件的处理正确与否 在对错误进行处理之前，错误条件是否已经
引起系统的干预等
(5) 边界测试
注意数据流、控制流中刚好等于、大于或小 于确定的比较值时出错的可能性。对这些地 方要仔细地选择测试用例，认真加以测试。
单元测试需要从程序的内部结构出发设计 测试用例。多个模块可以平行地独立进行 单元测试。
1. 单元测试的内容
在单元测试时，测试者需要依据详细设计 说明书和源程序清单，了解该模块的I/O条 件和模块的逻辑结构，主要采用白盒测试 的测试用例，辅之以黑盒测试的测试用例 ，使之对任何合理的输入和不合理的输入 ，都能鉴别和响应。
如果对模块运行时间有要求的话，还要专门 进行关键路径测试，以确定最坏情况下和平 均意义下影响模块运行时间的因素。
ห้องสมุดไป่ตู้ 2. 单元测试的步骤
模块并不是一个独立的程序，在考虑测试 模块时，同时要考虑它和外界的联系，用 一些辅助模块去模拟与被测模块相联系的 其它模块。
驱动模块 (driver)
桩模块 (stub) ── 存根模块
如果一个模块要完成多种功能，可以将这个 模块看成由几个小程序组成。必须对其中的 每个小程序先进行单元测试要做的工作，对 关键模块还要做性能测试。
对支持某些标准规程的程序，更要着手进行 互联测试。有人把这种情况特别称为模块测 试，以区别单元测试。
主要测试以下五个方面：
1、模块接口：
内部检查：传输参数的数目、属性、单位、次 序是否匹配；全程变量的定义是否一致；只做输 入的变元有无被修改，等等。
(2) 局部数据结构测试
不正确或不一致的数据类型说明 使用尚未赋值或尚未初始化的变量 错误的初始值或错误的缺省值 变量名拼写错或书写错 不一致的数据类型 全局数据对模块的影响
(3) 路径测试
选择适当的测试用例，对模块中重要的执行 路径进行测试。
应当设计测试用例查找由于错误的计算、不 正确的比较或不正常的控制流而导致的错误 。
计算次序问题
不同类型混合运算（例：比较类型不同的量）
初值设置错误
精度问题（例：精度不够导致两变量不可能相等， 而程序中等待相等条件的出现）
表达式错误
循环终止条件错误(例：次数差1，或陷入死循环)
4、出错处理通路： 预见出现错误的条件，设置处理。较常见
的问题有： 输出的错误信息难以理解，不能确定错误位置 描述的错误与实际错误不符 处理之前系统已经干预 处理不正确
(1) 模块接口测试
在单元测试的开始，应对通过被测模块的数 据流进行测试。测试项目包括：
调用本模块的输入参数是否正确； 本模块调用子模块时输入给子模块的参数
是否正确； 全局量的定义在各模块中是否一致；
在做内外存交换时要考虑：
文件属性是否正确； OPEN与CLOSE语句是否正确； 缓冲区容量与记录长度是否匹配； 在进行读写操作之前是否打开了文件； 在结束文件处理时是否关闭了文件； 正文书写／输入错误， I／O错误是否检查并做了处理。
通常，把模块组装成为系统的方式有两种 一次性组装方式(big bang)
组装测试（Integrated Testing）
组装测试 (集成测试、联合测试）
通常，在单元测试的基础上，需要将所有模 块按照设计要求组装成为系统。如需要考虑 以下的问题：
✓一个模块的功能是否会对另一个模块的功 能产生不利的影响
✓各个子功能组合起来，能否达到预期要求 的父功能
组装测试（Integrated Testing）
软件测试策略 测试流程图
软件测试策略
测试过程按4个步骤进行，即单元测试、组装 测试、确认测试和系统测试。
开始是单元测试，集中对用源代码实现的每 一个程序单元进行测试，检查各个程序模块 是否正确地实现了规定的功能。
软件测试策略
组装测试把已测试过的模块组装起来，主要 对与设计相关的软件体系结构的构造进行测 试。
–（1）软件测试不能发现代码风格不统一的问题，而代 码审查则很容易做到； –（2）有经验的人可以一目十行地审查代码，很快就能 抓住一些Bug（主要是常见的Bug）。 开发小组在执行代码审查之前要制定“代码审查表”， 从编程规范中提取最重要的规则。 为了提高代码审查效率，检查者不必给每一个检查项填 写结论，凡是正确的就跳过去，仅仅记录缺陷就行了。
优点: 一次审查可发现多个错误，不必改一个测一个。
2、制做测试软件：Stub （存根）和 Driver（驱动） 软件的编写，属额外开支。模块高内聚可简化这 一过程。
代码审查通常在开发人员之间开展，用眼睛检查代码是 否符合编程规范。为什么有了软件测试，还要代码审查？
因为代码审查有一些独到的优点，可以弥补软件测试的 不足：
系统测试把已经经过确认的软件纳入实际运 行环境中，与其它系统成份组合在一起进行 测试。
单元测试 (Unit Testing)
单元测试又称模块测试，是针对软件设计 的最小单位 ─ 程序模块，进行正确性检验 的测试工作。其目的在于发现各模块内部 可能存在的各种差错。
单元测试的主要手段 ：
1、代码审查(code inspection) Walk-through: 例如 Lucent Technologies 的测
试策略，是由三人一组(包括 author, reader, 和 recorder)，逐行检查源代码。
Rehearsal：由人扮演computer，模拟执行情况
外部检查：打开、结束、关闭文件的操作；文 件和属性；I\O错误处理；输出拼写，等等。
2、局部数据结构：
数据说明(declaration)；初始化与缺省值的设 置；变量名拼写；数据类型的相容性；上\下溢出 及地址异常，等等。
3、重要的执行通路：
由于穷尽测试不可能，故通常针对最常见的错误 设计测试方案。较常见的错误有：
对基本执行路径和循环进行测试可以发现大 量的路径错误。
(4) 错误处理测试
出错的描述是否难以理解 出错的描述是否能够对错误定位 显示的错误与实际的错误是否相符 对错误条件的处理正确与否 在对错误进行处理之前，错误条件是否已经
引起系统的干预等
(5) 边界测试
注意数据流、控制流中刚好等于、大于或小 于确定的比较值时出错的可能性。对这些地 方要仔细地选择测试用例，认真加以测试。
单元测试需要从程序的内部结构出发设计 测试用例。多个模块可以平行地独立进行 单元测试。
1. 单元测试的内容
在单元测试时，测试者需要依据详细设计 说明书和源程序清单，了解该模块的I/O条 件和模块的逻辑结构，主要采用白盒测试 的测试用例，辅之以黑盒测试的测试用例 ，使之对任何合理的输入和不合理的输入 ，都能鉴别和响应。
如果对模块运行时间有要求的话，还要专门 进行关键路径测试，以确定最坏情况下和平 均意义下影响模块运行时间的因素。
ห้องสมุดไป่ตู้ 2. 单元测试的步骤
模块并不是一个独立的程序，在考虑测试 模块时，同时要考虑它和外界的联系，用 一些辅助模块去模拟与被测模块相联系的 其它模块。
驱动模块 (driver)
桩模块 (stub) ── 存根模块
如果一个模块要完成多种功能，可以将这个 模块看成由几个小程序组成。必须对其中的 每个小程序先进行单元测试要做的工作，对 关键模块还要做性能测试。
对支持某些标准规程的程序，更要着手进行 互联测试。有人把这种情况特别称为模块测 试，以区别单元测试。
主要测试以下五个方面：
1、模块接口：
内部检查：传输参数的数目、属性、单位、次 序是否匹配；全程变量的定义是否一致；只做输 入的变元有无被修改，等等。
(2) 局部数据结构测试
不正确或不一致的数据类型说明 使用尚未赋值或尚未初始化的变量 错误的初始值或错误的缺省值 变量名拼写错或书写错 不一致的数据类型 全局数据对模块的影响
(3) 路径测试
选择适当的测试用例，对模块中重要的执行 路径进行测试。
应当设计测试用例查找由于错误的计算、不 正确的比较或不正常的控制流而导致的错误 。
计算次序问题
不同类型混合运算（例：比较类型不同的量）
初值设置错误
精度问题（例：精度不够导致两变量不可能相等， 而程序中等待相等条件的出现）
表达式错误
循环终止条件错误(例：次数差1，或陷入死循环)
4、出错处理通路： 预见出现错误的条件，设置处理。较常见
的问题有： 输出的错误信息难以理解，不能确定错误位置 描述的错误与实际错误不符 处理之前系统已经干预 处理不正确
(1) 模块接口测试
在单元测试的开始，应对通过被测模块的数 据流进行测试。测试项目包括：
调用本模块的输入参数是否正确； 本模块调用子模块时输入给子模块的参数
是否正确； 全局量的定义在各模块中是否一致；
在做内外存交换时要考虑：
文件属性是否正确； OPEN与CLOSE语句是否正确； 缓冲区容量与记录长度是否匹配； 在进行读写操作之前是否打开了文件； 在结束文件处理时是否关闭了文件； 正文书写／输入错误， I／O错误是否检查并做了处理。
通常，把模块组装成为系统的方式有两种 一次性组装方式(big bang)
组装测试（Integrated Testing）
组装测试 (集成测试、联合测试）
通常，在单元测试的基础上，需要将所有模 块按照设计要求组装成为系统。如需要考虑 以下的问题：
✓一个模块的功能是否会对另一个模块的功 能产生不利的影响
✓各个子功能组合起来，能否达到预期要求 的父功能
组装测试（Integrated Testing）
软件测试策略 测试流程图
软件测试策略
测试过程按4个步骤进行，即单元测试、组装 测试、确认测试和系统测试。
开始是单元测试，集中对用源代码实现的每 一个程序单元进行测试，检查各个程序模块 是否正确地实现了规定的功能。
软件测试策略
组装测试把已测试过的模块组装起来，主要 对与设计相关的软件体系结构的构造进行测 试。
–（1）软件测试不能发现代码风格不统一的问题，而代 码审查则很容易做到； –（2）有经验的人可以一目十行地审查代码，很快就能 抓住一些Bug（主要是常见的Bug）。 开发小组在执行代码审查之前要制定“代码审查表”， 从编程规范中提取最重要的规则。 为了提高代码审查效率，检查者不必给每一个检查项填 写结论，凡是正确的就跳过去，仅仅记录缺陷就行了。
优点: 一次审查可发现多个错误，不必改一个测一个。
2、制做测试软件：Stub （存根）和 Driver（驱动） 软件的编写，属额外开支。模块高内聚可简化这 一过程。
代码审查通常在开发人员之间开展，用眼睛检查代码是 否符合编程规范。为什么有了软件测试，还要代码审查？
因为代码审查有一些独到的优点，可以弥补软件测试的 不足：