软件测试--测试基础7--需求管理、需求分析

一、需求管理

1、需求工程在做什么

1. 需求开发：需求获取、需求分析、需求格式化、需求验证
2. 需求管理：需求分配、需求评审、需求基线、需求变更、需求跟踪

2、需求变更

1. 为什么要变更：
   • 外因：市场、客户
   • 内因：技术不足、缺陷、人员资源
2. 变更影响了什么：SRS、HLD、LLD、SP、UI、ZI、CODE
3. 怎么做变更的控制（需求变更控制目标）：控制项目成本，控制项目风险
4. 需求变更越早，影响范围越小，变更越晚，影响范围越大

1）不同阶段的需求变更影响的范围

i、需求阶段需求变更影响

需求规格说明书；
系统测试计划；
开发RTM、系统测试RTM

ii、概要设计需求变更影响

需求规格说明书、概要设计文档；
系统测试计划、系统测试方案、系统测试用例；
开发RTM、系统测试RTM、集成测试RTM；

iii、详细设计需求变更影响

需求规格说明书、概要设计文档、详细设计文档；
系统测试计划、系统测试方案、系统测试用例；
集成测试计划、集成测试方案、集成测试用例；
开发RTM、系统测试RTM、集成测试RTM、单元测试RTM

iv、编码以及后期测试阶段需求变更

需求规格说明书、概要设计文档、详细设计文档、编码
系统测试计划、系统测试方案、系统测试用例；
集成测试计划、集成测试方案、集成测试用例；
单元测试计划、单元测试方案、单元测试用例；
开发RTM、系统测试RTM、集成测试RTM、单元测试RTM

2）变更控制的目标：

1. 降低变更引起的成本

原则	方法
防止随意的变更	通过评审和会议让用户或者企业负责人在变更上签字来确认变更
尽量早的发生变更	多设计一些产品原形，由用户确认
尽量控制变更影响的范围	尽量不变更，如果变更，尽量发生在后续版本
尽量减少变更做引起的返工	当变更的需求稳定后再介入开发和测试

2. 降低变更引起的风险

原则	方法
高内聚，低耦合	尽量使一部分代码只完成一件事，函数与函数之间的关联尽量小，尽量使变更只影响到局部，而不影响到整个系统

3、需求的跟踪

1）为什么要需求变更跟踪

将和SRS有关的文档同一管理和关联起来，从而可以从任何一点找到其他文档的相关内容

2）输入、输出

i、输入

1. 开发的需求跟踪：SRS、HLD、LLD
2. 系统的需求跟踪：SRS、ST计划、ST方案、ST用例
3. 集成的需求跟踪：HLD、IT计划、IT方案、IT用例
4. 单元的需求跟踪：LLD、UT计划、UT方案、UT用例

ii、输出

RTM Requirement Trace Matrix 需求跟踪矩阵
（每个阶段，跟踪的内容和变更的跟踪）

阶段	编号	跟踪	编号	跟踪	编号	跟踪
SRS	系统测试项ID	ST描述	ST子项ID	ST子项描述	系统测试用例ID	系统测试用例描述
HLD	集成测试项ID	IT描述	IT子项ID	IT子项描述	集成测试用例ID	集成测试用例描述
LLD	单元测试项ID	UT描述	UT子项ID	UT子项描述	单元测试用例ID	单元测试用例描述

需求跟踪矩阵的作用：

• 开发RTM：保证所有的需求都被设计实现了
• 测试RTM：保证所有的需求都被测试了
• 保证可以通过需求，确定需求变更影响的范围，找到所有的成果物(HLD、LLD、系统测试计划……)

4、需求的特点

只关心想要什么，不关心怎么去做

5、需求工程

6、补充

1）代码编写原则

1. 高内聚、低耦合
2. 可续性高
3. 查阅代码编写规范

2）在公司出现以下问题如何解决

1. 业务背景不同，导致项目延期
   明确需求文档的格式和标准，尽可能细化需求文档
2. 需求变化频繁
   建立变更控制
3. 需求相关的代码，用例找不到，找不全
   建立需求跟踪

3）基线变更流程

CR Changes requirement：需求变更
CCB Changes control board：变更控制委员会
CMO Configuration management officer：配置管理员
PM：项目经理
SWE：软件开发工程师
STE：软件测试工程师
QA：质量保证人员
CI：基线

二、需求分析

1、概念

1）什么是需求分析

明确做什么，明确测什么，怎么测

2）需求分析的目的(针对测试而言)

1. 对需求进行细化和分解，从而找到所有的测试点
2. 使从测试覆盖所有的需求(方法：先覆盖业务流，然后模块，关联，非功能)
3. 更细致的需求分析有利于提高测试质量(非软件质量)

3）测试需求分析的特征

1. 所有的需求项要通过需求分析被核实
2. 测试需求分析应明确指出满足需求的前置条件和不满足需求的前置条件
3. 测试需求分析不涉及具体的测试数据，测试数据是在测试用例中产生

2、如何做测试需求分析

1. 明确系统框架，有多少个业务流程
2. 明确业务流中有多少个功能测试点，细化分解业务流：
   1. 明确每个功能模块的输入、输出、逻辑
   2. 满足功能需求的条件和不满足功能需求的条件
      以上两步要做到宁多勿缺
3. 明确每个功能的独立处理流程关系
4. 明确功能之间的处理、联系
   以上两步为细化业务流
5. 明确非功能需求和隐性需求 如：安全性、性能、界面美观、易用性等……
6. 系统运行环境包括代码、硬件、软件、外设、数据库、网络

3、UML 统一建模语言

1. 用例图：被称为参与者的外部用户所能观察到的系统功能模型图
   
   
2. 活动图：描述了一组顺序的或并发的活动
   
3. 包含3个因素：参与者(Actor执行者)，系统(Use Case 用例)，关系(Association关联，Dependency依赖，Generalize继承)