目录
摘要
软件要求通常分为令人眼花缭乱的类别。 功能性和非功能性需求排在最前面，下面有大量的子类别。 在这里，Clint Hoagland将其归结为三类，根据它们的测试方式进行区分。
内容
让我们说你是一个新的测试者。 你在工作的第一天开始，你被介绍给团队，然后你就会被带到你的办公桌前。 您启动计算机并与对手会面：您要测试的软件。 随附该软件是一系列要求，可以指导您完成任务。
快速的互联网搜索“需求类型”带来了各种需求分类系统，包括Hewlett-Packard的FURPS +模型和IEEE提出的模型。 这些模型可以帮助那些收集需求的人，但对测试人员来说并不是那么有用。 对于测试人员，我提出了一个不同的，更简单的系统，其中需求按照应该测试的方式进行分类。 对于测试人员，实际上只有三个类别：显式，隐式和潜在需求。
明确的要求：你写下来的东西
我们的第一类要求是明确的要求。 这是最简单的类型，也是最容易测试的。 在利益相关者向开发团队传达的文档中最常见的是明确的要求。 它们可能采用精心设计的规范，一组验收标准或一组线框的形式。
该软件是由明确要求描述的吗？ 如果是这样，这很好。 如果不是，那就糟糕了。 简单吧？
在没有完整规范的情况下怎么办？ 你怎么知道某件事是否是一个错误？
首先要记住的是，即使在没有明确的设计文档的情况下，也总会有明确的要求存在于某处。 寻找声明形式的明确要求 - 即与最终用户就软件可以执行的操作进行通信。 这些通常可以在用户文档或营销材料中找到。
要记住的另一件事是明确的要求只是难题之一。
隐含要求：客户期望的事情
隐含要求是第二种类型。 这些是用户期望未被明确捕获的所有内容。 示例包括性能，可用性，可用性和安全性。 用户希望他们的密码不会以纯文本格式存储; 这个要求不需要被任何人写下来。
考虑一种基于云的存储产品，它允许您在线存储文件。 该产品获得了新的明确要求：用户应该能够使用共享按钮通过URL与其他用户共享私人内容。 但是，在测试时发现，通过修改生成的URL中的值，其他用户可以查看共享用户的所有私有内容。 这违反了一个隐含的要求，即只有共享内容才能被其他用户访问，从而导致显示停止错误。
隐式要求有时被称为“非功能性”要求，尽管我发现这种用法令人困惑。 当然可以明确地捕捉任何这些“非功能”区域的业务预期，此时它们可以像任何其他明确要求一样对待。
潜在要求：会让您的客户满意的事情
最后，我们有潜在的要求。 潜在需求表示用户根据他们以前的经验而不期望的行为，但这会使他们更像是软件。 一个例子：当我在账户之间转账时，我的银行有一个动画过渡。 我没想到它会这样做，但它确实帮助我理解我是成功的，它看起来很酷，所以我很高兴。 另一个例子是游戏中的云同步：当视频游戏开始允许用户在任何计算机上访问他们保存的游戏文件时，用户对该功能感到惊讶和高兴。
一些网站会在您开始登录时自动填写您的用户名。有些网站不会。 这是一个潜在需求的例子，随着时间的推移，它成为一个隐含的要求。
测试三种要求
为什么以这种方式打破需求？ 这是查看软件的有用方法吗？
对于测试人员来说，以这种方式分解需求是有用的，因为显式，隐式和潜在需求必须在测试方式和处理失败以满足这些需求的方式上有所不同。 让我们轮流解决它们中的每一个问题。
测试：明确要求
无论何时将软件与任何类型的书面文档进行比较，您都要使用明确的要求进行测试。 但请记住，明确的要求通常意味着还应执行一项或多项否定检查。
当软件无法满足明确要求时，首先要检查它是软件还是需要更改的文档。 它可以是一个或另一个，甚至两者。 如果软件在没有满足其明确要求的情况下进入测试阶段，则值得退一步并检查团队的流程。 显式需求的验证应该由开发人员编写代码来处理，理想情况是通过创建一组自动检查来证明这些需求已经得到满足。
测试：隐含要求
在错误发现方和错误报告方面，对隐式需求的测试要复杂得多。 它也代表了测试人员帮助开发工作的最佳机会。
为了测试隐式需求，测试人员必须成为客户问题领域和软件用于解决这些问题的技术的专家。 虽然使用启发式测试方法可以提供帮助，但在测试隐式需求时也很难展示“覆盖率”。
当软件无法满足隐含要求时，该失败的报告还必须包括对客户期望软件行为不同的原因的解释。 从影响客户体验的角度来看，bug的影响是什么？
测试：潜在要求
对潜在需求进行测试是最棘手的，因为在您开始使用软件之前，无法猜测这些需求是什么。 为了测试潜在需求，测试人员必须深刻理解客户的偏好，同时仍要记住他们不是客户。
UX研究技术可以帮助您增加理解。 了解客户如何实际使用该软件，并使用该信息设计场景测试以发现潜在需求。 还要记住，最终用户并不总是知道什么是可能的，也可能不会要求能让他们满意的一切。
当软件无法匹配潜在需求时，该故障代表了改进软件的机会。 它也代表了计划外的工作。 而不是将这些机会视为错误，找到一种方法将它们纳入团队的常规规划过程。 拥有流动机制以结合新潜在需求的团队将产生更令人满意的产品和更快乐的客户。
测试不仅仅是检查明确的要求
将测试工作视为规范与实际软件之间的比较可能是诱人的。 但是，即使在存在规范的情况下 - 并且可能不存在规则 - 测试人员也必须考虑未记录的隐式和潜在需求。 专家测试人员是一名测试人员，他深入了解那些隐含和潜在的需求以及如何测试它们。
