应用错误收集

时间：2014-09-28 09:06:30

标签： tdd formal-verification

可以测试驱动开发正式验证吗？是否保证程序正确且正常工作？选择测试有正式的基础吗？是否有任何算法可以遵循它？

答案 0 :(得分：4)

TDD不是银弹。您仍然需要编写代码，但仍然可能在逻辑和代码中出错。我认为TDD是一种思维工具，可以帮助您以非常系统的方式解决问题。

以下是一些文章，可以帮助您了解要遵循的算法：

答案 1 :(得分：1)

值得注意的是，如果没有正式说明系统的功能，就很难编写一组已知足够的测试。以下是一些可能有用的论文，以及摘要中的引用：

＆＃34;本文的目的是表明，通过适当的工具支持，可以将正式规范与测试驱动开发相结合，而不会失去测试驱动开发的灵活性。＆＃34;

＆＃34;本文介绍了使用VDM ++正式规范语言作为可扩展敏捷形式（SAF）软件开发方法的基础，这是一种用于关键任务或大规模软件开发的敏捷方法＆＃34; < / p>

＆＃34;在本文中，我们提出将几种技术结合到一个敏捷的正式开发过程中：基于模型的测试，正式模型，模型的细化，模型检查和测试驱动的开发。＆＃34; < / p>

答案 2 :(得分：0)

TDD是一个基于实例的经验过程，而不是基于证据的方法。就正确性而言，它的价值与实践者的严谨性一样多。 TDD提供了关于如何通过测试驱动的程序的指导，而不是用于编程或测试的 - 你几乎可以TDD到完美的实现，什么都不做，或通过无能为力的测试。

但是，您可以应用Equivalence Partitioning等传统测试技术来提高TDD测试的完整性。 Code coverage分析还提供了关于测试有效性的（不完整）视图。

对于更加定理证明的方法，您可以查看Property-based Testing。虽然TDD周期在这样的背景下看起来肯定不像规范，但它可以用TDD思维攻击。

答案 3 :(得分：0)

可以测试驱动开发正式验证吗？

没有对测试驱动开发的正式验证，因为它的主要目标不是生成测试，而是提供一种方法来设计和编码。

是否保证程序正确且正常工作？

我不认为无论采取哪种方式，都能完全保证程序是正确的。

是否有选择测试的正式基础？

我们在TDD中选择测试的方式是编写那些应该引导我们完成下一个我们即将编写的代码单元的方法。

是否有任何算法可以遵循它？

它实际上非常简单（但很难熟练）。