MFQ-PPDCS测试分析和测试设计 - 感觉有点虚，落地还是要结合实际工程应用

测试积点老人

问题：
如何能够有效的完成测试用例的输出？

解决方案：
产品需求作为输入，软件设计和测试一起讨论具体的测试细节，测试将其归纳总结为单功能、功能交互、质量三个方面的需求。

对MFQ的需求进行四步操作：

• 模型覆盖需求逻辑
• 基本用例覆盖模型路径
• 将基本用例落地
• 经验拓展
  

测试分析：从产品需求到MFQ需求的转化。
测试设计：从MFQ需求到测试用例的转化。

讨论（按优先级）：

• 理论体系比较完善，但实际工程应用中不太好实施。因为实际问题往往还是需要依据经验来解决。
• 方法有点复杂，与传统相比，感觉绕路，如果没有很好的测试效果，该方法较难推广。
• 这可能是一个规范指南，但不能是一个具体的操作手册。需要团队不断总结提升，形成一套适用于团队本身的测试经验。
  

MFQ-PPDCS测试分析和测试设计

嵌入式软件的三个特点：

• 数量巨大和复杂的功能。 - 如何尽早覆盖每个功能点
• 非常多的功能交互。     - 如何尽早覆盖多个功能点组合
• 严格的质量要求。       - 如何尽早发现问题
  

现状：
测试分析与测试设计融合进行，没有具体定义分析和设计的边界。 - 不容易形成规范模板，继承性较差
经常依赖经验做测试设计，测试用例集离完整性和有效性不够好。 - 不容易发现问题，缺乏流程来保证

测试设计的常用方法：

• 等价类划分
• 边界值
• 决策表
• 业务流程图
• 基于状态的测试
  

增加的理念：

• 测试     - 持续问问题的过程
• 测试分析 - 是什么 - 我要问什么问题 - M单功能-F功能交互-Q质量
• 测试设计 - 怎么做 - 我怎么问问题   - PPDCS建模-基本用例覆盖路径-将用例落地-拓展测试（经验）
• 测试目的 - 所有可能的测试用例中哪些子集有最高可能性发现最多的错误
  

测试设计的四步方法：
1、模型覆盖需求：
基于模型的测试，建立模型的过程就是测试分析的过程
测试分析者不断同软件设计者交流来找到问题的答案
采用UML语言建模

2、基本用例覆盖模型：
模型路径更容易被测试用例覆盖
不同模型有不同的测试覆盖方法
根据确定的生成规则或算法自动生成测试用例（热点）
手动生成测试用例（实践）

3、测试数据覆盖基本用例：
识别出测试数据
考虑数据的变化

4、拓展测试（经验）
基于经验补充特殊的测试用例
基于错误的测试
探索性测试
反复 - 稳定性
叠加 - 多种不同任务
大量 - 并发，可以是同一种任务
结合白盒测试技术：状态覆盖、分支覆盖、路径覆盖

测试设计中建模的推荐方法（PPDCS）：
1、如果在测试对象的设计规范中存在相关“流程”的特征
    很多步骤构成一个流程
    步骤之间有顺序关系
    涉及超过一个角色或触发条件

2、如果在测试对象的设计规范中存在“变量或参数”的特征
    很多规则，每条规则有很多不同的变量和值组成
    参数间存在逻辑关系

3、如果在测试对象的设计规范中存在“数据”的特征
    数据之间没有规则或逻辑关系
    数据之间存在限制
    数据有范围

4、如果过程和数据的数量太多难以手工列出，采用“组合“（正交设计）
    大量参数
    每个参数有很多值
    参数之间有逻辑关系

5、如果在测试对象的设计规范中存在“状态”的特征
    行为变化基于内部状态
    事件触发

测试用例的改进方法：

• 重构。去除重复的部分，使用例更精简，运行时间更短。
• 用户角度。从用户使用场景展开，整体考虑。
  

比如用户使用uaps功能，关注什么情况下会切换，有哪些切换。
最终落地到每一个切换的影响因素，而不应该从切换影响因素出发。