【测试设计】需求分析方法论 .pdfVIP

【测试设计】需求分析⽅法论 需求分析总结 ⽬的 1、明确产品给⽤户带来的价值点，从⽽确定模块的重点和⽤户核⼼场景 2、细化需求，通过显性需求挖掘隐形需求，防⽌遗漏 3、确定测试范围，明确质量标准，⽐如模块⽀持/不⽀持范围 4、指导开发实现功能 5、指导测试分析和产出测试点 需求提取 ⼤多情况下，可能是PO做的； 也可能是⼩需求/BUG，模块负责⼈直接接⼿ PBL ⼀般从PBL获取原始需求 需求标识 信息来源 原始需求描述 原始测试需求（验收标准） 需求分析 1、版本需求分析 ⽬的：挖掘版本隐性需求 1、性能分析 稳定性，明确稳定性场景 版本指标 2、兼容性 向前兼容：虚拟机导⼊导出的功能需要兼容前⾯的版本 3、可靠性 4、升级 升级限制 ：⽀持从哪些版本升级 5、砍⽼需求 6、操作系统 2、模块需求分析 ⽬的：尽可能的量化和挖掘需求 1、显性需求 页⾯需求 容量 提⽰信息 输⼊ 页⾯操作 页⾯显⽰ 功能性需求 2、隐性需求 性能 兼容性 系统相关 ⽤户场景 硬件平台 反向需求 ⽐如： 容器弹性扩容：需求描述时可能只是说弹性扩容，实际上缩容也是隐含的必要需求； ⽀持vma格式⽂件导⼊：不⽀持其他格式⽂件导⼊也是隐含需求 安全需求 ⽐如：登录模块，安全需求是隐含需求，登录需要RSA加密（或其他加密⽅式） 3、五维分析 1、⽤户场景 2、明确性 3、⼆义性 4、完整性 5、可测性 功能可测 测试⼯具 硬件要求 可展⽰ 需求验证[可选] 【可选】针对未预研，可⾏性不确定的需求 验证需求的正确性及其质量 输出 产出需求跟踪Xmind 准确 确保产出的需求是准确的（确保开发出来的功能是⽤户需要的、可⽤的） 全⾯ 确保产出的需求项是全⾯的（多维度分析需求，避免遗漏，后期影响产品质量、进度） 优先级 产出的需求项有优先级（便于把握需求优先级，为测试分析、设计提供依据） 缺陷预防 bug[可选] 提前发现需求中遗漏、⽭盾、含糊的地⽅和⼀些其他问题，这些问题可能会影响项⽬需求的可测试性、正确性以及其他测试质量【可选】 ⼯具需求 [可选] 某些需求需要特定⼯具协助才能完成测试的，提前提⼯具需求给开发，⼀般⼯具需求开发不要超过2⼈/天 【可选】 学习计划 [可选] 对于不熟悉的技术、⽅法、语⾔、⼯具或硬件平台，允许⼀段时间⽤来学习相关技术、原理。[可选] 实现技术 例如虚拟⽹络的实现可以⽤brctl，也可以⽤ovs。需要熟悉这些技术原理 业界⽅法 1、我们是这么实现的，友商等他们是怎么实现的呢？ 2、业界是如何测试这个模块的？是否有可借鉴的⽅法？ 需求管理 需求评审 评审内容 完整性审查 准确性审查 评审形式 相互评审、交叉评审 ⼩组评审 项⽬经理 相关开发⼈员 相关测试⼈员 评审记录 案例修改或补充 需求 变更 需求变更分析 维护需求跟踪Xmind 相关内容同步变更