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

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

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

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

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

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

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

举个栗子

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

答案是有可能的。原因可能是同步机制没做好，可能搜索产品使用了缓存技术，由于缓存原因即使产品被删除，也同样能够被搜索。 

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

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

无论是上述哪种情况，都要充分理解实际的商业需求和流程，进而定义完备而准确的功能测试和测试用例来做到对黑盒子的完全照明。

策略高手

通过这段时间对功能测试项目的完整参与，小艾不仅积累了丰富的执行经验和各种功能测试技能，同时在组长的帮助和自己的努力下，对功能测试的测试策略也有了比较深刻的体会，于是，小艾做出了如下的总结：

功能测试范围

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

与其他类型的关系

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

测试覆盖率和测试效率

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

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

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

功能bug的问题分析

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

工具和模板

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

尾声

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

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

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