一文详解软件测试需求分析是什么
作者：测试要用手
为什么要分析需求
1.1、必要性
如果把测试活动比作软件生命周期，测试需求分析就相当于软件的需求规格说明，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。所以整个测试活动的依据来源于测试需求，测试需求分析是整个测试活动环节必不可少的环节。需求分析越详细越精准，表明对所测软件的了解越深，对所要进行的任务内容越清晰，就更有把握保证测试的质量和进度。
1.2、不做的后果
时间&资源的浪费，实现了用户不需要的需求。
重复需求的遗漏，降低客户满意度。
错误预估工作量，延误发布周期，可能降低发布质量。
1.3、测试及早介入原则
根据统计表面，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%~60%。此外，缺陷存在放大趋势，如需求阶段的一个错误可能会导致N个设计的错误。因此，越是测试后期，为修复缺陷所付出的代价就会越大。所以，软件测试人员要尽早且不断地进行软件测试（测试左移思想），以提高软件质量，降低软件开发成本。
1.4、需求分类
一般需求分为业务需求、用户需求、功能需求：
业务需求：业务需求描述了组织为什么要开发一个系统，即组织希望达到的目。业务需求通常来自项目投资人、购买产品的客户、实际用户管理者、组织内部市场营销部门或业务部门根据自己的业务需求和后续策划的活动方法所整理记录成的需求文档，这份文档有时也被称作项目轮廓图或市场需求文档。
用户需求：描述的是用户的目标，是用户能通过这个产品在什么场景（什么情况下）能完成什么动作（做什么）。例如：软件的界面是否好看、功能使用便捷等。用户需求可以认可为业务需求的一个具体目标。
功能需求：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求也被称为行为需求，功能需求是去解决业务需求、用户需求的具体解决方案。也就是通常所说的需求说明书（通常由软件开发方编写，一般为产品经理，使得用户和软件开发方都对软件的初始规定有一个共同的理解，是整个开发的基础），对用户需求做具体的分析、提出实施方案。
什么是测试需求
2.1、概述
测试需求通常是以功能需求为基础，通过对功能需求的细化和分解，形成可测内容。
2.2、范围
测试需求应尽可能全部覆盖已定义的业务需求，以及功能和非功能方面的需求。
2.3、目的
测试需求用于解决“测什么”的问题，即指明被测对象中什么需要测试。测试需求分析主要用于：
明确需求的范围
明确每一个功能的业务处理过程
明确不同功能点业务组合
挖掘显式需求背后的隐式需求
测试需求的特征
3.1测试需求的特征
测试需求必须是可核实的，即必须有一个可观察、可评测的结果，无法核实的需求不是测试需求。
测试需求应指明满足需求的正常前置条件，同时也要指明不满足需求时的出错条件。
测试需求不涉及具体的测试数据，测试数据设计是在测试用例设计环节解决的问题。
3.2测试需求的重要性
测试需求是编写测试用例的重要依据。
测试需求有助于保障测试的质量和进度。
衡量测试覆盖率的重要指标。
测试需求和功能需求关系
测试需求和功能需求的关系
功能需求：系统应该做什么。例如ATM取款机的业务需求：每次取款额度在100-2000之间；取款金额为100的倍数；每日取款总额不得超过20000，这是功能需求。
测试需求：系统应该做什么、系统不应该做什么、发现系统设计中存在的问题。例如取款金额可选在100-2000之间且为100倍数可取；小于100或者大于2000不可取；在100-2000之间但不是100倍数不可取；当日取款总额必须小于等于20000；取款金额必须小于等于账户余额等等，这是测试需求。
如何开展测试需求分析
5.1、概述
开展测试需求分析的前提是要明确业务需求、用户需求、功能需求以及需求的背景、场景。测试流程各环节都应该与此保持一致。
5.2、测试需求采集
测试需求采集是将需求规格说明书（不限于）中具有可测试性的需求或特性提取出来，形成原始测试需求。（可测试性：指提取的需求或特性必须存在一个明确的期望结果，通过某种方法可以对期望结果进行验证是否符合文档中的要求。）
测试需求采集方法：
通过列表的形式（excel）对软件开发需求进行梳理，形成原始需求列表，列表内容可包含需求标识、原始测试需求描述、信息来源等。
软件需求说明书对应的开发文档及章节号可作为原始测试需求标识。
软件需求说明书的描述作为原始测试需求的描述。
软件需求说明书的来源信息可作为原始测试需求的信息来源。
“去重”（删除列表中重复的、冗余的原始测试需求描述）、“细化”（对太简略的原始测试需求描述进行细化）、“合并”（若有类似的原始测试需求需要对其进行合并）
5.3、测试需求分析流程
需求项整理：可通过上方需求采集方法进行需求项的整理，测试方还需要与项目组确认功能需求的优先级或重要程度，并对其达成一致，此为产品质量等级目标的重要依据之一。但不是所有项目需求都是清晰的、有需求说明书的，可能会遇到以下几种情况：
有详细的需求文档：一般情况下，比较严谨的项目团队都会有详细的需求说明书文档，这种情况我们只需要详细阅读需求文档来进行需求项的整理和测试点的提取工作。对于需求不明确的地方可以直接找项目负责人（一般为项目经理）进行沟通，做到对需求整体的把握和理解，利于更好的进行测试。
需求文档不明确，即有文档但文档粗糙：如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档；如果时间紧张无法完善需求文档，测试人员需将文档中每一处不理解的地方和开发沟通清楚，切忌不要含糊不清的测试。
没有需求文档：可以直接通过与项目经理、开发等进行沟通、询问、收集、梳理、理解需求，自己写一个概要的需求描述，进行评审，让各方确认需求描述是否符合业务、用户、功能需求，使研发和测试方对需求的理解达成一致。
测试点整理：测试点的提取主要依据的是前面我们讲到的六大质量模型以及测试类型和测试方法，结合功能需求被测对象（功能点）进行测试需求分析，就可以知道我们需要从哪些方面进行测试，从而提取出测试点。测试点优先级划分一般分为高中低，功能场景为高，异常功能场景为中，非功能场景为低。后续测试用例可延用测试点的优先级划分。
显性需求：显而易见的，直观的功能需求。
隐性需求：用户也不能完全清晰的感受和用语言进行描述的，需要结合业务、用户、功能需求对需求进行延伸，比如：用户的显性需求被满足时，用户不会感到惊喜和兴奋；但精准推送用户想要的东西时，用户会感到十分惊喜，这个过程，激发的用户的隐性需求，隐性需求是培养用户忠诚度的最好方式。
5.4、输出测试需求跟踪矩阵
测试需求跟踪矩阵明确功能点与测试点的对应关系，列出所有整理需求项的功能点与之对应的测试点，同时需要包括测试类型以及优先级&重要程度。
5.5、测试需求分析评审
测试需求分析产出的需求跟踪矩阵需要与项目组进行评审，需要各方达成一致。
总结
到此这篇关于软件测试需求分析的文章就介绍到这了,更多相关软件测试需求分析内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！