第一篇：软件测试项目化教学实例ZW7
软件测试技术概论
第7章 集成测试
7.1什么是集成测试
7.1.1集成测试与系统测试的区别 7.1.2集成测试关注的重点 7.1.3集成测试和开发的关系
图7-1系统结构图
图7-2软件结构图
7.1.4集成测试的层次
7.2集成测试策略
7.2.1大爆炸集成
1.目的 2.介绍 3.策略
软件测试技术概论
图7-3软件模块结构图
图7-4一次性组装示意图
软件测试技术概论 4.优点 5.缺点 6.适用范围
7.2.2自顶向下的集成
1.目的 2.介绍 3.策略
图7-5深度优先组装方式
图7-6广度优先组装方式 4 4.优点 5.缺点 6.适用范围
软件测试技术概论
7.2.3自底向上的集
1.目的 2.介绍 3.策略
图7-7自底向上集成示意图
软件测试技术概论 4.优点 5.缺点 6.适用范围
7.2.4三明治集成
1.目的 2.介绍 3.策略
图7-8三明治测试策略 6 4.优点 5.缺点 6.适用范围
软件测试技术概论
7.2.5修改过的三明治集成
1.目的 2.介绍 3.策略
图7-9修改后的三明治集成
软件测试技术概论 4.优点 5.缺点 6.适用范围
7.2.6基干集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.7分层集成
1.目的 2.介绍 3.策略
图7-10层次内集成
软件测试技术概论
7-11层间集成
图
软件测试技术概论 4.优点 5.缺点 6.使用范围
7.2.8基于功能的集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.9高频集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.10基于进度的集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围 10
软件测试技术概论
7.2.11基于风险的集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.12基于事件（消息）的集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.13基于使用的集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.14客户/服务器的集成
1.目的
软件测试技术概论 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.2.15分布式集成
1.目的 2.介绍 3.策略 4.优点 5.缺点 6.使用范围
7.3集成测试分析
7.3.1体系结构分析
软件测试技术概论
图7-12 系统依赖关系示意图
软件测试技术概论 7.3.2模块分析 7.3.3接口分析
1.接口的划分 2.接口的分类 3.接口数据分析
7.3.4风险分析 7.3.5可测试性分析 7.3.6集成测试策略分析 7.3.7常见的集成测试故障
7.4集成测试用例设计思路
7.4.1为系统运行设计用例 7.4.2为正向测试设计用例 7.4.3为逆向测试设计用例 7.4.4为满足特殊需求设计用例 7.4.5为高覆盖设计用例 7.4.6测试用例补充
软件测试技术概论
7.4.7注意事项
7.5集成测试过程
7.5.1计划阶段
1.时间安排 2.输入 3.入口条件 4.活动步骤 5.输出 6.出口条件
7.5.2设计阶段
1.时间安排 2.输入 3.入口条件 4.活动步骤 5.输出 6.出口条件
7.5.3实现阶段
1.时间安排 2.输入 3.入口条件 4.活动步骤 5.输出
软件测试技术概论 6.出口条件
7.5.4执行阶段
1.时间安排 2.输入 3.入口条件 4.活动步骤 5.输出 6.出口条件
7.6集成测试环境
图7-13集成测试环境示意图
软件测试技术概论
7.7集成测试工具介绍 7.8集成测试应坚持的原则 7.9本章小结
集成测试是一个由单元到系统的过渡性测试，由于其位置的特殊性，集成测试往往容易被忽视。对于集成测试的研究业界已经提供了很多的方法，并且很多著作都涉及到了这一方面的内容【2】【26】【126】【127】【128】。集成测试策略给出了进行集成测试的一个思路，最常见的集成测试策略有自底向上集成、自顶向下集成、三明治集成、基干集成等。对于面向对象系统使用较多的集成策略有基于线程的集成和基于使用的集成。一般来说，对于一个大的系统，其使用的集成策略往往会综合多种集成策略，策略的选择需要根据其逻辑层次特性和物理分布特性来考虑。
在进行集成分析时需要考虑整个系统的体系结构，包括系统层次关系和依赖关系；需要分析系统的模块，尤其是确定关键模块；需要进行接口分析，划分接口类型，根据不同的接口进行数据分析；需要进行风险分析，分析可能出现的技术风险、人员风险、物料仪器风险、管理风险和市场风险；需要进行可测试分析，以便提前为测试的实现做好准备；常见集成测试故障分析有助于我们进行测试数据的选择和故障预防。
集成测试用例设计类似于单元测试用例设计，可以从以下几个维度考虑：为系统运行起来而设计用例，为正向测试而设计用例，为逆向测试而设计用例，为满足特殊需求而设计用例，为高覆盖设计用例和测试用例补充。
从过程上看集成测试可以分为计划阶段、设计阶段、实现阶段和执行阶段4个阶段。其中计划阶段关注于测试对象范围、工作量、进度、资源、可能存在的风险等因素；设计阶段完成测试分析，包括结构分析、模块分析、接口分析、策略分析、环境分析等等；实现阶段主要完成用例设计，规程设计以及测试脚本；执行阶段完成对测试对象的测试执行工作，并输出测试报告和问题单。
第二篇：软件测试项目化教学实例ZW8
软件测试技术概论
第8章 系统测试
8.1系统测试概念 8.2系统测试方法
8.2.1功能测试
1.基本概念 2.分析方法 3.用例设计
8.2.2协议一致性测试
1.基本概念 2.分析技术
图8-1协议一致性测试过程
3.用例设计
软件测试技术概论
8.2.3性能测试
1.基本概念 2.分析技术 3.用例设计
8.2.4压力测试
1.基本概念 2.分析技术 3.用例设计
8.2.5容量测试
1.基本概念 2.分析方法 3.用例设计
8.2.6安全性测试
1.基本概念 2.分析方法 3.用例设计
8.2.7恢复性测试
1.基本概念 2.分析技术 3.用例设计
8.2.8备份测试
软件测试技术概论 1.基本概念 2.分析技术 3.用例设计
8.2.9 GUI测试
1.基本概念 2.分析技术 3.用例设计
8.2.10健壮性测试
1.基本概念 2.分析技术
软件测试技术概论
软件测试技术概论
3.用例设计
软件测试技术概论
8.2.11兼容性测试
1.基本概念 2.分析技术 3.用例设计
8.2.12可用性测试
1.基本概念 2.分析技术 3.用例设计
8.2.13可安装性测试
1.基本概念 2.分析技术
图8-2一般安装程序流程图
软件测试技术概论
图8-3对安装程序使用自动测试的流程图
软件测试技术概论
图8-4使用自动测试测试安装空间流程图
3.用例设计
8.2.14文档测试
1.基本概念 2.分析技术 3.用例设计
8.2.15在线帮助测试1.基本概念 2.分析技术 3.用例设计
8.2.16数据转换测试1.基本概念 2.分析技术 3.用例设计
8.3系统测试过程
软件测试技术概论
图8-5 PDCA循环
软件测试技术概论
图8-6系统测试过程
软件测试技术概论 8.3.1完成系统测试计划
1.决定系统测试类型 2.确定系统测试进度
软件测试技术概论
软件测试技术概论
3.组织系统测试小组 4.建立系统测试环境 5.安装系统测试工具
软件测试技术概论
8.3.2完成系统测试用例 8.3.3评审/审批系统测试计划
1.安排/进行评审 2.获得批准
8.3.4执行系统测试
1.回归测试
软件测试技术概论
2.执行新的系统测试 3.文档化系统缺陷
8.4本章小结
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它 16
软件测试技术概论
被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、压力测试、容量测试等。为了进行全面的系统验证，一般需要综合多种测试方法结合进行测试。具体测试内容的选择需要根据业务的特点、进度、成本和质量等多个维度进行考虑。在本章我们介绍了16种系统测试的方法，其实在实际系统测试过程中还有一些别的测试方法，有些方法我们将在第9章和第10章有所介绍，有些方法由于只适用于某些业务领域，因此在这里就不涉及了，还有一些测试基本可以融入到上面介绍的16种测试方法中，例如数据库测试可以在功能测试、性能测试、压力测试、容量测试等多个领域内分别进行。同时在上面介绍的多种系统测试方法中，彼此之间也并不是完全没有关联的，例如功能测试和协议测试经常会在一起进行，压力测试、容量测试以及性能测试也经常混合在一起进行。具体如何做需要根据实际来判断。
系统测试不是一个突发性的测试，必须经过一个从计划到实现的过程。本章介绍的基于PDCA模型的测试过程体系必须被理解，同时结合前面单元测试过程、集成测试过程，读者应当对测试过程方面有一个比较全面的认识。有关全面介绍测试过程方面的内容可以参考笔者即将出版的《软件测试过程》一书。
第三篇：软件测试项目化教学实例ZW16
软件测试技术概论
第16章 同行评审
16.1基本概念
软件测试技术概论
16.2同行评审的一般过程
图16-1 同行评审过程
软件测试技术概论 16.2.1计划阶段
1.分配角色和职责 2.进行计划活动 3.选择同行评审类型
软件测试技术概论
16.2.2实施被选择的同行评审过程 16.2.3同行评审过程度量 16.2.4同行评审的评审/审计
16.3走读
16.3.1过程目标 16.3.2特定的角色和职责 16.3.3输入 16.3.4入口标准 16.3.5过程 16.3.6出口标准 16.3.7输出
16.4技术评审
16.4.1过程目标 16.4.2特定的角色和职责 16.4.3输入
软件测试技术概论 16.4.4入口标准 16.4.5过程 16.4.6出口标准 16.4.7输出
16.5正规检视
16.5.1正规检视小组
1.成员角色和职责 2.角色兼职原则
16.5.2正规检视过程
图16-2正规检视流程定义
1.计划阶段 2.介绍会议 3.会议准备 4.检视会议 5.第 3小时会议 6.修改错误 7.问题跟踪 8.重新正规检视
软件测试技术概论
16.5.3正规检视常用表格
软件测试技术概论
软件测试技术概论
软件测试技术概论
软件测试技术概论
软件测试技术概论
软件测试技术概论
16.6本章小结
本章介绍了同行评审的概念以及同行评审的3种形式——走读、技术评审和正规检视。尽管同行评审可以适用于任何工作产品，可以在开发阶段的任何一个时间点进行，但是还有一个成本的问题。不同的同行评审类型，根据其过程的严格程度，其成本是不同的。走读形式最自由，因此需要的成本也最低；其次是技术评审。正规检视是成本最高的，因此它应当被用到最值得付出的产品项上。一般正规检视在需求，设计文档上面应用的比较多一些，而走读可以应用到各种产品项上（包括文档和代码）。技术评审一般是在阶段点上进行，以确认某个阶段的工作已经完成，并且达到一定的技术要求，可以进入到下一个阶段。
根据经验，在开发过程中可以按照下面的方法安排各类同行评审：
方法一在某个产品项（包括文档和代码）的开发过程中，可以进行多次走读，像在印度一些CMM5级的公司经常进行每日走读的方式，例如：在编码时，员工在一天8小时的工作中，把7个小时左右的时间放在编码上，再利用其余的1个小时进行交叉走读。这种方式是一个非常好的实践，能够有效地减少低级错误，并提高产品质量。
方法二在某个产品项已经完成（包括文档和代码），完成的概念是指已经经过多次走读，并且可以准备提交进入基线了。这时，对于一些关键性文档或代码进行一次或多次的正规检视，次数的多少需要看检视对象的规模大小。这个过程如果组织得好，是非常高效的。
方法三在一个开发阶段结束，并且目标里程碑中所包含的所有产品项（包括文档和代码）都已经完成，且都已经被基线化了。这时可以进行一个技术评审，该评审确认任务的完成情况和完成质量，并结束当前阶段，开始启动下一个阶段。
正规检视的次数安排不能太多，一般一个人一周最多只能参加1次正规检视，否则会导致人员疲惫，影响检视效率。同时检视的效率还与员工花在检视准备和执行上面的时间和工作量有关。例如，IBM发现当检视速率超过一定值时检视效率会成倍下降。适当的检视速率取决于被检视的产品的类型和参加检视人员的经验。对设计和代码检视来说，表 16-8显示了一些可用的检视速率的数据，从中我们可以看到，COBOL应用程序的检视速率是一般系统程序检视速率的6～8倍，是性能敏感系统程序的15倍。组织确定自己检视速率的最好的方式是收集自己的数据并得出适合自己的标准值。
软件测试技术概论
随着组织经验的积累，同行评审（尤其是正规检视）效率也越来越高。通过提高检视效率，组织能够在软件交付前发现大部分的错误（表 16-9给出了一个IBM统计的实例）。另一方面，检视所花费的时间也有很明显的变化：如1000行源代码所花费的时间增加了1.68倍（概要设计检视）和7.00倍（详细设计检视）。尽管在前期设计检视上面花费了额外的时间，但在代码检视阶段每千行源代码的检视时间却减少到原来的76%，而每小时检视发现的问题数更是增加到原来的3倍。这些改进一方面是由于产品程序员们对产品的了解更加深入所致，另一方面则是因为检视是一种可以学习的技能，可以通过经验的积累而得到明显的改善。
软件测试技术概论
其中：KCSI：千行变更的源指令 I0：概要设计检视 I1：详细设计检视 I2：代码检视
检视效率=检视发现缺陷数检视和测试发现的总缺陷数 质量索引=试用期间发现的缺陷数开发期间发现的总缺陷数
第四篇：软件测试项目化教学实例ZW10
软件测试技术概论
第10章 其他专项性测试
10.1可接受性测试 10.2 Alpha测试 10.3 Beta测试 10.4标杆测试 10.5配置测试
软件测试技术概论
软件测试技术概论 10.6外场测试 10.7 SQL测试 10.8 2000年测试
软件测试技术概论
10.9回归测试 10.10本章小结
本章介绍了一些特定的测试方法。这些方法可以作为前几章的补充或延伸。这里，并没有详细说明这些测试如何使用，仅做了一些简单的介绍。读者若感兴趣，可以参考相关文献。
第五篇：软件测试项目化教学实例ZW14
软件测试技术概论
第14章 需求测试
14.1需求测试概述
14.1.1什么是需求
1.需求的层次
图14-1软件需求各层次关系
2.FURPS+模型 3.可能的需求风险 4.好的需求应具有的特点
软件测试技术概论
14.1.2测试需求
14.2通过评审来测试需求
14.2.1需求评审中的常见风险 14.2.2需求评审检查表
软件测试技术概论 4
软件测试技术概论
软件测试技术概论 6
软件测试技术概论
软件测试技术概论 14.3通过用例设计来测试需求
图14-2化学制品请求对话图
软件测试技术概论
图14-3测试路径图
软件测试技术概论
14.4需求建模测试
14.4.1统一建模语言
1.Use Case图
软件测试技术概论 图14-4 Use Case图例
2.Use Case 测试
14.4.2消息顺序图（MSC）
图14-5 MSC图示例
软件测试技术概论
图14-6 HMSC示例
软件测试技术概论
14.4.3分析建模工具介绍
软件测试技术概论
14.4.4需求的形式化描述
图14-7需求的形式化表示样例
软件测试技术概论
14.5基于原型的测试
14.5.1原型的目的 14.5.2原型的种类 14.5.3原型的测试方法
14.6本章小结
需求是一个软件开发项目的灵魂所在，有着至关重要的位置。保证需求的质量是一个项目成败的关键。本章，我们从需求评审、用例测试、建模测试和原型测试等多个角度探索对需求的验证，其最终的目的是希望尽可能地使需求稳定，减少项目开发过程中的需求变化，从而加快项目的开发进度，降低项目的开发成本，提高最终软件产品的质量。收集需求并编写需求文档是软件项目设计成功的很好起点。但还需要保证需求的正确性，使需求能体现出良好需求说明的全部特性。如果能把早期的黑盒子测试设计、非正式需求评审、软件需求规格说明书检视和其他需求验证技术相结合，你将花比以前更少的时间、更低的费用来构造质量更高的系统。
点击咨询 