基于属性的测试(PBT)在工业领域的应用日益广泛，但在教育领域却明显滞后。许多学者甚至从未听说过它。这并不奇怪; 计算机教育甚至还没有适应基本的软件测试，即使它可以解决教学问题。所以这个滞后是可以预测的。

举例问题

        但即使是想使用它的人也往往很难找到好的例子。再怎样费劲心思颠来倒去地找，也很难将数学算法例子与之联系起来。这是一个多方面的问题。如果没有令人信服的例子，就没有人愿意去教它。即使他们教了，除非例子很有说服力，否则学生也不会多么注意它。如果引不起学生的注意，他们也就不会意识到在以后的职业生涯中会有使用它的机会。

        这失去的不仅仅是一种测试技术。我们认为PBT更像是一个正式的规范，它是一个关于行为的抽象声明。与正式的规范不同，它不需要学习新的语言或数学算法形式，它是可执行的，并且产生具体的反例。因此，在Brown的系统逻辑课程中，我们使用它作为更正式规范的起点。（即便他们对正式规范也许一窍不通，只是单纯地想成为了更好的测试人员。我们仍然认为这也是一个不错的收获.）

        因此，在过去的10年里，随着越来越人多的关注，我们一直在教授PBT：从我们的快速入门课程开始，然后是系统逻辑，并且在其他课程也逐渐开始。那么我们如何激发这个概念呢？

关系问题

        我们通过所谓的关系问题来驱动PBT。那些是什么呢？

        试着思考典型的单元测试。你写一个输入输出对：f(x) is y 。假设它失败了：

• 通常，函数f是错误的。恭喜你，你刚抓到一只bug！
• 有时，测试是错误的：f(x)实际上不是y。这也许需要一些思考，也可能凸显出了对问题的错误理解。

        这通常是单元测试故事的结尾。然而，还有一种可能性：

• 那就是其中并没有什么“错”。f（x）有多个合法结果w、y和z；您的测试选择了y，但是这个特定的实现碰巧返回了z或w。

        我们称之为“关系”，因为f显然更像是一个关系而不是一个函数。

一些例子

        到目前为止，还很抽象。但信息处理的许多问题实际上都与关系有关：

• 正如估算图表或网络中的最短路径的思考方式一样，最短路径可以有很多，而不仅仅是一条。如果我们编写一个测试来检查一个特定的路径，就很容易遇到上面的问题。
• 许多其他的图表算法也是关系型的。合法答案有很多，而实现过程恰好只选择了其中一个。非确定性的数据结构激发了关系型行为。
• 各种各样的匹配问题——例如，稳定婚姻问题——都是关系问题。
• 组合优化问题是关系型的。
• 即使对非原子数据进行排序，也是关系型问题。

        简而言之，信息处理充满了关系问题。虽然它们并不是PBT唯一有意义的运用背景，但它们确实提供了学生已经研究过的丰富问题集合，这些问题可以用来在一个有意义的环境中揭示这个观点。

评估学生表现

        好吧，我们已经让学生写PBT好几年了。但他们做得怎么样呢？我们如何衡量这样一个问题呢？（课程成绩太浅显了，甚至作业成绩也可能包括各种标准——类似代码风格——这些标准与这个问题并不严格相关。自然，他们的主要产出是一个“二进制分类器”——它将结果标记为有效或无效，以便我们可以计算正确率和召回率。然而，这些措施仍然不能从语义上去洞察学生们做得如何，以及他们遗漏了什么。

        因此，我们建立了一个评估这一问题的新框架。也就是说，我们将每个问题的抽象属性语句（视为一个形式规范）细分为一组子属性，这些子属性的合集是原始属性。然后将每个子属性转换为一个测试套件，该套件接受那些强制执行该属性的验证器，并拒绝那些没有强制执行该属性的验证器。这让我们更细致地了解学生是如何做的，以及他们犯了哪些错误。

如果对此有兴趣，或想了解最新成果，请访问文章。

{测试窝原创译文，译者：Elaine66}