在一家软件公司里，几乎所有的部门都跟质量保障部（简称质保部）打过交道，大家对测试也都或多或少有所了解。角度不同、理解不同，质保部的工作可不仅仅是找BUG，发布产品这么简单，实际上，质保部的核心理念是与各开发或项目部门协作，确保并提高软件的质量。这其中，拓尔思质保部进行了一系列尝试与探索。

在质保部所有的工作中，包含了两大块内容：功能测试与性能测试。大家可以回忆一下，产品完成了，项目上线了，是不是经常会找质保来检查质量？质保部也有机会接触到公司的各种新产品，甚至奔赴全国各地。但是，大家注意一下就会发现，质保部介入的时间都是什么时候？末期！一般来说，末期这个词意味着效率要高，也意味着风险也高。在长期的合作过程中，拓尔思质保部发现，也许更早的协作、更早的介入可能更好。正如一个楼盘的建设，打地基时就让质监部门检查是很重要的，房子盖完了，查出有问题，损失可就大了。

提起协作，总需要一个方向，甚至还需要理论支撑，因为这个工作还需要传承下去。为此拓尔思质保部在循序的工作中，总结出一套具有拓尔思特色的协作方法，切入点正是一种新的测试理念：灰盒测试。

提起测试，有的同事会说：了解，不就是黑盒测试与白盒测试吗。没错！按照测试无数分类标准中的一种，这么分没错的，前者正如其名，不关心测试代码，从功能上（其实更多的时候就是从界面开始）来进行测试，一个常见的场景是这样的，“某人在TRS IDS注册用户提交时，弹出一个JS错误框，怎么办？”这时候，这个人可能要自己用一下、查一下、改一下，然后测试者过一下，就这样，这种测试直观、快捷，缺点是太直观以至于看不到暗处，太快捷以至于只能后期介入，界面变了、时间晚了，都会对整个过程造成影响。

白盒测试，是能看见盒子里面的代码，实际上我们很多部门已经在开展的单元测试就是白盒测试的一种。一种常见的场景是：“王工，TRS EKP的注册方法出现了问题，空名提交没有返回错误！”白盒测试的好处是定位准确，坏处是成本高难度大。实际上，在软件测试的课程中，大家觉得最难的就是白盒测试的方法，左路径右覆盖，非一日之功所能拈来。另一个问题就是，开发与测试的任务协调问题，这种模式要求测试承担一部分开发的工作。

拓尔思质保部的灰盒测试，解决以上问题，更重要的是改进了过程。1999年洛克希德-马丁公司提出了灰盒测试的方法，它揉合了黑盒、白盒与变异测试等方法，其关注点是从需求入手，获取用例并运用与校验中。目前，灰盒测试这种方法在国外运用尤其多，国内只有很少的公司有一些积累。由于目前这类公开信息还很有限，因此拓尔思质保部摸索着开始提出一些具有拓尔思特色的方法与理论：基于业务逻辑的灰盒测试方法。

灰盒测试可以补充（注意不是替代）当前的测试、更早的介入测试、更好的协作、自动化。为了达到这个目的，拓尔思质保部首先改进了开发流程。常见的软件开发流程如下图：

在这种流程中，开发跟测试在很多时间是错开的，测试者介入的时间相对较晚，紧密合作也就不是那么方便了，那么灰盒测试的流程又是怎样的呢？看看下面这幅图：

简单总结就是，需求讨论我参加、概要设计我知道、软件测试早参与。这个时候的测试者，不仅仅是测试者，还是“客户替身”，我们把这种方式称为“全程协作式”的灰盒测试，“全程协作式”是理念，灰盒测试就是方法。

灰盒测试是从需求获取用例并测试，也就是说，起点不同，方法不同。常见的流程如下：

★ 熟悉产品的模块与定义

★ 获得模块说明（此过程需要《接口文档》）

★ 编写业务逻辑

★ 代码实现

★ 自动化框架测试

★ 获得结果

★ 回归测试

★ 生成测试报告

在上面流程中，提一下两个重要的概念：一为文档，很多时候人们并不是很重视文档，实际上，文档是个好东西，不是写给自己看的，而是写给别人看的，没文档，只靠听说会很累；二是业务逻辑的测试，这也是所提出的灰盒的核心，常规的黑盒测试，总是在关注某一个点(如果用例足够多，应该可以达到高覆盖)，而用户在绝大多数时候，进行的实际操作往往是一个流程，也就是一串路径。比如我们测试经常会把登录作为一个独立的点去测试，但实际上，绝大多数人，登录之后总想做些什么，而这些业务，也就是我们所谓的“典型场景”，设计的时候就需要考虑到，否则可能造成错误。比如，在TRS IDS中，注册登录往往涉及到管理的动作，甚至还有同步的触发（这个并不是直观所能看到的），这个流程是否正常，就显得非常关键，事实上，这种业务逻辑的场景在实际项目中已经有客户提及。

另一个重点就是自动化，我们知道测试几乎不可能在一轮完成，总是有很多重复的工作，都靠人力未免太过庞杂，因此必须进行自动化集成，关于这点，拓尔思质保部已经构建出一个简单的框架，满足灰盒测试的工作，也满足单元测试（或其他白盒测试）。

拓尔思质保部认为，技术本身并非重点，最重要的是思想。测试思想、开发思想、软件思想，不一而足。需要说明的是，灰盒测试是一种思想，也是过程改进的一种方法，是否采用要取决于实际情况，同时也需要更多的实践与考验。思想与方法永远是为产品服务的。

另外，拓尔思质保部进行这项工作的目的是协作，还是协作。关于这点，太多的经历告诉我们，一个高效、紧密、互相信任的团队是多么的重要。