重读《从菜鸟到测试架构师》-- 对黑盒子的全方位照明

上回说到，小艾学会了分而治之的方式来将模块细化作功能测试，这样的好处是更容易找到bug，但尽管容易找bug，并不表示bug就能彻底被找到，而不被交付到客户手里。也出于对客户发现的bug进行分析，组长告诉小艾，不只仅须要分而治之，也须要合而治之。

上一章咱们也提到一个名词：跨模块/解决方案的功能测试，即功能集成测试，其实这就是为了确保全部的功能特征，或者User Story在一个产品或应用的开发过程当中可以被完全测试，而对产品的各个模块或者解决方案，按照用户的使用方式，根据模块/解决方案间的逻辑关系，设计跨越多个模块/解决方案的端到端的功能测试场景和功能测试用例，利用其对系统进行全面的功能测试。

找到小盒子间的虫子——合而治之

在开发跨模块/解决方案的功能测试场景时，一个重要的策略是对商业逻辑的梳理，明确可能的实际商业场景，经过对实际商业场景的理解，开发出跨不一样模块/解决方案的端到端的功能测试场景。

另一种就是基于模块之间的消息传递，进行技术层面的验证，确保技术上的正确性，还有就是基于不一样产品之间的集成，作产品集成的跨产品的集成测试。

跨模块/解决方案功能测试的测试场景应该被定义为：经过一个模块或者解决方案的不一样的输出及这些输出是怎么做为其余模块或者解决方案的输入，而定义的可以体现这种整合或者合并的功能测试场景。

说完上述的定义以后，组长告诉小艾这么作的目的是可以确保基于实际的商业流程，以及数据流程的测试完备性。

举个栗子

在跨模块/解决方案的情景下，有一个很典型的例子，假设某电商网站有两个模块，其一用做产品管理，其二实现搜索功能，两个模块是不一样的测试人员进行测试且经过的，会不会有一种状况，当咱们在产品管理模块将某产品进行删除操做，但依然可以被用户搜索出被删除的产品？ 

答案是有可能的。缘由多是同步机制没作好，可能搜索产品使用了缓存技术，因为缓存缘由即便产品被删除，也一样可以被搜索。 

有的产品是基于模块开发，其自己就是由若干个小的产品组成的，所以进入集成开发阶段时作的测试也是一种常见的“合而治之”的例子。 

有些产品会须要与不一样产品进行集成来互相取长补短，完成真正的用户商业流程，在这样的应用开发场景中，须要作充分的产品集成测试来确保功能、性能的可靠性。

 

不管是上述哪一种状况，都要充分理解实际的商业需求和流程，进而定义完备而准确的功能测试和测试用例来作到对黑盒子的彻底照明。

 

策略高手

经过这段时间对功能测试项目的完整参与，小艾不只积累了丰富的执行经验和各类功能测试技能，同时在组长的帮助和本身的努力下，对功能测试的测试策略也有了比较深入的体会，因而，小艾作出了以下的总结：

功能测试范围

在定义功能测试范围时，要兼顾功能测试的各个不一样层面，如UI Testing（界面测试）,与API/Command level Testing（API或者命令层的测试）的测试用例的比例关系。 

与其余类型的关系

一个大型产品的测试都是复杂的，会涉及不一样的测试类型。在考虑功能测试的时候，必定要考虑到和其余测试类型的交叉与依赖关系，这里须要提到的是，被选为回归测试的功能测试用例的经过，每每是性能测试开始的标志。而从测试环境的选择上考虑的话，除了要在纯粹的运行时环境中测试产品的功能以外，还要考虑在客户化的环境及移植后的环境去测试产品的功能来保证在这些环境里功能可以正常运行。

 

测试覆盖率和测试效率

从功能测试的目的来讲，一方面要保证测试d完整性，达到最大的测试覆盖率，另外一方面，从实际项目开发的角度看，作到100%的没有任何bug的测试是不可能的，所以要充分考虑测试的效率。

功能测试用例自动化开发的策略考虑

自动化对于功能测试是否重复执行是很是关键的。在功能测试策略的层面必定要定义自动化开发的范围，方法，标准，这是功能测试用例重复执行的基线。

功能bug的问题分析

策略层面要明确问题分析的一些具体要求，如提供一系列标准信息来帮助开发人员更好地理解问题、发现问题，找到解决方法。 

工具和模板

定义合适的功能测试工具和各类测试模板是功能测试可以高效进行的策略考虑之一

尾声

迄今为止谈到的功能测试能够说是小艾亲自参与的，关于在大型应用的某版本中对于新功能在开发流程中各个不一样阶段，如何发现隐藏的bug，保证软件质量来进行的针对这些新功能的功能性检查，其实对于一个大型应用的功能测试，从策略的角度，要考查的东西远不止这些。下一章咱们就来看看小艾还学到了哪些与功能测试相关的内容~

 

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