2 评论

如何开展灰盒测试[2]:管理方面的准备工作

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


★观念上的改变


  可能是因为黑盒测试应用太广的缘故,导致很多开发人员和测试人员认为黑盒测试就是测试的全部。由于黑盒测试关注的是软件系统的外部边界。在大多数的软件公司里,软件的外部边界主要就是用户界面。这就造成了一个【误区】——把软件测试和用户界面测试等同起来
  如果开发人员持有这个错误观念,他/她就把精力放在:如何让软件的界面操作正常。至于软件的内部模块,其接口是否正常、协同是否正常,就不太关注了。用某些开发人员的话来讲,就是:“软件只要能貌似正常地工作,就行了”。
  同样的,如果测试人员持有这样的观念,他/她就仅仅去测试软件的外部边界(比如用户界面),而毫不关心软件内部模块的问题。
  在这种误区的影响下,最终发布出来的软件产品,多半是“金玉其外、败絮其中”。所以,在管理上,要通过各种方式,首先改变这种错误的观念,让开发人员和测试人员都注重内部模块的协同问题。


★设计上的改变


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

◇以动态库接口为例


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

◇以 Web 接口为例


  考虑到有些网友不是搞 C/S 开发的(尤其不是搞 C++的),可能看不懂上述例子。俺再举一个 Web 接口的例子。
  和动态库的接口风格类似,Web 接口也有两种常见的风格:RESTSOAP。同样的,俺比较倾向于使用 REST 风格。抛开其它的优缺点不谈,单纯从“可测试性”来看,REST 的优势非常明显——更简单、更可读。


★文档上的改变>


  由于灰盒测试侧重于内部模块的接口测试,因此接口文档就显得非常重要了。模块的其它文档可以省略,但是模块的接口文档是一定不能马虎的。接口文档不光是开发人员与开发人员之间的契约,而且是开发人员与灰盒测试人员之间的契约。这玩意儿的重要性,无须多说,想必大伙儿也应该明白。
  由于很多开发人员不愿意/不屑于写文档,还有一些开发人员是在编码完成之后,再补文档。这些都对灰盒测试的开展很不利。如果没有彻底改变,灰盒测试很难开展。
  对于接口文档的要求,俺主要强调两点:其一是文档的内容,其二是完成文档的时间点。

◇接口文档的内容


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

◇接口文档的完成时间


  关于时间点,俺的做法是:在内部模块的编码之前,一定要先让开发人员把接口文档写出来,并经过评审。
  这么做不光对开发有好处,对测试也很有好处。当接口文档完成后,开发人员开始 Coding 的时候,测试人员也可以同步进行测试用例及测试脚本的编写。这就尽可能地实现了开发工作和测试工作的并行。


★测试团队的改变


  前面说的设计问题和文档问题,都是开发人员的事情,那测试人员这边,需要做出哪些改变捏?主要的一条是人员结构的改变。以俺的经验,在测试团队中,要安排 1/4 ~ 1/3 的人员全力负责灰盒测试。因此,在开展灰盒测试之前,先要通过内部培养或外部招聘的方式,落实有能力的测试人员,来担此重任。
  前一个帖子,俺曾经说过,灰盒测试的培训成本/招聘成本介于黑盒与白盒之间。那么,俺就大致说一下,对负责灰盒测试的人员,大致有哪些技能方面的要求。事先声明:灰盒测试的技能要求,与要测试软件密切相关;以下列出的技能要求,来自俺本人的经验,肯定不全面,仅供参考。

◇通用技能


  首先,要有初步的编程基础:至少得懂得循环语句、判断语句、算术表达式、逻辑表达式、函数调用等最基本的东东。考虑到多年来,高校的计算机系一直在扩招,很多测试人员都曾经在计算机系呆过,俺窃以为不难达到这个水平。
  最好掌握一门功能较强的脚本语言。按照俺的习惯,首先推荐Python(俺还专门写了一个 Python 扫盲的系列教程,在“这里”);当然,PerlLua 也可以考虑;如果你测试的软件仅限于 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

2 条评论