(如何进行灰盒测试.docVIP

如何开展灰盒测试 灰盒测试优缺点分析 ★几个基本概念 　　首先，把一些基本概念，简单通俗地说一下。如果觉得俺解释得不够好，不够细，可以自己去查维基百科的词条：洋文的在“这里 ”，中文的词条在“这里 ”（可惜中文词条不够全，偏偏缺了“灰盒测试”这一节）。　　◇黑盒测试　　通俗来说：黑盒测试不关注软件内部的实现细节。他仅仅把被测试的软件当成一个整体来处理，只关注软件的外在表现，不关注内部细节。典型的黑盒测试，就是光拿着鼠标操作一下用户界面，看看功能是否满足要求。　　◇白盒测试　　白盒测试与黑盒测试相反，重点关注软件内部的实现细节（比如代码覆盖率等）。　　◇灰盒测试　　如果你是从事开发或者测试的行当，应该已经听过黑盒测试与白盒测试这2个概念。但对灰盒测试，或许比较耳生。单纯从名称上来看，灰盒测试是介于黑盒测试与白盒测试之间的一种测试方式。　　这种测试方式，主要用于多模块构成的稍微复杂的软件系统。在灰盒测试中，重点关注软件系统的各个组成模块之间的互动。这里所说的互动，包括模块之间的互相调用、数据传递、同步/互斥、等等。　　◇灰盒测试与黑盒测试的区别　　如果某软件包含多个模块，当你使用黑盒测试时，你只要关心整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，你就需要关心模块与模块之间的交互。这是灰盒测试与黑盒测试的区别。　　◇灰盒测试与白盒测试的区别　　但是，在灰盒测试中，你还是无需关心模块内部的实现细节。对于软件系统的内部 模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试则不同，还需要再深入地了解内部 模块的实现细节。所以，这是灰盒测试与黑盒测试的区别。　　◇灰盒测试与单元测试的区别　　刚才看到有网友在评论中问到此问题，俺补充一下。　 　首先，在进行单元测试时，需要写一些测试代码（行话叫“桩代码”，洋文叫stub）。通常测试代码和被测试代码通常是同种语言（比如Java的单元测试 通常也用Java来写），且测试代码和被测试代码的耦合很紧密。因此，单元测试通常由开发人员来完成的，测试人员的能力未必能胜任。　　其次，单元测试的颗粒度会更细（会细到类一级、函数一级），而灰盒测试仅仅到模块一级。　　★相对于黑盒测试的优点 　　灰盒测试相对黑盒测试的优点，其实有不少，俺挑几个重要的来说说。　　◇测试可以及早介入　　由于黑盒测试把整个软件系统当成一个整体来测试。如果系统的某个关键模块还没有完工，那测试人员就无法对整个系统进行测试，只好闲着没事干。而灰盒测试是针对模块的边界进行，模块开发完一个就测试一个。　　◇有助于测试人员理解系统结构　　为了进行灰盒测试，测试人员首先要熟悉内部模块之间的协作机制。在熟悉的过程中，“顺便”也就对整个系统（及其结构）有一个初步的、宏观的认识。这有助于测试人员发现一些系统结构方面的Bug。　　而对于黑盒测试来说，由于测试人员不清楚软件系统的内部结构，难以发现一些结构性的缺陷。　　◇有助于管理层了解真实的开发进度　　一些复杂的大系统，经常会发生开发进度失控的情况。因为很多开发人员有报喜不报忧的倾向。当某个开发人员号称自己的工作已经完成了90%，往往意味着他/她还要花同样多的时间来完成剩下的10%。这导致负责项目管理的人，无法了解开发的真实进度。　　由于灰盒测试针对对每一个模块进行，而且测试人员会从一个客观的角度来反馈模块的完成情况，这非常有利于管理层了解整个系统的真实完成情况。　　◇可以构造更好的测试用例　　如果仅仅用黑盒的方式测试系统的外部边界（通常是用户界面），有很多软件缺陷是不容易发现的。俺分别以B/S系统和C/S系统来举例。　 　假设开发一个复杂的（Windows环境下的）C/S软件。那么，这个软件通常不会仅仅只有一个EXE文件。它可能会有若干个EXE文件以及若干个 DLL文件。假如某个DLL提供的导出函数，没有按照约定对输入参数进行有效性判断（比如指针是否为空），那你用黑盒测试的方式，难以暴露出这种缺陷。而 灰盒测试就容易发现此类问题（具体如何发现，后续的帖子会细说）。　　假如你开发的是一个Web应用系统，那么，这种系统的服务端多半会提供若干 个Web接口用于被客户端调用。假如某个Web接口存在安全性问题/并发性问题/健壮性问题/XX问题，你单纯用黑盒测试的手段，同样难以发现，而灰盒测 试就可以搞定（灰盒测试是如何搞定的，后续帖子会细说）。　　◇利于提升测试人员能力　　很多公司搞的黑盒测试，就是让测试人员用鼠标（键盘都难得用）操作用户界面。在这种的环境里，测试人员干的活，很多都是重复性的体力劳动，技术能力难以得到提高。　　而如果搞灰盒测试，测试人员就需要多懂一点技术背景知识，必要时还