在功能的开发周期中，即使在满足所有要求（UI改进等）之后，该功能也在不断变化。如果您对该功能进行了自动化测试，则这些更改可能会破坏您的自动化，您将不得不重做它。如果功能不断变化，那么在每次修订后重新设计自动化都没有意义。但是，在某些时候，您必须自动化它，以便进行回归测试。我们如何找到返工自动化的最佳时间？我们如何获得最佳数量？我的团队同意我们过度改造了我们的一个功能的自动化。我们犯了一个错误的例子就是在会议之前重新设计自动化，我们向客户展示了该功能以获得客户反馈。我们应该知道客户反馈会导致功能发生更多变化。在这种情况下，功能测试应该已经足够了。 有没有人有任何提示或经验可以分享？
答案 0 :(得分：1)
总体提示是在您开始构建之前对功能的“完成”意味着达成共识。
如果在构建过程中遇到了一些新的调整，你想要添加它们以改进功能（或其他）不要将它们添加到现有的故事中 - 写一个新的...并确保你将其优先于您需要做的其他事情。
有时，但并非总是如此，这表明您正在使用过大的功能增量。尝试进一步分割和细化故事，直到你可以写下一些非常具体的“完成”定义。考虑在开始构建之前自动完成“完成”的测试（但不要过分）。
您可能会找到Specification By Example使用的书籍。
答案 1 :(得分：0)
根据我的经验，您所开发的功能尚未被客户完全理解。
将该功能分成小部分，如@adrianh建议。
不稳定客户的另一个提示：让他们首先看到伪原型，甚至可能在计划会议中（直接将其编码为html或更简单的原型，如原型/图表工具）。让他们玩吧。这样，您可以更轻松地使用您的功能。