为什么你需要原型测试？
原型是一个操场，如果你愿意的话。你可以测试一下，如果不能解决问题，就把它们扔掉。迭代地了解事物如何与真实用户一起工作等。
原型测试不明确或尚未完全确定的具体方面，因此比尝试弄清楚如何整合某些东西还不完全知道一个完整的系统。这也意味着扔掉它时不会伤害太多。
在没有任何实际编程的情况下实现原型并不罕见。纸质原型和交互式PowerPoint幻灯片就是这方面的例子。
编写高质量的生产软件需要在项目的所有领域进行大量的工作。如果系统的某个特定部分可能很难实现，甚至不可能实现，那么编写一个可以解决问题的原型是一个不错的主意。当知道问题可以解决时，花更多的时间写出真正的高质量软件是可以接受的。
原型也可能是向用户展示概念的一种方式，否则难以解释。在这种情况下，原型重点在于展示该概念的关键特征，但它可能例如显示静态数据而不是实际计算。
所以，当它不起作用时你不会被解雇。
通常，在对原型进行编码时，您可能不太注意测试和编码标准。目标是快速找到一些工作来证明这个概念，或者开始讨论项目的各个方面。如果你确定这是不可行的或者决定采取不同的方向，那么你可以减少做出决定的努力。原型与完成的（或正在进行的）产品有不同的质量标准。
有时你会拿原型，然后简单地将它重构成实际的产品。这实际上取决于原型的结构是多么谨慎。通常最好的做法是使用原型作为概念并重新开始，使用常规流程和标准构建真正的应用程序。这样，您的产品就不会因为您快速获取原型而采取的捷径而“感染”。当用单元测试改造原型时，确定已经进行了充分的测试也很困难，因为只需编写少量的“正常”案例测试并轻松实现，尤其是在写入的代码难以测试的情况下。在代码之前编写测试并使用覆盖率分析有助于确保您已从测试性角度对设计进行充分测试和思考。
由于编码该死的东西可能需要很多年，而原型，可以在几分钟/小时/天
这也是很常见的原型，成为生产代码来完成。让我感到害怕，但它总是发生。 – 2010-04-02 19:59:10
那么，有*的过程*工作的方式。例如IBM的“该领域的迭代式开发”（尽管他们选择将其称为“原型应用程序”以将区别标记为原型）。但是，它应该*通常应该如何呢？就是说，原型与生产代码是分开的......然而，正如你所指出的那样，这可不是它总是如何结束的。 – Joey 2010-04-02 20:00:59