什么是操作性定义，我们为什么应该使用它们？

📝 面试求职： 「面试试题小程序」，内容涵盖测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

完善需求是构建高质量软件的重要部分。Tom Gilb曾写道：“在你的运营软件中将会出现的超过60%的错误，在代码编写之前就已经存在了”，并且“如果我们能向上游推进并改进我们的设计，我们会获得更大的优势。”

操作性定义可以作为一种工具，将测试向上游推进，以发现定义需求的过程以及需求本身中的漏洞。

W. Edwards Deming的质量持续改进理念帮助日本在第二次世界大战后重建，他写道：“操作性定义为一个概念赋予了可传达的意义。”

诺贝尔奖获得者、物理学家Percy W. Bridgeman在他的科学研究中创造了操作性定义。当他制造人造钻石时，他的仪表在极端压力下不断损坏，他的工作促使他去审视科学家是如何定义测量的。John Willis写道，Bridgeman的工作启发了Walter Shewhart和Deming。

Deming给出了一个操作性定义的例子：

对一块金属或一个组件的规格测试
用于判断的标准（或标准）
决策：是或否，对象或材料是否符合标准（或标准）

另一个操作性定义的例子是：

规格，例如：

作为Gmail用户；
我想登录我的Gmail账户；
这样我就可以查看我的电子邮件。

标准，例如：

验收标准；
我可以看到发送到我的Gmail地址的电子邮件。

对正在测试的内容是否符合标准的决策，例如：

“完成”的定义包括所有验收标准都将被测试

用户故事等需求能否作为操作性定义？

“需求是否构成操作性定义？”这个问题可以用作启发式方法，帮助我们理解需求完善的过程。Kindle字典说，启发式方法“能使一个人自己发现或学到某件事”。如果需求是操作性定义，那么它们必须具有操作性定义的结构和清晰度。

没有任何规格能够“完整”，因为总会有一些需求被忽视，或者在开发过程中出现。任何定义工作需求的过程都应该包括Deming操作性定义例子中概述的三个组成部分。

这是因为：

需要对工作进行规格说明
它需要有标准来测试
它需要被测试

如果用例和用户故事被正确地编写和使用，它们可以被视为操作性定义。这是因为它们必须具有操作性定义的三个组成部分。

用例提供了一种捕获规格的方法。用例中的目标是一组标准。期望新功能将针对目标进行测试。用例有验收标准，因此期望工作将针对验收标准进行测试。
用户故事包含一个作为规格的描述，并且有验收标准，即其标准。

如果用户故事或用例是操作性定义，那么正在开发的功能将针对标准进行测试。

一个作为操作性定义的用例示例：

规格：

作为Gmail用户
我想删除收件箱中的电子邮件
这样我就可以删除不需要的电子邮件

标准：

验收标准

- 点击一封电子邮件的选择复选框
- 点击删除图标
- 该电子邮件不再在收件箱中

对正在测试的内容是否符合标准的决策：

“完成”的定义包括所有验收标准都将被测试

一个不是操作性定义的用例示例：

规格：

作为Gmail用户
我想删除收件箱中的电子邮件
这样我就可以删除不需要的电子邮件

标准：

验收标准
- 点击一封电子邮件的选择复选框
- 点击删除图标
- 该电子邮件不再在收件箱中

开发团队没有定义测试验收标准的实践

如果用户故事或用例不是操作性定义，那么它没有被正确地编写或使用。检查用例或用户故事是否是操作性定义，可以更深入地理解用户故事或用例。

哪些技术不会产生操作性定义？

并不是所有描述计划工作的技术都可以被视为操作性定义。例如，有时测试人员会得到Gherkin作为规格。《Cucumber之书》说，Gherkin是Cucumber测试要进行的一系列步骤，因此也是用于测试工作的标准。

然而，测试人员还需要规格来理解要测试的工作。Gherkin不是操作性定义。这并不是由于Gherkin的“Given-When-Then”语法。Gherkin不是从其派生测试的完整规格。相反，它只是列出了用于运行测试的标准。操作性定义将包括规格。

这就是为什么将Gherkin用作测试规格是不足够的。知道Gherkin不是操作性定义，可以解释为什么以Gherkin为基础进行测试是笨拙的。这可以加强你要求更多支持测试的信息的理由。

开发操作性定义的技巧

如果你与一个非正式定义需求的团队合作，操作性定义特别有用。这是因为它们提供了一种方法来检查正在开发的功能是否有规格和标准，以及该功能是否会针对其标准进行测试。

如果你与一个非正式定义其工作需求的团队合作，这可能会很具挑战性，因为不清楚该功能应该做什么。测试人员可以要求他们的团队提供规格和标准，以便测试更有效。如果规格或标准没有提供，那么在测试中就会犯错误。这将浪费测试人员和开发团队的时间。

团队需要完成的工作的定义需要清晰。操作性定义也有助于我们将测试向上游推进，以识别需求模糊的地方。

有时，计划的工作被模糊地描述。操作性定义提供了一个指南，以确定提议的工作描述是否不模糊。

Deming写道：“安全、健全、可靠或任何其他质量的操作性定义必须是可传达的，昨天和今天具有相同的含义。”用户故事、用例或任何其他描述提议工作的方法都可能不清楚。例如，如果用户故事以“作为一个用户……”开头，那么它可能是不清楚的。它应该更具体，说明是哪种用户。

操作性定义可以用来验证描述是否清晰。Deming写道，操作性定义应该对供应商和购买者具有“相同的含义”，并且对……工人也具有相同的含义。如果计划工作的描述对销售和工程等多个部门的人员不清楚，那么它就不是操作性定义。它需要被修订以使其不模糊。

有时，团队会在新功能的需求中加入形容词。需求可能会说新功能是“好的”“可靠的”“安全的”“更好的”或“更快的”。然而，Deming写道，这些形容词直到用操作性术语表达为采样、测试和标准时，才具有“可传达的含义”，就像在操作性定义中一样。

总结

测试应该向上游推进，因为我们可以在此之前发现代码编写中的问题。操作性定义是向上游测试的有用工具，因为操作性定义提供了清晰度。无论使用哪种方法来定义需求，对计划工作的描述都应该是操作性定义。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】