上一个帖子 分析了灰盒测试的优缺点，照道理紧接着就应该忽悠一下相关的技术问题了。但是捏，在介绍具体的技术细节之前，俺有必要先来强调一下管理上的注意事项。安全圈内有一句俗话，叫三分技术七分管理。此话很有道理。在绝大多数时候，管理问题总是比技术问题关键，比技术问题难搞。当你企图推行某个东东的时候，真正的障碍往往是管理上的，而不是技术上的。所以，今天先介绍一下，推行灰盒测试之前，需要进行哪些管理上的准备工作。

　　★观念上的改变

　　可能是因为黑盒测试应用太广的缘故，导致很多开发人员和测试人员认为黑盒测试就是测试的全部。由于黑盒测试关注的是软件系统的外部边界。在大多数的软件公司里，软件的外部边界主要就是用户界面。这就造成了一个误区：把软件测试和用户界面测试等同起来 。

　　如果开发人员持有这个错误观念，他/她就把精力放在：如何让软件的界面操作正常。至于软件的内部模块，其接口是否正常、协同是否正常，就不太关注了。用某些开发人员的话来讲，就是：“软件只要能貌似正常地工作，就行了”。

　　同样的，如果测试人员持有这样的观念，他/她就仅仅去测试软件的外部边界（比如用户界面），而毫不关心软件内部模块的问题。

　　在这种误区的影响下，最终发布出来的软件产品，多半是“金玉其外、败絮其中”。所以，在管理上，要通过各种方式，首先改变这种错误的观念，让开发人员和测试人员都注重内部模块的协同问题。

　　★设计上的改变

　　说完观念上的改变，再来谈谈设计上的改变。

　　大部分开发人员在设计内部模块的接口时，往往只考虑开发上的便利，而不考虑测试上的便利。结果捏，软件开发完之后，测试人员在进行模块接口的测试时，会非常费力，甚至无从下手。所以，俺在进行模块接口的设计评审时，会非常强调“可测试性”的考虑。

　　◇以动态库接口为例

　　当你用C++开发一个动态库时，对于动态库的导出函数可以有两种风格：C++风格和纯C风格（extern "C"）。在俺负责的产品中，动态库的接口设计通常要求用纯C风格的导出函数。抛开各种高深的设计理念不谈（这不是今天的重点），单纯考虑“可测试性”，纯C风格的函数接口非常方便测试。很多时候，测试用一些简单的脚本，就可以对“纯C风格”的导出函数进行测试。具体如何做，下一帖会具体介绍。

　　◇以Web接口为例

　　考虑到有些网友不是搞C/S开发的（尤其不是搞C++的），可能看不懂上述例子。俺再举一个Web接口的例子。

　　和动态库的接口风格类似，Web接口也有两种常见的风格：SOAP和REST（两者的介绍参见“这里 ”和“这里 ”）。同样的，俺比较倾向于使用REST风格。抛开其它的优缺点不谈，单纯从“可测试性”来看，REST的优势非常明显——更简单、更可读。

　　★文档上的改变

　　由于灰盒测试侧重于内部模块的接口测试，因此接口文档就显得非常重要了。模块的其它文档可以省略，但是模块的接口文档是一定不能马虎的。接口文档不光是开发人员与开发人员之间的契约，而且是开发人员与灰盒测试人员之间的契约。这玩意儿的重要性，无须多说，想必大伙儿也应该明白。

　　由于很多开发人员不愿意/不屑于写文档，还有一些开发人员是在编码完成之后，再补文档。这些都对灰盒测试的开展很不利。如果没有彻底改变，灰盒测试很难开展。

　　对于接口文档的要求，俺主要强调两点：一个是文档的内容，一个是完成文档的时间点。

　　◇接口文档的内容

　　接口文档在内容上一定要简洁、实用，而且要确保测试人员能看懂——毕竟测试人员的技术水平不如开发人员那么高。另外，不同类型的接口，会有不同的接口文档形式，俺会在后面的帖子里面详细介绍。