软件测试项目化教学实例ZW16

第一篇：软件测试项目化教学实例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：代码检视

检视效率=检视发现缺陷数检视和测试发现的总缺陷数 质量索引=试用期间发现的缺陷数开发期间发现的总缺陷数

第二篇：软件测试项目化教学实例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模型的测试过程体系必须被理解，同时结合前面单元测试过程、集成测试过程，读者应当对测试过程方面有一个比较全面的认识。有关全面介绍测试过程方面的内容可以参考笔者即将出版的《软件测试过程》一书。

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

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

第五篇：软件测试项目化教学实例ZW15

软件测试技术概论

第15章 设计测试

15.1设计测试概述

15.1.1什么是设计 15.1.2软件构架设计

1.软件构架视图

图15-1功能视图例子

图15-2代码视图例子

软件测试技术概论

图15-3开发视图例子

图15-4并发视图例子

软件测试技术概论

图15-5物理视图例子

2.场景

软件测试技术概论

15.1.3概要设计和详细设计

15.2设计的评审

15.2.1设计查检表

软件测试技术概论 6

软件测试技术概论

软件测试技术概论 8

软件测试技术概论

软件测试技术概论

软件测试技术概论

15.2.2构架设计评审方法

1.软件构架分析方法

图15-6 SAAM分析的活动及依赖关系

2.表面的软件构架分析方法

图15-7 ASSAM分析的活动和依赖关系

软件测试技术概论 3.构架均衡分析方法

15.2.3软件构架评价最佳工业实践

1.成本和受益 2.评价技术的分类

3.建议的最佳实践 4.建议总结

软件测试技术概论

15.3 SDL及相关测试

15.3.1 SDL介绍 15.3.2 SDL基本概念

1.系统 2.环境 3.功能块 4.信道 5.信号 6.信号路由 7.进程 8.过程 9.定时器 10.服务

15.3.3 SDL结构

软件测试技术概论

图15-8 SDL框架示意图

图15-9 SDL系统图

图15-10 SDL功能块图

软件测试技术概论

图15-11 SDL进程图（含服务）

图15-12 SDL服务图

软件测试技术概论

图15-13 SDL过程图

15.3.4 SDL测试

1.SDL Simulator

图15-14 Simulator界面

2.SDL Validator

软件测试技术概论

图15-15 SDL Validator界面

图15-16 SDL Validator统计信息

软件测试技术概论

图15-17 Navigator 3.TTCN

图15-18 TTCN-SDL测试关系

15.4本章小结

设计是一个承上启下的过程，它把抽象的用户需求转换成具体的可实现的系统结构，这是一个需要创意的过程，有人把它理解成一种艺术。正因为如此，这个过程也是最易于产生风险的过程。如何把握好设计的质量成为软件工程领域内的一项课题，本章在这方面做了一些探索，总结了业界在该领域的一些经验，提出从静态的评审到动态的测试等多种手段。

目前业界在构架设计评审方面使用最多的是基于场景的评审方法，最基本的方法是 18

软件测试技术概论

SAAM。在该方法的基础上可扩展出很多新的方法，例如本章中介绍的ASAAM以及ATAM。

SDL是一种基于结构化设计的设计描述语言，主要应用在嵌入式领域。目前关于SDL验证方面有许多可以应用的工具，包括Telelogic的Simulator、Validator以及ITEX。TTCN作为一种ITU-T推荐的协议一致性测试方法，可以和SDL进行无缝连接。因此，对于SDL设计的系统，使用TTCN作为测试描述语言是非常好的。