敏捷这个话题似乎热了好多年，随之也就自然地有了
敏捷测试这个术语。
说到敏捷，大家一定听过不少相关的演讲，看到不少相关的书籍，不过不管有什么新的技术，新的流程，归根结底都是遵循着敏捷宣言并以敏捷原则作为根本。就像Scrum开拓了一套敏捷
项目管理的框架，XP指导着敏捷开发中的工程实践一样，敏捷测试也就是一组指引测试
工作在敏捷团队中的一些最佳实践。
首先，敏捷测试非常强调和多方的合作。在瀑布开发模式下，测试人员一般是根据需求文档和设计文档来设计
测试用例，然后等功能开发完成，软件交付到测试人员手上才开始正式的测试工作，这样对于测试的所有输入就都是文档。而敏捷测试让测试人员在
软件开发的最初就加入团队，为的就是使测试人员更加地靠近产品本身，对于产品经理的需求和开发人员的设计有深入的理解，甚至能和后续的部署和运维团队尽早地接触，了解到产品的全方位。
再次，尽早地使产品可以测试起来，越早越好。测试工作不再是软件开发中的某一个环节，而是时时刻刻贯穿于软件开发中。实现这一点的基础就是软件的可测性，而可测性又包括至少两点
有较为明确的需求指标（这里使用了“较为”两个字是因为有些非功能上的指标前期可能的确不太明了，但是随着产品开发的进行，最终还是会慢慢清晰的），这样才能对测试结果进行判定
有适合测试的接口，这样才能方便的设计和执行测试用例，并能最大规模地发挥测试自动化的优势
之后，使团队一起加入测试。千万不要孤军奋斗，
软件测试是一件极其需要团队力量的过程，让策划/开发/运维甚至是产品经理一起加入。
编写用户验收测试用例的时候要邀请策划和产品经理，避免对于需求的理解错误
请运维一起加入产品的部署测试，他们有着更多的生产环境的实际操作经验
当然每个角色对于加入的方式可能会不太相同，但是重要的一点就是把所有的测试环节都对团队成员透明，让他们知道产品会进行哪些测试，已经进行了哪些测试，当前的测试结果怎么样。
在测试可以跑起来之后，尽量频繁地测试。说到这个，测试自动化很自然地被提上了日程。注意，这里用的是“测试自动化”，而不是“
自动化测试”。个人认为测试自动化不仅仅是把测试用例通过编写代码脚本化并通过机器运行起来，而是包含了一套对于测试过程的自动化，包括测试环境的自动部署，测试数据的自动生成，测试脚本的自动执行和测试结果的自动报告等等。好了，回到“频繁地测试”这个话题，我们需要多频繁呢？越频繁越好！
每一次的代码（产品代码或是测试代码）提交或是每一次的配置更新都有潜在破坏软件的可能性，都是需要测试的
产品在不同部署环境中的表现往往是不可预料的，尽可能多的对可能的部署环境进行验证
即使部署环境和产品都没有变化，也需要重复测试。这个可能会有些疑问，既然什么都没变，已经跑过通过的测试还有必要重复执行吗？答案是“有必要”
· 产品在刚启动时和运行了一段时间之后的表现是完全不同的，看似重复执行的测试其实已经是运行在不同状态下的
· 测试的执行往往是按照一定顺序的，依据“杀虫剂”原理，系统是会有一定“抵抗力”的，这时可以不采取简单的重复测试，而是打乱测试顺序（虽然测试用例的设计在原则上是独立的，但是在实际中对于软件产品的内部状态变化是不可预知的）
上面这些只是敏捷测试个人的一些理解，其中并没有涉及到具体技术层面的东西，更多的是一种思想层面对于软件测试的转变
· 软件测试是软件开发的一部分
· 软件测试是团队成员的职责
· 软件测试需要尽早，自动，频繁的执行
也正是因为有了这些需求，TDD/ATDD/CI才会被团队所接受，慢慢变成了一种标配