灰盒测试与团队协作
声明：原创文章，转载请注明出处。
前言：之前一直做的软件质量工作，有过一些经验和一些不太成熟的思路，尽管与现在从事的产品运营不同，但无论是内涵还是联系，都是非常紧密的，无论如何，我都会继续关注产品的质量问题。
其实我想写成一篇散文的…
引言：互联网公司几乎所有的部门都跟测试部门打过交道，大家对测试都或多或少有所了解，角度不同，理解不同，我们的工作可不仅仅是找BUG，发布产品这么简单噢，背后有很多内容与故事，以后可以慢慢道来，实际上，我们的核心理念就是与各开发或项目部门协作，确保并提高软件的质量，这其中，我们进行了一些尝试与探索。
需求：在测试部所有的工作中，包含了两个大块的内容，功能测试与性能测试，大家可以回忆一下，产品完成了，项目上线了，是不是经常会找测试部来检查质量？我们也有机会接触公司各种新产品，甚至奔赴全国各地（也许空闲时间可以逛逛大好好河山），但是，大家注意没有，我们介入的时间都是什么时候？末期。嗯，大多都是这种时候，一般来说，末期这个词意味着效率要高，也意味着风险也高，在长期的合作过程中，我们发现，也许，更早的协作、更早的介入可能更好，正如一个楼盘的建设，打地基时就让质监部门检查是很重要的，房子盖完了，查出有问题，损失可就大了。
图1 著名的“楼歪歪”，要知道，比萨斜塔是不可复制的
有意思的是，在学校的时候，软件工程中，也是这么说的。
切入：提起协作，总需要一个名头，一个方向，甚至还需要理论支撑，因为这个工作还需要传承下去。为此我们在循序的工作中，总结出一套具有“地方”特色的协作方法，切入点正是一种新的测试理念：灰盒测试。
提起测试，稍有了解的朋友都会说，了解，不久黑盒测试与白盒测试吗。没错，按照测试无数分类标准中的一种，这么分没错的，前者正如其名，不关心测试代码，从功能上（其实更多的时候就是从界面开始）来进行测试，一个常见的场景是这样的，“姚工，刚才在注册用户提交时，弹出一个JS错误框啊，咋整的啊？”，这个时候，姚工可能要自己用一下，查一下，改一下，然后测试者过一下，就这样，这种测试直观、快捷，缺点是太直观以至于看不到暗处，太快捷以至于只能后期介入，界面变了，时间晚了，都会对整个过程造成影响。
白盒测试，那就简单了，能看见盒子里面的代码嘛，实际上我们很多部门已经在开展的单元测试就是白盒测试的一种，这个过程质保当然也是可以做的，一种常见的场景是这样的，“王总，Portal的注册方法有问题啊，空名提交没有返回错误！”。白盒测试的好处是定位准确，坏处是成本高难度大，实际上，在软件测试的课程中，大家最觉得最难的就是白盒测试的方法，左路径右覆盖，非一日之功所能拈来。另一个问题就是，开发与测试的任务协调问题，这种模式要求测试承担一部分开发的工作，就目前我们的资源来说，还达不到这种条件。实际上，单元测试我认为还是应该由开发来进行，当然，如果以后质保资源更加充分，可以调整，你知道，质保的工作还是很饱和的。
罗嗦半天，黑盒、白盒都有了，都有问题，我们要说的就是，我们整了个灰盒测试，部门解决了以上问题，更重要的，是为了改进过程。
方法：其实灰盒测试不是我们发明的，1999年洛克希德-马丁公司（大名鼎鼎大名鼎鼎啊）就提出了灰盒测试的方法，揉合了黑盒、白盒与变异测试等方法，其关注点就是从需求入手，获取用例并运用与校验中。目前，灰盒测试这种方法在国外运用尤其多，国内的话，淘宝公司也有一定的积累。由于目前公开信息还是有限，因此我们摸索着也开始提出一些具有我们自己特色的方法与理论：基于业务逻辑的灰盒测试方法。
我们想要什么呢？
补充（注意不是替代）当前的测试、更早的介入测试、更好的协作、自动化（该偷懒时就要偷懒）。
为了达到这个目的，我们首先改进了开发流程，常见的软件开发流程是这样的：
在这种流程中，开发跟测试在很多时间是错开的，测试者介入的时间相对较晚，紧密合作也就不是那么方便了，那么灰盒测试的流程又是怎样个流程呢，看看下面这幅图。
简单来总结就是，需求讨论我参加、概要设计我知道、软件测试早参与，当然，如有不爽我就提，这个时候的测试者，不仅仅是测试者，还是“客户替身”，我们把这种方式称为“全程协作式”[1]的灰盒测试，“全程协作式”是理念，灰盒测试是方法。
既然说到方法，有人可能会问，怎么测呢，怎么执行呢。
不要着急，正如灰盒测试的定义，从需求获取用例并测试，也就是说，起点不同，方法不同，一个常见的流程是这样的：
l
熟悉产品的模块与定义l
获得模块说明（此过程需要《接口文档》）l
编写业务逻辑l
代码实现l
自动化框架测试l
获得结果l
回归测试l
生成测试报告
在上面这个流程中，我们重点提一下两个重要的概念，意味文档，很多时候我们并不是很重视文档，实际上，文档是个好东西，不是写给自己看的，而是写给别人看的，没文档，只能靠听说了，岂不太累。第二个地方，我们说要从业务逻辑的测试，这也是我们所提出的灰盒的核心，常规的黑盒测试，总是在关注某一个点(如果用例足够多，应该可以达到高覆盖)，而用户在绝大多数时候，进行的实际操作往往是一个流程，也就是一串路径。比如我们测试经常会把登录作为一个独立的点去测试，但实际上，绝大多数人，登录之后总想做些什么，而这些业务，也就是我们所谓的“典型场景”，设计的时候就需要考虑到，否则可能造成错误，比如，在某身份管理系统中（这个产品最近的使用率越来越高啊），注册登录往往涉及到管理的动作，甚至还有同步的触发（这个并不是直观所能看到的），这个流程是否正常，就显得非常关键，事实上，这种业务逻辑的场景在实际项目中已经有客户提及（2010年曾参加过某银行项目，客户方就组织了大量人力资源进行该项工作）。
另一个重点就是自动化，我们知道测试几乎不可能在一轮完成，总是有很多重复的工作，都靠人力未免太过庞杂，因此必须进行自动化集成，关于这点，我们已经构建出一个简单的框架，满足灰盒测试的工作，也满足单元测试（或其他白盒测试）。
关于具体怎么做，怎么实现，大家可以参考下一篇《基于业务逻辑的灰盒测试》，我们一直认为，技术本身并非重点，最重要的是我们的思想。测试思想、开发思想、软件思想，不一而足。
这也是我们为什么进行这项工作的原因，协作，协作，还是协作，关于这点，也无需赘言，太多的经历告诉我们，一个高效、紧密、互相信任的团队是多么的重要。
看到这篇文章的您，就是我们团队的一部分。
