需求分析方法—把测试流程图表化

一、需求分析基础

1.什么是测试需求

需求测试，是验证需求是否是正确的、完整的、无二义性。测试人员要能够分辨出来问题点，并跟用户进行核对，确定用户的真实需求。

需求测试的输入：需求文档（MRD、PRD、UC）

需求测试的输出：问题点及修改建议，测试分析MM图。

2.为什么要进行需求测试

1) 新人对业务不熟：测试人员对被测系统的业务流程不熟悉

2) 错误或缺失测试方法：对功能点没有采用正确的测试方法， 导致测试不充分。

3) 场景的缺失或部分缺失：Spec非常详细，所有的精力放在功能点的测试上，忽视了业务场景的覆盖

4) 为了知道需求变更：这是最不想，但又最经常发生的事情

3.需求测试的范围

1) 需求背景，目标，影响范围

2) 系统的输入输出，类型，精度，允许的出错次数，输出的格式，数据的来源以及正确性

3) 响应时间，提示的方式，异常处理方式，性能指标

4) 主要流程描述，操作流程和步骤说明，分析是否合理化

5) 需求的上下文是否一致，有没有于其他需求发生冲突

6) 需求逻辑是否足够清晰，每个条款都是描述问题及解决问题是否包含

7) 需求是否都是可测试的

8) 寻找隐含的需求，和相互依赖的需求

4.推荐的需求文档格式

1) 业务名称解释

2) 需求背景及目标介绍

3) 用户操作场景说明

4) 功能总览：用列表的方式，逐项叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出

5) 系统交互图

6) 界面原型（对该系统的输入、输出数据类型、格式、数值范围、精度的描述）

7) 业务规则说明

8) 业务正常流流程：功能模块，主要操作

9) 业务异常流处理：异常场景，错误提示；异常流转

二、淘宝需求模式

PD、运营参与，前期需求讨论、PRD需求整理、PRD，UC评审、测试需求分析，测试用例设计

淘宝存在的项目优化很多，中途接手项目的情况很普遍，测试人员需要考虑的全局观和整体性体现在业务建模上和业务流程上的全面性

需要注意的：项目背景

三、如何进行需求分析的方法论　

工程经验中，需求分析工作方法可以分为 三个方面进行考虑

第一阶段：全局式

这一阶段是和需求方沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。确定对应的接口人
输出成果：调查报告、业务流程分解、问题确认

内容校验方法：

1. 需求总体完整性测试：包含内容（业务名词解释、需求背景和目标、用户操作场景说明、功能总览、系统交互图、界面原型、业务规则说明、业务正常和异常流处理）

1. 来源测试，需求的来源，使用者，确认需求的各个模块的重要性

3. 可以使用的方法或者图表

功能分解图，MM图,系统交互图

明确系统涵盖的功能点和范围

系统用例图：明确角色关系，系统的调用者与系统之间的关系，明确角色的权限设置和权限冲突，

第二阶段：流程式

已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。
可以输出成果：业务流程报告

可以采用的方式方法：功能分解表、活动图

明确功能入口，页面间的跳转，参数的传递等

1. 服务结果为导向的测试方法，用用例结构图方式进行功能分解的形式进行，校验流程形式的复杂度便易性，合理性，准确性
2. 通过设计用例来验证需求中描述中不详细的遗漏点

实际应用中可以考虑的测试方法：

1. 内容测试：输入输出是否明确，格式校验定义是否完整，是否有预计的响应时间，异常流处理等

a) 缺少导致这个行为结果的原因的描述；

b) 没有给出明确定义说明；描述中遗漏了几种可能的异常信息需要进行处理；

c) 缺少用户权限的描述；

d) 缺少分支流程的说明；

e) 业务规则说明上的遗漏；

f) 边界值上的遗漏

可以采用的流程图表法：画决策流程表（针对if—else—then的形式），明确用户流程导向，区别出核心流程和优先级

1. 二义性：和一致性并行检查

a) 异常分支是否已经说明

b) 引用上的歧义，未指明具体引用的内容

c) 动作的范围界限不清

d) 遗漏:有原因但没有结果的说明；有结果但缺少原因的说明

e) 逻辑操作符歧义：与，或，非，与非等复合操作符使用不当

f) 否定的范围不明确

g) 含糊性陈述：一些变量添加了不必要的别名，引起歧义

h) 结构混淆：因果混淆，用例先后次序不严谨

i) 内置假定臆断条件：对知识范围的臆断

j) 边界值上的含糊

可以采用用例图的方法：

1. 一致性检查：这点比较难理解，需要考虑在需求中的功能分解，和有交互的功能重合部分和交互部分会否出现一致性的需求错误

a) 任何一条需求不能和其他需求互相矛盾，主要表现为逻辑关系之间是否有冲突（包含、并且、或之间的关系验证）

实例说明：

如果小于18岁,并且打网球,那么寄送给他们一本网球俱乐部的手册

如果大于等于18岁,或者有一个摩托车的驾照,那么寄送给他们一个摩托车俱乐部的手册

如果这个人同时收到了2份手册,那么把这个人放在A的邮件列表中

拥有摩托车手的驾照,必须大于18岁

第三阶段：详细确认式

这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。可以通过技术方案业务流程报告、数据项表以及操作承建方提供的DEMO系统

实现手段：原型演示系统、交互图、时序图、流程图

测试方法：1.对demo中的功能进行需求文档的功能点是否能覆盖进行排查。

例如： 覆盖的功能、覆盖的市场、覆盖的异常流、覆盖的数据类别

2. 对接口引用的关系，数据传输的过程，系统的交互等

整体来讲，需求分析的三个阶段是测试中不可忽视一个重要的部分，三个阶段的实施和采用，在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

四、总结校验的内容是否完整checklist

一般需求清单
需求	完整的需求是？ 需求理解是否统一？ 需求是一致呢？ （即，没有内部矛盾） 是否充分的需求设置解决所有适当的异常情况？（基于场景） 需求是否充分的考虑边界条件？ 需求是可行的？ （即需求对存在的合理性） 需求可以实施范围内已知的限制？ 规定明确表示是否可逆？ 这些最简单的需求设置，能够满足利益相关者的需求？ 有功能性和非功能性需求被考虑？
个性化需求	需求精确无误？ 表示为简单或原子作为可能的形式在规定？ 需求可测试/核查？ 客户的语言编写的需求，使用客户的术语？ 是需求大家都能接受的利益相关者？ 是规定的利益相关者的需求说明，而不是一个解决方案？ 如果合适的话，是可追溯的需求？ 是需求有必要吗？ 是否所有的遗失物品或与待定，业主确定的悬而未决的问题，以及时间线的关闭它？

业务需求清单
一般	做业务需求符合CxOne需求对照表？
内容	所有的需求是可以理解的利益相关者？ 是确定的业务价值？ （节约成本，减少库存等） 是客户确定的价值？ （新功能，改进的易用性等） 该系统是如何避免将达到目标的详细信息？ 这是否需求回答一个问题：我们为什么做这个软件？ 这个需求是产品或企业的目标是什么？ 这是客户需求的目标吗？ 这是一个制度的目标需求？