什么是敏捷测试？敏捷测试有哪些流程改进？

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

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

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

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

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

　敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重。可以对一些文档进行精简，比如说测试计划，传统的测试计划很大程度上是对格式的强调，在敏捷测试里可以对测试计划做到精简，强调测试中采用的策略，测试的需求范围和测试的阶段时间安排。测试需求点可以用excel等文本格式简单的列出，测试人员可以根据测试需求点写测试用例，测试用例可以做到精简，没有必要把每一个步骤和期望的结果详细的描述出来，很大程度上是提出一个测试的思路，这样可以节省更多的测试用例设计时间，可以把更多的时间用于设计测试用例的思路和写一些必要的测试用例脚本以及和设计和开发人员的交流和沟通。在《敏捷测试的方法和实践》中提出测试阶段性的重要性：敏捷测试强调的是“迭代”。所以我认为项目的测试应该分成几个阶段进行。

  第一个阶段：验收阶段。可以采用冒烟测试的方法，对新的版本进行主要流程的测试，这个阶段强调的是可以走通主要流程，就是场景法里面的基本流。如果主要流程还存在致命的错误，完全有必要把这个版本退还给开发，要求开发经理加强开发代码的质量。

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

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

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

　备注：不同的产品会有不同的测试策略，这里的阶段性测试可能更多的针对一些要考虑到流程性的产品。

　实践：某产品安装卸载测试

　自动化测试

　这里谈谈自己对自动化测试在敏捷测试中的一些作用。这里不免会谈到适合做自动化的项目，必须是功能稳定成型的产品。如果是在一个成型的产品中做敏捷测试，自动化的引入可以是使敏捷程度更高，比如前面提到的第一个阶段，完全可以由自动化测试完成。但是如果是一个全新的项目，项目的前期自动化测试是不现实的，可以在项目后期相对稳定的阶段，做功能的自动化测试。自动化测试前期需要有很大的工作量，必须投入一定的时间和人力资源。

　实践：某项目的安装卸载测试

　BVT （版本的验证测试），每天都有一个新版本的发布，自动化测试可以提前验证版本的可测试性。可以节省测试人员的时间。如果这个版本有问题，可以直接放弃。用另外的版本测试，起到了领航性的作用。

　测试人员在敏捷方法中的价值

　测试人员一定要参见需求和功能设计的讨论会，而且要积极主动的站在客户的角度提出一些问题，这里强调的是，测试人员在研讨会前需要先熟悉需求，至少对大致的功能有个了解。这里可能与测试人员对需求的理解程度和测试人员的经验息息相关。

　单元测试的重要性：一般单元测试都是由开发人员做的，单元测试做与没做，对测试的整个进度起到了至关重要的作用。一个做好单元测试的模块，对测试人员来说可以节省更多的时间，不会把时间浪费在一些比较低级的错误上，而又更多的时间去思考更加深层次的测试用例，对产品质量的改进和提高有深远的影响。

　读后感总结：

　敏捷开发的精华在于要对客户的需要做出快速的反应，敏捷测试也是需要站在客户的角度思考问题，确保产品满足客户的需求。沟通及时也是敏捷测试的一个关键因素，合适的沟通，不但可以节省开发确认bug 的时间，也可以帮助测试人员有更多的测试思路。