TA&TD测试分析和测试设计方法论(KYM、TOP、MFQ、PPDS)
测试分析与测试设计
Refer：
《海盗派测试分析 MFQ&PPDCS》是2017年1月人民邮电出版社出版的图书，作者是邰晓梅
https://testerhome.com/topics/35193
https://www.cnblogs.com/josie-xu/p/10536592.html
e.g.
https://cn.kyligence.io/blog/test-apache-kylin-with-mfq/
引言
Mike Smith希望人们不要笼统地说 “测试分析与设计”，Test A&D；而是要表达为 “测试分析与测试设计”，TA & TD。因为“测试分析”与“测试设计”是两个不同的测试活动。
他认为“Test Analysis”是个“What Issue”- What are the measures & targets of success for testing？（测试成功的目标和标准是什么？），
“Test Design”是个“How Issue”- How will those measures and targets be achieved？（这些目标和标准如何达成？）。
《海盗派测试分析 MFQ&PPDCS》是由华为 邰晓梅 提出的一种结构化的思维以及测试分析和测试设计方法
KYM、TCO、MFQ属于测试分析TA，输出测试点：
测试分析是一种分析活动，输入可以是前期对系统、设计有帮助的任何信息，如需求、场景、架构、设计、规范、友商信息等。通过测试分析，希望对被测系统能有深入的理解，获得测试点，明确测试深度和广度。
测试点即测试中需要关注的地方，包含测试条件、测试数据、测试观察点、测试预期、测试约束和限制等。
TCON（Test Condition）属于测试设计TD, 输出测试用例：
测试设计是一种设计活动，是依据测试点按照一定的方法和规范要求，得到测试执行依据（即测试用例）的过程。
测试用例是测试执行的依据，一般包含预置条件、部署、标题、步骤、测试数据、预期结果等。
以发送电子邮件的测试点为例
分为四部曲。整个四部曲之间实质上是全貌到细节，整体到部分的关系。
测试活动整体步骤：KYM (了解确定测试任务) --> TCO (输出测试大纲) --> 建模 (MFQ) --> TD (测试设计) --> TE (测试执行）。
它运用启发思维的方式，让大家从不同的维度对需求进行进一步了解，从测试的角度重新定义需求，结构化的思维方式辅助图形化工具使得场景遗漏概率降低。
MFQ的 四部曲 分别如下：
| 阶段 | 步骤 | 项目及任务 | 类别 | 维度 | 侧重点描述 | 方法/内容 | 注释 |
| TA-测试分析 （提取: 测试点） |
步一 | KYM: 了解你的测试对象/任务 | 目标 |
用户、产品和任务 (信息采集和功能理解) |
强调用户需求、产品历史和测试环境分析 | 通用的维度可用如下引导词来标识：CIDTESTD引导词法，即： Customer： 用户需求，痛点，使用场景； Information： 项目历史，文档记录 Developer Relations： 开发人员人数，代码质量，开发自测； Test Team： 测试人员人数，技能配比； Equipment&Tools： 测试所需要的设备，环境，工具； Sheduler： 交付时间，交付方式，测试周期； Test Item： 测试项，测试策略，测试项目优先级； Deliverables：交付件, 测试交付的时间要求和内容要求 |
对于需求承接者来说，需要从不同的维度去了解、分析需求，在分析过程中，有任何疑问均可以罗列出来 |
| 步二 | TOC: 输出测试覆盖大纲 | 要求 | 划分了单功能和功能交互点， | 划分测试范围，圈定测试的边界，对测试的对象进行拆分，枚举出需要测试的要点， 目的就是梳理测试覆盖大纲 |
最重要的是要识别出 M、F、Q，这时的输出物还只是测试点: Time：产品各个节点周期 |
从测试的角度对原始需求进行提炼，提炼出对测试有用的测试点，并且对提取出的信息进行重组，识别出需求中的风险，做到对需求心中有数。 | |
| 2.1 SFDIPOT：启发式测试策略模型中产品元素 | 建模 | ||||||
| 2.2 MFQ: 功能交互质量建模 | 建模 | 单一功能 (PPDS)、功能交互和质量属性 | 涉及功能组合、交互测试和非功能测试要点 | 将被测对象分层，针对不同层次进行测试分析和设计进行，使测试设计人员不会那么容易忘记一些测试的相关点（单功能、功能交互、质量属性等测试点） | |||
| TD-测试设计 （设计: 测试用例） |
步三 | 3.1 PPDCS: | 测试设计 |
流程P、参数P、数据D、组合C、状态S |
完成MFQ的划分后，需要分别针对M，F，Q选择建模方法（PPDCS) | PPDCS ( Process，Parameter，DATA，Conbination，State)，用来细化测试场景测试用例。 | |
| 3.2 TCON: 测试条件 | 确定业务场景，测试输入、输出 | 在业务流程建模后，根据业务场景进行场景划分，再根据输入的数据进行输入划分， 然后再根据业务中的特性进行特殊输入补充。 |
根据不同输入确定其输出，就完成了测试用例TestCase的基本内容。 | 根据上一步建模的测试场景，生成TCON，用上述判定不同情况下的测试条件转变，TCON这里可以理解为 TestCase。 | |||
| TE-测试执行 （整理: 测试报告） |
步四 | 测试执行 |
一、测试分析--KYM (Know Your Mission)理解你的测试任务
在项目的任何阶段介入都可以应用 KYM，KYM 贯穿整个测试项目始终，它不是一次性的行为。
KYM从 用户、产品 和 任务 三个维度深入理解测试任务。
KYM 是启发式的，对于 “基于风险的测试” 中，它是收集信息的重要动作，主要包括 4 个方面的信息收集：了解用户（Customers）、了解项目（Project）、了解产品（Product）、了解任务（Mission）。
KYM 通用的维度可用如下引导词来标识：CIDTESTD引导词法，即：Customer、Information、Developer Relations、Test Team、Equipment&Tools、Sheduler、Test Item、Deliverables。
Test Item: 测试项，测试策略，测试项目优先级 Schedule： 交付时间，交付方式，测试周期 Tools&Equipemnt: 测试所需要的设备，环境，工具 Test Team: 测试人员人数，技能配比 Customer： 用户需求，痛点，使用场景 Information： 项目历史，文档记录 Developer relation：开发人员人数，代码质量，开发自测
Deliverables： 交付件,测试交付的时间要求和内容要求
二、测试分析--TCO(Testing Coverage Outline)测试覆盖大纲
做过了 KYM，已经对用户、任务和被测对象有了一定的了解，是否现在就可以开始做测试分析和测试设计？
答案是否定的，因为对于被测对象的认识还是过于粗糙，如果只抓住一个点就往下深入，很可能陷入 “只见树木，不见森林” 的迷雾。
画 TCO 即划分测试范围，圈定测试的边界，对测试的对象进行拆分，枚举出需要测试的要点;
主要帮助达成的是：需求信息提炼、信息重组 和 结构化, 目的就是梳理测试覆盖大纲。
TCO (Testing Coverage Outline） 测试覆盖要点，做TCO是从测试的角度分析当前被测系统有哪些测试需求、测试要点。
TCO(Testing Coverage Outline)，即从测试的角度对原始需求进行提炼，提炼出对测试有用的测试点，并且对提取出的信息进行重组，识别出需求中的风险，做到对需求心中有数。
是把从KYM中获取到的测试信息进行整合，对被测对象进行分层提炼，最重要是找出单功能M、功能交互F、质量属性Q，同时识别出风险Risk，列出疑问Issue，在分析过程中也可以提前把一些变量参数单独列入Data。
KYM与TCO均不是一次性过程。
1 为什么需要TCO:
在日常的工作交流（需求、方案、实现）或是在做KYM的时候，我们面临着大量的碎片化信息需要梳理。
我们需要将碎片化的信息进行提炼、重组和结构化，这就是TCO的过程。
（一个好的结构化的TCO也应该便于日后原始信息的还原。）在这样过程中我们就能够对被测系统、测试点做到心中有数。
2 做TCO的形式和内容：
形式上，目前用的比较多的是思维导图（脑图）,也可以是其他任何便于交流和理解的方式。
内容上，根据项目的上下文特点可能会有一些差异。
Time: 产品各个节点周期 Operation： 产品使用 Platform： 产品依赖平台 Structure： 产品组成 Function： 产品作用 Data： 产品数据 Interface： 产品接口 Bugs： 测试过程发现bug Risks： 测试过程隐藏风险
M： 测试对象的单功能拆分
3 测试覆盖大纲TCO的编写可以有两种方式：
一种是依据启发式测试策略模型中产品元素（SFDIPOT）
一种是 MFQ，MD（基于模型的单功能测试分析与测试设计）、FI（功能交互的测试分析与测试设计）、QC（非功能的质量属性的测试分析与测试设计）
前者提供的是简单快速的分析，以便可以通过输出的 TCO，选取测试点快速进行探索性测试
后者提供的是更深入系统的分析，以便能够全面的测试验证被测对象
三、测试分析--MFQ(Model Function Quality)
通过TCO对需求的整理之后，划分了单功能和功能交互点，这时的输出物还只是测试点，不足以支撑整个测试，还需要对具体的单功能使用建模方法。
本章我们讨论的是一种新的，或者说更全面的测试设计方法。
现在在很多测试更完善的企业(如华为)，他们提出了新的测试过程设计：
需求/规格→测试分析→测试设计→用例设计，将测试计划分为4个阶段，然后通过模型的方法来控制测试设计的整个过程，当然事实也证明基于模型的测试对帮助提高和改进测试设计质量是有很大的帮助。
通过模型可以描述系统如何工作，可以通过表格形式、流程图或其他图表来表示。
测试分析：从产品需求到MFQ需求的转化。
测试设计：从MFQ需求到测试用例的转化
在测试分析的方法论中，MFQ模型主要从 三个维度 对测试对象进行分析/划分，提取测试点：
① 单一功能（MD-Model Based Discrete Function），即被测对象由哪些单一功能组成；
② 功能交互（FI-Function Interaction），即功能之间有哪些复杂的功能交互点需要测试；
③ 质量属性（QC-Quality Characteristics），需要关注哪些非功能的质量属性方面的测试。
从这三个角度进行测试要点的提取。
四、测试设计--四步法 生成测试用例
测试设计四步法：建模完成后，按照下面四步法生成测试用例。
MFQ 模型将测试设计分为4 个步骤，第一步是为测试对象建模; 第二步是设计基础测试用例来覆盖模型; 第三步是确定测试数据; 第四步是非正式测试。详细的测试设计步骤在接下来的章节中会详细介绍。
4.1 单功能建模（Modeling）
任何系统都是结构化的，每个整体的被测对象都可以划分为多个部分，每部分都负责一定的功能，那么这里的“部分”，被称为M 这一步需要确定测试对象，确定单功能便捷，单功能拆分； M1-Mn：基于模型的单功能测试与分析1(流程P、参数P、数据D、组合C、状态S) 1. 画流程图 2. 增加测试条件（MF主流程+AF补充流程覆盖） 3. 搞清楚参数+数据
完成MFQ的划分后，需要分别针对M，F，Q选择 PPDCS 建模方法
什么是 PPDCS 方法 ？
PPDCS(Process，Parameter，DATA，Conbination，State) 建模方法从不同维度设立了建模思路，下面简单介绍一下其中三种建模方法的适用场景：
Parameter：需求中或者划分出来的单功能或者功能交互点有许多参数，且这些参数相互之间有一定的业务规则约束，即某些参数之间组合才能符合需求。
DATA：需求中或者划分出来的单功能或者功能交互点有许多参数，但是这些参数之间没有业务规则的约束。
State：需求中或者划分出来的单功能或者功能交互点涉及多种状态，且各种状态之间由于某些业务规则，能够相互转换。
怎么做 PPDCS？
PPDCS 方法实施时，可以从以下 4 个方面展开：
关注触发词语 Triggers
抓住核心功能 Essentials
尝试不同特征 Spanning Differences
围绕既定目标 Targets
4.2 功能交互建模（Funcition）
交互场景不可能进行穷举，或陷入穷举陷阱。此时优先级和重要等级是我们罗列时主要进行考虑的对象 1.确认交互范围 2.确定交互边界
4.3 质量属性建模（Quality）
非功能的质量属性也需要进行验证，比如 效率、兼容性、易用性 、可靠性、 安全性、 可维护性 、可移植性、
在软件质量模型的 ISO/IEC 25010 中定义了:使用质量模型和产品质量模型。
产品质量属性（8）：功能适应性、效率、兼容性、易用性、可靠稳定性、安全性、可维护性和可移植性（安装升级卸载测试）性能测试;
使用质量属性：功能合理性、产品安全性、产品文档测试、用户体验测试。
五、Test Condition(TestCase)
TCON 根据上一步建模的测试场景，生成TCON，用上述判定不同情况下的测试条件转变，TCON这里可以理解为TestCase。
测试条件 TCON（Test Condition）即确定测试场景和测试输入输出，在业务流程建模后，根据业务场景进行场景划分，再根据输入的数据进行输入划分，然后再根据业务中的特性进行特殊输入补充。根据不同输入确定其输出，就完成了测试用例的基本内容。
5.1 用例清单
| 用例编号 | 系统模块名称 | 子模块名称 | 用例描述(测试项) | 前置条件 | 操作步骤 | 描述 | 预期输出 | 测试结果 | 测试人员 | 测试日期 |
| 1 | 登录 | 用户名 | 系统运行正常 | 用户名为空 密码正确 | 点击登录 | 提示 用户名不能为空 | 与预期输出吻合 | 2024.11 | ||
5.2 执行用例
| 用例编号 | |
| 用例名称 | |
| 模块/项目名称 | |
| 用例属性 | 功能测试 性能/负载测试、界面测试、兼容性测试、易用性测试、安全性测试 |
| 用例名称 | |
| 场景描述 | |
| 重要等级 | |
| 预置条件 | |
| 测试数据 | |
| 测试步骤 |
常用的测试用例设计方法: （1）黑盒测试方法： （2）经验测试方法： （3）白盒测试方法： |
| 预期结果 | 具体性能指标：响应时间、cpu/ram占用率、 |
| 实际结果/结论 | 通过 不通过 |
| 测试状态/备注 | |
| 测试人员、日期 |
e.g.
总结：MFQ 需要团队每个成员参与完成测试点的梳理，MFQ 不是一次性过程，需要在迭代演进中针对产品需求和风险点进行补充修改。
到此步 TD (Test Design测试设计) 结束， 用例设计、TE (Test Execution)测试执行，这里不再细述。
附录 A：工程实例：需求实例化 + MFQ融合实践
浙公网安备 33010602011771号