从MFQ方法到需求分析
前几天看了一篇性能测试相关的文章：性能测试模型初探及应用方法分析，其中提到了MFQ分析方法。专门去查阅了MFQ相关的一些资料，学习了一番。
之后想起了以前看《Google的软件测试之道》这本书时，书中提到的一种测试分析方法：ACC分析方法。
还有我个人在工作学习中总结的一个分析方法：象限分析法。
这篇博客，对这三种方法进行一个简单介绍，仅供参考。。。
参考资料：
一、MFQ方法
MFQ是由邰晓梅提出的一种结构化的思维以及测试分析和测试设计方法，分为四部曲。整个四部曲之间实质上是全貌到细节，整体到部分的关系。
它运用启发思维的方式让大家从不同的维度对需求进行进一步了解，从测试的角度重新定义需求，结构化的思维方式辅助图形化工具使得场景遗漏概率降低。
MFQ的四部曲分别如下：
1、KYM
KYM（Kown Your Mission），即了解自己的测试对象。对于需求承接者来说，需要从不同的维度去了解、分析需求，在分析过程中，有任何疑问均可以罗列出来。
KYM通用的维度可用如下引导词来标识：CIDTESTD，即：Customer、Information、Developer Relations、Test Team、Equipment&Tools、Sheduler、Test Item、Deliverables。
2、TCO
TCO(Testing Coverage Outline)，即从测试的角度对原始需求进行提炼，提炼出对测试有用的测试点，并且对提取出的信息进行重组，识别出需求中的风险，做到对需求心中有数。
KYM与TCO均不是一次性过程，并且需要各种角色成员一起梳理，其中TCO中最重要的是要识别出M、F、Q：
M：基于模型的单功能测试分析和设计；
F：功能交互测试分析和设计；
Q：质量属性测试分析和设计；
3、建模MFQ&PPDCS
通过TCO对需求的整理之后，划分了单功能和功能交互点，这时的输出物还只是测试点，不足以支撑整个测试，还需要对具体的单功能使用建模方法。
PPDCS(Process，Parameter，DATA，Conbination，State)建模方法从不同维度设立了建模思路，下面简单介绍一下其中三种建模方法的适用场景：
Parameter：需求中或者划分出来的单功能或者功能交互点有许多参数，且这些参数相互之间有一定的业务规则约束，即某些参数之间组合才能符合需求。
DATA：需求中或者划分出来的单功能或者功能交互点有许多参数，但是这些参数之间没有业务规则的约束。
State：需求中或者划分出来的单功能或者功能交互点涉及多种状态，且各种状态之间由于某些业务规则，能够相互转换。
4、TCON
根据上一步建模的测试场景，生成TCON，用上述判定不同情况下的测试条件转变，TCON这里可以理解为TestCase。
总结：MFQ需要团队每个成员参与完成测试点的梳理，并且，MFQ不是一次性过程，需要在迭代中针对任务完成情况以及风险点进行及时纠正及完善。
二、ACC分析方法
来源：《Google软件测试之道》
具体可参考我之前的博客：《Google软件测试之道》测试工程师
ACC（Attribute Component Capability）分析方法即：特质、组件、能力。这是从Google众多测试团队实践中总结的一个优秀流程，受众较多，搜索“Google Test Analytics”即可找到。
ACC指导原则如下：
①避免散漫的文字，使用简明的列表；
②不必推销（测试计划的受众是工程师）；
③尽量简洁（测试计划的大小和测试问题的规模有关，和作者的写作欲望无关）；
④渐进式的描述（make it flow）：测试计划的每个部分应该是前面部分的延伸；
⑤指导者的思路（一个好的计划过程可以帮助计划者思考产品功能及其测试需求，有条不紊的从概念过度到直接实现的低层细节）；
⑥最终结果应该是测试用例（测试计划最直接的体现就是可以清楚的指导测试用例的编写）；
A：代表特质（Attribute）
在设计测试计划或者做ACC分析时，必须先确定该产品对用户、对业务的意义；比如：为什么开发它？能带来什么价值？怎样吸引客户？核心竞争力是什么？等等。。。
特质代表了产品的品质和特色，是区别于竞争对手的关键。
C:代表组件（Component）
组件是构成待建系统的模块，在特质被识别后确定，组件是使一个软件之所以如此的关键代码块；实际上，它们是测试人员所要测试的对象。
C：代表能力（capability）
能力（功能点）代表系统在用户指令下完成的动作。它们是对输入的响应、对查询的应答、以及代表用户完成的活动。
能力一般是面向用户的，表达用户眼里系统的行为，它最重要的一个特点是它的可测试性。
关于能力点分析的一种方法：
上图是一个以特质为X轴、以组件为Y轴的表格，通过这种方法将功能点映射到特质和组件上。其中有很多空格，它表示：只有部分组件对该特质有影响（不是每个组件都对特质有影响）；
能力表的每一行或列表示按某种方式相关联一个功能点切片，这样可以将应用功能分解为多个可测试点的办法。单元格中数字表示该组件满足此特质能力的数量，数字越大，该交叉点需要！
测试的测试点越多，这些能力点可以方便指定组件/特质对的需要的测试；可以以这些功能点直接涉及测试用例，或将它们组合成更大的用例或测试场景。
注意以下几点：
①每个功能点至少对应一个用例
②重要的功能点对应多个用例
③并非所有的功能点都是同等重要的，区分优先级很重要
三、象限分析法
这个方法是我个人阅读《高效能人士的七个习惯》这本书后总结出来的，可能不是首创，但也包含了个人的一些思考和总结。方法如下图：
说明：
这个方法的原则就是将测试需求根据不同维度和等级划分为四个象限，然后进行对应的填充，在具体的测试执行过程中，根据具体情况（比如资源、时间等）进行优先级执行。
上图是我去年这个时候画的，按照需求的功能、非功能、重要、不重要四个维度划分。此刻写这篇博客的时候，想到了其他的不同维度，比如：优先级、实现难易程度等。
有一定测试经验的童鞋应该都了解，在国内目前的大环境下，测试的时间和资源往往都是不够的，这种情况下如何做取舍，降低上线的风险程度是必须衡量的。
根据需求分析的结果，进行不同维度划分，可以更好地安排接下来的测试工作，做到合理取舍，降低上线风险。
PS：无论是MFQ还是ACC或者象限分析法，其实都需要根据具体情况（比如团队成员构成，技术水平，职业素养，资源），进行合理的划分和分析，由简入繁。
以上内容仅供参考，如有更好的意见，可以提出来，一起交流讨论。。。
