文 | 赵哲鸿
关于MFQ，本文将从以下几个方面一一道来：
why：为什么要学习MFQ
how：如何在团队实践MFQ
What：什么是MFQ
Some thoughtover MFQ：在实践中的一点感悟
乍一看文章的结构，大多数读者应该会说，这不就是著名的黄金圈法则嘛！的确，在接受一项任务之前，先思考为什么接这项任务，这项任务主要为了解决什么问题，达成什么目标，为了这个目标，我应该怎么去做，最后再由实践对任务有一个更高层次的认识。整一套流程下来，能使我们事半功倍。下面，先介绍一下为什么学习MFQ。
Why
对于实践敏捷开发流程的团队，要求测试前移，因而对测试的要求更倾向于能够指导开发的测试设计，而非由开发牵引的测试用例。
大部分团队虽然有测试用例，但测试用例的设计没有采用结构化的方法，在测试场景、异常场景上经常有欠缺和遗漏，而MFQ正是一种结构化的思维以及建模工具，能灵活应用于实际的项目之中。
How
谈到how的话，不得不说一下MFQ的四部曲，KYM-TCO-MFQ&PPDCS-TCON，下面以一个实际需求来进一步讲述这四部曲。
需求实例名称：大数据平台支持补丁升级功能
四部曲之一：KYM
KYM即Kown Your Mission的意思，了解自己的测试对象，对于需求承接者来说，需要从不同的维度去了解、分析需求，在分析过程中，有任何疑问均可以罗列出来。KYM通用的维度可用如下引导词来标识：CIDTESTD，即Customer、Information、Developer Relations、Test Team、Equipment&Tools、Sheduler、Test Item、Deliverables。依据需求设计的KYM如下图所示：
四部曲之二：TCO
TCO(Testing Coverage Outline)，即从测试的角度对原始需求进行提炼，提炼出对测试有用的测试点，并且对提取出的信息进行重组，识别出需求中的风险，做到对需求心中有数。KYM与TCO均不是一次性过程，并且需要各种角色成员一起梳理，其中TCO中最重要的是要识别出M、F、Q：
M：基于模型的单功能测试分析和设计
F：功能交互测试分析和设计
Q：质量属性测试分析和设计
下面给出上述需求对应的TCO图：
通过团队成员的共同努力，对单功能和功能交互点进行了划分，并识别出了后续建模需要用到的DATA属性，接下来，就要开始实施四部曲中的第三部了。
四部曲之三：建模MFQ&PPDCS
通过TCO对需求的整理之后，划分了单功能和功能交互点，这时，输出物还只是测试点，不足以支撑整个测试，还需要对具体的单功能使用建模方法，经过分析，一致认为针对M，可以用PPDCS中的P(Process)来进行建模，这里，不使用别的建模方法(Parameter，DATA，Conbination，State)，因为划分出来的单功能包含多个步骤，且每一个步骤有一定的前后约束关系。下面简单介绍一下其余四种建模方法的适用场景：
Parameter：需求中或者划分出来的单功能或者功能交互点有许多参数，且这些参数相互之间有一定的业务规则约束，即某些参数之间组合才能符合需求。
DATA：需求中或者划分出来的单功能或者功能交互点有许多参数，但是这些参数之间没有业务规则的约束。
State：需求中或者划分出来的单功能或者功能交互点涉及多种状态，且各种状态之间由于某些业务规则，能够相互转换。
下面给出对单功能Model的建模图：
在TCO步骤中，已经识别出几个参数，下面对划分出来的所有的Function的最末端的测试场景进行DATA方法建模，建模的结果用判定表表示如下图所示：
当建模完毕，生成测试场景之后，需要对测试场景进行语言描述，即given-when-then用例描述方法，也即四部曲的最后一部TCON。
四部曲之四：TCON
根据上述的测试场景，生成TCON，用上述判定表的前两个测试条件转化，形成的TCON如下图所示：
至此，整个MFQ的流程已经完毕，在这里，再次强调，MFQ需要团队成员齐心协力，一起完成测试点的梳理，并且，MFQ以及PPDCS不是一次性过程，需要在迭代进行中，针对任务完成情况以及风险点对TCO进行纠正以及完善，后期，还要在测试执行以及自动化用例编写，探索性测试上面做一些尝试。
What
MFQ是邰晓梅提出的一套测试分析和测试设计方法，整个四部曲之间实质上是全貌到细节，整体到部分的关系。它运用启发思维的方式让大家从不同的维度对需求进行进一步澄清，从测试的角度重新定义需求，结构化的思维方式辅助图形化工具使得场景遗漏概率降低。
Some thought over MFQ
最后，给出笔者关于MFQ的一些思考。
MFQ的学习对象不仅仅局限于测试，开发以及需求人员也需要学习，对于开发者，有助于理解需求，在做功能之前想清楚需要怎么做，可能有什么坑，也能及时把握风险，尽量把风险控制在能够承受的范围之内。MFQ的推行也需要每个团队成员的齐心协力。当然MFQ要想做好，本质上也是要求目前的每个团队成员能力的提升，比如测试，不仅仅只需要测试技能，还需要熟悉业务，了解一定的代码相关的知识；而对于开发者，也需要具有测试思维，做功能不仅仅局限于只实现基本功能，要多考虑异常场景以及扩展性；而对于需求人员，不仅仅只是对接客户，要能够利用自己的专业知识尽最大可能澄清需求，并且能够指导开发。最后，用敏捷里面提到的思想来作为文章的结尾，QA不是具体的一个人，是一个角色，每个人都要能是QA，只有大家的认识能够保持一致，MFQ才能发挥最大的效果。