敏捷测试在敏捷开发中贯穿始末，设计到多种角色的参与，产品、开发、设计、测试等等，每个角色承担着不同的测试任务，产品与设计可以进行验证需求实现的测试，开发可以多进行单元测试，测试人员进行详细系统的测试。所有的这些人紧密联系，最终共同承担软件的质量，是一个密不可分的大的团队。

　　这里主要谈谈测试人员是如何实施敏捷测试的，在敏捷中，测试要从头到尾都参与，从产品的设计测试人员就已经开始进入了。参考客户需求看看设计文档是否已经实现客户的要求，对有疑问的地方与产品人员进行沟通。搞清楚整个产品的逻辑和设计的理念。并在脑中已经存在这个功能来如何设计测试用例。

　　在产品与开发与测试都已清楚要实现的功能后，开发进行功能的开发，测试人员进行测试用例的编写，测试人员最好在开发人员差不多完成开发时进行测试用例的评审会议，在会议上，产品、开发、设计、测试根据已编写好的测试用例一起讨论该功能的测试覆盖点，是哪些测试用例已经覆盖到了，有哪些测试用例没有覆盖到，之前测试用例的完成是基于一个测试人员从想象中的功能来编写的，实际开发出来的功能是怎么样的，测试人员是不知道的，但是测试用例评审如果开在功能开发已经接近于结束或已经结束时，那么基本的测试点就出来了，而开测试用例评审的目的就是尽可能全的把测试点覆盖，毕竟一个人的思维总是有局限性的，大家一起讨论测试点的覆盖将会给测试带来更多思路。在开会讨论之前，测试人员要做好准备，对哪个功能的哪个测试点有疑问，在会上可以提出来大家讨论，确定最贴近用户需求的一种方案，并做好记录，以便日后更新之前写好的测试用例。

　　通过这个会议，可以有效地提高测试覆盖面，从而提高产品质量。

　　当功能开发完毕后，测试人员就可以进行系统测试了，按照设计完成的测试用例进行测试，但是在测试的过程中，仍会发现测试用例并没有设计到的测试步骤会导致Bug，所以测试中需要测试人员具备敏捷的判断力，根据实际的软件判断什么样组合的操作会易产生Bug。并记录好这些操作，以便日后更新测试用例，这种在测试中根据软件各种反馈出来的信息探索着更加深刻的了解软件从而组合出更加有意义的操作步骤找出更多有意义的Bug。这中测试方式是探索式测试。

　　敏捷测试应该能够接纳变更，在敏捷测试中总会有功能的变更，所以一旦一个已经测过的功能发生变更就需要我们重新测过，并且要具备快速接纳变更的能力，脑子里要迅速的联想该变更功能所能覆盖的测试点。及与该变更功能有关联的其他功能均要重新测过，这需要测试人员具备迅速反应能力。

　　敏捷的测试给测试人员带来更大的压力，我们需要更快的反应速度，更高的责任感，更强的掌控能力，一旦某一环失控，之后可能会导致失控的局面，软件不能即时发布。