软件测试与维护
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 结构化维护
结构化维护是一种依靠完整的软件配置 而进行的维护，其中的软件配置包括源 程序清单、维护计划以及软件工程过程 各阶段产生的文档。
软件测试过程
软件测试是贯穿于软件开发过程始终的一个活动， 由测试计划、单元测试、集成测试、系统测试、 验收测试组成。
一、测试计划：作为软件项目计划的子计划，在项 目启动初期就开始进行规划，在项目进行的各阶 段可以同步进行相应的测试计划的编制。
➢ 需求分析阶段开始编制系统测试和验收测试的计划 ➢ 系统设计阶段编制集成测试计划 ➢ 编码的同时编制单元测试计划
• 如输入百分制的成绩，输出等级制成绩。
录入数据>100
测试结果：无效成绩
录入数据<0
测试结果：无效成绩
0=<录入数据<60
测试结果：不及格
60=<录入数据<70
测试结果：及格
70=<录入数据<80
测试结果：中
Biblioteka Baidu
80=<录入数据<90
测试结果：良
90=<录入数据<＝100
测试结果：优
测试用例：102，－10，30，65，74，86，93
影响维护工作量的因素
• 在软件的维护过程中，需要花 费大量的工作量，从而直接影 响了软件维护的成本。
• 应当考虑有哪些因素影响软件 维护的工作量，相应应该采取 什么维护策略，才能有效地维 护软件并控制维护的成本。
• 系统大小：系统越大，理解掌握起来 越困难。系统越大，所执行功能越复 杂。因而需要更多的维护工作量。
面向对象测试
1、面向对象单元测试
• 此时的“单元”不再是程序模块的概念，而是以类为单位， 把操作作为类的一部分进行测试
2、面向对象集成测试
（1）基于线程的测试：把响应系统的一个事件所需要的一 组类集成为一个线程，分别集成并测试每个线程，同时进 行回归测试。
（2）基于使用的测试：先测试独立类，再按层次测试依赖 类，直到构造出整个系统。
Ass=MTTF/(MTTF+MTTR) MTTF为系统平均无故障时间， MTTR为系统平均维
修时间。
• 估算系统平均无故障时间及系统故障总数略。
▪ 软件维护的概念 ▪ 软件可维护性 ▪ 软件维护的实施 ▪ 对老化系统的维护 ▪ 逆向工程与再工程 ▪ 软件配置管理
软件维护的概念
• 软件维护的定义 • 影响维护工作量的因素 • 结构化维护与非结构化维
护 • 维护成本
软件维护的定义
• 在软件运行／维护阶段对软件 产品进行的修改就是所谓的维 护。
• 维护的类型有三种：
– 改正性维护 – 适应性维护 – 完善性维护
改正性维护
• 在软件交付使用后，因开发时测试的不 彻底、不完全，必然会有部分隐藏的错 误遗留到运行阶段。
• 这些隐藏下来的错误在某些特定的使用 环境下就会暴露出来。
➢ 利用已测试过的模块作为部分测试软件，减少测试工作量。 ➢ 能够较早发现模块间的接口错误。 ➢ 发生的错误往往和最近加进来的模块有关，便于错误诊断与定位。 ➢ 先加入系统的模块不断在新的条件下受到新的检测，对程序的测试更彻
底。
• 渐增组装测试的方法：自顶向下、自底向上。
➢ 自顶向下渐增组装测试：从主控模块开始，沿着软件的 控制层次向下移动，从而逐个地把各个模块集成到系统 中来。在这种方法中不需要“驱动模块”，需要“桩模 块”。
二、单元测试：依据详细设计说明书，测试某个模 块是否满足规定的功能，是整个软件测试过程中 最基本的活动。多采用白盒测试技术。
单元测试的主要任务： ➢ 模块接口测试 ➢ 局部数据结构测试 ➢ 路径测试 ➢ 错误处理测试 ➢ 边界测试
单元测试方法：单元测试通常在编码阶段进行，使用一些辅助模块去模拟 与被测模块相联系的其它模块。辅助模块主要有驱动模块和桩模块。
1、有效性测试：用黑盒测试法确定软件是 否满足需求规格说明书的要求。
2、软件配置复查：保证软件配置的所有成 分齐全，并已编排好分类的目录。
3、Alpha测试：在开发环境下由用户进行测 试，并作出全面的评价，开发者在场。
4、Beta测试：由用户在软件实际使用环境 下进行测试，开发者不在场。
5、测试结果确认，交付相应文档。
• 其它： – 应用的类型 – 数学模型 – 任务的难度 – 开关与标记、IF嵌套深度、索引或下 标数等 对维护工作量都有影响。
• 许多软件在开发时并未考虑将来的修改， 为软件的维护带来许多问题。
结构化维护与非结构化维护
• 非结构化维护 非结构化维护往往与早期的软件开发非 工程化有关，是软件开发过程中没有按 照软件工程原则实施软件开发留下的后 遗症。
• 程序设计语言：使用强功能的程序设 计语言可以控制程序的规模。语言的 功能越强，生成程序的模块化和结构 化程度越高，所需的指令数就越少， 程序的可读性越好。
• 系统年龄：
– 老系统随着不断的修改，结构越 来越乱；
– 维护人员经常更换，程序又变得 越来越难于理解。
– 许多老系统在当初并未按照软件 工程的要求进行开发，因而没有文 档，或文档太少。
2、白盒测试法：是基于程序的内部结构与处 理过程而进行的测试，又叫结构测试。白盒 测试的内容是程序的内部算法细节。
3、测试中的信息流：
软件测试用例设计
一、白盒测试用例设计
• 白盒测试用例设计主要采用的是逻辑覆盖，以程序内部逻辑 结构为依据的用例设计方法。包括语句覆盖、判断覆盖、条 件覆盖、判断－条件覆盖、条件组合覆盖、路径覆盖等。
完善性维护
• 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。
• 为了满足这些要求，需要修改或再开发 软件，以扩充软件功能、增强软件性能、 改进加工效率、提高软件的可维护性。
• 这种情况下进行的维护活动叫做完善性 维护。
• 实践表明，在几种维护活动中，完善 性维护所占的比重最大。即大部分维 护工作是改变和加强软件，而不是纠 错。
二、调试策略
1、试探法：猜测故障可能的大致位置进行试探，以获得程序错误的准 确定位。
2、回溯法：确定最先发现错误的位置，沿程序控制流程往回追踪源程 序代码，找出程序错误的准确位置。
3、对分查找法：与二分查找排序算法一致。 4、归纳法：以程序的错误征兆为线索，分析这些线索之间的关系，找
出故障。 5、演绎法：先列出所有可能成立的原因或假设，逐个排除。
3、面向对象确认测试
• 测试的主要内容是用户可见的动作和用户可识别的输出， 不需考虑类的构造及类之间的联系。
软件调试
• 软件调试也叫排错，涉及两个步骤：
1、诊断：确定错误的位置和性质。 2、排错：修改程序，改正错误。
一、调试方法
1、输出存储器内容。 2、在程序中插入输入输出语句。 3、使用自动调试工具。
的程度。
非渐增组装测试：先完成单元模块的确认测试，然 后将所有模块按设计要求组合成系统，再进行测试。
测试过程中发现的问题断定出错的位置和出错的原因。
渐增组装测试：把所有需要集成到系统中的模块按 照一定的次序，逐个集成到系统中去，并在进行模 块间协作性测试的同时对模块的功能进行确认测试。
• 渐增组装测试的优点：
软件测试的基本概念 软件测试过程 软件测试用例设计 面向对象测试 软件调试 自动测试工具 软件可靠性评估
软件测试目标
软件测试的目标就是发现软件中隐藏的错误。 由于对软件测试的目标存在一些错误认识和做法， G.Myers给出了关于软件测试目标的一些规则说明： (1) 测试是程序的执行过程，目的在于发现错误； (2) 一个好的测试用例在于能发现至今未发现的错误； (3) 一个成功的测试是发现了至今未发现的错误的测试。 组织专门的测试小组时，程序的编写者不适合对自己编写 的程序进行确认测试（程序调试除外）。
• 完善性维护不一定是救火式的紧急维 修，而可以是有计划、有预谋的一种 再开发活动。
• 事实证明，来自用户要求扩充、加强 软件功能、性能的维护活动约占整个 维护工作的50％。
• 在整个软件维护阶段所花费的全部工作量中， 完善性维护占了几乎一半的工作量。
• 软件维护活动所花费的工作占整个生存期工 作量的70%以上，这是由于在漫长的软件运 行过程中需要不断对软件进行修改，以改正 新发现的错误、适应新的环境和用户新的要 求，这些修改需要花费很多精力和时间，而 且有时会引入新的错误。
自动测试工具
• 常见的自动测试工具：
1、测试数据生成程序 2、动态分析程序 3、静态分析程序 4、模块测试程序 5、集成环境测试
软件可靠性评估
一、可靠性概念 1、软件可靠性：在给定的时间间隔内，程序按
照规格说明书成功运行的概率。 2、软件可用性：在给定的时间点，程序按照规
格说明书成功运行的概率。 • 一般使用稳态可用性对系统进行评估：
• 为了识别和纠正软件错误、改正软件性 能上的缺陷、排除实施中的误使用，应 当进行的诊断和改正错误的过程就叫做 改正性维护。
适应性维护
• 在使用过程中，
– 外部环境（新的硬、软件配置） – 数据环境（数据库、数据格式、数据
输入/输出方式、数据存储介质） 可能发生变化。
• 为使软件适应这种变化，而去修改 软件的过程就叫做适应性维护。
1、语句覆盖：被测程序中每个语句至少执行一次。
测试用例：a=2,b=0,x=4 执行路径：1-2-3-4-5-6-7
2、判定覆盖：不仅被测程序中每个语句至少执行一次，而且每 个判定的每种可能的结果至少执行一次。
测试用例：
a=3,b=0,x=4 执行路径：1-2-3-4-5-6-7 判断式：T，F a=2,b=1,x=1 执行路径：1-2-4-6-7 判断式：F，T
2、边界类分析：在边界处设计专门的 测试用例，用于验证程序运行在边界时 是否发生错误。
• 如根据上例可设计测试用例为：
－1，0，59，60，69，70，79，80，89，90，100， 101
3、错误推测：测试人员凭借测试经验 和直觉，例举出程序中可能有的错误和 容易发生错误的特殊情况来选择测试用 例。
3、条件覆盖：不仅被测程序中每个语句至少执行一次，而且判 定表达式中的每个条件都取到各种可能的结果。
用例：
a=2,b=0,x=4 执行路径：1-2-3-4-5-6-7 条件式：T，T，T，T a=1,b=1,x=1 执行路径：1-2-4-5-6-7 条件式：F，F，F，F
二、黑盒测试用例设计
1、等价类划分：把所有可能的输入数据划分出若干 个等价类，每个等价类中的一个典型值在测试过程 中与该等价类中所有的其它值的作用相同。
– 在长期的维护过程中文档在许多 地方与程序实现变得不一致，在维 护时就会遇到很大困难。
• 数据库技术的应用：使用数据库， 可以简单而有效地管理和存储用户 程序中的数据，还可以减少生成用 户报表应用软件的维护工作量。
• 先进的软件开发技术：在软件开发 时，若使用能使软件结构比较稳定 的分析与设计技术，及程序设计技 术，如面向对象技术、复用技术等， 可减少大量的工作量。
五、测试方法
• 软件测试最基本的方法是黑盒测试法和白盒 测试法。
1、黑盒测试法：是基于程序外部功能规格而 进行的测试，又叫功能测试法。将待测试的 模块当作一个黑盒子，只对模块接口处的输 入输出数据进行测试。
黑盒测试一般以程序模块为单位进行，适合于 对程序模块的确认测试，系统集成测试和用 户验收测试。
（1）驱动模块：相当于调用被测模块的主程序。 （2）桩模块：用来代替被测模块需要调用的子模块。
三、集成测试：在单元测试的基础上， 承担对系统进行组装与检测的双重任务， 是软件测试活动中最重要的部分。主要 有非渐增组装测试和渐增组装测试两种 方法。
具体测试任务
➢ 连接各模块时，穿越模块接口的数据是否会丢失。 ➢ 一个模块的功能是否对另一个模块的功能产生不利影响。 ➢ 各子模块组合起来，能否达到预期的协作功能。 ➢ 全局数据结构是否有问题。 ➢ 单个模块的计算误差积累起来，是否会放大进而达到不能接受
➢ 自底向上渐增组装测试：从软件结构的最底层模块开始 组装。在这种方法中不需要“桩模块”，需要“驱动模 块”
集成测试结束标准：
➢ 成功执行了测试计划中规定的所有集成测试
➢ 修正了所发现的错误，并成功地进行了再次测试。
➢ 所有集成测试文档齐全。
➢ 测试结果通过了专门小组的评审。
四、确认测试
• 确认测试又叫有效性测试或验收测试。任务是按照 软件需求规格说明书的要求，验证软件的功能、性 能以及其它特性等是否与用户的要求保持一致，并 得到用户确认。
结构化维护是一种依靠完整的软件配置 而进行的维护，其中的软件配置包括源 程序清单、维护计划以及软件工程过程 各阶段产生的文档。
软件测试过程
软件测试是贯穿于软件开发过程始终的一个活动， 由测试计划、单元测试、集成测试、系统测试、 验收测试组成。
一、测试计划：作为软件项目计划的子计划，在项 目启动初期就开始进行规划，在项目进行的各阶 段可以同步进行相应的测试计划的编制。
➢ 需求分析阶段开始编制系统测试和验收测试的计划 ➢ 系统设计阶段编制集成测试计划 ➢ 编码的同时编制单元测试计划
• 如输入百分制的成绩，输出等级制成绩。
录入数据>100
测试结果：无效成绩
录入数据<0
测试结果：无效成绩
0=<录入数据<60
测试结果：不及格
60=<录入数据<70
测试结果：及格
70=<录入数据<80
测试结果：中
Biblioteka Baidu
80=<录入数据<90
测试结果：良
90=<录入数据<＝100
测试结果：优
测试用例：102，－10，30，65，74，86，93
影响维护工作量的因素
• 在软件的维护过程中，需要花 费大量的工作量，从而直接影 响了软件维护的成本。
• 应当考虑有哪些因素影响软件 维护的工作量，相应应该采取 什么维护策略，才能有效地维 护软件并控制维护的成本。
• 系统大小：系统越大，理解掌握起来 越困难。系统越大，所执行功能越复 杂。因而需要更多的维护工作量。
面向对象测试
1、面向对象单元测试
• 此时的“单元”不再是程序模块的概念，而是以类为单位， 把操作作为类的一部分进行测试
2、面向对象集成测试
（1）基于线程的测试：把响应系统的一个事件所需要的一 组类集成为一个线程，分别集成并测试每个线程，同时进 行回归测试。
（2）基于使用的测试：先测试独立类，再按层次测试依赖 类，直到构造出整个系统。
Ass=MTTF/(MTTF+MTTR) MTTF为系统平均无故障时间， MTTR为系统平均维
修时间。
• 估算系统平均无故障时间及系统故障总数略。
▪ 软件维护的概念 ▪ 软件可维护性 ▪ 软件维护的实施 ▪ 对老化系统的维护 ▪ 逆向工程与再工程 ▪ 软件配置管理
软件维护的概念
• 软件维护的定义 • 影响维护工作量的因素 • 结构化维护与非结构化维
护 • 维护成本
软件维护的定义
• 在软件运行／维护阶段对软件 产品进行的修改就是所谓的维 护。
• 维护的类型有三种：
– 改正性维护 – 适应性维护 – 完善性维护
改正性维护
• 在软件交付使用后，因开发时测试的不 彻底、不完全，必然会有部分隐藏的错 误遗留到运行阶段。
• 这些隐藏下来的错误在某些特定的使用 环境下就会暴露出来。
➢ 利用已测试过的模块作为部分测试软件，减少测试工作量。 ➢ 能够较早发现模块间的接口错误。 ➢ 发生的错误往往和最近加进来的模块有关，便于错误诊断与定位。 ➢ 先加入系统的模块不断在新的条件下受到新的检测，对程序的测试更彻
底。
• 渐增组装测试的方法：自顶向下、自底向上。
➢ 自顶向下渐增组装测试：从主控模块开始，沿着软件的 控制层次向下移动，从而逐个地把各个模块集成到系统 中来。在这种方法中不需要“驱动模块”，需要“桩模 块”。
二、单元测试：依据详细设计说明书，测试某个模 块是否满足规定的功能，是整个软件测试过程中 最基本的活动。多采用白盒测试技术。
单元测试的主要任务： ➢ 模块接口测试 ➢ 局部数据结构测试 ➢ 路径测试 ➢ 错误处理测试 ➢ 边界测试
单元测试方法：单元测试通常在编码阶段进行，使用一些辅助模块去模拟 与被测模块相联系的其它模块。辅助模块主要有驱动模块和桩模块。
1、有效性测试：用黑盒测试法确定软件是 否满足需求规格说明书的要求。
2、软件配置复查：保证软件配置的所有成 分齐全，并已编排好分类的目录。
3、Alpha测试：在开发环境下由用户进行测 试，并作出全面的评价，开发者在场。
4、Beta测试：由用户在软件实际使用环境 下进行测试，开发者不在场。
5、测试结果确认，交付相应文档。
• 其它： – 应用的类型 – 数学模型 – 任务的难度 – 开关与标记、IF嵌套深度、索引或下 标数等 对维护工作量都有影响。
• 许多软件在开发时并未考虑将来的修改， 为软件的维护带来许多问题。
结构化维护与非结构化维护
• 非结构化维护 非结构化维护往往与早期的软件开发非 工程化有关，是软件开发过程中没有按 照软件工程原则实施软件开发留下的后 遗症。
• 程序设计语言：使用强功能的程序设 计语言可以控制程序的规模。语言的 功能越强，生成程序的模块化和结构 化程度越高，所需的指令数就越少， 程序的可读性越好。
• 系统年龄：
– 老系统随着不断的修改，结构越 来越乱；
– 维护人员经常更换，程序又变得 越来越难于理解。
– 许多老系统在当初并未按照软件 工程的要求进行开发，因而没有文 档，或文档太少。
2、白盒测试法：是基于程序的内部结构与处 理过程而进行的测试，又叫结构测试。白盒 测试的内容是程序的内部算法细节。
3、测试中的信息流：
软件测试用例设计
一、白盒测试用例设计
• 白盒测试用例设计主要采用的是逻辑覆盖，以程序内部逻辑 结构为依据的用例设计方法。包括语句覆盖、判断覆盖、条 件覆盖、判断－条件覆盖、条件组合覆盖、路径覆盖等。
完善性维护
• 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。
• 为了满足这些要求，需要修改或再开发 软件，以扩充软件功能、增强软件性能、 改进加工效率、提高软件的可维护性。
• 这种情况下进行的维护活动叫做完善性 维护。
• 实践表明，在几种维护活动中，完善 性维护所占的比重最大。即大部分维 护工作是改变和加强软件，而不是纠 错。
二、调试策略
1、试探法：猜测故障可能的大致位置进行试探，以获得程序错误的准 确定位。
2、回溯法：确定最先发现错误的位置，沿程序控制流程往回追踪源程 序代码，找出程序错误的准确位置。
3、对分查找法：与二分查找排序算法一致。 4、归纳法：以程序的错误征兆为线索，分析这些线索之间的关系，找
出故障。 5、演绎法：先列出所有可能成立的原因或假设，逐个排除。
3、面向对象确认测试
• 测试的主要内容是用户可见的动作和用户可识别的输出， 不需考虑类的构造及类之间的联系。
软件调试
• 软件调试也叫排错，涉及两个步骤：
1、诊断：确定错误的位置和性质。 2、排错：修改程序，改正错误。
一、调试方法
1、输出存储器内容。 2、在程序中插入输入输出语句。 3、使用自动调试工具。
的程度。
非渐增组装测试：先完成单元模块的确认测试，然 后将所有模块按设计要求组合成系统，再进行测试。
测试过程中发现的问题断定出错的位置和出错的原因。
渐增组装测试：把所有需要集成到系统中的模块按 照一定的次序，逐个集成到系统中去，并在进行模 块间协作性测试的同时对模块的功能进行确认测试。
• 渐增组装测试的优点：
软件测试的基本概念 软件测试过程 软件测试用例设计 面向对象测试 软件调试 自动测试工具 软件可靠性评估
软件测试目标
软件测试的目标就是发现软件中隐藏的错误。 由于对软件测试的目标存在一些错误认识和做法， G.Myers给出了关于软件测试目标的一些规则说明： (1) 测试是程序的执行过程，目的在于发现错误； (2) 一个好的测试用例在于能发现至今未发现的错误； (3) 一个成功的测试是发现了至今未发现的错误的测试。 组织专门的测试小组时，程序的编写者不适合对自己编写 的程序进行确认测试（程序调试除外）。
• 完善性维护不一定是救火式的紧急维 修，而可以是有计划、有预谋的一种 再开发活动。
• 事实证明，来自用户要求扩充、加强 软件功能、性能的维护活动约占整个 维护工作的50％。
• 在整个软件维护阶段所花费的全部工作量中， 完善性维护占了几乎一半的工作量。
• 软件维护活动所花费的工作占整个生存期工 作量的70%以上，这是由于在漫长的软件运 行过程中需要不断对软件进行修改，以改正 新发现的错误、适应新的环境和用户新的要 求，这些修改需要花费很多精力和时间，而 且有时会引入新的错误。
自动测试工具
• 常见的自动测试工具：
1、测试数据生成程序 2、动态分析程序 3、静态分析程序 4、模块测试程序 5、集成环境测试
软件可靠性评估
一、可靠性概念 1、软件可靠性：在给定的时间间隔内，程序按
照规格说明书成功运行的概率。 2、软件可用性：在给定的时间点，程序按照规
格说明书成功运行的概率。 • 一般使用稳态可用性对系统进行评估：
• 为了识别和纠正软件错误、改正软件性 能上的缺陷、排除实施中的误使用，应 当进行的诊断和改正错误的过程就叫做 改正性维护。
适应性维护
• 在使用过程中，
– 外部环境（新的硬、软件配置） – 数据环境（数据库、数据格式、数据
输入/输出方式、数据存储介质） 可能发生变化。
• 为使软件适应这种变化，而去修改 软件的过程就叫做适应性维护。
1、语句覆盖：被测程序中每个语句至少执行一次。
测试用例：a=2,b=0,x=4 执行路径：1-2-3-4-5-6-7
2、判定覆盖：不仅被测程序中每个语句至少执行一次，而且每 个判定的每种可能的结果至少执行一次。
测试用例：
a=3,b=0,x=4 执行路径：1-2-3-4-5-6-7 判断式：T，F a=2,b=1,x=1 执行路径：1-2-4-6-7 判断式：F，T
2、边界类分析：在边界处设计专门的 测试用例，用于验证程序运行在边界时 是否发生错误。
• 如根据上例可设计测试用例为：
－1，0，59，60，69，70，79，80，89，90，100， 101
3、错误推测：测试人员凭借测试经验 和直觉，例举出程序中可能有的错误和 容易发生错误的特殊情况来选择测试用 例。
3、条件覆盖：不仅被测程序中每个语句至少执行一次，而且判 定表达式中的每个条件都取到各种可能的结果。
用例：
a=2,b=0,x=4 执行路径：1-2-3-4-5-6-7 条件式：T，T，T，T a=1,b=1,x=1 执行路径：1-2-4-5-6-7 条件式：F，F，F，F
二、黑盒测试用例设计
1、等价类划分：把所有可能的输入数据划分出若干 个等价类，每个等价类中的一个典型值在测试过程 中与该等价类中所有的其它值的作用相同。
– 在长期的维护过程中文档在许多 地方与程序实现变得不一致，在维 护时就会遇到很大困难。
• 数据库技术的应用：使用数据库， 可以简单而有效地管理和存储用户 程序中的数据，还可以减少生成用 户报表应用软件的维护工作量。
• 先进的软件开发技术：在软件开发 时，若使用能使软件结构比较稳定 的分析与设计技术，及程序设计技 术，如面向对象技术、复用技术等， 可减少大量的工作量。
五、测试方法
• 软件测试最基本的方法是黑盒测试法和白盒 测试法。
1、黑盒测试法：是基于程序外部功能规格而 进行的测试，又叫功能测试法。将待测试的 模块当作一个黑盒子，只对模块接口处的输 入输出数据进行测试。
黑盒测试一般以程序模块为单位进行，适合于 对程序模块的确认测试，系统集成测试和用 户验收测试。
（1）驱动模块：相当于调用被测模块的主程序。 （2）桩模块：用来代替被测模块需要调用的子模块。
三、集成测试：在单元测试的基础上， 承担对系统进行组装与检测的双重任务， 是软件测试活动中最重要的部分。主要 有非渐增组装测试和渐增组装测试两种 方法。
具体测试任务
➢ 连接各模块时，穿越模块接口的数据是否会丢失。 ➢ 一个模块的功能是否对另一个模块的功能产生不利影响。 ➢ 各子模块组合起来，能否达到预期的协作功能。 ➢ 全局数据结构是否有问题。 ➢ 单个模块的计算误差积累起来，是否会放大进而达到不能接受
➢ 自底向上渐增组装测试：从软件结构的最底层模块开始 组装。在这种方法中不需要“桩模块”，需要“驱动模 块”
集成测试结束标准：
➢ 成功执行了测试计划中规定的所有集成测试
➢ 修正了所发现的错误，并成功地进行了再次测试。
➢ 所有集成测试文档齐全。
➢ 测试结果通过了专门小组的评审。
四、确认测试
• 确认测试又叫有效性测试或验收测试。任务是按照 软件需求规格说明书的要求，验证软件的功能、性 能以及其它特性等是否与用户的要求保持一致，并 得到用户确认。