功能测试之经典思路---灰盒测试

 

一、灰盒测试概念

灰盒测试是一种基于黑盒测试和白盒测试之间的测试方法，是业务流程基础上关注系统模块（单位不固定模块是泛指可能是一个或几个类、一个job、一个功能模块、一个处理分支等等）之间如何交互运作的测试方法，灰盒测试既可保证黑盒的关注点又可掌控白盒的内部结构，但不会去对内部程序功能和运作做详细了解，灰盒测试结合了白盒测试和黑盒测试的要素。

二、黑盒测试、灰盒测试、白盒测试区别

1、  黑盒和灰盒的区别：

如果某软件包含多个模块，当你使用黑盒测试时，你只要关心整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，你就需要关心模块与模块之间的交互。这是灰盒测试与黑盒测试的区别。

2、  白盒和灰盒的区别：

在灰盒测试中，你还是无需关心模块内部的实现细节。对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试则不同，还需要再深入地了解内部 模块的实现细节和各个分支。所以，这是灰盒测试与黑盒测试的区别。

3、  单元测试和灰盒的区别：

首先，在进行单元测试时，需要写一些测试代码（行话叫“桩代码”，叫stub）。一般来说，测试代码与被测试代码采用同种语言（比如Java的单元测试通常也用Java来写），且测试代码和被测试代码之间的耦合很紧密。因此，单元测试通常由开发人员来完成的——测试人员的能力未必能胜任。

其次，单元测试的颗粒度会更细（会细到模块内部的类一级、函数一级），而灰盒测试仅仅到模块一级。

 

三、灰盒测试测试流程

1、  需求分析以及评审

首先需求评审产品需要提前发出需求，测试先过一遍把疑问记录下，测试过的过程中需要结合接口、UED界面、功能描述进行拉通。以便在讲解需求时能提出业务问题。

2、  开发控制流程图

需求评审后，开发需要输出控制流程图，此处说的控制流程图不是概设也不是详设，而是介于这两者之间的一种图形，也就是跟灰盒测试相对应的流程。最好带有简单的功能说明，开发输出的这份文档应该对系统有了一个分析过程，数据字典应该已经输出。

简单的业务说明：

1、  测试分析

在拿到产品的需求文档、UED以及接口文档，开发的控制流程图后可以进行详细的拉通评审工作，评审控制流程图的过程也是重新梳理需求的过程，此过程可以做到产品、开发、测试三方对软件的理解一致，对业务有疑问的地方可以跟产品确认，可以跟开发详细谈，这个过程就是真正做到尽可能早的测试以及返工导致的成本浪费。此时应该已经可以做到从系统整体到局部都有了解。

2、  测试案例以及场景输出

结合需求经过模块与模块交互的详细分析，此时可以设计测试案例了，案例设计具体我们把一个系统按照大的功能模块进行组划分；在同一个功能模块下又可区分为：页面测试、接口测试、业务/逻辑测试、场景测试、安全性测试，另外再梳理出联测案例；这样的区分主要是便于条理清晰以及模块复用，比如业务逻辑测试这个组下的案例经过开发控制流程的分析可能判断出在不同模块功能对它都是调用的相同类或对象，那此时这部分案例我只需要写一次在模块后面备注需要用到的模块即可，那不同模块对此部分的相同逻辑的案例只需要执行一次即可，为了保证整体功能的正确性此时场景案例和联测案例是需要在不同模块之间都需要测试的。

二级目录为功能模块名称：

三级目录为某个功能下的具体划分，此时的分类需要结合需求和控制流程图，总的原则是做到结构清晰：

 

1、  自动化或测试桩准备

灰盒测试要提高测试效率得想尽一切办法利用可以利用的测试工具来进行系统测试，如SouPUI发起http请求或者SOAP 使用 HTTP 传送 XML文件；也可以使用自动化工具发送MQ或htpp请求，当然如果会简单的编码这些LOADRUNNER都是可以搞定的，比如并非问题可以借助LR进行测试。如果存在加密方式还需要写简单的桩进行请求和返回处理。特别是系统功能内部测试时有了工具或测试桩可以大大提高测试效率。

2、  测试问题分析

这个步骤其实是很重要的，通过问题的问题分析统计可以了解软件质量、可以知道问题出现的阶段需求问题、开发问题、测试分析问题、测试漏测问题。问题分析基本都能反推出是软件流程的不足还是执行的不足。

问题分析主要分两部分：

6.1 每一轮问题的分析，做次过程分析的前提是测试流程已经比较规范，开发在每次修改bug试需要备注好出现问题说明可以贴错误代码在备注中，便于测试后期做分析统计工作。分析的维度基本就是轮次问题分析，问题的原因：需求问题、设计问题、编码问题、测试漏测问题。只需要统计出大概的问题范围即可。

6.2 生产问题的分析：对生产问题应该重点统计和分析，生产问题需要问题经手人进行回溯包括测试和开发，再由负责人进行汇总，可以组织问题归类学习。应该追溯到某个问题的具体原因，会漏到生产是哪个环节做得不好，需求问题、设计问题、测试漏测、还是沟通问题、软件流程问题。

3、  软件工程流程改进

一切分析度量都是为了下次避免出现类似问题，找到问题确定改进措施才能让我们的工作更高效、质量更好。对于生产问题可以做好归类学习。

一、灰盒测试好处

1、  白盒测试成本高

外聘成本太高、内部培养周期长。

2、  规范软件流程

强调了开发文档，也就是说开发过程有了系统设计的环节，便于返工浪费成本以及后期工作移交其他开发有文档可以参考。

3、  自动化提高测试效率

灰盒测试过程中引入自动化的设计，可以提高测试效率。

4、  缩短项目周期

对于白盒测试势必要花大量的时间进行结构测试和逻辑测试，但是在国内大多数对软件的体验性要求不是特别高的公司，灰盒测试既可以保证绝大部分功能质量又可以缩短开发周期，对于大大小小的项目都适合，特别是业务复杂的项目更是需要灰盒测试让测试人员从整体到局部对系统都有一个了解以便来保障软件质量。

二、测试是有策略和技术

在很多公司都认为测试是没有技术含量的，如果只是单纯地做做黑盒测试、根据需求文档进行测试，确实这样的测试既不能提前发现需求问题也无法验证出系统整体的结构性问题。灰盒测试对测试人员的要求会比黑盒高，起码是分析问题和解决问题的能力要更强，对业务能够做到从整体到局部全部贯通，从被动转为主动，融合测试驱动开发的方法。

 

2016-12-19