软件测试学习（二）需求分析阶段

1.什么是软件需求

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。
功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

2.测试在需求分析阶段要做什么

2.1为什么测试要参与需求分析？

吃透被测对象详细需求——是后期测试活动的依据。
指出需求歧义——避免需求流失。
对需求不合理提出改进建议——把可能的缺陷关闭在需求分析阶段。

实际工作中，当测试接入时，项目处于什么阶段是不确定的。不同阶段的项目，测试展开工作的重点不同。需要通过历史需求和当前需求分析，明确被测对象现状与风险，作为后期展开工作活动的重要依据。

2.2 针对不同阶段的测试重点

项目根据阶段分三类：新项目，中期项目，维护项目。

1. 新项目：项目立项刚结束，承接到规划的需求，开发和测试新接入此项目。

此类项目往往迭代一规划的开发任务已经初步给出，但产品最终成型还是停留在规划上，这个时候测试人员也要依据自己的经验，专业，结合原始需求与开发一起参与需求分析整个过程。并提出建议和意见。通常开发人员更多的会从代码实现可行性，难度，实现方式等方面考虑。测试则应从用户体验，界面交互，性能，甚至是维护和推广的角度来考虑。

2.中期项目：项目已完成几个迭代，处于开发中期。
此类项目迭代已稳定进行几个周期，开发处于中期。这时候接入测试，测试人员需要先熟悉已完成的需求，产品规划等，再结合新需求进行需求分析。一方面做新需求分析，一方面要考虑新需求对老版本的关联和影响。或采用新需求兼容老版本的方式，或者老版本做更改和扩展，适应新需求。根据项目实际情况决定。

3.维护项目：项目开发结束，上线，处于维护阶段。

此类项目基本已经开发完成，开发人员通常只留有部分人员。测试此时接入，需要较多时间来熟悉已有功能。根据项目资料文档尽快熟悉产品的情况。后期维护，承接新需求时重点考虑的是新需求对老版本的影响。通常也是采用新需求兼容老版本的方面。不会再对老版本做大的变动。

2.3 测试需求分析的输入是什么？

客户需求、开发需求、协议、标准、规范和测试案例库。

2.4 测试需求分析的输出是什么？

需求来源分析的输出为《测试需求来源表》；
原始测试需求提取的输出为《原始测试需求表》；
原始测试需求分析的输出为《初始测试项表》；
测试特性分析的输出为《测试特性表》和《特性测试项表》。

2.5 测试需求分析的常用的工程方法有哪些？

如果是增量开发，原始测试需求提取的分析方法为继承性需求分析；
原始测试需求分析常用的工程方法为质量模型分析、功能交互分析和用户场景分析；
测试特性分析的工程方法为测试特性建模和测试项分解分配。

2.6 使用质量模型法开展测试需求分析

软件质量由ISO9126的6大项的27个质量特性子项来衡量，质量模型分析就是从软件质量因子角度来分析的。从不同的测试目的出发、以不同的角度来分析和测试产品，不同类型的测试会发现不同类型的Bug。
在测试分析设计活动中考虑质量模型分析，能够使测试分析设计人员尽可能从多个方面和角度进行测试分析，能非常有效的提升测试完备性。质量特性表参见如下：
在这里插入图片描述

2.7 使用功能交互法开展测试需求分析

软件功能不是独立的，功能之间存在交互、顺序执行等影响因素，这就是功能交互分析的角度。将被测功能和软件其他相关功能进行交互分析，根据影响点可以得出初始测试项。被测功能，也可以代指原始测试项或一组有逻辑关系的原始测试项求集合，软件其他相关功能包括所有需要进行交互分析的新增和继承功能特性。通过分析功能间的相互影响，能非常有效的提升测试完备性。
在这里插入图片描述