软件测试项目化教学实例ZW6[5篇材料]

第一篇：软件测试项目化教学实例ZW6

软件测试技术概论

第6章 单元测试

6.1什么是单元测试

6.1.1单元测试的目的

6.1.2单元测试和集成测试的区别 6.1.3单元测试和系统测试的区别

6.2为什么要进行单元测试

图6-1各种测试的时间效率

软件测试技术概论

6.3单元测试环境

图6-2单元测试环境

6.4单元测试策略

6.4.1【策略一】由顶向下的单元测试策略 6.4.2 【策略二】由低到上的单元测试策略 6.4.3【策略三】孤立测试 6.4.4综合测试

6.5单元测试分析

图6-3单元测试的5个分析角度

软件测试技术概论 6.5.1模块接口 6.5.2局部数据结构 6.5.3独立路径 6.5.4出错处理 6.5.5边界条件

6.6单元测试用例设计思路

6.6.1为系统运行设计用例 6.6.2为正向测试设计用例 6.6.3为逆向测试设计用例 6.6.4为满足特殊需求设计用例 6.6.5为代码覆盖设计用例 6.6.6为覆盖率指标完成设计用例

6.7单元测试过程

软件测试技术概论

图6-4单元测试阶段主要数据流图

软件测试技术概论 6.7.1完成测试计划

1.计划总的方法、资源和进度 2.确定被测特性 3.优化总的计划

6.7.2获取测试集

1.设计测试集

2.完成改进的计划和设计

6.7.3度量测试单元

1.执行测试规程 2.检查结束条件 3.评价测试工作和单元

6.8单元测试工具介绍 6.9单元测试应坚持的原则 6.10我们的问题 6.11本章小结

单元测试属于白盒测试范畴，是所有动态测试中粒度最小的测试，也是验证活动中的基础活动。一般的单元执行策略有3种：

由顶向下进行单元测试，该方法可以省去驱动模块的设计； 由底向上进行单元测试，该方法可以省去桩模块的设计；

独立的单元测试，及不与任何模块发生关系，所有需要用到的其他单元都做桩模块，6 驱动模块也自己设计。

软件测试技术概论

方法1 和2 综合了集成的概念，随着单元测试的进行，可以看到系统一个初步集成的概貌。但是覆盖率会越来越难以保证，并且在每个单元测试之前必须保证相关单元的正确性。方法3 比较独立，覆盖率容易保证，并且可以并行进行，但工作量最大。一般采用混合方法比较好。在对一个单元进行分析时，可以从5个角度进行考虑：模块接口、局部数据结构、独立路径、出错处理和边界条件。根据这些分析，可以应用第5章中提到的测试分析方法来产生测试数据。一般常用的用例设计方法包括：规范导出法、等价类划分、边界值分析、数据流分析、错误猜测，根据覆盖率进行设计、因果图和判定表等。

单元测试是有一个过程的，并且该过程绝对不是在代码完成之后开始的。单元测试最早开始的时间可以追溯到设计阶段。一般一个单元测试过程可以划分为计划阶段、设计阶段和执行总结阶段。在有些文档中把执行阶段和总结阶段分开了，也有一些文档把设计阶段划分为用例设计阶段和脚本实现阶段。单元测试计划阶段和设计阶段是一个很重要的阶段，国内很多软件公司都不是很重视这个阶段。这两个阶段直接决定了单元测试的质量。从经验来看，单元测试执行和总结阶段基本和编码阶段时间差不多或略有减少，但是单元测试计划阶段和设计阶段将占整个单元测试过程的60％～70％左右的时间。

第二篇：软件测试项目化教学实例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本章小结

需求是一个软件开发项目的灵魂所在，有着至关重要的位置。保证需求的质量是一个项目成败的关键。本章，我们从需求评审、用例测试、建模测试和原型测试等多个角度探索对需求的验证，其最终的目的是希望尽可能地使需求稳定，减少项目开发过程中的需求变化，从而加快项目的开发进度，降低项目的开发成本，提高最终软件产品的质量。收集需求并编写需求文档是软件项目设计成功的很好起点。但还需要保证需求的正确性，使需求能体现出良好需求说明的全部特性。如果能把早期的黑盒子测试设计、非正式需求评审、软件需求规格说明书检视和其他需求验证技术相结合，你将花比以前更少的时间、更低的费用来构造质量更高的系统。