在Scrum中，在客户完成迭代时经常进行测试是个好主意。但问题是，当一些原型与客户一起完成时，我应该使用什么样的测试？据我所知，当所有迭代完成时，验收测试是可以的 - 但不是它的某些部分。测试计划的示例会很有帮助
答案 0 :(得分：3)
据推测，原型是为了展示某些东西（性能，特定功能等） - 因此，您应该使用代码开发等效的验收测试。
换句话说，假设您正在制作一个原型，展示如何在整个应用程序中每秒处理一百万条消息。除了编写代码以执行此操作之外，您还应该弄清楚如何在迭代结束时让客户签署确认软件确实处理了那么多消息。
作为早期演示的一部分，您应该与客户讨论代码和测试。
另外请记住，在敏捷/ Scrum测试中，测试是一个连续的过程，而不仅仅是您作为迭代活动结束而保存的内容。
答案 1 :(得分：1)
我发现“测试”一词的麻烦在于它假设您正在开发的功能是正确的东西。
如果您要向客户展示原型，请尝试以您所做的一切都是错误的方式开展工作，并希望尽快找到答案。发现它是客户想要的将是一个很好的惊喜。您的测试应该是从您的客户那里获得反馈，并且您希望在获得成功之前获得一两次失败。如果您的客户只是点头并说“是的，没关系”，那么您可能会遇到错误的客户（这里写的内容可能有所帮助：http://lizkeogh.com/2010/02/02/theyre-not-user-stories/）。
我还使用BDD的场景与BA和用户讨论我们期望发生的事情，这样原型本身就有更好的机会。
我的原型通常是经过单元测试的代码，后面有硬编码数据，而不是之后需要丢弃的黑客攻击部分。 GUI是一个复杂的位和最有可能改变的部分（我没有对GUI进行单元测试）。
希望这有帮助！
答案 2 :(得分：0)
在Scrum中，您总是拥有一个完全正常工作的产品（这意味着您可以通过测试来确保产品能够满足应有的要求）。该产品可能缺少一些关键功能（或者当您在第一次迭代时所有这些功能），但您的目标是忘记“原型”的想法，并开始考虑“所有代码始终生产就绪”。
有一个例外：技术飙升。在这里，当您尝试学习新技术时，您开发了一个小型演示（再次完全正常但非常有限）。大多数情况下，您会将此代码重构为最终形式（而不是简单地将其抛弃并从头开始）。
这篇文章可能有助于更好地理解这个想法：克林顿基思的Prototypes。