1、概述

　　1.1 黑盒测试的概念

　　黑盒测试（black box test）也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

　　黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

　　1.2 黑盒测试方法

　　黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

　　PS：黑盒测试用例设计方法的介绍这里不作具体说明。

　　2、准备阶段

　　2.1 需求收集/分析

　　在需求收集/分析阶段，需求人员会对用户的需求进行详细的分析，形成产品说明书/需求说明文档，做得更好的可以细化到用例图，活动图等UML图。举一个例子，下面就是一个游戏人物信息系统的用例图。

　　从图中可以了解这个系统的基本功能，以及各个功能之间的组成。然后可以在测试计划书中结合产品说明书对此系统功能块的测试目标进行详细的描述，从而保证系统重要功能块的覆盖面，后面有经验的案例设计人员会通过测试计划书设计出合理的案例对功能进行测试。这时我们测试人员还可以起到另一个作用，对需求进行评审，比如丢弃物品功能，大家有不同的见解，这时可以让需求人员进一步确认用户是否需要对丢弃物品功能的需求进行修改。不同系统的产品说明书与用例图总是不同的，不过在测试人员的眼中，它可是用来确定产品是否可以满足用户需求的主要标准，我们可以将它提取出来，写成测试规程，测试规程可以对应一个或多个测试用例。这里主要描述产品需要达到的功能，性能要求，稳定性要求。基本要求就是让测试在早期的需求分析阶段就介入项目，对需求有一个整体的把握，有助于确定后期测试的目标。当然，更高要求是对需求进行评审/测试，论证需求是否可以满足用户的要求，从而降低需求带来的风险。

　　此阶段的难点和重点：

　　● 需求总是不完善的。实际工作中我们不可能有100%完善的需求。需求说明书中总会遗漏很多细节，通常需求人员认为那些地方都是理所当然的，但开发人员却会有不同的理解，所以测试人员要尽可能在执行阶段前找出需求中不明确、有遗漏的地方，整理成checklist列表，并进行同行评审（参与人员包括需求人员/测试人员/研发人员/项目经理）。如果能在收集需求阶段就提出问题那比从已经写好的需求说明书中挑错要好的多。问题越早发现越容易解决。

　　这是偶实际工作中一个关于需求定义的例子：

　　项目需要研发一个3.0*3.0TFT触摸屏A的手机，但是当时公司仓库里只有3.0*4.2TFT触摸屏B。于是项目组从节约资源的角度，提出这样一个需求：在ID设计时，将B屏下部使用外壳盖住，做成假A屏的手机。这个需求看似没什么问题，就是一个简单的大屏做小屏的操作而已。但是确忽略了一个重点：选择的裁减的屏幕是触摸屏，在使用外壳盖住多余部分的时候，外壳与屏之间的隙缝将是结构设计的一个盲点。如果缝隙太大，产品使用一段时间后，缝隙内进入灰尘/颗粒，将导致整个触摸屏的触摸功能失效；如果缝隙太小，那么在批量生产时，外壳很容易在安装时就压住触摸屏，同样导致触摸屏功能失效。所以，项目组提出的大屏裁小屏的需求不合理，需要重新定义。

　　● 同类需求的一致规范性。在同一个项目中，一些细节需要开发人员统一处理，比如：退出正在编辑的界面，是否弹出提示框；标点符号是用中文半角还是全角；错误提示是弹出窗口还是显示在原界面；错误提示语与图标风格是否统一等等。测试人员（或需求人员）最好能整理出一个列表，通过评审与开发人员达成一致，这样在后期测试时会避免很多不必要的麻烦，也为产品风格的统一性铺好了路基。