敏捷开发另一目标是，快速为客户提供期望的价值，所以，在短时间内，一个完整的简单的软件系统必须形成，然后不同的部件在独立开发测试后，马上能够和现有的产品（也是一个完整的简单的软件系统）集成。这需要开发者，QA合作进行测试。开发者至少要做到用单元测试来保证部件质量。QA必须在集成的基础上开发结合性测试，头到尾测试，以整个系统为整体的方式进行测试。

　　具体的测试方法应该有实际情况出发，像独孤九剑那样，随机应变。任何流程只要适应团队的发展，是好的流程。

　　测试的分配与配合

　　理想情况下，单元测试是由开发者自己进行，或是在QA的指导下设计。现实中，开发者的测试能力有限，有时因为懒或不得不进行的赶工，他们不写或进行很少的单元测试，所以，测试帮助开发者进行单元测试，是一种必要。开发者和测试的合作可以是一起设计或是分工。仅仅让开发者搞单元测试，或把所有的单元测试扔给测试做都是比较极端的做法。我认为平衡点是，测试从黑箱的角度进行单元测试，程序从基本的行为正确的目的用白箱的角度进行单元测试。两者的努力可以重叠。

　　在这个话题上，各个公司的运作都是不一样的，有些公司所有的测试都是设计完成后的测试（结果是整个系统根本没有测试性，所有的东西都结在一起了），有些从早开始搞单元测试，有些把单元测试全部推给QA。也有很多是开发者和QA重复了许多同样的工作，等于是过多地重复地进行了许多同样的单元测试。

　　如何平衡开法者和QA的单元测试，这里没有一个简单的回答。这是开发团队和QA团队必须相互磨合后达到的一种高效率的平衡。软件开发本身是人与人的互动。所以没有相互交流相互沟通的开发肯定会把产品推向错误的发展方向。

　　如何设计好的单元测试案例

　　这是一个测试战术的问题，各个公司的在战术运用上都是不一样的。可能大的框架是一样的，但是在执行的过程中，具体细节都是不同的。不管变化是什么，只要坚持了正确的原则，测试的结果一定会很好，首先，了解整个团队期望的目标，然后熟悉使用的工具，后是遵循业界公认的正确准则。我所知道的工具是NUnit和JUnit，CxxTest，和几种不同的构建系统（微软的构建系统，Maven 1/2，FireFox的构建系统我只知道一点点，还有一些杂毛系统）。NUnit/JUnit的特性是任何单元测试都能在任何顺序下运行，单元测试本身是一个独立的程序，它不需要依赖其他单元测试。它有自己的设置函数和任何情况下都能执行的清除函数。知道这些我知道如何设计一个独立的，不依赖其他单元测试的测试案例。CxxTest是有一定的不同，但是也是多少差不多。单元测试的目的是测试一个基本的单元代码，当然对于QA，NUnit/JUnit都可以用于更复杂的测试案例的设计和执行。对于开法者来说，简单直接的是测试一个小单元的代码。更复杂的测试案例超出了单元测试的范围。

　　所有的测试都应该在构建后运行，构建应该越频繁越好。现实中，所有的测试都运行可能会造成构建速度太慢。所以平衡测试数量和分割测试案例运行都要团队根据实际情况解决。而且，不被经常运行的测试案例如何在其他形式中运行，也要根据团队根据实际情况来决定。测试案例太多而导致无法经常运行是一个很大的问题。找到平衡甚至能够超越平衡而达到频繁运行所有测试案例，是衡量测试团队敏捷处事的指标之一。能够频繁地运行大量耗时的测试案例，是一个团队所能达到的一个了不起的成。

　　结束语

　　这又是一篇废话连篇的总结性博文，我实在也写不出什么，很多东西必须用案例的运用来说明。很多情况下开发者的单元测试和QA的测试没有明显的界限，两者交际的区域是一种灰色地带，有时QA水平很低下，开发者必须进行很多QA形式的测试，有时两者的程序设计能力都很强，但是交流不够，两者会设计很多相同重复的测试案例。有时开发者根本不进行单元测试或是简单至极的单元测试，很多没有涉及的方面都由QA进行覆盖。如何确立QA开发者的测试方向，如何建立有效的测试机制，每个公司的测试战略，测试流程的规划。具体事宜，还是需要实际情况和长期的协调来决定的。

　　我个人想要做到的是，公司个人可以向我咨询具体解决方法，我以自己经验对这些具体情况提供一些指导。请留言处留言。