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

周冬冬
Kyligence 测试工程师
2020年 1月 08日

笔者来自 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 的测试工作。