51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2823|回复: 0

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

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:28
  • 签到天数: 385 天

    连续签到: 4 天

    [LV.9]测试副司令

    发表于 2018-11-30 16:00:15 | 显示全部楼层 |阅读模式
    问题:
    如何能够有效的完成测试用例的输出?

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

    对MFQ的需求进行四步操作:
    • 模型覆盖需求逻辑
    • 基本用例覆盖模型路径
    • 将基本用例落地
    • 经验拓展


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

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


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

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


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

    测试设计的常用方法:
    • 等价类划分
    • 边界值
    • 决策表
    • 业务流程图
    • 基于状态的测试


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


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

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

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

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

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

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

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

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

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

    测试用例的改进方法:
    • 重构。去除重复的部分,使用例更精简,运行时间更短。
    • 用户角度。从用户使用场景展开,整体考虑。


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


    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 02:35 , Processed in 0.062305 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表