Steve McConnell 的 Code Complete 是一本优秀的书，我推荐给想要更多地了解软件工程的人。由于图表列出了建模或原型设计，因此它们似乎将它们等同起来，因为它们都是真实事物的抽象。

WRT 发现他们可能在这里提到的错误是功能性错误与非功能性和行为问题。例如，找到 99% 的大多数边界错误的最简单和最快的方法可能是通过代码检查和/或单元测试。（不幸的是，由于同行代码审查（不是正式检查）和快乐路径单元测试的不足，或者专注于获得某种代码覆盖率而不是测试覆盖率的单元测试，许多边界错误偷偷溜走了。）

真正的收获是

• 可以通过代码检查、原型设计或建模以及单元测试来发现一些 [功能] 错误
• 但更重要的是，没有一种方法足以暴露所有类型的错误（Beizer 的农药悖论）

越来越多的公司更加重视 TDD、单元测试甚至同行评审。这都是好东西。这并不意味着测试人员将永远失业。但是，由于强调推动“质量”上游并降低在周期后期发现某些类型的错误的成本，我怀疑测试的作用将会增加，测试人员将真正参与 SDLC 的所有方面。

如果你有一本“我们如何在微软测试软件”一书，那里有一章是关于基于模型的测试的。

TESTHEAD 对该章节的评论可以在http://mkl-testhead.blogspot.com/2010/12/testhead-book-club-how-we-test-software_15.html找到

我不会推测作者所说的“建模”是什么意思，因为在软件领域它可能意味着不同的东西。也许你可以使用文章底部的评论框问他的意思。

在他的文章中，我认为“原型设计”意味着构建产品某些方面的模型版本，用于说明和测试一个想法。例如，用户界面的纸质原型可能是一组手绘图片，这些图片说明了用户界面的本质。纸质原型的倡导者断言，测试纸质原型将产生对“真实”产品需求和设计的洞察。

如果做得好，原型制作可以成为在投入大量精力构建实际产品之前获得概念早期输入的宝贵工具。

我认为 user246 给出了一个很好的答案。但是，我敢于推测建模一词。我们使用这个术语来谈论在实际获得一些代码之前创建一个你手头的规范的编码模型。所以它非常接近原型设计。还有一些非常复杂的建模工具，例如 NModel（NModel 主页）。在实践中，我会通读一个新功能（静态方法）的规范，然后，如果逻辑非常复杂，我会用 NModel 设置一个小模型程序，让它分析我的模型是否可能死结束等（是的，它可以做到这一点）。我个人不经常使用 NModel。相反，我写下程序应该做什么的模型，例如流程图. 当已经有代码可以用作规范时，这也很有用。查看图表或者可能已经在构建它时，我通常会很好地了解可能出现问题的地方以及可能会发现错误的地方。