MFQ-PPDCS测试分析和测试设计 - 感觉有点虚，落地还是要结合实际工程应用
问题：如何能够有效的完成测试用例的输出？
解决方案：
产品需求作为输入，软件设计和测试一起讨论具体的测试细节，测试将其归纳总结为单功能、功能交互、质量三个方面的需求。
对MFQ的需求进行四步操作：
[*]模型覆盖需求逻辑
[*]基本用例覆盖模型路径
[*]将基本用例落地
[*]经验拓展
测试分析：从产品需求到MFQ需求的转化。
测试设计：从MFQ需求到测试用例的转化。
讨论（按优先级）：
[*]理论体系比较完善，但实际工程应用中不太好实施。因为实际问题往往还是需要依据经验来解决。
[*]方法有点复杂，与传统相比，感觉绕路，如果没有很好的测试效果，该方法较难推广。
[*]这可能是一个规范指南，但不能是一个具体的操作手册。需要团队不断总结提升，形成一套适用于团队本身的测试经验。
MFQ-PPDCS测试分析和测试设计
嵌入式软件的三个特点：
[*]数量巨大和复杂的功能。 - 如何尽早覆盖每个功能点
[*]非常多的功能交互。 - 如何尽早覆盖多个功能点组合
[*]严格的质量要求。 - 如何尽早发现问题
现状：
测试分析与测试设计融合进行，没有具体定义分析和设计的边界。 - 不容易形成规范模板，继承性较差
经常依赖经验做测试设计，测试用例集离完整性和有效性不够好。 - 不容易发现问题，缺乏流程来保证
测试设计的常用方法：
[*]等价类划分
[*]边界值
[*]决策表
[*]业务流程图
[*]基于状态的测试
增加的理念：
[*]测试 - 持续问问题的过程
[*]测试分析 - 是什么 - 我要问什么问题 - M单功能-F功能交互-Q质量
[*]测试设计 - 怎么做 - 我怎么问问题 - PPDCS建模-基本用例覆盖路径-将用例落地-拓展测试（经验）
[*]测试目的 - 所有可能的测试用例中哪些子集有最高可能性发现最多的错误
测试设计的四步方法：
1、模型覆盖需求：
基于模型的测试，建立模型的过程就是测试分析的过程
测试分析者不断同软件设计者交流来找到问题的答案
采用UML语言建模
2、基本用例覆盖模型：
模型路径更容易被测试用例覆盖
不同模型有不同的测试覆盖方法
根据确定的生成规则或算法自动生成测试用例（热点）
手动生成测试用例（实践）
3、测试数据覆盖基本用例：
识别出测试数据
考虑数据的变化
4、拓展测试（经验）
基于经验补充特殊的测试用例
基于错误的测试
探索性测试
反复 - 稳定性
叠加 - 多种不同任务
大量 - 并发，可以是同一种任务
结合白盒测试技术：状态覆盖、分支覆盖、路径覆盖
测试设计中建模的推荐方法（PPDCS）：
1、如果在测试对象的设计规范中存在相关“流程”的特征
很多步骤构成一个流程
步骤之间有顺序关系
涉及超过一个角色或触发条件
2、如果在测试对象的设计规范中存在“变量或参数”的特征
很多规则，每条规则有很多不同的变量和值组成
参数间存在逻辑关系
3、如果在测试对象的设计规范中存在“数据”的特征
数据之间没有规则或逻辑关系
数据之间存在限制
数据有范围
4、如果过程和数据的数量太多难以手工列出，采用“组合“（正交设计）
大量参数
每个参数有很多值
参数之间有逻辑关系
5、如果在测试对象的设计规范中存在“状态”的特征
行为变化基于内部状态
事件触发
测试用例的改进方法：
[*]重构。去除重复的部分，使用例更精简，运行时间更短。
[*]用户角度。从用户使用场景展开，整体考虑。
比如用户使用uaps功能，关注什么情况下会切换，有哪些切换。
最终落地到每一个切换的影响因素，而不应该从切换影响因素出发。
页:
[1]
