首先敏捷测试是敏捷的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。

     敏捷测试是遵循敏捷宣言的一种测试实践：

   1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。

   2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

   3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

   敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重。可以对一些文档进行精简，比如说测试计划，传统的测试计划很大程度上是对格式的强调，在敏捷测试里可以对测试计划做到精简，强调测试中采用的策略，测试的需求范围和测试的阶段时间安排。

   测试需求点可以用excel等文本格式简单的列出，测试人员可以根据测试需求点写测试用例，测试用例可以做到精简，没有必要把每一个步骤和期望的结果详细的描述出来，很大程度上是提出一个测试的思路。

   这样可以节省更多的测试用例设计时间，可以把更多的时间用于设计测试用例的思路和写一些必要的测试用例脚本以及和设计和开发人员的交流和沟通。

   在《敏捷测试的方法和实践》中提出测试阶段性的重要性：敏捷测试强调的是“迭代”。所以我认为项目的测试应该分成几个阶段进行，第一个阶段：验收阶段。可以采用冒烟测试的方法，对新的版本进行主要流程的测试，这个阶段强调的是可以走通主要流程，就是场景法里面的基本流。如果主要流程还存在致命的错误，完全有必要把这个版本退还给开发，要求开发经理加强开发代码的质量。

   第二个阶段：新功能的测试和回归测试 保证各个功能点能够被覆盖。这里强调的是敏捷开发测试的方法，不一定需要所有的模块都开发完成，可以针对已提交的模块进行功能性测试。这也包括参与到单元测试和集成测试中。

   第三个阶段：系统测试和回归测试阶段。这个阶段可以运用场景法测试和相互交叉测试。在系统测试的同时也可以回归上个阶段的出现defect。

   第四个阶段：稳定性测试。如果还有多余的时间，可以运用探索性测试和错误经验法测试。在这个阶段产品相对稳定，可以多考虑一些异常流的情况。