如何测试Android组件化

Android组件化调研——知己知彼

基于倒推的思路，要评估测试策略，本质上我们需要了解测试回归范围，而测试回归范围依托于开发改动的影响范围，但若要与开发沟通改动和影响范围，我们最好先了解下Android组件化。 提到“Android组件化”这一名词，第一时间可能会想到以下这些问题：什么是Android组件化？为什么要进行Android组件化？Android组件化有什么好处？想要了解Android组件化，我们需要进行调研学习。

• Android组件化

1、Android组件化概念 组件化大致可分为功能组件化和业务组件化。功能组件化，常见的是将一些底层的公共功能模块进行独立化，如网络请求模块、登录注册模块等。业务组件化，即为业务模块独立化，彼此无关联，由一个项目工程拆分成若干个业务模块，由App主工程提供统一的入口，每个业务独立的模块共享项目的依赖库。

2、为什么要进行组件化 在Android项目组件化之前的单一工程，代码的耦合严重，每修改一处代码后就会到处报错，且都要重新编译打包测试，非常耗时，增加了项目的维护成本，很难进行多人协作开发。另外，在单一工程中很难进行单元测试。 当前APP版本迭代的频率越来越高，新功能的不断增加，业务也会变的越来越复杂，单一工程已经很难适应当前的项目业务需求环境。 3、Android组件化的优点 1）各个业务模块组件独立化，降低业务耦合，更适用于快速的业务迭代； 2）稳定的公共模块采用依赖库方式，提供给各个业务线使用，减少重复开发和维护工作量； 3）加快编译速度，提高开发效率； 4）自由选择开发框架； 5）方便做单元测试； 6）代码架构更加清晰，降低项目的维护难度； 7）适合于团队开发，各业务研发可以互不干扰、提升协作效率。 4、Android组件化常见问题及需关注点 1）共享数据资源/方法调用问题； 2）组件之间的调用和通信问题； 3）组件之间的资源名冲突问题；

Android组件化回归范围确定——谋定后动

在对Android组件化的基本概念和关注点有了初步调研后，接下来，是与开发沟通开发实现方案，进而从实际工程角度了解改动影响范围和建议回归范围。 将调研的有效信息与沟通后的信息进行整合，整理出最终的Android组件化改动范围和影响范围。 举个栗子，比如搜狗手机浏览器积分中心需求中的积分任务： 1、测试角度评估回归范围 首先，我们根据调研了解到的Android组件化的特点及关注点，从测试角度评估初步的影响范围和回归范围，这具体包含：积分任务的主路径功能、各个积分任务与其他模块的交叉功能点（例如搜索任务，涉及到积分中心模块与搜索模块的功能交叉）、积分任务的各个网络请求等公共库调用的正确性等； 2、了解工程角度改动范围及建议回归范围 然后，在与开发的实际沟通中，我们了解到，开发给出的改动影响范围与我们的调研结果基本吻合，建议回归范围为：该模块的主路径功能及与模块交叉点的主路径功能； 3、确定最终回归范围 最终，我们整合第1步和第2步中的改动影响范围及回归范围，确定积分任务的最终的影响范围及回归范围： 1）影响范围：不涉及到具体模块功能逻辑，需要关注主路径功能及与其他模块间的交叉功能。 2）回归范围：积分任务主路径功能：积分任务主路径功能，及各个积分任务与其他模块的交叉功能点（冒烟级别粒度）。

Android组件化测试策略制定——运筹帷幄

在做好一切准备工作之后，接下来就是制定测试策略。首先，是制定各个模块的测试策略，进而站在全局角度，确定整体的项目测试策略。 模块的测试策略的制定，这里我们仍以上面的积分任务为例，在确定最终的回归范围后，我们分析回归范围对应的case级别，得出该功能的测试策略结论，即为执行冒烟级别的回归测试。 确定了各个模块的测试策略后，考虑到本次Android组件化的特点，从全局角度出发我们制定了整体的测试策略，如下所示： 1、整体各个模块进行冒烟/二轮粒度的测试； 2、在测试过程中，根据实际bug情况实时调整测试策略； 3、提高随机测试的安排次数。 至此，已完成了Android组件化这一工程优化需求的测试策略评估，接下来就是开始正式的测试阶段。