2、编码阶段：

　　完成了需求设计阶段，就要开始进入编码阶段了，虽然说开发与测试需要同步的，但是功能还没做完也没法同步去测吧，不过还是有事做的，就是可以同步开始写测试用例，这个就用到DevTest工具了。DevTest主要用于管理测试用例，以及根据测试用例来进行在不同环境下、不同时间下和不同的范围里进行的手动测试与自动测试，并且可以生成报表供评估测试质量和产品质量。

　　也许有人有疑问，敏捷测试还需要测试用例？我的答案还是“是”又“不是”。

　　先说“不是”，对于敏捷测试本身而言，我们实际新功能测试中其实没有用到测试用例，完全是根据设计文档来进行测试的（也许又有人来问敏捷好像不需要测试文档，这个在这里不多说，详见我另外一篇文章《结合工具来实现敏捷开发》），所以这个时候是不需要测试用例的；

　　而为什么又说“是”呢？因为敏捷在不同的公司不同的情况可以有不同的实现方式，我们公司不是做项目的而是做产品的，也就是说像微软的Windows一样，我们公司的产品也是1.0，2.0这样做下去，现在已经9.0了，在这期间，或多或少有很多功能是在不同版本里都有的，特别是那些基本功能，为了测试新功能是否破坏原有功能，我们需要测试这些老功能是否能正常工作，也许有人说，那我只要在测试新功能时测一下老功能就行了，测试用例也不需要吧？是的，也许你们公司不需要，但是对于我们公司而言，特别对于9.0而言，之前所有版本的功能都是老功能，之前的老功能有几百个，几千个，你能在测试新功能时测一下吗？很显然，这个是很难做到的，新功能做完时，一般情况，测试人员会检查是否能正常工作，是否对一些基本功能没影响，至于对其他看起来不怎么搭嘎的功能其实不太会去关注，而且时间上也不允许。这样子的话，测试用例就显得很重要了，因为测试用例从本质上来说就是介绍需要测试的功能点以及怎么去测试它们，把每个版本的每个的功能点都通过测试用例的方式保存下来，测试时想漏掉一个测试点都难。所以测试新功能时没测到的地方，都可以在用测试用例生成测试任务时重新覆盖全面，不过这一步由于测试覆盖面太广，也就意味着所花时间会很多，所以一般情况下，一部分测试点会用自动化测试工具跑掉，另一部分只能人工来跑的也只在最后系统测试的时候做掉。

　　看了这个“是”与“不是”，大家应该知道我们公司的“敏捷测试”其实是结合了敏捷测试与传统测试，也即是兼顾速度与质量，所以有时候我们称之为有我们公司特色的敏捷测试，呵呵。

　　在写测试用例的时候，测试人员需要和设计人员进行大量的沟通，以彻底理解这个功能为接下来的实际测试做好准备，“沟通”在敏捷里是一个重要的原则，在实际工作，我们也真正体验到它的好处，只有通过沟通，几个部门之间对于产品才有一个认识高度上统一，才能设计出、开发出、测试出一个好的产品来。不过这点，我觉得大家也只能真正通过实践才能体验，我说得太多，其实也没法让大家信服的。

　　3、敏捷测试阶段：

　　好了，写完测试用例了，开发也做完几个功能了，咱们也可以开始测试了，《结合工具来实现敏捷开发》里也讲过，我们公司是采用Scrum方式的，所以会生成很多迭代周期（Sprint），每个迭代周期中会从Backlog里分配一些Story来做，咱们测的也就是做好的Story，其实也就是功能点了。

　　这部分工作主要在DevTrack中完成