测试策略的选择

woodcraft

原创内容，如有转载，请注明出处。

我们的测试团队已经有快4年的历史了，今年，我考虑最多的就是如何转变测试的策略。

我一直这么以为，测试的切入点，大体而言，有两种。

第一种是基于应用的测试，用户如何使用，需求如何定义，我们就如何进行测试。

第二种是基于实现的测试，开发人员如何实现需求，我们就如何验证这个过程。

有了解测试的兄弟应该能明白，第一种测试也可以叫“黑盒测试”，第二种测试也可以叫“白盒测试”。

有测试者会问，那“灰盒测试”是什么？

百度百科上关于“灰盒测试”是这么解释的：

灰盒测试，确实是介于二者之间（黑盒/白盒）的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。 灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

很长，我是这么理解的，“灰盒测试”是基于接口的测试。它是在概要设计的基础上，关注于软件模块的各种接口进行的测试。对比白盒，它不关注于具体的代码实现。对比黑盒，它需要测试者了解部分设计思路与协议。

OK，测试的切入点有三种了，那么在具体项目中，应该如何选择？

黑盒的投入成本低，大多数公司的测试团队都是从黑盒起步的。白盒成本高，很多公司很难投入。因此有些公司的策略选择是从成本角度考虑的。

我很反感于这种现状。我认为，测试策略的选择，应该是基于具体项目的。

对于封闭性较大的项目，且项目的组成模块较少，如MP3/手机/GPS、功能模块较少PC软件，我认为选择黑盒测试是一种性价比比较高的策略。因为这种系统的封闭性，应用比较单纯，基于黑盒，投入较少，但是客户应用基本可以保证。

对于开放性的项目，如操作系统，我认为选择白盒测试比较合适。系统太开放了，你如何保证应用的完整性？白盒测试投入虽然较大，但是从保证性上来说，这是不得以的选择。

对于介于2者之间的项目，如C/S架构中的客户端，如果接口较多，我认为选择灰盒测试比较合适。选择黑盒，经常会遗失测试用例。选择白盒，成本太高。

总而言之，项目开放性越高，接口越多，我越倾向于选择白盒测试。项目越封闭，接口越少，我越倾向于做黑盒测试。