如何开展灰盒测试[2]：管理方面的准备工作
如何开展灰盒测试[2]：管理方面的准备工作
上一个帖子 分析了灰盒测试的优缺点，照道理紧接着就应该忽悠一下相关的技术问题了。但是捏，在介绍具体的技术细节之前，俺有必要先来强调一下管理上的注意事项。安全圈内有一句俗话，叫三分技术七分管理。此话很有道理。在绝大多数时候，管理问题总是比技术问题关键，比技术问题难搞。当你企图推行某个东东的时候，真正的障碍往往是管理上的，而不是技术上的。所以，今天先介绍一下，推行灰盒测试之前，需要进行哪些管理上的准备工作。
可能是因为黑盒测试应用太广的缘故，导致很多开发人员和测试人员认为黑盒测试就是测试的全部。由于黑盒测试关注的是软件系统的外部边界。在大多数的软件公司里，软件的外部边界主要就是用户界面。这就造成了一个【误区】—— 把软件测试和用户界面测试等同起来 。
如果开发人员持有这个错误观念，他/她就把精力放在：如何让软件的界面操作正常。至于软件的内部模块，其接口是否正常、协同是否正常，就不太关注了。用某些开发人员的话来讲，就是：“软件只要能貌似正常地工作，就行了”。
同样的，如果测试人员持有这样的观念，他/她就仅仅去测试软件的外部边界（比如用户界面），而毫不关心软件内部模块的问题。
在这种误区的影响下，最终发布出来的软件产品，多半是“金玉其外、败絮其中”。所以，在管理上，要通过各种方式，首先改变这种错误的观念，让开发人员和测试人员都注重内部模块的协同问题。
说完观念上的改变，再来谈谈设计上的改变。
大部分开发人员在设计内部模块的接口时，往往只考虑开发上的便利，而不考虑测试上的便利。结果捏，软件开发完之后，测试人员在进行模块接口的测试时，会非常费力，甚至无从下手。所以，俺在进行模块接口的设计评审时，会非常强调“可测试性”的考虑。
当你用 C++ 开发一个动态库时，对于动态库的导出函数可以有两种风格：“C++ 风格”和“纯 C 风格”（extern "C"）。在俺负责的产品中，动态库的接口设计通常要求用纯 C 风格的导出函数。抛开各种高深的设计理念不谈（这不是今天的重点），单纯考虑“可测试性”，纯 C 风格的函数接口非常方便测试。很多时候，测试用一些简单的脚本，就可以对“纯 C 风格”的导出函数进行测试。具体如何做，下一帖会具体介绍。
考虑到有些网友不是搞 C/S 开发的（尤其不是搞 C++的），可能看不懂上述例子。俺再举一个 Web 接口的例子。
和动态库的接口风格类似，Web 接口也有两种常见的风格： REST 和 SOAP 。同样的，俺比较倾向于使用 REST 风格。抛开其它的优缺点不谈，单纯从“可测试性”来看，REST 的优势非常明显——更简单、更可读。
由于灰盒测试侧重于内部模块的接口测试，因此接口文档就显得非常重要了。模块的其它文档可以省略，但是模块的接口文档是一定不能马虎的。接口文档不光是开发人员与开发人员之间的契约，而且是开发人员与灰盒测试人员之间的契约。这玩意儿的重要性，无须多说，想必大伙儿也应该明白。
由于很多开发人员不愿意/不屑于写文档，还有一些开发人员是在编码完成之后，再补文档。这些都对灰盒测试的开展很不利。如果没有彻底改变，灰盒测试很难开展。
对于接口文档的要求，俺主要强调两点：其一是文档的内容，其二是完成文档的时间点。
接口文档在内容上一定要简洁、实用，而且要确保测试人员能看懂——毕竟测试人员的技术水平不如开发人员那么高。
另外，不同类型的接口，会有不同的接口文档形式，俺会在后面的帖子里面详细介绍。
关于时间点，俺的做法是：在内部模块的编码之前，一定要先让开发人员把接口文档写出来，并经过评审。
这么做不光对开发有好处，对测试也很有好处。当接口文档完成后，开发人员开始 Coding 的时候，测试人员也可以同步进行测试用例及测试脚本的编写。这就尽可能地实现了开发工作和测试工作的并行。
前面说的设计问题和文档问题，都是开发人员的事情，那测试人员这边，需要做出哪些改变捏？主要的一条是人员结构的改变。以俺的经验，在测试团队中，要安排 1/4 ~ 1/3 的人员全力负责灰盒测试。因此，在开展灰盒测试之前，先要通过内部培养或外部招聘的方式，落实有能力的测试人员，来担此重任。
前一个帖子 ，俺曾经说过，灰盒测试的培训成本/招聘成本介于黑盒与白盒之间。那么，俺就大致说一下，对负责灰盒测试的人员，大致有哪些技能方面的要求。事先声明：灰盒测试的技能要求，与要测试软件密切相关；以下列出的技能要求，来自俺本人的经验，肯定不全面，仅供参考。
首先，要有初步的编程基础：至少得懂得循环语句、判断语句、算术表达式、逻辑表达式、函数调用等最基本的东东。考虑到多年来，高校的计算机系一直在扩招，很多测试人员都曾经在计算机系呆过，俺窃以为不难达到这个水平。
最好掌握一门功能较强的脚本语言。按照俺的习惯，首先推荐 Python （俺还专门写了一个 Python 扫盲的系列教程，在“ 这里 ”）；当然， Perl 、 Lua 也可以考虑；如果你测试的软件仅限于 Windows 平台， PowerShell 也是不错的选择。
既然是 B/S 系统，HTML 的一些基本语法要了解，包括：超链接、form的提交等。
B/S 的系统，对 Web 接口的调用几乎是免不了的。因此，要有基本的 HTTP 协议的常识，至少包括：Request/Response 的区别、GET/POST 的区别、知道常见的 HTTP 状态码。
如果这个 B/S 系统里面，大量使用 JavaScript，那最好稍微了解一下 JS 的基本语法；同样的，如果 B/S 系统中大量使用XML，也需要具备基本的 XML 知识。
假如测试的 C/S 软件大量使用动态库。测试人员最好稍微懂一点 C 语言的语法，因为大多数动态库的导出函数声明，都是用C语言描述。
假如这个 C/S 软件经常使用多进程及管道，那还得了解一下标准输入/标准输出/管道的基本概念。
无论是 B/S 还是 C/S，可能都会涉及到数据库。这时候，灰盒测试的家伙就需要懂一些数据库相关的知识，包括：基本 SQL 语法，用上述提到的脚本进行数据库记录的增删改查。
假如你测试的软件，其内部模块还涉及网络通讯，那最好还要掌握一些基本的网络知识，包括：TCP/UDP 的概念、用上述提到的脚本进行简单的 SOCKET 编程。
以上就是开展灰盒测试之前，在管理上要进行的准备工作。下一个帖子，俺介绍一下 具体的技术实现 。
回到本系列的目录
★观念上的改变
可能是因为黑盒测试应用太广的缘故，导致很多开发人员和测试人员认为黑盒测试就是测试的全部。由于黑盒测试关注的是软件系统的外部边界。在大多数的软件公司里，软件的外部边界主要就是用户界面。这就造成了一个【误区】—— 把软件测试和用户界面测试等同起来 。
如果开发人员持有这个错误观念，他/她就把精力放在：如何让软件的界面操作正常。至于软件的内部模块，其接口是否正常、协同是否正常，就不太关注了。用某些开发人员的话来讲，就是：“软件只要能貌似正常地工作，就行了”。
同样的，如果测试人员持有这样的观念，他/她就仅仅去测试软件的外部边界（比如用户界面），而毫不关心软件内部模块的问题。
在这种误区的影响下，最终发布出来的软件产品，多半是“金玉其外、败絮其中”。所以，在管理上，要通过各种方式，首先改变这种错误的观念，让开发人员和测试人员都注重内部模块的协同问题。
★设计上的改变
说完观念上的改变，再来谈谈设计上的改变。
大部分开发人员在设计内部模块的接口时，往往只考虑开发上的便利，而不考虑测试上的便利。结果捏，软件开发完之后，测试人员在进行模块接口的测试时，会非常费力，甚至无从下手。所以，俺在进行模块接口的设计评审时，会非常强调“可测试性”的考虑。
◇以动态库接口为例
当你用 C++ 开发一个动态库时，对于动态库的导出函数可以有两种风格：“C++ 风格”和“纯 C 风格”（extern "C"）。在俺负责的产品中，动态库的接口设计通常要求用纯 C 风格的导出函数。抛开各种高深的设计理念不谈（这不是今天的重点），单纯考虑“可测试性”，纯 C 风格的函数接口非常方便测试。很多时候，测试用一些简单的脚本，就可以对“纯 C 风格”的导出函数进行测试。具体如何做，下一帖会具体介绍。
◇以 Web 接口为例
考虑到有些网友不是搞 C/S 开发的（尤其不是搞 C++的），可能看不懂上述例子。俺再举一个 Web 接口的例子。
和动态库的接口风格类似，Web 接口也有两种常见的风格： REST 和 SOAP 。同样的，俺比较倾向于使用 REST 风格。抛开其它的优缺点不谈，单纯从“可测试性”来看，REST 的优势非常明显——更简单、更可读。
★文档上的改变>
由于灰盒测试侧重于内部模块的接口测试，因此接口文档就显得非常重要了。模块的其它文档可以省略，但是模块的接口文档是一定不能马虎的。接口文档不光是开发人员与开发人员之间的契约，而且是开发人员与灰盒测试人员之间的契约。这玩意儿的重要性，无须多说，想必大伙儿也应该明白。
由于很多开发人员不愿意/不屑于写文档，还有一些开发人员是在编码完成之后，再补文档。这些都对灰盒测试的开展很不利。如果没有彻底改变，灰盒测试很难开展。
对于接口文档的要求，俺主要强调两点：其一是文档的内容，其二是完成文档的时间点。
◇接口文档的内容
接口文档在内容上一定要简洁、实用，而且要确保测试人员能看懂——毕竟测试人员的技术水平不如开发人员那么高。
另外，不同类型的接口，会有不同的接口文档形式，俺会在后面的帖子里面详细介绍。
◇接口文档的完成时间
关于时间点，俺的做法是：在内部模块的编码之前，一定要先让开发人员把接口文档写出来，并经过评审。
这么做不光对开发有好处，对测试也很有好处。当接口文档完成后，开发人员开始 Coding 的时候，测试人员也可以同步进行测试用例及测试脚本的编写。这就尽可能地实现了开发工作和测试工作的并行。
★测试团队的改变
前面说的设计问题和文档问题，都是开发人员的事情，那测试人员这边，需要做出哪些改变捏？主要的一条是人员结构的改变。以俺的经验，在测试团队中，要安排 1/4 ~ 1/3 的人员全力负责灰盒测试。因此，在开展灰盒测试之前，先要通过内部培养或外部招聘的方式，落实有能力的测试人员，来担此重任。
前一个帖子 ，俺曾经说过，灰盒测试的培训成本/招聘成本介于黑盒与白盒之间。那么，俺就大致说一下，对负责灰盒测试的人员，大致有哪些技能方面的要求。事先声明：灰盒测试的技能要求，与要测试软件密切相关；以下列出的技能要求，来自俺本人的经验，肯定不全面，仅供参考。
◇通用技能
首先，要有初步的编程基础：至少得懂得循环语句、判断语句、算术表达式、逻辑表达式、函数调用等最基本的东东。考虑到多年来，高校的计算机系一直在扩招，很多测试人员都曾经在计算机系呆过，俺窃以为不难达到这个水平。
最好掌握一门功能较强的脚本语言。按照俺的习惯，首先推荐 Python （俺还专门写了一个 Python 扫盲的系列教程，在“ 这里 ”）；当然， Perl 、 Lua 也可以考虑；如果你测试的软件仅限于 Windows 平台， PowerShell 也是不错的选择。
◇针对 B/S 软件的技能
既然是 B/S 系统，HTML 的一些基本语法要了解，包括：超链接、form的提交等。
B/S 的系统，对 Web 接口的调用几乎是免不了的。因此，要有基本的 HTTP 协议的常识，至少包括：Request/Response 的区别、GET/POST 的区别、知道常见的 HTTP 状态码。
如果这个 B/S 系统里面，大量使用 JavaScript，那最好稍微了解一下 JS 的基本语法；同样的，如果 B/S 系统中大量使用XML，也需要具备基本的 XML 知识。
◇针对 C/S 软件的技能
假如测试的 C/S 软件大量使用动态库。测试人员最好稍微懂一点 C 语言的语法，因为大多数动态库的导出函数声明，都是用C语言描述。
假如这个 C/S 软件经常使用多进程及管道，那还得了解一下标准输入/标准输出/管道的基本概念。
◇数据库相关的技能
无论是 B/S 还是 C/S，可能都会涉及到数据库。这时候，灰盒测试的家伙就需要懂一些数据库相关的知识，包括：基本 SQL 语法，用上述提到的脚本进行数据库记录的增删改查。
◇网络相关的技能
假如你测试的软件，其内部模块还涉及网络通讯，那最好还要掌握一些基本的网络知识，包括：TCP/UDP 的概念、用上述提到的脚本进行简单的 SOCKET 编程。
★结尾
以上就是开展灰盒测试之前，在管理上要进行的准备工作。下一个帖子，俺介绍一下 具体的技术实现 。
回到本系列的目录
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2010/12/grey-box-testing-2.html
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2010/12/grey-box-testing-2.html
文章版权归原作者所有。
