在这种流程中，开发跟测试在很多时间是错开的，测试者介入的时间相对较晚，紧密合作也就不是那么方便了，那么灰盒测试的流程又是怎样个流程呢，看看下面这幅图。
简单来总结就是，需求讨论我参加、概要设计我知道、软件测试早参与，当然，如有不爽我就提，这个时候的测试者，不仅仅是测试者，还是“客户替身”，我们把这种方式称为“全程协作式”[1]的灰盒测试，“全程协作式”是理念，灰盒测试是方法。
既然说到方法，有人可能会问，怎么测呢，怎么执行呢。
不要着急，正如灰盒测试的定义，从需求获取用例并测试，也就是说，起点不同，方法不同，一个常见的流程是这样的：
1、熟悉产品的模块与定义
2、获得模块说明（此过程需要《接口文档》）
3、编写业务逻辑
4、代码实现
5、自动化框架测试
6、获得结果
7、回归测试
8、生成测试报告
在上面这个流程中，我们重点提一下两个重要的概念，意味文档，很多时候我们并不是很重视文档，实际上，文档是个好东西，不是写给自己看的，而是写给别人看的，没文档，只能靠听说了，岂不太累。第二个地方，我们说要从业务逻辑的测试，这也是我们所提出的灰盒的核心，常规的黑盒测试，总是在关注某一个点（如果用例足够多，应该可以达到高覆盖），而用户在绝大多数时候，进行的实际操作往往是一个流程，也就是一串路径。比如我们测试经常会把登录作为一个独立的点去测试，但实际上，绝大多数人，登录之后总想做些什么，而这些业务，也就是我们所谓的“典型场景”，设计的时候就需要考虑到，否则可能造成错误，比如，在某身份管理系统中（这个产品最近的使用率越来越高啊），注册登录往往涉及到管理的动作，甚至还有同步的触发（这个并不是直观所能看到的），这个流程是否正常，就显得非常关键，事实上，这种业务逻辑的场景在实际项目中已经有客户提及（2010年曾参加过某银行项目，客户方就组织了大量人力资源进行该项工作）。
另一个重点就是自动化，我们知道测试几乎不可能在一轮完成，总是有很多重复的工作，都靠人力未免太过庞杂，因此必须进行自动化集成，关于这点，我们已经构建出一个简单的框架，满足灰盒测试的工作，也满足单元测试（或其他白盒测试）。
关于具体怎么做，怎么实现，大家可以参考下一篇《基于业务逻辑的灰盒测试》，我们一直认为，技术本身并非重点，最重要的是我们的思想。测试思想、开发思想、软件思想，不一而足。
这也是我们为什么进行这项工作的原因，协作，协作，还是协作，关于这点，也无需赘言，太多的经历告诉我们，一个高效、紧密、互相信任的团队是多么的重要。
看到这篇文章的您，就是我们团队的一部分。
