好久没写自动化测试的文章了，忘了自己的主业，实在是罪过罪过。今天就来点热闹的，抛个砖。分享一个我对某个案例的看法。题目虽然看起来比较晦涩，而且有堆砌关键词的嫌疑，但是我相信还是比较贴切的。

       相信现在业界都还是认为白盒测试是比较高级的一种测试，因为他会涉及到开发的具体逻辑，需要测试人员有读代码的能力。

　　我也部分同意这种看法，但是我认为，黑盒测试在某种意义上，尤其是自动化测试上，是非常具有意义的。

　　为什么这么说？我们来讲一个案例。

　　一个电子商务的网站的同事向我描述了他目前的测试任务，问我如何快速的，健康的测试。他的测试任务是，测试这个网站的接口函数。所谓接口函数，就是目前大部分正规一点的网站，都会进行分层架构，将自己的业务逻辑做一个封装，封装成为不同的内部函数，或者将来开放出去做服务。打个比方，添加一个商品，内部就是一个简单的addAuction()函数，或者是一个auction.add()对象方法，而不是去直接写SQL语句去数据库中取得。得到一个商品，就是getAuction(auctionID)，或者是auction：：get()对象方法。

　　我认为这么做很好，对公司下一步的规范化非常有好处。于是我问：“那么你是怎么测试的呢？”

　　同事的测试方法让我很惊奇：“我们写了一些SQL语句对数据库进行操作，如果需要验证getAuction的时候，就使用SQL语句在数据库里面插入了相应的数据，然后调用getAuction函数。如果要验证addAuction方法，就调用方法，然后写SQL语句去数据库中取数据出来，看看是否正确。我们甚至写了SQL的生成器帮助我们的测试人员进行SQL的编写。”

　　“那问题在哪儿呢？”我问。

　　“问题在于，当电子商务网站涉及到复杂的各种商品、店铺、库存、财务信息的时候，这个系统的接口就会变得很复杂，表现在数据库层面，就是数据库表之前的关联非常复杂，各种多对多一对多的约束让表的数据制作变得异常复杂。一个场景，往往需要很多的SQL语句造数据，最要命的是，当SQL语句积累到一定程度的时候，场景测试代码变得不可维护。”

　　对于这个案例，我认为测试人员的问题在于：你知道的太多了。

　　为了确认我的猜想，我问他：你确认所有的开发的前端代码，都会调用接口层，而不是去直接和数据库交互吗？

　　他说是的，目前公司要求分层，所有的开发代码都需要从接口进行调用。这样，我就很放心的下了这个结论。

　　我的建议是：抛弃掉所有的SQL层面的东西，直接调用开发的代码进行数据的制造。

　　这位同事的眼睛都瞪大了：“怎么能这样？我怎么知道开发是不是把正确的数据写到了数据库？？”

　　“你不需要知道”，我说，“之所以造成目前的问题在于，你拥有的数据库知识，帮了你的倒忙。如果你把被测试对象当做一个黑盒，你的测试用例将会好很多。”

　　“我还是不明白，如果我不在数据库层面验证是否正确，我怎么知道开发的程序是对的？”

　　“假设你测试添加商品这个方法，不管开发是把这些商品信息写在数据库上，还是写在纸上，最后开发获取商品的方法，是不是都是通过getAuction()来获取？”

　　“嗯，是的”

　　“那谁在乎你的商品是不是写在数据库里？即使你把它写在了纸上，只要在getAuction()函数中可以拿到，就可以满足功能要求啊？”

　　“好像懂你的意思了，但是如果不是写在数据库里，我怎么保证他的性能呢？”

　　“具体这个函数的性能怎么样，我们靠性能测试来保证，如果写在纸上也能满足性能要求，我觉得，就让他写在纸上吧，这样也挺创新的。另外一个方面，就是你把它写在数据库里面了，你也不敢说他的性能就好啊，还是要进行性能测试。”

　　“嗯，这倒是值得一试，因为这么写测试用例，测试人员的效率肯定会提高不少，因为不需要去处理复杂的数据库约束关系。”

　　“不止这样，将来测试用例的维护性也会非常好。开发人员对表字段的修改和你不相关，测试用例照样运行，开发人员对表直接依赖关系的修改也和你没有关系，甚至将来开发使用NoSQL替换掉数据库系统，你对测试用例的维护成本也会很低。”

　　上面这个案例中，我们用黑盒测试的方法，取代掉了白盒测试的方法。而对于测试人员的效率提升将会是非常有帮助的。

　　为什么这样呢？因为黑盒就像是面向对象的封装一样，封装掉了你不需要知道的所有的事情，你不需要知道文件是不是这么存储的，不需要知道是不是写入了数据库，因为所有的表象可以证明这一切，甚至是你根本不关心是不是使用数据库。这样你的测试用例中的代码，就不会依赖与黑盒里面的东西——因为你根本“不知道”他们存在，代码里没有，那当然就不会因为数据库层面的修改而改变了。

　　但是事情就这么结束了吗？我们的白盒思想跑到哪儿去了？

　　其实这里所谓的黑盒测试，是指我们的自动化测试代码要黑盒，测试代码中不要出现任何盒子以内的东西，而我们的测试用例设计，还是可以使用白盒的方法，对盒子内部的代码进行查看，对分支进行判断，以确认自己的测试用例设计足够全面，也就是通过白盒的分析方法，编写黑盒测试用例进行测试，也就是用白盒的思想黑盒地测试。

　　最后要说明的是，这种测试方法当然不能保证会比全白盒测试覆盖更加广泛。但是，处于项目工期压力的测试人员，使用这种方法可以写出最快速，最可维护的代码，我相信，性价比是可以的。更何况谁也不能做到100%的覆盖，我用50%的时间覆盖90%的测试点，总比用200%的时间覆盖95%的测试点要经济吧。