测试需求分析

测试需求分析

本文主要是来讲解来做好测试需求的分析以及为什么要做测试需求分析：

• 软件需求
• 软件测试
• 软件测试需求
• 测试需求分析

---

软件需求

1. 软件需求的定义：

(1)用户解决问题或达到目标所需条件或权能(Capability)。

(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

(3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制

软件需求的分类

软件需求包括:

• 业务需求

• 用户需求和功能需求

• 非功能需求

  1. 业务需求( business requirement):

     反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

  2. 用户需求(user requirement):

     文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。

  3. 功能需求(functional requirement):

     定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

---

软件测试

软件测试的定义

• 什么是软件测试

  描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。

• 软件测试的经典定义是：

  在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程.

软件测试目标

测试目标是什么？

1．发现一些可以通过测试避免的开发风险。
2．实施测试来降低所发现的风险。
3．确定测试何时可以结束。
4．在开发项目的过程中将测试看作是一个标准项目。

测试度量

测试的目标要有具体的指标，可以被度量，在测试执行结束之前或之
后，能够判断测试目标是否被达到。对各项质量要求的验证达到什么程度，能够给出数字描述的就尽量给出，从功能、性到安全性、兼容性等逐项给出明确的目标.

测试目标实现的衡量标准是什么？

衡量测试目标的实现，就是通过测试覆盖率来衡量，通过对测试结果的分析，来明确产品质量要求、功能点或代码行（分支、条件等）的测试覆盖率.

• 需求覆盖率
• 代码覆盖率

如何计算这些覆盖率？

• 什么是覆盖率

• 覆盖率是度量测试完整性的一个手段，是测试有效性的一个度量。
• 测试覆盖是对测试完全程度的评测。
• 测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

覆盖评测

基于需求的测试覆盖和基于代码的测试覆盖.

• 基于需求的测试覆盖
  在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）.

软件测试需求

明白了如何去做好软件测试目标的度量，那么我们就要明白基于需求的软件测试覆盖需要依据的一个数据: 需求或者功能点量。

什么是软件测试需求

• 软件测试需求是软件需求分析后的一个产出，是针对需求功能点的一个分析产物,是在项目中要测试什么。
• 软件测试需求是为更好的完成测试目标而出现。
• 软件测试需求以避免测试遗漏与误解为出发点。

如何进行分析？

5W+1H原则
- 测试需求是什么（What）
- 为什么这样测试（why）
- 什么时候测试时间（When）
- 需要多少人测试（Who）
- 测试的环境是什么（Where）。
- 如何去测试（How)

测试需求分析

测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出一个checklist，作为测试该软件的主要工作内容。

为什么要做测试需求分析

如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。

---

• 1、把不直观的需求—–转变为—–直观的需求(用例图/活动图)

• a. 使得测试范围可以度量(有多少功能点，有多少功能项);

• b. 使得独立的功能点其对应的所有的处理分支可以度量;

• c. 使得该系统需要测试的业务场景可以度量

---

• 
  
• 2、把不明确的需求—–转变为——明确的需求
  

• 明确其功能点对应的输出、处理和输出

---

• 
  
• 3、把不能度量的需求—-转变为—–可度量的需求
  

• a.度量测试范围;
  
• b.度量处理分支;
  
• c.度量业务场景;

例如：

• 如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。

测试需求

在掌控了软件项目的背景，了解了产品的质量要求和软件测试的基本需求之后，同时，测试人员也会阅读相关软件需求文档，参与需求评审。在这些基础之上，可以进行测试的需求分析，即包括下面这些工作：

---

• 明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试；
• 知道哪些测试目标优先级高、哪些目标优先级低；
• 要完成哪些相应的测试任务才能确保目标的实现。

- 然后才能估算测试的工作量，安排测试的资源和进度。

测试需求分析是测试设计和开发测试用例的基础，测试需求分析得越细，对测试用例的设计质量的帮助越大，详细的测试需求还是衡量测试覆盖率的主要依据。只有在做好测试需求的基础上，才能规划项目所需的资源、时间以及所存在的风险等。

测试需求分析

需求来源

• 从客户角度进行分析：通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求。

---

• 从技术角度分析：通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求。

---

如果有完善的需求文档（如产品功能规格说明书），那么功能测试需求可以根据需求文档，再结合前面分析和自己的业务知识等，比较容易确定功能测试的需求。

---

如果缺乏完善的需求文档，就需要借助启发式分析方法，从系统业务目标、结构、功能、数据、运行平台、操作等多方面进行综合分析，了解测试需求，并通过和用户、业务人员、产品经理或产品设计人员、开发人员等沟通，逐步让测试需求清晰起来。

---

测试分析过程

• 测试需求分析过程

• 可以从质量要求出发，来展开测试需求分析，如从功能、性能、安全性、兼容性等各个质量要求出发，不断细化其内容，挖掘其对应的测试需求，覆盖质量要求。

---

• 也可以从开发需求（如产品功能特性点、敏捷开发的用户故事）出发，针对每一条开发需求形成已分解的测试项，结合质量要求，这些测试项再扩展为测试任务，这些测试任务包括了具体的功能性测试任务和非功能性测试任务。

---

• 在整理测试需求时，需要分类、细化、合并并按照优先级进行排序，形成测试需求列表.

测试需求的分析技术

（1）通过提炼，抓住主要线索，或作为整体来进行分析，使测试需求分析简单化。

（2）通过业务需求或功能层次的整理，使测试需求分析结构化、层次化。

（3）通过绘制业务流程图、数据流程图等，使测试需求分析可视化。

（4）通过类比、隐喻，加强用户需求的理解，更好地转化为测试需求。