五步搞定需求分析与设计|再谈测试需求分析与设计

最近部门新加不少新同学，如何让他们更好的融入到团队中，更好更快的完成测试任务，特针对新人进行测试需求分析与设计进行培训与辅导。本文整理部分内容和大家一起分享。

1）需求了解：

需求提出的背景是什么？需要解决什么样的问题？满足哪一类用户的痛点？产品经理是如何满足用户需求/痛点，方案是什么？

2）需求验证与澄清：

产品经理视角：你是产品经理，你会如何设计并满足用户需求和痛点？这个方案和你的方案有什么不同，你觉得那个更好？你对产品经理这个方案有哪些疑问需要和她澄清沟通？

用户视角：你是用户，这个方案是否能够解决你的问题或者痛点？

竞争对手视角：竞品是如何满足某一类用户的需求，解决用户的痛点。这个方案和我们的方案有何不同？为什么会有这个不同？他的方案的优点是什么？缺点是什么？我们的方案比他好在什么地方？

业务的视角：需求验收的标准是什么？满足什么条件该需求就达到了需求的价值？

1) 单功能性需求：为满足用户某单一功能或者用户体验而产生的功能性需求，比如文章的评论、点赞、分享等单一能力；轮播图；总资产优化等

2) 继承类需求：在原有需求的基础上变更或者衍生出的需求，根据需求变更的范围可分为交互类继承性需求、局部变更类继承性需求和扩展类继承性需求。

3) 运营类需求：运营类需求又称为配置类需求，通过业务或者运营配置实现业务能力，比如通过配置不同的数据库连接串，实现访问不同的数据库。

4) 用户场景类或者系统类需求：此类需求一般是工程类需求，业务的实现过程比较复杂，涉及到不同的角色和业务环节。

通过大量的测试实践，总结出需求分析与设计的6个基础步骤。

1）角色分析。

2）目标是什么？有什么价值

3）实现目标的路径分析

4）路径节点分析

5）用例编写

因篇幅问题，本文重点以系统类需求、功能类需求的分析过程为例和大家进行分享。

1）功能类需求：某模板需求，要求能够展示三个商品，展示一段时间收益，商品关键字等信息。

（1）角色分析：改模板需求主要角色运营人员，进行后台配置；C端客户，配置好后展示个用户。

2.项目目标

实现如图所示的一种模板能力，运营可以根据需要配置模板的数据并展示在App上。

3.项目达成路径

提供如图所示八个业务参数入口和四个接口返回参数入口。

4.路径节点分析

对于简单功能性需求，路径节点一般都很简单，如图所示的十二个参数入口；即我们需要的节点数据。大家可以参考图中备注。

5.测试用例编写

在测试用例编写时，需要考虑覆盖每一个参数的异常情况以及参数组合约束关系，同时因为是一个内置模板类功能需要，需要考虑系统兼容性问题。

2) 用户场景类或者系统类需求：

本文使用一个报销单系统来说明系统类需求的分析过程，如图所示，该系统需要实现的一个能力就是把线下报销单流程变成电子化的线上报销流程。

纸质项目报销单

1.角色分析：

1）申请报销（角色）

2）处理报销（角色）

3）项目成本分析（角色）

4）预算管理（角色）

2.项目目标

将纸质报销单实现线上电子化，实现线上审批和报销。

3.项目达成路径

关于项目的路径达成，一般产品经理会给出完整的解决方案，但在测试同学还是要根据自己的想法去思考，如果你是产品经理如何设计这个产品，如何满足用户需求。然后根据产品经理的方案和自己的思考进行比对，看看差异在什么地方？是我们思考的深度还是角度偏差导致差异？慢慢和产品的思考对齐，快速提升我们对业务的理解能力和思考的深度，确保做到对业务的不遗不漏，真正的做到躬身入局，不断提升自己的能力。

在思考的过程中，采用敏捷思维方式，深入思考每一个角色可能发生的故事，一步步深挖需求，解决用户的问题和需求。下图以报销流程为类，如图所示：

4.路径节点分析

通过第三步对每个角色进行分析，会逐渐的梳理出来公共的事件，比如报销单电子化项目中，申请报销，报销审核、报销核准、预支款申请等都是我们梳理出来的事件或者节点。

5.测试用例编写

根据梳理出来的事件和节点，采用场景分析法或者流程图分析法。

流程图分析法以角色为永道、以事件为节点，根据实际的业务触发条件，梳理出来整个业务流程，编写场景级的用例，场景级的用例就可以直接转换成优先级较高的测试用例。完成场景级的用例，可以对每一个节点或者事件再进行分析和梳理，变成常规用例。

场景分析法是分析场景类需求和系统级需求最常用的一种用例分析方法，现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行基本流和备选流:如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中(如备选流 1 和 3);也可能起源于另一个备选流(如备选流 2)，或者终止用例而不再重新加入到某个流(如备选流 2和 4)。

场景分析法是分析场景类需求和系统级需求最常用的一种用例分析方法，大家可以根据前面的分析，自己尝试使用场景分析法完成报销流程的的测试场景分析，本文不在详细赘述。

软件测试需求分析与设计是测试的最最核心的能力，主要解决”测什么？，““怎么测？”的问题。

测什么？主要通过对需求分析梳理出来角色，测试对象和测试范围，理解测试价值和目标（用户需求是什么？业务目标是什么？产品价值是什么？）。

怎么测是通过需求分析与设计，梳理出来测试的难点重点，测试的深度与广度，测试策略（先测什么？再测什么？最后测什么？），都有那些阶段性产出和工价产品。