基于属性的测试的教学和评估

2021-04-13   出处:blog.brownplt.org/  作/译者:shriramkmurthi/Elaine66  

        

        基于属性的测试(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}


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
137°|1372 人阅读|0 条评论

登录 后发表评论