5.1 软件测试策略（上）在线视频

大家好

今天我们来分享软件测试策略

软件测试的目的

是将软件发布给最终用户之前

以发现错误为特定目的的运行程序的过程

测试要显示的内容包括哪些呢

测试我们要显示

我们在软件当中

犯下的一些错误

还有要测试我们的软件与需求是否一致

另外我们还需要测试我们的软件性能

是否达到了相关的要求

最后我们还要测试

这个软件的质量方面的一些指标

比如它的可靠性等等

我们的软件测试策略这个部分

主要讨论以下几个问题

第一个是策略性的方法

第二个是策略问题

第三个是针对传统的软件的测试策略

然后是针对面向对象的软件的测试策略

再有是对WebApp程序的测试策略

还有对于移动应用的测试策略

另外还有一些高级测试的概念

以及软件的调试

首先我们看一下策略性的方法

为了进行有效的测试

应该进行有效的技术评审

这样在测试开始之前

我们就能够消除很多错误

另外测试要开始于构件级

并向外扩展

面向整个基于计算机系统的集成测试

不同的测试技术

适合不同的软件工程方法

并且会在不同的时间节点上进行

测试是由软件的开发者进行

对于大型的软件项目

可能就需要有独立的测试团队来进行

测试和调试是不同的活动

但是调试必须要适应所有的测试策略

测试会涉及到两个问题

一个是验证

一个是确认

验证是指确保软件

正确实的实现了

特定的功能的任务集合

而确认是指

不同的任务集可以确保

已经构建了软件

可以追溯到客户提出的需求

那么我们可以另外一种方式来解释

确认和验证的问题

也就是说

验证我们是否正确的构造了产品

而确认是说

我们是否构造了正确的产品

这个就是验证与确认的区别

那么是由谁来测试软件呢

我们刚才说

可能是由开发人员来测试软件

也可能是由独立的测试人员来测试软件

那么 这两种人进行测试软件的时候

他们是有区别的

首先我们看一下

开发人员

他会使用“温和地”方法来进行测试

而且他可能会受到“移交”的驱动

也就是说

他可能会担心

我要在特定的时间节点上

一定把软件交付出去

所以开发人员的测试

可能是在“移交”的驱动下

不会测试得非常的全面和彻底

而我们独立的测试人员

那么他们虽然不了解这个系统

首先他要学习这个系统

但是他会想尽各种办法

来试图摧毁这个系统

也就是说

他会试图想尽各种办法

来挑出我们软件当中存在的错误

而且它是受到质量的驱动

那么大家可以看出这两种测试人员的区别是

开发人员他们了解这个系统

使用温和的方法去找到软件当中存在的错误

并且它会有

在特定时间要“移交”软件的压力

所以他的测试

不会那么全面

而我们的软件测试人员

他对系统不是很了解

所以他必须要先学习这个系统

然后想尽各种办法去发现

去挖掘我们软件当中存在的错误

因为他要交付质量可靠的测试过的产品

那我们的测试策略

根据我们软件工程的步骤

从系统工程到分析建模

到设计建模

到代码生成

而反过来

从代码生产开始

我们可以进行单元测试

集成测试

确认测试和系统测试

单元测试起始于图中螺旋的漩涡的中心

侧重于以源代码实现的每个单元

例如构件

或者是面向对象当中的类

或者是webapp中的内容对象

沿着螺旋向外就是集成测试

这时的测试重点

在于软件体系结构的设计和构建

沿着螺旋向外就是再走一圈

就是确认测试

在这个阶段

依据已经建立的软件

对需求进行确认

最后到达系统测试的阶段

将软件与系统的其他部分

作为一个整体来进行测试

为了测试计算机软件

沿着我们的曲线向外螺旋前进

每绕一圈

我们都拓宽了测试的范围

测试策略

我们的测试策略通常开始于'小范围测试'

然后才慢慢的转向'大范围测试'

对于传统的软件

我们的‘小范围测试’指的是

集中在模块上

构件上的测试

然后进行各个模块的集成测试

对于面向对象的软件

'小范围测试'通常是关注于单个模块

我们从

传统的转向面向对象的时候

