害怕测试不完备？试试华为结构化测试方法 MFQ

笔者来自 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

笔者对 Kylin 进行了最基础的 MFQ 分析，针对每个功能属性可以继续枚举场景和输入。

△ 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 的 Dinstinct 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 的测试范围，简单来说就是圈定功能边界，这里主要依据功能流程图进行划分。

△ 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）功能合理性、产品安全性、用户体验、产品潜在风险等使用质量属性。

在这里具体列举一下：

产品质量属性：安装升级卸载测试 、性能测试 、稳定性测试、兼容性测试、安全性测试

使用质量属性：产品文档测试、用户体验测试、功能合理性检查等

5）对 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 的 Q（质量属性）很多，需要测试的覆盖面广。进行测试分析时，需要对非功能特性逐一进行测试分析。

作者简介：周冬冬 ，非著名测试工程师一名，五年测试经验，参与过华为海思项目，中兴 5 G 项目测试，目前主要负责 Kyligence Insight & MDX 的测试工作。