集成测试的思路

发表于:2010-06-17来源:作者:点击数: 标签:思路
集成测试的思路 软件测试 对于集成测试,初学者往往比较模糊,到底怎么测?是不是把两个模块连在一起,然后采用 单元测试 的技术,测试这个更大的模块? 我们都知道,集成测试关注的是模块之间的接口。那么可以将“接口”作为切入点。纵观模块之间的接口,我们

  集成测试的思路  软件测试

  对于集成测试,初学者往往比较模糊,到底怎么测?是不是把两个模块连在一起,然后采用单元测试的技术,测试这个更大的模块?

  我们都知道,集成测试关注的是模块之间的接口。那么可以将“接口”作为切入点。纵观模块之间的接口,我们可以归纳为以下几种类型,下面一一介绍一下。

  1、通信协议:两个模块之间通信采用的是标准的或者自定义的(网络)协议;

  协议中即包含数据部分,又包含控制部分;有些实现将数据与控制分离,如FTP;而大部分实现将数据与控制通过一条链路来传递,往往通过不同的消息包进行分离。

  2、调用关系:模块A调用模块B,实际上是由模块A向模块B发出了一条控制指令,这里数据传递体现的不是很明显,往往体现为参数与返回值,它们可以认为是控制的副本。

  3、文件、数据库、队列、第三方中间件等:表现的主要是数据的传递,其中的控制体现的不明显。

  4、共享资源:比如共享一段“存储区域”,其中涉及的关键资源主要是“锁”了;这样的两个模块在运行时往往分布到不同的进程或者线程中,表现为对资源的竞争,以及数据的共享。

  5、同步:一个模块的运行需要另外一个模块的触发,双方往往存在“信号”等通知机制,也可以理解为一种特殊的控制方式。

  OK,现在切入点有了,我们可以将被测系统归类(以上的分类),找出其中的数据接口与控制接口。

  接下来的做法与一般的测试思路没有什么不同。

  首先,将数据接口与控制接口分解——需要传递哪些数据?存在哪些控制指令?

  然后,找出数据与指令中的变数所在;如数据(协议包)中的字段的取值,指令的参数变化等;

  接下来,将变数划分等价类,找出每类的代表,就是我们的测试数据了——我们的目标是:让每类数据流与控制流均通过接口一次,从而实现接口测试的完全性;

  最后,就是考虑如何生成这些测试数据了。往往需要对应到集成后“大模块”的输入与输出。

  谈了很多,上面的内容更多的关注了实现。下面我们要考虑另外一个侧面——业务。

  模块之间的联系(接口)往往是为了体现业务上的关联。大家都知道,关联本身也是有很多属性的。如关联点(每个模块)都存在一个角色,关联有多重性(multiplicity)——即模块A在运行时可能对应多个模块B的实例。

  我们找到了测试的另外一个切入点,模块的集成能否准确体现业务上的关联?各个模块是否具备其角色的全部属性和接口,模块之间的关联关系如何打破?关联的多重性是否有效?

  当然,集成测试不会太关心业务或者需求,那是系统测试的事了。但此时想想,往往能够得到意外的收获。

  太多的关注功能,往往忽略其他。有时我们不得不考虑接口的性能,尤其对于系统关键接口。接口的性能测试越早进行越好。如果等到系统测试时做,可能接口外面封装了太多的代码,影响性能问题的精确定位。

原文转自:http://www.ltesting.net