如何对测试需求进行分解、如何进行测试需求分析

测试及早介入原则：根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误(包括最终的缺陷)数量的50%～60%。 此外，IBM的份研究结果表明， 缺陷存在放大趋势，如需求阶段的一个错误可能会导致N个设计错误。越是测试后期，为修复缺陷所付出的价就会越大，因此，软件测试人员要尽早地且不断地进行软件测试，以提高软件质量，降低软件开发成本。

如何理解测试需求

一般需求分为业务需求、用户需求、功能需求。

• 业务需求：业务需求描述了组织为什么要开发一个系统， 即组织希望达到的目标。业务需求通常来自项目投资人，购买产品的客户实际用户的管理者、市场营销部门或产品集划部门。使用前置和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。
• 用户需求：用户需求描述的是用户的目标或用户要求系统必须能完成的任务。比如软件的界面是否好看、功能使用是否便捷等都属于用户需求。用户需求可以认为是对业务需求的一个具体目标。比如业务需求提出了这个系统具有语音功能，那么用户需求可能就包含了语音具备的功能，比如. 比如可以喊刘德德华的电影影去搜家 电影等。
• 功能需求：功能需求规定开发人员必须在产品中实现的软件功能，用户利用这个功能来完成任务，满足业务需求。功能需求有时也被称作行为需求功能需求是去解决业务需求、用户需求的具体的解决方案，也就是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法(需求说明书通常是由软件开发方编写比如产品经理。使得用户和软件开发方都对软件的初始规定有个共同的理解，是整个开发的基础)。同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗赛的成本是不是小于带来的收益，还有风险评估等。

什么是测试需求

• 概述:测试需求通常是以功能需求为基础，通过对功能需求的细化和分解，形成可测试的内容。
• 范围:测试需求应尽可能全部覆盖已定义的业务需求，以及功能和非功能方面的需求。
• 目的:明确需求的范围、明确每个功能的业务处理过程、明确不同功能点业务组合， 挖掘显式需求背后的隐式需求。测试需求用于解决测什么的问题，即指明被测对象中什么需要测试。

测试需求的特征

• 测试需求必须是可核实的,即必须有一个可观察、 可评测的结果，无法核实的需求不是测试需求。
• 测试需求应指明满足需求的正常前置条件，同时也要指明不满足需求时的出错条件。
• 测试需求不涉及具体的测试数据,测试数据设计是测试用例设计环节解决的课题。

测试需求与功能需求的关系

• 功能需求：系统应该做什么。例如，某ATM机取款业务需求：每次取款额度在100～2000之间;取款的金额是100的倍数，每日取款总额不得超过20000，这是功能需求。
• 测试需求：系统应该做什么、不应该做什么，发现系统设计中存在的问题。例如，取款金额可选：在100~2000之间且为100的倍数可取，小于100或大于2000不可取，在100~2000之间但不是100的倍数不可取，取款总额必须不超过账户余额，这是测试需求。

如何开展测试需求分析

开展测试需求分析首先要明确的是业务需求、用户需求、功能需求以及需求提出的背景、场景，测试流程各环节都应与此保持一致。

测试需求采集

测试需求采集是将软件开发需求说明书(不限于)中的具有可测试性的需求或特性提取出来，形成原始测试需求(可测试性;指提取的需求或特性必须存在一个明确的期望结果，通过某种方法可以对期望结果进行验证是否符合文档中的要求)。

测试需求采集方法

• 通过列表的形式( EXCEL )对软件开发需求进行梳理， 形成原始测试需求列表， 列表的内容可包含需求标识、原始测试需求描述、信息来源。
• 软件需求对应的开发文档及章节号可作为软件需求标识。
• 软件需求的简述作为原始测试需求描述。
• 软件需求获取的来源信息作为信息来源。
• “去重”(删除列表中重复的、冗余的原始测试需求描述)、“细化”(对太简述的原始测试需求描述进行细化)、“合井 (若有类似的原测试始需求，需要对其进行合并(或提取成公共测试项) )

测试需求分析流程

测试需求分析流程

结合上面软件需求分析流程图，我们这里着重对"需求项整理"、"测试点整理"、 "输出测试需 求矩阵"环节进行说明。

需求项整理

我们在上一小节"测试需求采集"中简单的讲述了测试需求采集方法。不知大家是否考虑过，所有项目需求都是清晰、可视(需求说明书)的吗 ？如果不是又该如何，实际中可能会遇到哪些项目需求?

• 有详细的需求文档:比较严谨规范的团队项目的实施是有详细的需求说明文档的，我们就可以详细阅读需求文档来进行测试点的梳理工作，对于需 求中认为不明确的地方可以找项目负责人进行沟通，做到对需求整体把握和理解,利于测试更好的进行。
• 需求文档不明确,既有文档但文档很粗糙。一般有两种方法，如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档，如果因为各种原因，比如时间紧张或者开发不愿意，那么就自己去沟通对于文档中不明确的点问清楚，切忌不要含蝴不清的测试，于人于己都没有好处。
• 没有需求文档:很尴尬。。。这里提供两种方法。第一种方法，通过与项目或产品经理、研发沟通、询问，收集、梳理、 理解需求，自己写一个概要的需求描述，让大家确认(可以通过会议方式)需求描述是否符合业务、用户、功能需求，使研发(包含项目经理)、测试对需求理解达成一致。第二种，基于用户使用场景和行业经验来去做判断它是否合理，这种方式不适应刚入职新人。

同时，我们要与项目经理或需求工程师确认功能需求的优先级和重要程度，并对其达成一致，此为产品质量等级目标的重要依据之一。

我们在上一篇文章——《聊一聊 软件测试——软件测试基础》，已经介绍了软件产品质量模型、测试类型、测试方法、结合功能需求对被测对象进行测试需求分析，就能知道我们需要从哪些方面进行测试，从而可以得到测试点。

测试点整理

我们在“软件测试基础理论章节中已经介绍了软件产品质量模型、测试类型和测试方法，结合功能需求对被测对象进行测试需求分析，就能知道我们需要从哪些方面来进行测试，从而可以得到测试点。

关于显式需求和隐式需求

• 显性需求:一显而易见，直观的功能需求我们统一称之为用户的显性需求。
• 隐性需求:用户也不能完全清晰感受和用语言进行描述的，需要我们结合业务、用户、功能需求、 对需求进行延伸性、依赖互补性等方面分析。隐性需求也叫兴奋需求，当用户的显性需求被满足时，用户一般不会兴奋或惊喜，而不被满足时，用户则会产生抱怨，比如用户在某音乐网站搜索《青花瓷》， 如果搜索不到则会产生抱怨。当用户的隐性需求被满足时，用户一般会兴奋或惊喜，而不被满足时，用户却不会产生抱怨，比如用户想要听点新歌或者是来点周杰伦的歌。如果网站告诉用户:流行的歌还有《菊花台》、《牛X很忙》等等，用户立马精神崩溃:这网站太T了解我了。很显然，在这个过程中，网站激发了用户的隐性需求。

总结:

• 满足用户的显性需求是底线。
• 隐性需求是培养用户忠诚度的最好方式。

输出测试需求矩阵

测试需求矩阵明确了功能点与测试点的对应关系，输出测试需求矩阵，需要引入个评审环节，明确需求重要程度或优先级。

测试需求分析评审

在需求分析阶段，我们还可以进行哪些思考?测试的风险、重点和难点，关于这方面我们后续交流。