关于一些误解黑盒测试想法的论述

之前分别写了一些白盒测试、黑盒测试、回归测试、自动化测试的一些基本的东西，这期就重点说说白盒测试和黑盒测试的不同

一般软件开发人员和测试人员对白盒测试和黑盒测试的感念都有一定的认识，但认为是编代码所做的测试是白盒测试，黑盒测试不用编写代码，这其实是一种误解。

虽然不管是app测试还是软件测试等，都可以使用以下两种方法之一进行测试。

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

从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。

黑盒测试的优点

1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了

2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点

1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴

2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。

而白盒测试，之前也有说过它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。具体的方法的其他信息，我已经在之前的几片文章写过，大家可以去看看

TestBird - 手游和App自动化测试平台