产品测试需求分析

需求分析的过程规范

1. 准入标准

1. 产品经理准备好了需求规格说明书和原型图

2. 工作内容

1. 仔细阅读需求文档和原型图
2. 根据测试的知识去整理测试点

1. 产品的三大特性：是测试工程师选择测试类型和质量标准的依据
   1.1 领域特性：软件是为什么人群服务的
   1.2 用户特性：专业性，用户规模，使用习惯，特殊用户
   1.3 使用特性：使用场景，使用频率

2. 五个聚焦点：决定用例的设计方法和和编写方式
   2.1 业务逻辑：业务流程图、文字说明、角色用例图，结合所给资料分析业务流程是否完整
   2.2 输入域的约束：原型图，文字说明，结合两者分析用户会在什么地方输入什么类型的数据，会受到什么限制
   2.3 界面：原型图和配文，分析产品将要呈现的布局、风格
   2.4 数据：
   系统数据：软件系统启动运行的时候，需要依赖的数据
   业务数据：用户在使用软件过程中产生的数据
   测试用例的数据依据这些规范来造
   2.5 模块：归类和管理 具有相同的业务目的、功能的标签
   功能：必须具有输入和唯一处理逻辑，输出的集合
   模块是用来管理功能的
   一般规格需求说明书中，都会有 功能拓补图，可以通过描述来确定软件各部分之间的关系，一般我们只需关注被测部分的上游和下游

3. 准备需求问题清单，把分析需求过程中的遇到的疑问记录下来，在需求评审会议上，和产品经理进行确认

3. 交付物

3.1 测试检查点：主要包括：原始需求描述、标识编号、测试要点，用来覆盖需求

图例1：

图例2：

3.2 设计测试点的常用设计思路

设计思路：采用分层思想

1. 界面检查：包含UI布局，界面元素等，布局、风格有没有明确的说明
2. 元素的功能检查：包含单个控件的自身功能逻辑，如输入框的输入功能，按钮的点击功能等，各个控件联动的功能需求。元素本身提供的操作是可以使用的
3. 业务逻辑检查：包含页面跳转，对应弹出框等，关注行为和对应响应 （响应方式，响应的内容）
4. 隐式需求：包含模块与模块间的关联，约定俗称的(如平年2月28天,闰年29天)，国土领域等，也是关注行为和对应响应 （响应方式，响应的内容）

3.3 整理需求问题清单

编写测试检查点时，对需求描述存在疑问或者分歧，输出到需求问题清单中

准出标准

通过需求评审会议（同行评审），需求说明书定稿