成功构建回归测试的关键仍然在于是否能够设计出优秀的规约界面，并针对规约界面进行测试。这样，不但设计具有抗变化性，测试同样具有抗变化性。而唯一可能改变的就只有实现了。在回归测试的帮助下，代码的变化是不足为惧的。我们把有关测试的详细讨论放在测试一节中。
组织规则
在后续的章节中，我们会详细的讨论XP中的一项非常有特点的组织规则－结对编程。这里我们需要知道，不同的团队有着不同的组织，其迭代过程也需要应用不同的组织规则。例如，组织的规模，小规模的组织可以应用更快的迭代周期，如一周，在一个迭代周期中，团队可以集中力量来开发一个需求，强调重构和测试，避免过多的前期设计。对于大的组织来说，可以考虑迭代周期更长一些，更注重前期设计，并将开发人员和测试人员的迭代周期交错开来。团队的组织构成也是影响迭代过程的主要原因。团队是否都是由相同水平的人构成，每个人的专长是否能够互补，团队是否存在沟通问题。
(四)需求和故事
如何分析需求，如何记录需求，如何将需求映射为设计，这些永远是需求分析中最为重要的问题。XP提倡以一种简单实用的态度来对待需求，而在软件开发的历史中，需求分析从来都是最需要严谨对待的工作流程。究竟谁是对的？
故事
每个人都喜欢听故事，这也许是从小就养成的习惯。如果能够把需求分析工作变成听故事的过程，那该有多好。需求分析人员写出一个个优美的故事，开发人员边看故事，边实现故事。也许这就是XP的设计思路所在。用户故事，XP把需求变成了一个个故事，摒弃了枯燥无味的需求稳定。文档的作用是传递信息，如果失去这个意义，再优秀的文档也没有任何用处。但是，完整细致、厚达数十页的需求文档是否真的能够达到沟通的目标呢？对于大多数而言，恐怕看到文档的厚度就已经心生惧意了吧。好吧，我们通过很多的辅助手段，可以强制要求开发人员都投入大量的精力来研究、学习复杂的需求文档。但是这厚厚的需求文档真的能够完整的记录所有的需求吗？更糟糕的是，需求是会发生变化的，到时候如何维护这份需求文档呢？回想精益原则，我们可以判定，这种处理需求的方式一定会产生大量的浪费。将需求做的尽善尽美需要成本，项目组的人员熟悉需求需要成本，维护文档需求成本，解决不一致的问题也需要成本。那么，我们可以针对这几点做一个分析：
需求的文档是否要尽善尽美？需求文档的最大目标是将信息从业务人员传递给开发人员（当然也会存在其它的目的，例如作为合同的组成部分）。那么，文档是否完美和能否实现沟通效果并没有直接的关系。
文章来源于领测软件测试网 https://www.ltesting.net/
