笔者来自 Kyligence 产品及创新中心的测试团队，我们的产品 Kyligence Enterprise 以 Apache Kylin 为核心，面向企业级客户，提供更加丰富和稳定的功能，因此对产品质量有更高要求。鉴于Apache Kylin的广泛应用，我们对 Apache Kylin 的测试进行了测试分析，希望能够帮助到 Kylin 的使用者更快速找到测试Kylin的方向，不断提升Apache Kylin 的产品质量。
本文主要依据MFQ的方法对Apache Kylin的测试进行测试分析
一 、 MFQ简介
MFQ是一种测试分析的方法，帮助测试设计人员，快速抓取关键信息，完成测试设计。
MFQ主要概念：
1、KYM
KYM（Kown Your Mission），即了解自己的测试对象。对于测试设计人员来说，需要从不同的维度去了解、分析测试对象，在分析过程中，有任何疑问均可以罗列出来，同时记录下获取到的信息。
KYM通用的维度可用如下引导词来标识：CIDTESTD，即：Customer、Information、Developer Relations、Test Team、Equipment&Tools、Scheduler、Test Item、Deliverables。
KYM可以根据不同的测试对象灵活变通，其目的是了解测试对象，不需要生搬硬套。
2、TCO
TCO(Testing Coverage Outline)，即划分测试范围，圈定测试的边界，对测试的对象进行拆分，枚举出需要测试的要点，目的就是梳理测试覆盖大纲。
在产品演进的过程中需要根据产品变更，持续更新KYM和TCO，可以由各种角色成员一起梳理。
3、MFQ
其中TCO中最重要的是要识别出M、F、Q：
M：基于模型的单功能测试分析和设计；简单介绍 M即一个相对完整的单功能，每个人的划分方式可能不一样，原则上只要覆盖完整，方便度量测试的输入和输出即可。M的划分是基于对产品功能流程对了解，可以将产品的功能流程分解为几个独立的功能。
F：功能交互测试分析和设计；由存在交互的M组成，可以先完成M的交互组合，然后根据业务剔除不存在交互的部分
Q：质量属性测试分析和设计；各个产品的侧重点不同，大体上包含：稳定性/易用性/兼容性/一致性等非功能属性。
4、建模方法PPDCS
通过TCO对需求的整理之后，划分了单功能和功能交互点，这时的输出物还只是测试点，不足以支撑整个测试，还需要对具体的单功能使用建模方法。
PPDCS(Process，Parameter，DATA，Combination，State)这是五种建模方法，可以根据测试对象和个人喜好灵活选择。
在业务流程建模后，根据业务场景进行场景划分，再根据输入的数据进行二次划分，然后再根据业务中的特性进行补充。
5、TCON
TCON(Test Condition)即确定测试场景和测试输入输出，在业务流程建模后，根据业务场景进行场景划分，再根据输入的数据进行输入划分，然后再根据业务中的特性进行特殊输入补充。根据不同输入确定其输出，就完成了测试用例的基本内容。
总结：MFQ需要团队每个成员参与完成测试点的梳理，MFQ不是一次性过程，需要在迭代演进中针对产品需求和风险点进行补充修改。
二 、使用MFQ分析Apache Kylin
下图是进行了最基础的MFQ分析，针对每个功能属性可以继续枚举场景和输入。
1.KYM
Apache Kylin是什么？组件包含那些？工作流程？有那些外部依赖？有什么优缺点？这是用来几个完成KYM的问题，大家可以再进行补充。这些信息大家可以到Apache Kylin的官网上去获取 网址为：http://kylin.apache.org/cn/
信息的收集需要各个角色去进行不同角度的补充，本文信息收集主要来自开源社区，对细节未详细展开。本文从功能特性，组件，工作流程，构建引擎，客户群体，优缺点等角度收集信息。
功能特性：
1）分布式预处理的大数据查询加速引擎 --亚秒内返回查询结果 2）提供Hadoop/Spark之上的SQL查询接口,支持jdbc/odbc/restful 3）支持超大规模数据 4）多维分析（OLAP）能力 5）可以对接BI工具（如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet）6）定义数据集支持星形和雪花形模型7）支持MOLAP CUBE构建 8）Job管理与监控 9）支持cube的增量更新 10）利用HBase Coprocessor 11）基于HyperLogLog的Dinstinc Count近似算法 12）友好的web界面以管理，监控和使用立方体 13）项目及表级别的访问控制安全14）支持LDAP、SSO
主要组件：
1）REST Server: 2）查询引擎（Query Engine）3）路由（Routing） 4）元数据管理工具（Metadata）5）任务引擎（Cube Build Engine）6) 存储引擎（Storage Engine）
工作流程：
1）同步数据源，定义数据集上的一个星形或雪花形模型
2）在定义的数据表上构建cube
3）使用标准SQL通过ODBC、JDBC或RESTFUL进行查询，仅需亚秒级响应时间即可获得查询结果
客户群体：
企业用户为主，主要是规模较大，拥有数据量较大的企业例如ebay 思科 三星 百度 京东等
优点：
查询速度快，支持多种BI对接
缺点：
存储cube需要占用的空间大，cube构建时会影响查询速度
构建引擎种类：
MR，Spark
信息收集需要持续进行，本文只是简单列举一些，作为示例
2.TCO
确定Apache Kylin的测试范围，简单来说就是圈定功能边界，这里主要依据功能流程图进行划分。
上图其实就是我们的TCO，包含Apache Kylin组件和数据源（hive /kafka /RDBMS）
从业务流程只有以下两种：
1）cube构建
2）实时查询
这两个业务功能以及覆盖的组件就是我们的测试的范围。
测试范围的划分原则就是以功能的起止点为边界进行划分，依赖组件的测试也属于测试的一部分。
3、MFQ的划分
MFQ主要工作是找到M，M的拆分则是根据TCO进行拆分和建模，怎么进行拆分和建模呢？
1） 功能拆分
M即一个完整的功能，以Apache Kylin为例，按照功能进行拆分可以拆分出两部分，查询和cube构建，根据场景的不同，又可以拆分成四个：
M1: cube构建（包含模型构建）
M2: 实时查询--命中cube
M3:实时查询--命中数据源（可以与M2合并分析）
M4:cube的增量构建（可与M1合并分析）
上述的拆分是根据对功能的理解进行的，其实只要覆盖完整且便于测试，拆分可以灵活选择功能切割点。
例如拆成三部分：
M1: 构建模型
M2: 构建cube
M3: 实时查询
2）功能建模
建模就是功能的抽象，可以快速找出功能测试需要覆盖的场景，建模方法灵活选择，以cube构建为例，进行功能流程图建模，这里以文字表述：
数据源导入（数据源参数）--确定模型信息（模型参数）---确定cube信息（cube参数）--执行cube构建（构建参数）。
根据以上步骤中的参数进行合理组合，可以完成cube构建这个单功能的用例。
case示例：
输入：数据源为hive，模型为雪花模型，cube参数默认，构建参数默认，执行构建。
输出：有cube生成，cube明细参数符合输入，进行查询能在亚秒内返回结果。
3）功能交互
F的划分则是对M进行排列组合，然后去除不存在业务交集的部分，具体可以查看贴图
4）质量属性补充
Q主要是根据产品的非功能特性进行补充测试，大家可以从以下维度进行分析：
1）功能适用性、效率、兼容性、易用性、可靠性、安全性、可维护性和可移植性等产品质量属性
2）功能合理性、产品安全性、用户体验、产品潜在风险等使用质量属性
在这里具体列举一下：
产品质量属性：安装升级卸载测试 、性能测试 、稳定性测试、兼容性测试、安全性测试
使用质量属性：产品文档测试、用户体验测试、功能合理性检查等
对web界面的测试分析，可以按功能展开：
1）安全（登录，注销，注册，鉴权）2）项目管理（增删改查）3）模型管理（增删改查）4）cube管理（增删改查）5）页面监控 6）任务管理（查看，停止，删除，暂停）7）系统管理（参数配置，权限管理，用户管理，组管理）8）国际化和界面提示测试
4.TCON
这部分主要根据功能流程和业务确定测试用例的场景（预置条件），输入和输出。 测试用例要求输入输出明确，操作指导清楚易懂，通过标准清晰。
以cube构建为例：
预置条件：Apache Kylin安装成功，数据源为hive
操作：
1）登录Apache Kylin， 进入建模功能单击同步数据源的按钮，同步数据源中的表A，B，C
2）单击创建模型，选择同步的表A ，B，C 根据提示完成模型创建
3）单击创建cube，选择刚才创建的模型，根据提示完成cube创建
4）单击cube上的构建按钮，查看任务监控
预期（通过标准）：
1）登录成功 ，表同步成功。
2）模型创建成功，列表展示正常，可以在对应数据库中查看到记录
3） cube创建成功，列表展示正常，可以在对应数据库中查看到记录
4）任务执行正常，成功后可在hbase中查看到cube对应的所有cuboid。
三、Apache Kylin在使用MFQ上需要注意的事项：
1.Apache Kylin的各个子功能划分清晰，可以快速完成功能建模，在交互场景设计时，充分考虑实际使用场景，避免设计脱离实际业务场景。
2.需要注意对外部依赖的测试例如hadoop平台，数据源类型等，对数据需要考虑数据本身各类异常情况。
3.作为一个面向企业级用户的软件，测试设计主要覆盖其核心价值，对异常场景的测试可以作为补充，不建议投入过多精力。
4.需要对数据规模和资源消耗进行一个相关性评估，作为商用收费标准的基本参考
5.建议可以由团队的各个角色对MFQ进行多个角度补充，最后集中评审，保证测试质量。
6.Apache Kylin包含web界面，测试时需要考虑接口测试和web测试，考虑用户使用体验。
7.除了功能特性之外，在Q中列举了较多的非功能特性，需要逐个进行测试分析。
8查询的SQL语句，建议生成一个SQL集，作为测试的输入，查询接口是Apache Kylin对外暴露的服务接口，可以多投入一部分人力到这个接口上。
四、总结
综合分析下来，Kylin 的功能强大，功能流程明确，非常适合使用MFQ的方法进行测试分析。Kylin的非功能特性（MFQ中的Q）很多，需要测试的覆盖面广。进行测试分析时，需要对非功能特性逐一进行测试分析。
