测试是非常重要的，是软件成败的关键。但是目前国内对测试并不关注，或是假装关注。这样就无法保证软件的质量。测试有很多种，我们这里要说的是和需求息息相关的测试，就是接收测试（Acceptance Test）（关于这个词，可能不同的文章会有不同的译法）。
Surely you aren’t going to assume you’re getting what you need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done.
上面这段话摘自『XPInstalled』。接收测试有两个作用：首先是让客户明白系统能够做什么，然后是让程序员明白该让系统做些什么。
有一种测试的方法是把测试留到最后才做，让客户去发现错误。千万别这么做。原先花费1块钱就可以改正的错误，到了这个时候，可能需要花费1000块钱才能解决。这是软件开发的放大效应。因为很多的工作已经基于这个错误建立了，开发人员也已经对这个错误没有映像了。
XP中有一个很重要的价值，叫做反馈（Feedback）。Kent Beck在Extreme Programming Explained中有句话讲得非常好："乐观是编程的职业病，反馈则是其处方。"从需求的识别，到根据需求构建的系统交付给客户，客户提出意见。这就是一个反馈过程。反馈过程所花费的时间越少越好。接受测试就是解决客户反馈的一个有效的手段。客户编写可重复的测试脚本，开发人员开发出的软件要经受这个测试脚本的考验。这种的反馈速度是很高的，能够有效的解决反馈的问题。
因此，客户在要求实现需求时，同时也有义务提供相关的接收测试：
if it’s worth having the programmers build it, it’s worth knowing that they got it right.
一个有价值的功能一定是可测试的，如果不是，那么这个功能要么是没有价值，要么是尚未描述清楚。
要注意，这个测试必须是可重复的。这是因为需求的易变性。需求在不断变化，这就意味着代码在不断的变化。因此，原先已经用接收测试证明过了的代码还需要再次证明。这就要求测试是可以重复的。
大量的测试，甚至重复的测试引出了一个新的问题：全凭手工进行测试会浪费大量的时间。因此，易变的需求对测试提出了一个新的要求：自动化测试。只有自动化的进行测试，才可以完成如此大量的测试工作。目前，最好的自动化测试工具，应该就是Xunit系列。关于这方面的问题，大家可以参考相关的资料，这里我们不作深入的讨论。
接收测试最可能的一种形式就是自然语言的说明，外带一组的测试数据。需要强调的一点是，这个测试数据一定要包括输入和输出。这样才可以做出比较。如果只有输入没有输出。测试很可能就是白费劲。所以，计算这个输出是手工计算的，它也是必要的。
除了接收测试，还有一个很重要的概念就是单元测试（Unit Test）。但是单元测试和设计的关系比较大，和需求没有过多的关系，我们这里就只是点一下。大家如有兴趣，可以参考相关的资料。
7、分解
对于需求来说，需要用到的最多的技能可能就是分解的技能了。可以说软件科学最重要的思想就是"分而治之"的思想。不是吗？面向对象是不是一种分解的思想。类、组件、包，这种层级结构不正是体现了"分而治之"吗？当然我这里可能把包和组件弄混淆了。但我的主要目的是要指出这种分解的方法在软件开发中是无处不在的。对于需求也是一样。我们最早做的业务建模就是为了得到一个系统的概貌图。然后到了细节需求阶段，我们会把这张图放大，细分，一直到我们有把握处理为止。
如何把100块砖累起来呢？如果一块一块的累，那很容易就倒了。一种比较好的做法，就是先10块10块的打包，这样，100块砖就变成了10个砖包，再把它们累起来就容易的多了。面向对象其实就是这么做的，当然，面向对象的实现比累砖要难多了。
我们看看XP中是如何处理分解的。XP中最大的周期叫做发布版（release），一个发布版需要一个月或几个月的时间，一般不超过6个月。发布版的末期，需要向客户提供一个可以运行的软件的发布版。然后，XP还定义了次级的周期，称为迭代（iteration），一次的迭代大概需要一周或几周的时间。每一次的迭代都是一个"伪发布版"（pretend release），就是说，迭代的最后也必需要提供一个可以工作的软件，这个软件随时都可以发布。为了定义一次迭代中要处理的事情，XP还定义了素材（story），一份素材代表了客户希望在软件中出现的一项功能（feature），一份素材是很小的，它只需要花费一个开发人员几天或几周的时间。素材已经很小了，但是还需要细分到任务（task），一项任务只需要1到4天的工作量。这并不是最小的单位，XP还把任务划分到测试（test），但这已经到个人级别上了。
我们看到，XP从客户到每一个开发人员，定义了5级的单位，并把时间精确到了天、小时。所以我有时候听人说，XP好像对开发人员的要求不严格。错了，XP可以说是目前要求最为严格的方法，这种分类方法可见一斑。这种分类有什么好处呢？
首先，我们来看发布版，发布版的最短时间是一个月，也就是说，最频繁是一个月向客户交付一次软件。这样，就在很大程度上保证了反馈的迅速进行。避免了传统的开发方法中最后客户发现问题时已经太迟了的现象。
再看迭代，迭代之所以被称为伪发布版，就是因为它的产出物的性质和发布版是一样的。都是可以交付的产品，但是迭代的功能比较少，没有必要交付给客户。我们知道，在传统的软件开发中，整合是一个大问题。整合必然会出现问题，但是没人知道问题在哪儿。所以呢，XP通过不间断的整合，避免了这个问题。
但是，迭代的周期如此之短，能够做些什么呢。这就是素材出现的原因。素材由客户提出，由客户决定优先级，由客户决定放在哪一次的发布版和迭代中。同时，如上面我们谈到的，客户需要为素材制定接收测试。
一份素材的周期是几天或几周，而一次迭代的时间也就几周。这说明素材对迭代而言，单位过大了。所以要把素材再次分解为任务。每一个任务都需要一个开发人员认领，签字。在分解素材的过程中，我们可以发现有一些任务是多个素材共享的，这个概念和用例中的使用的概念是一致的。开发人员会估计自己的任务所需要的时间。从而得出一个迭代周期的总时间。这个时间的估计是基于以往的经验的，因此随着项目的进行，这个估计往往会越发的准确。
我们这里讲XP的分解哲学，并不是要求大家也依样画葫芦，你真要那样做也不行。因为XP的各项实践都是一体的，只有实现了所有的实践，才能体现其威力。我们这样断章取义是行不通的。但是其中的思想我们是可以借用的。分解、归类、排序、估计。这种分析问题的方法，也是我们值得借鉴的。这里有几点要注意：
最早的分解依据往往是客户要求的时间。例如，客户希望在3个月内看到什么什么。在客户和开发放商议之后，决定制定两次的发布版。这个决定虽然开发方可以提供参考意见，但是决定权在客户方；
素材的提出，素材的优先级，素材的安排，这些都是客户的权利。客户也有权利取消、增加、修改素材，或是改变其优先级；
客户投入多少，就能够看到多少的软件。客户也可以取消目前的项目，而且，先前的投资也会有相应部分的软件产出；
对于开发时间的估计是开发人员的权力，其它任何强加于开发人员的时间安排都是不对的；
任务的选择也是出于开发人员自愿的原则；
如果开发人员估计出的总的时间和迭代的预计的时间有出入，绝对不能牺牲开发人员的额外时间换取迭代在限定时间内完成。这种做法无异于饮鸩止渴。比较好的做法是去掉一些任务。
8、客户如何参与
这是一个纯粹的补充问题。一次，一位读者写信来问我，中国的客户素质比较低，对计算机不了解，XP强调的现场客户现实中根本做不到。
XP要求开发人员在开发软件的过程中随时予以支持。诚然，要做到这一点是很难的。我自己也遇到过这种难题，知道问题的棘手程度。我想，这个问题可以分为两个方面。
一种是定制的软件。对于这种项目，你需要解决用户的参与问题，往往客户方的老总愿意投入资金，但是却不愿意投入支持的人力。我也曾见过客户方专门招了一个应届生来对付需求的情况。遇到这种情况，如果你没有能力克服它，那么这个项目绝对是失败的。即便项目最后成功了，申请了什么"重大攻关"之类的奖项，你我都很清楚，这只不过是表面功夫而已。造成这种问题的原因有很多，你需要分析它们，列举出最深层的原因，并且保证列出的这些原因之间并不会相互影响。然后再试着来解决它。一般而言，如果客户方是真正愿意实现这个软件的话，事情并不是不可解决的。
另一种是产品化的软件。我们可以把这种软件的客户分为三类：市场人员、领域专家、最终用户。市场人员往往对软件有最初的认识，但是这种认识往往不够深入。所以，在开发产品化的软件时，一定要配备专门的市场人员，他们对客户的需求最了解，是需求的第一手来源。既然你的老板想要开发这个软件，说明对软件的未来市场有期待，市场人员加入的要求应该是可以得到满足的。其次是领域专家，现在很多的软件公司都配备有领域专家，他们的作用可不小，和市场人员相比，他们也同样熟悉需求，因为他们自己就是资深的用户，并且他们还熟悉理论，能够为软件开发出大力气。最后是最终用户，前面的两类人的参与还不够，如果最终用户不认可软件，那还是没有用。所以，要求市场人员找寻可能的目标客户，试用软件，提出意见，是非常重要的。我们常说的Beta测试也就是这样做的。
9、结语
最早这片文章的想法是来自于一个信贷系统（以文章的观点来看，这个系统是一个失败的案例）。除此之外，还加上了一些以前的项目的经验，以及朋友的一些经验。最后综合成了这一篇文章。
这个系列的文章的写作时间的跨度很长。在这个期间，我的思想也经历一个很大的转变，所以在写作中也出现过对已经完稿的部分大肆删修的情况。这篇文章虽名为『需求的实践』，但所提到的各种想法、方法，都有理论的依据。当然也是参考了很多的资料。而我个人的能力又极为有限，所以有些时候是心有余而力不足。在这样的情形下，文章难免会出现很多的错误。还希望能得到读者们的谅解和指正。
在写作的过程中，也有很多的热心人写来信件，其中好些还成为了好朋友。曾经想把里面的问题整理出来，但是由于疏忽，其中的一部分已经找不到了。希望还能有机会做这件事情。
参考资料：
Karl Wieger:《Software Requirements》
Scott W. Ambler: AgileModeling: http://www.agilemodeling.com
Scott W. Ambler: The Object Primer 2nd Edition
Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process
GOF:《Design Patterns: Elements of Reusable Object Oriented Software》
Eric Gamma, Kent Beck: Junit: http://www.junit.org
Kent Beck，Martin Fowler:《Planning Extreme Programming》
文章来源于领测软件测试网 https://www.ltesting.net/
