敏捷测试VS传统测试，6招玩转敏捷测试！
一、什么是敏捷测试？
敏捷测试是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计、开发人员的交流和协作。
在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，对原有功能的回归测试则依赖于自动化测试。
简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，快速迭代，即我们进行短周期的开发，上线，反馈，优化，使得项目易于调整，故而敏捷。
二、敏捷测试在项目中的应用形式
每日站会：也就是每天早晨15到30分钟的会议，会议形式是项目组成员到白板前介绍昨天完成的事项，遇到的问题或好的方法，今天计划完成的工作内容等；
白板上会写上需求池、开发就绪、开发中和已完成的SR、测试就绪、测试中和完成的SR、验收就绪、验收中的SR、验收完成的SR；
通过分析白板上story的进度情况，看项目是否存在进度延迟的情况，若存在，项目经理提出疑问，分析原因，找出改进方法。
极限编程（Extreme Programming，XP）是一种可以使开发人员快速生产高质量代码的软件开发过程。XP中开发人员可以结对编程，提高代码的质量。
测试驱动开发：敏捷测试中每个story都有计划开始和结束的时间，开发人员对自己的story进行分析设计时，测试人员需要对story进行分析设计测试用例，开发人员提交时需要向测试人员show case说明开发的story功能已经实现可以开始测试；
此时测试人员进行测试，如果到story需要提交给测试人员进行测试的时间点开发人员还未完成功能的开发，测试人员要督促开发人员进行提交测试，延迟提交或存在分析的情况下，需要反馈给项目进行重新制定措施。
三、敏捷测试与传统测试的区别
1.项目相当于开发与测试并行，项目整体时间较快。
2.模块提交较快，测试时较有压迫感。
3.工作任务划分清晰，工作效率较高。
4.项目规划要合理，不然测试时会出现复测的现象，加大工作量。
5.发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘。
6.耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7.发现BUG能够很快的解决，对相关的模块的测试影响比较小。
8.版本更换比较勤，影响到测试的速度。
9.要多与开发沟通。
10.要注意版本的更新情况。
11.测试人员几乎要参加整个项目组的所有会议。
四、敏捷测试中的关键过程
在一个sprint中，测试人员的工作内容主要分为五个部分：user story分析、测试用例设计开发、测试执行和分析、测试持续集成、回归测试。这五个部分的工作均要持续到sprint结束，只是启动时刻有早有晚，具体如下图所示
user story分析工作：敏捷测试是不断确认客户的需求得以实现，因此对用户需求的分析、理解需要一直持续，发现有偏差及时纠正、设置合理的验收点和测试项。
Testcase Develop工作：设计测试用例，完成测试代码的开发、测试数据的准备，并及时与开发人员沟通软件接口，确保测试代码能够成功驱动业务代码。
Testing & Analysing工作：执行测试，统计测试覆盖率，分析测试结果，若发现bug，及时沟通，并协助定位bug。
Continuous Integration工作：将测试代码进行集成，以保证当前功能若被后续集成代码污染是能够及时得到报警，不断地完善软件产品的功能基线。
RegressionTesting工作：在完成全部user story后，对所有代码进行完整的回归测试，对所有bug修复情况进行确认。
五、敏捷测试人员怎么提高开发生产率？
在敏捷测试中，测试人员则是帮助加快进度的人，也就是提高生产率的人。
1.若缺陷发现越及时越容易修改
比如在1天内就能发现，则1天内发生的改动很少，很容易找到问题。这就需要一个自动测试工具来以接近实时地发现缺陷。
如果每天进行一次持续集成，则集成测试不能通过的原因会很单一容易定位。设想一个数字电视系统，从授权/编码/加密/复用/调制//显示……环节很多信息很不透明，若在最后一刻才做集成，基本上无法判断问题出在哪里。
2.若发现缺陷的人就是制造缺陷的人，则越容易修改。
如果开发人员有自动测试工具能快速看自己写的程序有没有问题，而不是交给测试人员发现则更容易修改。想象一下编译器就知道了，如果编译活动都要委派给别人（最然现在很难想象，在软件开发的极早期其实就是这样的），效率会很低。
3.一个开发人员花费在查找和修改bug的时间越少，则开发效率越高。
另外一个推论是：在0缺陷的产品上增加一个功能，比缺陷缠身的产品上要容易得多。
因此1和2两条的推论就是开发效率提高。
六、敏捷测试的人做什么？
- 不断推进自动化测试的效率和效果。
- 不断推进持续集成的效率和效果。
- 不断提高开发人员开发功能而非处理缺陷的时间（即使缺陷是开发人员自己制造自己修改）。
当然有一个前提，就是每个软件对待需求/进度/质量/成本的目标和策略是不同的，敏捷测试人员不能有本位主义，不能片面追求测试活动本身的效果，而是应该帮助开发团队达成其目标和策略。
