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

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

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

    产品或应用的天然模块划分模块化

    产品或应用中功能的类似性,把类似的功能分到一个小盒子中单元测试

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

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

 

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

从原理上讲,按照必定的标准把须要测试的产品分红不一样的模块后,功能测试团队就能够对小的模块按照功能测试流程进行完整的测试。把大黑盒子分块后,对每一个小盒子分而治之,因为小盒子模块更小,更灵活,下降了功能测试的复杂度,更容易在小盒子里面抓到虫子,这将大大下降定位虫子的时间和难度。blog

每个迭代过程,要确保该迭代过程交付的功能点都被功能测试覆盖到,同时确保随着迭代过程的深刻,全部的功能点都可以被有效地经过回归测试覆盖,保证小盒子交付的质量。资源

客户的反馈——虫子依然存在么?产品

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

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

 

 

尾声

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

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

 

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

相关文章
相关标签/搜索