具有复杂输出的算法的测试方法

时间:2009-06-23 00:21:56

标签: unit-testing testing

如何测试基本上是黑盒子的程序的结果?例如,一年前我不得不写一棵B树作为家庭作业,我真的很难测试正确性。您在这种情况下使用了哪些策略?可视化?强大的输入 - >测试数据的结果集?当你很难获得这样的数据时你会怎么做因为获得它们的唯一方法是你正确的工作程序?

编辑:我认为我的问题被误解了。理解B树如何工作没有问题。这是微不足道的。但是编写用于验证其正确功能的可靠测试并非易事。我认为这个学校问题类似于许多实际的真实单词场景和测试用例。有时理解域名与提供正确的程序有很大的不同......

EDIT2:是的,使用B树可以用笔和纸验证正确的行为。但这真的很脏而且不好玩:)对于需要大量数据进行验证的问题,这种方法效果不佳......

8 个答案:

答案 0 :(得分:2)

如果您没有掌握手头的问题,您如何制定解决方案呢?我的建议是了解域名,以便能够在纸上解决问题并确保您的程序匹配。

答案 1 :(得分:2)

我不确定这些答案是否能真正解决手头的问题。 B树的输入和输出与任何其他字典的输入和输出没有任何不同---但如果算法正确实现,算法的性能会更好。它只有两个功能才能测试(添加和查找),所以理论上,这个单一组件的“黑盒”测试应该没问题。设计可测试性不是问题,因为无论你如何操作,整个算法都将是一个组件。

所以问题是:当你必须实现微妙的算法时,你头脑中不能总是理解的具有复杂输出的种类,你如何测试它们?我认为您可以使用三种不同的策略:

  1. 黑盒测试基本功能。对于B树案例,这就像cwash建议的那样,以及确保当你添加一个项目时,你可以找到它等等。

  2. 测试算法应该维护的某些不变量(B树应该平衡,节点内的值应该排序等)

  3. 可能需要进行一些小的“铅笔和纸”测试 - 手动完成算法并检查它是否与您的代码相匹配。但是大数据测试都可以是类型2.这些也可能很脆弱,所以除非你需要确切地确定你的算法,否则你可能想要避免它们。

答案 2 :(得分:0)

咨询有关该主题的专家。

我知道如果我有一个复杂的程序我正在尝试修复,我不知道在我的更改之后输出应该是什么,所以我需要咨询一位了解业务需求的开发人员,他们是能够验证我所做的是正确的。

答案 3 :(得分:0)

我将专注于构建运行B树算法功能的测试用例。多年来我没有看过它,但我很确定你能够找到一个记录的步骤序列,以按特定的顺序插入一组值,然后验证叶子节点是否应该如此。如果按照这些方式构建测试,您应该能够证明您的实现是正确的。

答案 4 :(得分:0)

关键是要知道在测试死亡事件和进行充分覆盖应该涵盖的测试之间存在平衡。通过测试字母字符或标点符号,边缘情况(例如空输入或检查输入)是数字,可能是您需要的大多数测试。为了补充这一点,可能需要处理一两个常见情况,以显示程序也可以处理非边缘情况。覆盖大多数程序中的所有有效输入都是过度杀伤,并且会导致大量的测试。

答案 5 :(得分:0)

我认为你问的问题的答案归结为设计可测试性。通常,当您测试驱动解决方案的开发时,您可以免费获得可测试的设计。但是让我们面对现实,当你实现一个高度数学的算法时,这并不会失败。

为确保您拥有可测试的设计,您需要了解接缝是什么。然后你需要了解一些经验法则,例如避免静态,使用多态,正确分解问题和分离问题。

观看"The Clean Code Talks -- Unit Testing" by Misko Hevery,我认为它会帮助您绕过它。

答案 6 :(得分:0)

尝试从需求的角度来看,而不是从实现的角度来看。在编写代码之前,您必须准确理解您希望它执行的操作。

测试和要求应该是匹配对。如果您在定义测试时遇到问题,可能是因为要求没有明确定义。这反过来意味着你可能有错误,而不是实施错误,但“缺乏明确的要求”错误。在这种情况下,代码编写者将处理他/她认为是需求的精神列表,但不能确定,并且他们不会被写下来以进行独立的理解和验证。

我一直在努力解决那些要求不明确的软件,因为客户甚至无法告诉我们他们想要什么。但是当我们交付给他们时,他们肯定可以告诉我们他们不喜欢什么!软件工程的一个重要部分是在编码开始之前就满足要求。这在高级别(整体产品,客户需求输入)以及较小级别(模块,单个功能,其中需求由软件团队或个人内部定义)中都是如此。虽然高级要求更具流动性,但我认为迭代开发在某种程度上仍然是正确的。

答案 7 :(得分:0)

@Bystrik Jurina,

我经常参与涉及不同数据格式之间转换的项目。大多数答案都集中在测试B树或类似算法上,但似乎您正在寻找更一般的答案。

我的大多数工作都是基于命令行的。这可能听起来像是一个矛盾,但我使用的第一个工具之一是可视化。我将编写一些方法来以易于使用的格式写出我的数据结构。这可以(并且通常确实)包括视觉上清晰的东西。但通常它也意味着我可以使用较小的测试程序轻松解析,甚至导入Excel。

我将首先关注基本概要,然后编写一个程序来完成我需要完成的任务。如果这是一个多步骤过程,这可能意味着一次执行一个步骤并在继续之前验证每个步骤的结果。或者编写仅在特定情况下有效的内容,然后扩展预期可以工作的案例集。首先,您可以验证代码在有限的情况下工作,例如已知的输入数据。随着项目的进展,您可以开始记录您可能未测试的案例或意外类型的输入数据的警告。这有一些缺点,但是当你处理一组已知的输入数据时,这是一个很好的方法

验证技术可以包括正式测试用例,或者用于挑战您的假设的非正式程序。这可能意味着编写一个基本的驱动程序来实现“核心”例程。一个很好的例子是将记录添加到数据库,然后将其读回并将原始对象与从数据库加载的对象进行比较。

如果您无法绕过程序运行的方式,请考虑它需要完成的工作。编写测试不同输入产生不同输出的方式的代码可能更容易。生成可视化是一个很好的帮助,因为决定如何显示数据的行为可以让您考虑不同的条件并专注于数据结构的最关键部分。

我经常发现构建可视化使我承认数据的存储方式不是很清楚。对于B树,表示不是很灵活。但是对于其他情况,当嵌套的对象树更自然时,您可能正在使用并行数组。