我们关注的就是面向对象的类

类所封装了属性和操作

并意味着它们之间的通信和协作的测试

在测试开始之前的很长时间

我们就要以可计量

或者可量化的方法来确定产品的需求

明确的阐明测试的目标

了解软件的用户

并给出每一类用户的概况描述

然后制定我们的测试计划

强调“快速周期测试”

构造“健壮的”软件

并设计出能对自身进行测试的软件

另外的测试策略还有

我们要使用有效的技术评审

来作为测试之前的过滤器

这样我们可以过滤一些

不必要的错误

进行技术评审

对测试策略和测试用例的本身

也要进行评估

传统的软件测试

我们开始于单元测试

单元测试会让软件工程师

对被测试的模块

使用测试用例

输出测试结果

设计信息的评审

可以指导我们建设什么样的测试用例

每个测试用例

都应与一组预期的结果联系在一起

单元测试我们通常会测试被测试模块的接口

局部的数据结构

边界条件

独立路径

还有错误处理路径

我们通过设计测试用例来对这几个方面

分别进行测试

对穿越模块接口的数据流的测试

要在任何其他测试开始之前就要进行

如果数据不能正确的输入

或者是输出

则其他的测试都没有意义

测试局部数据结构

可能的话

在单元测试期间

确定对全局数据结构而产生的局部的影响

边界测试是最重要的单元测试任务之一

软件通常会在边界处容易发生错误

在允许出现的最大值

最小值的地方

使用刚好小于等于

或者是大于等于最大值或最小值的数据结构

另外控制流和数值作为测试用例

就有可能很好的发现这些错误

选择测试的执行路径是最基本的任务

设计测试用例

是为了发现因错误的计算

不正确的比较

或者不适当的控制流

而引起的错误

那么好的设计

要求能够预置出错的条件

并设置异常处理的路径

以便当错误确实出现时

重新确定路径或者彻底中断处理

这种方法叫做防错法

我们的单元测试

我们要为它构造出单元测试的环境

所以我们要为模块准备它的驱动模块

也就是要调用我们的被测试模块的模块

同时我们还要为我们的被测试模块准备桩模块

也就是我们被测试的模块

要去调用的那个模块就叫做桩模块

那我们通过驱动模块

和桩模块配合我们的被测试模块

进行测试

因为每个构件都不是单独的程序

因此需要为每个测试单元

开发驱动模块和桩模块

驱动程序只是一个主程序

它接受测试用例的数据

将这些数据传递给待测试的构件

并打印出相应的结果

桩程序的作用是替换那些

从属于被测试的构件

或者被调用的构件

桩程序或伪程序适应从属模块的接口

可能做少量的数据操作

提供入口的验证

并将控制返回给被测试模块

就达到了测试的目的

为什么要进行集成测试呢

我们以为

我们的单元测试每个模块都正确了

那我们把所有的模块集成在一起

就一定是正确的吗

不是这样的

数据可能在穿越接口时丢失

一个模块可能对另一个模块产生负面的影响

子功能联合在一起

并不一定能够达到预期的效果

单个模块中

可以接受的不精确性

在连接起来

可能这种不精确性

会被放大到无法接受的程度

全局数据结构

也可能会产生问题等等

这一系列问题

使得我们必须要进行集成测试

集成测试可以使用自顶向下的方法

也可以使用自底向上的方法

首先我们看自顶向下的集成方法

我们使用桩模块测试顶层模块

然后每次替换一个桩模块

可以采用“深度优先”的方法

逐层向下的替换桩模块

当新的模块被集成的时候

我们需要重新的运行某些测试子集

保证新的模块集成的时候

原来已经被测试的正确的部分

没有引入新的错误

模块集成顺序是从主控模块开始

沿着控制层次逐层向下

以深度优先或者广度优先的方式

将从属于

或者间接从属于主控模块的

集成到结构当中去

那么自底向上的集成方法呢

我们每次替换一个驱动模块

采用“深度优先”的方法

将可工作的模块组织在一起

并进行集成

我们会得到测试过的集群

然后再逐层向上的

替换我们的桩模块

除了自顶向下和自底向上的方法之外

