“黑盒测试是软件测试的主要方法之一,也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者无须了解程序的内部情况,无须掌握应用程序的代码、内部结构和编程语言的知识,只要知道程序的输入、输出和系统的功能即可。这是从用户的角度针对软件界面、功能及外部结构进行测试,而不考虑程序内部逻辑结构。”这段关于黑盒测试的定义参考自维基百科。
黑盒测试也是应用最广的方法之一,不少公司都是以黑盒测试为主。那么黑盒测试有什么不足呢?我们先看看《微软的软件测试之道》对黑盒测试的分析,如图1-9所示。
图1-9 黑盒测试分析图
图1-9中的A代表黑盒测试的没覆盖部分,B代表黑盒测试的冗余部分,C代表黑盒测试的有效部分。
从业界的统计数据来看,有效测试部分的百分比范围为35%~65%。从图1-9来看,要提升有效测试部分比例,就要把右边的圆(B+C)往左移动,尽可能使两个圆重合面积(C)增大。可以看出优化测试策略有两个方向:一是增加有效测试,二是减少冗余测试或者无效测试。
增加有效测试的方法有两种:一是加强相关评审,二是应用业界的测试方法或者测试建模思想。
加强相关评审是从源头的需求抓起,加强对需求的评审,多从用户角度思考相关可用性及可能场景等。测试用例设计的评审,以及加强对产品开发等角色用例的评审。
应用业界的测试方法或者测试建模思想(详细方法参考第3章的内容),需要在测试用例设计的时候尽可能地覆盖更多功能,这就需要大家充分利用业界各种先进的测试模型来设计测试用例,这样可以更科学、更高效地扩大有效测试范围。如果有条件的话,可以通过阅读开发代码来梳理相关逻辑,这样用例设计的覆盖面会更全。
减少冗余测试可以通过减少无效用例或者低成效的用例、优化精简测试用例等方式进行。
减少无效用例或者低成效的用例,详细方法可以参考1.6节的数据反推。根据用例模块化划分,对Bug根据模块(TAPD上相应的模块选项)进行分类,统计每个模块出现Bug的个数,如果多次执行后Bug个数少的模块,优先级就降低。如果客户端架构稳定后,对于后续新功能没有涉及的这些模块,则可以考虑不执行相关用例。后续在每次集成测试后,测试结果都必须保存,统计经常出现Bug的相关用例,优化和增加相关测试用例,并且同步到各个平台。
优化精简测试用例,可以借助代码覆盖率作为标准,执行原来的用例和精简优化后的用例,如果两者的代码覆盖率差不多,那就达到目的了。通过代码覆盖率测试,还可以找出没有执行过的冗余代码,这样可以减少安装包的大小。借助精准测试方法,通过精准测试系统,分析测试用例以及代码映射关系,可以进一步确定测试用例的覆盖情况。这样就可以选择适当的测试用例保证合理的覆盖度。详细的原理方法可以参见第10章。
上文提到的优化测试策略都是从黑盒的角度进行分析的,因为黑盒测试有局限性,测试有效代码覆盖率只有35%~65%,那么如何保证黑盒测试没有测试到的部分代码的稳定性和可靠性,就需要进行白盒测试。业界通常采用的是单元测试。通过合适的单元测试,可以让代码覆盖率达到75%以上。但是由于单元测试的工作量比较大,刚开始不可能对全部代码进行单元测试,所以可以考虑先用黑盒测试,借助代码覆盖率工具,找出黑盒测试没有覆盖到的代码或模块(有可能某些代码属于冗余或者死代码),然后对这部分代码进行单元测试,这样可以最大限度地提高覆盖率,更好地保证代码质量。