测试软件要求规范 （SRS）

软件中的大多数错误都是由于不完整或不准确的功能要求造成的。软件代码，无论它写得有多好，如果需求中存在歧义，就无法做任何有目的的事情。

在完成开发或产品发布后修复 Bug 的成本太高。因此，最好进行需求分析并捕获需求歧义并尽早修复它们

开发生命周期。

如何在设计阶段测量和冻结需求？

我们需要定义一些标准测试来衡量需求。一旦每个要求都通过这些测试，您就可以评估和冻结功能要求。

下面是一个度量要求的示例。假设您正在处理一个基于 Web 的应用程序，并且要求如下：

“Web 应用程序应尽早响应用户查询”

在这种情况下，您将如何冻结要求？

您的需求满足标准是什么？要获得答案，请向以下人员提出此问题

利益相关者：多长时间的响应时间对您来说是可以的？如果答案是，我们将在2秒内接受响应，那么这是您的需求基准。冻结此要求，并对下一个要求执行相同的过程。

现在让我们再举一个例子。对于我们公司的一个项目，我们从客户那里获得了应用程序第一阶段的SRS文档。当我们讨论这些需求时，团队中的每个人都对需求有自己的理解。我们很快意识到本文档中存在很多歧义。我们决定在编写测试用例或开始设计阶段之前先修复这些歧义。所有模棱两可的要求都与问题列表一起发送给客户，以澄清这些问题。后来每个人都了解了整个项目的范围，我们很清楚要开始项目设计和编写测试用例。

需求应该是清晰和一致的 - 在开始编写测试用例之前，确保整个项目范围和要求对每个人都是清楚的。

通常，我们使用自己的方法来发现未指定的需求。当我们阅读 SRS 文档时，除了 SRS 文档应该涵盖的其他要求之外，我们还记下了自己对指定要求的理解。这有助于我们提出正确的要求

有关未指定要求的问题。

测试需求规范的下一个标准是-“发现缺少的需求”。有时，SRS 编写器只是假定一些要求。但需求不应基于假设。要求应明确而完整，涵盖要开发的系统的每个方面。需求规范应该提到这两种类型的需求，即系统应该做什么，不应该做什么。

为了检查需求的完整性，将需求分为三个部分，“必须

实现“需求，这些需求没有指定，而是”假设“的，第三种类型是”想象“类型的需求。在设计阶段之前检查是否解决了所有需求类型。

检查需求是否与项目目标相关 - 有时，SRS 编写者对应用程序后续阶段的功能有自己的看法。为此，他们可能会介绍一些

应用程序当前阶段的需求，他们可能只想实现，但在后面的部分完成之前不会使用。我们需要仔细了解这些要求。如果您认为任何要求与正在开发的当前阶段的范围无关，则可以询问有关该要求的目的的问题。然后，这将详细描述特定要求，以便更轻松地设计和测试应用程序，考虑未来的范围。

如何确定要求是否相关？

使用这个简单的方法 - 设置项目目标并提出以下问题：如果我们不实现此要求，是否会在实现我们的特定目标时造成任何问题？如果不是，那么这是一个无关紧要的要求。了解这些要求对项目经理很有用。他们可以要求客户在紧迫的期限内更改这些要求。

需求规范文档应解决以下问题：

• 项目功能（应该做什么，不应该做什么）

• 软件，硬件界面和用户界面

• 系统正确性、安全性和性能标准

• 实施问题（风险）（如果有）

结论：

• 要求应明确且具体，没有不确定性

• 要求应根据具体值进行衡量

• 需求应该是可测试的，每个需求都有一些评估标准

• 要求应该是完整的，没有任何矛盾。