上QQ阅读APP看书,第一时间看更新
1.2.2 按内部逻辑的透明度划分
在现代软件工程实践中,软件测试和软件开发的协作越发紧密,开发和测试的职责界限变得模糊,不再泾渭分明。测试人员需要对软件产品有清晰的认识,对产品架构和内部实现逻辑有一定了解,对软件实现中涉及的编程语言、工具、框架比较熟悉。
按照程序内部逻辑的透明度来划分,测试可以分为黑盒测试(Black-box Testing)和白盒测试(White-box Testing)。
黑盒测试,单纯从用户角度来测试,不管软件内部逻辑(或者说,假定测试人员不了解内部逻辑),只根据产品说明,看特定的输入是否可以产生预期的输出[2]。
白盒测试,按照代码内部实现逻辑来设计测试用例[2],力求全方面地测试业务代码的内部实现逻辑。相对于黑盒测试,白盒测试可以测试程序内部逻辑分支、追踪日志、查询数据库、获取消息队列等程序逻辑的运行状态。
但是,不管是黑盒测试还是白盒测试,它们都有一定的局限性。
对于黑盒测试,由于软件内部实现逻辑不可见,因此即使测试得到了预期的值,我们也不能确定其逻辑的正确性。比如,对于一个简单的数学四则运算的程序,我们设计了如表1-1所示的测试用例。
表1-1 黑盒测试设计范例
如果程序的内部实现很“魔幻”,即不做运算,任何计算的结果都直接设定为2,那么这个程序可以通过这些测试,但是显然它的实现逻辑是错误的,肯定不是一个可以接受的程序。
对于白盒测试,因为程序内部逻辑可见,我们可以设计测试用例,让每个逻辑分支都得到验证。但是,我们无法确认这些逻辑分支处理的是有意义的情况,无法确认这些逻辑的处理达到了设计预期,也无法确认是否有逻辑分支的缺失。
现代软件工程实践鼓励测试工程师结合黑盒和白盒测试,从用户的角度去设计测试用例,用白盒测试辅助确认内部逻辑。