敏捷测试VS传统测试对比，6招玩转敏捷测试！

测试积点老人

随着这几年敏捷概念和方法的流行，越来越多的组织和项目选择了敏捷开发模式。那么对于测试人员来说，究竟敏捷测试与传统测试有什么区别？测试人员在一个敏捷项目中需要如何转变才能适应当前这种流行的测试模式呢？今天我们就来探讨一下！

一、什么是敏捷测试？
首先，究竟什么是敏捷测试？在我个人看来，敏捷测试是一种注重“以人为本”，快速迭代的开发方式。因为人是一个项目中的关键所在，故以人为本；快速迭代，即我们进行短周期的开发，上线，反馈，优化，使得项目易于调整，故而敏捷。

二、敏捷测试在项目中的应用形式：
体现在三个方面：每日站会、极限编程、测试驱动开发。


每日站会：也就是每天早晨15分钟到30分钟的会议时间，最多不超过45分钟，会议形式是项目组中的成员占到白板前逐个介绍昨天完成的事项，遇到的问题，或好的方法分享，今天计划完成的工作内容等；


对于存在的问题，项目成员可以提出自己的好的见解帮助同事；白板上会写上需求池、开发就绪、开发中的SR、已完成SR、测试就绪、测试中的SR、测试完成的SR、验收就绪、验收中的SR、验收完成的SR；


每个SR会写上story的内容，开发人员，计划开始时间，计划结束时间，实际开始、结束时间、完成该SR用了多少时间，计划用多长时间等；通过分析白板上story的进度情况，看项目是否存在进度延迟的情况，若存在，项目经理提出疑问，分析原因，找出改进方法。


极限编程（Extreme Programming，XP）是一种可以使开发人员快速生产高质量代码的软件开发过程。XP中开发人员可以结对编程，提高代码的质量。


测试驱动开发，敏捷测试中每个story都有计划开始和结束的时间点，开发人员对自己负责的story进行分析设计的时候，测试人员需要对story进行分析设计测试用例，在开发提交测试人员测试story的时候，开发人员需要向测试人员show case，说明开发的story功能已经实现可以开始测试了；此时测试人员根据测试用例进行测试；如果到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两条的推论就是开发效率提高。


六、敏捷测试的人做什么？
1. 不断推进自动化测试的效率和效果。
2. 不断推进持续集成的效率和效果。
3. 不断提高开发人员开发功能而非处理缺陷的时间（即使缺陷是开发人员自己制造自己修改）。


当然有一个前提，就是每个软件对待需求/进度/质量/成本的目标和策略是不同的，敏捷测试人员不能有本位主义，不能片面追求测试活动本身的效果，而是应该帮助开发团队达成其目标和策略。

七、总结：
测试人员是敏捷团队非常重要的一环，测试人员的成长对敏捷团队非常重要。从传统测试工作转入敏捷测试工作必然会遇到很多不适，但是只要坚持对敏捷的学习和各种新工具的开发使用，一切都能够适应下来。