软件测试需求分析基础篇

　　本章节主要讲解软件测试需求分析一些基础的相关概念，方便大家在后面更容易掌握深入的内容。需求，简单理解就是客户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么，这样的一份文档就是我们通常说的软件需求说明书，也就是我们说的原始需求。

　　IEEE 软件工程标准中对需求进行了详细的定义，具体的定义为：

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

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

• 　　(3)一种反映上面(1)或(2)中所描述的条件或权能的文档说明。

　　需求是“用户所需要的并能触发一个程序或系统开发工作的说明”，为了满足用户需求，我们必须将需求形成一份文档(即需求说明书)。需求说明书描述了系统的行为、特性或属性，在开发过程中对系统的约束。

　　在这里有几个与“用户”相关的名词：“用户”“客户”和“最终用户”。通常购买软件的人称之为客户，而真正操作软件的用户叫“最终用户”，当然我们通常说的“用户”是泛指“客户”和“最终用户”。对于企业来说，“客户”和“最终用户”通常不会是同一个人。

　　对于需求不同角色的人，其要求也不尽相同，这就是我们通常所说的需求层次。通常需求可能被分为三层：业务需求、用户需求和功能需求，如图6-1 所示。

　　图6-1 需求的三个层次

　　(1)业务需求

　　业务需求是描述组织或客户的高层次目标，通常问题定义本身就是业务需求。业务需求是一个系统目标，它必须是业务导向的、可度量的、合理的、可行的。这类需求通常来自于高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。

　　业务需求从总体上描述了为什么要开发系统(why)，组织希望达到什么目标。一般使用前景和范围(vision and scope)文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求(project charter 或market requirement)文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM 后公司的客户满意度达到80%以上”就是一条组织愿景。当然这些高层的需求数量并不会很多，也不会很具体(2～5 条)。

　　(2)用户需求

　　用户需求是指描述用户对产品的要求，即要求产品完成哪些任务。如何完成用户需求呢?通常可以通过对用户访谈、调查等方法来获得用户原始的要求，再对用户使用的场景进行整理，进而得到用户需求说明书。用户需求说明书必须能够体现整个软件系统将给用户带来的价值，或用户要求系统必须完成的任务，也就是用户需求描述了用户通过使用该系统能做什么事情。用户需求是很重要的内容，通常可以使用用例、用户故事、特性等来表达用户的需求。

　　(3)功能需求

　　功能需求是需求最核心的内容，它详细描述了具体的功能应该如何实现，开发工程师根据功能需求提供设计的解决方案，主要包括方案设计、详细设计、编码实现，都是依据功能需求说明书来进行的。功能需求的数量远比用户需求多，这些需求会被记录在软件需求规格说明书中(SoftwareRequirements Specification，SRS)。

　　SRS 完整地描述了软件系统的预期特性、输入和输出等相关信息。产品特性是指一组逻辑上相关的功能需求，为用户提供某项功能，使用业务目标得以满足。对于商业软件来说，特性则是一组能被客户很快识别，并帮助他决定是否购买的需求，客户希望得到的产品特性和用户的任务相关的需求不完全是一回事，一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

　　功能需求除了来自于用户需求，还有来自以下几部分的需求：

　　1)系统需求(System Requirement)

　　系统需求用于描述包含多个系统的顶级需求，它是从系统实现的角度描述的需求，当然有时还需要考虑相关的硬件、环境方面的需求。

　　2)业务规则

　　业务规则本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

　　3)质量属性(Quality Requirement)

　　质量属性是指产品是否遵守软件质量模型中关于质量特性的要求，常见的质量属性包括：功能、性能、易用性、可靠性、可移植等。

　　4)约束(Constraint)

　　约束也称为限制条件、补充规约，通常是对解决方案的一些约束说明，通常相关的法律、法规都会成为约束条件的来源。

　　在原始需求整理好之后，测试工程师会将原始需求转化为测试规格，我们通常说的测试规格是产品测试规格和特性测试规格的一个统称，一般我们说的测试规格是指整个系统测试的规格。测试规格主要是对客户需求、产品包需求、设计需求、设计规格进行综合分析得到的一份文档，之所以需求这份文档，是因为我们必须在测试的角度对测试进行分析，以确定我们测试的主要内容和特性。

　　但这些原始需求是没有给出来的，或者说原始需求在这方面给出来的信息很有限，测试规格需要经过多次会议和整理才能得到，然后对每条测试规格使用唯一标识进行标记。测试特性是指在逻辑上相关的一组测试规格的集合，可以是功能方面的测试规格集合，也可以是非功能性方面的测试规格集合，当然这个逻辑划分是有一定规则的。

　　本章节关于“测试需求分析基础知识”就学习到这里，大家觉得有用的话记得每天来这里和小编一起学习涨薪技能哦。