我们还可以使用混合测试

使用桩程序来测试顶层模块

使用可工作的模块组织在一起

替换我们的驱动模块

形成我们的

被测试的驱动模块的集群

来测试和代替我们的驱动模块

这里边我们会使用到

一个叫做回归测试的概念

回归测试就是

重新运行已经进行过的测试子级

以确保变更没有引发非预期的副作用

每次对软件进行修改时

就改变了软件的配置的某些方面

比如说软件 文档

或者支持软件的数据等等

那么回归测试有助于确保我们的变更

由于测试或者其他原因引起的变更

不会引入非预期的行为

或者是增加新的错误

回归测试可以手动进行

通过重新运行一部分测试用例

或者是全部测试用例

那么回归测试也可以使用一些

自动的捕获

或者是回放的工具来进行

在测试中有一种冒烟测试

它是对产品软件进行

“每日构造”的一种常见的方法

冒烟测试的步骤是

已经被形成代码的软件构件

被集成到一个“build”

也就是一个构造当中

那么一个构造包括所有的数据文件

库和可重用的模块

以及工程化的构件

那么其中一个构件

需要实现一项或者多项产品的功能

那么冒烟测试的核心思想就是

我们对构造出来的构造

每日都进行对整个构造的一个测试

我们设计一系列的测试来揭示错误

使得此构造不能正确的执行其功能

目的就是要揭示显示阻塞的错误

这种错误

最有可能使软件项目滞后于

我们的开发进度和计划

将此构造与其他的构造集成在一起

每天都对整个产品

进行冒烟测试

集成测试可以是

刚才我们说的自顶向下的方法

也可以是自底向上的方法

在测试当中

我们会经常用到一些通用的测试标准

比如对接口的完整性进行测试

和功能确认进行测试

信息内容进行测试

以及对性能进行测试

接口完整性指的是

每当一个模块或多个模块（集群）

被加到软件中

我们都对内部和外部的接口进行测试

功能测试指的是

我们要测试发现软件当中的功能缺陷

信息测试指的是

测试局部数据的结构

或者全部数据结构中的错误

性能测试指的是

我们要测试我们软件指定的性能边界

好 下面我们看一下

面向对象的软件测试策略

面向对象的软件测试策略

跟传统的软件测试的策略

会有一些不同的地方

我们面向对象的测试

开始于评估分析模型

和设计模型的正确性和一致性

这一点是跟传统测试一样的

但我们的测试策略会有一些少量的改变

由于面向对象的封装

扩展了“单元”的概念

使得我们的单元测试的概念不同

在面向对象当中

单元测试指的是对类

和类所封装的属性

和操作进行测试

那么集成测试的重点

是在一个“线程”的使用当中

或使用的场景当中的上下文的类

来进行测试

我们可以使用传统的黑盒方法

来进行确认测试

我们的测试用例的设计

可以借鉴传统的测试方法

但也应该包括一些

面向对象特有的一些功能

我们可以借鉴我们的扩大测试范围的观点

我们可以认为

面向对象的分析和设计模型的评审

是特别有用的

因为相同的语义结构

例如

类 属性 操作 消息

出现在分析 设计和代码的层面上

因此在分析过程中

如果发现了类属性的定义中存在问题

可能会出现的问题

那么我们如果直到在设计

和代码的时候才去发现它

那么就会产生一些不必要的代价

或产生了一些副作用

那么面向对象的测试策略

我们对应着传统的测试策略方法

相应的看一下

面向对象的单元测试

等价于我们的类测试

包括类的操作

进行测试

和检查类的状态行为

这两个方面

我们可以应用三种不同的策略进行集成

我们可以基于线程的测试

来整合响应一个输入或者是一个事件

所需要的类的集合

我们可以基于使用来进行测试

我们整合的响应一个用例

所需要的所有的类的集合

我们还可以进行集群测试

也就是

整合展示一个协作

所需要的类集

借助于

试图发现协作当中的错误的测试用例

来测试我们的集群

通过检查CRC

也就是我们的

类 责任 协作

卡片

和对象关系模型所确定的

这些个协作的类簇

也就是说相互协作的一组类的集合

来进行集群测试