敏捷开发中的测试??SpecDD模型
对于敏捷开发中的测试，其实之前我也是认为很有必要的。
对于一个敏捷开发过程（或者按照周博士的话叫做混合型的敏捷开发过程）而言，我觉得测试这个过程不是一个单一的过程，因为它不是只在某一个阶段开展的，而是在整个过程中无时无刻不见它。
1、需求阶段：
当一个需求被设计出来的时候，测试必须介入，做什么事情呢？
第一个事情，根据这个设计文档，开始写测试用例
第二个事情，根据这个设计文档，结合用户的实际需求，从概念上看是否真的能够符合客户的需求（这个很重要，一旦能够发现问题，等于给公司减少了非常多的钱，因为如果有设计问题到后被发现，那个时候开发和测试已经投入多少力量去做了，而且所用的代码可能会影响到其他程序的运行，要改回来，代价是很大的。）
2、开发阶段：
虽然开发阶段是开发人员的事情，但是测试人员同样必须介入：
第一个事情，开发人员完成代码后，白盒测试人员需要介入进去。
第二个事情，开发人员进行开发时，需要确保他们的开发能否符合测试用例中的测试点的要求。（我们知道，测试人员与开发人员的思想不是很一致，那天周博士也举了下拉框那个例子能很好的说明问题，所以现在的情况是，测试人员已经提前把很多测试的点列出来，虽然还有不少点可能会在实际测试中发现，但是开发人员在开发阶段如果能把测试用例中这些测试点都覆盖得很好，那么产品质量从初期已经在一个正确的道路上前进了。当然如果开发人员自顾自，觉得怎么做怎么做，到后来发现不符合设计思想，然后去返工，这种后果造成的影响大家都能想象得到。）
3、测试阶段：
这个测试阶段的确是传统上测试人员拿到产品开始测试的阶段，但是它也不是一个单一的阶段，也需要很多不同的阶段组成。
第一个阶段：迭代测试阶段
这个阶段中，需要把当前迭代中完成的功能进行测试，完成一个测试一个。在敏捷中，理论上每天都会有很用的Build让测试人员可以测试，所以一旦一个功能开发完成了以后，必然我们能够马上得到一个Build开展测试，发现重要的Bug可以马上修复。
这个阶段非常重要，因为这是一个造成代价小的阶段，首先开发刚完成功能，修起Bug来轻车熟路，另外一点，这个代码还没有被其他一些功能所调用，所以对其他地方造成的影响还不会很大。
所以测试人员需要在这个阶段投入大量人力去保质保量完成。
第二个阶段：多迭代集成测试阶段
当几个迭代已经过去了，有很多功能已经做好了以后，这个时候考虑到虽然单个功能看起来都还好，但是这么多功能现在都做完了，是不是相互之前会影响啊，或者对于稳定性造成影响之类的的因素，有必要进行多迭代功能集成测试（也包括了回归测试），这种测试比较多的是在类似Alpha Release，Beta Release的时候进行。
第三个阶段：系统性综合测试阶段
当所有迭代都完成以后，当然我们还是需要进行一次全方位的测试（当然也包括负载测试、性能测试等），这个比较类似传统那个测试阶段了，这里不多说了。
我们看得出，测试这块在SpecDD中占了很大一个地位，而且更重要的是，它是一个不固定的过程，在SpecDD中几乎每个过程都是需要测试这个过程存在的，所以它被称之为“流浪汉“也比较贴切，或者叫”济公“也不错，因为“哪里不平哪有我”。
