重读《从菜鸟到测试架构师》-- 如何把黑盒子分块

上一章节我们说到，小艾在导师深入浅出的介绍下，终于明白了测试的策略，流程并着手自己写了一条测试用例，而在执行的过程中，小艾也终于使用自己的手电发现了第一个bug。然而一个大的Java EE产品或者应用，通常代码量巨大，业务逻辑及体系架构都非常复杂，对于这样的产品或应用，如果采用简单的方式从整体上测试其功能，是没办法面面俱到的。

小艾可以理解把产品或者应用进行模块化或基于解决方案的分解的好处，但并不知道该如何将产品或应用进行模块化。就这个问题，小艾找到了组长，组长告诉小艾，其实分块没有固定的原则，不过从操作层面上，一般有以下考虑因素：

    产品或应用的自然模块划分

    产品或应用中功能的相似性，把相似的功能分到一个小盒子中

    功能测试团队的资源（主要是人员）情况，实际的项目中要考虑资源状况，对其进行粒度合适的功能模块分解。

其中，合适粒度非常重要，并非模块分的越多越细就越好。粒度过大会带来在同一个功能测试计划书中涵盖的细节过多，功能测试用例的量级也越大，易读性、可控性变差。而粒度过小会造成整体功能测试计划书的量级太多，人员分配凌乱，可控性变差，后续回归的复杂度也会提升。

 

如何精准找寻某一种bug —— 分而治之

从原理上讲，按照一定的标准把需要测试的产品分成不同的模块后，功能测试团队就可以对小的模块按照功能测试流程进行完整的测试。把大黑盒子分块后，对每个小盒子分而治之，由于小盒子模块更小，更灵活，降低了功能测试的复杂度，更容易在小盒子里面抓到虫子，这将大大降低定位虫子的时间和难度。

每一个迭代过程，要确保该迭代过程交付的功能点都被功能测试覆盖到，同时确保随着迭代过程的深入，所有的功能点都能够被有效地通过回归测试覆盖，保证小盒子交付的质量。

客户的反馈——虫子依然存在么？

按理说，我们分而治之更容易抓到虫子，这样交付的产品应该是完美的，但真的是这样么？

通过客户的试用，依然发现了一些bug，而通过对客户寻找的bug进行分析发现，比较典型的是功能测试团队只考虑了模块测试，而忽略了对业务的端到端的功能测试场景的设计，这种功能测试往往是跨几个不同的功能测试模块，或者不同的解决方案之间的集成。

 

 

尾声

组长告诉小艾，一个完整的功能测试一定是在进行了单元测试之后，对产品进行基于模块化或基于解决方案的测试，对产品进行分而治之，然后进行跨多个不同模块，或解决方案的跨模块/解决方案功能测试(Cross Component/Solution Testing)，或称为功能集成测试，从而达到对小盒子内部及盒子间的完全的功能测试覆盖。

小艾这才明白为什么将模块细化测试却依然还会有bug能够跑到客户手里。组长接下来会告诉小艾如何做来完善功能测试呢？请听下回分解。

 

想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月