敏捷测试理论以及实践 - 1

【本篇是《敏捷测试理论以及实践》第一篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】

 

前言：

关于敏捷测试这块内容，本来之前一直想写的，但是自己一直觉得还没法归纳得很好，不过最近有个客户到我们公司来拜访时，也提到了他们公司要把测试这块工作弄好的事情，谈了几个小时，相互交流了一下意见，总算双方都有点收获，所以接下来几天想结合我们公司的实际情况介绍一下敏捷测试的一些相关知识，当然咱的想法也并非很权威啦，仅供参考。

 

正文：

谈到敏捷测试，可能有些人不一定听到过，不过很多人应该听到过敏捷开发吧，其实从广义来讲，测试也是属于开发过程的一部分，测试完成以后开发过程才算真正完成，所以敏捷测试其实也可以算是敏捷开发的一部分，之所以大家不怎么关注，一方面国内对测试行业的关注度远远低于开发行业，第二个方面其实也跟第一个相关，就是敏捷开发先流行起来，再加上国内的开发、测试比例，所以敏捷测试这个概念就显得不怎么流行了。不过，情况也在慢慢变化，从我了解到的情况看，越来越多公司已经在关注这一块了。

 

大家在百度上搜索一把，可以看到敏捷测试的标准定义：

 

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

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

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

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

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

 

稍微研究一把，大家就会知道，虽然加个敏捷两字，其实测试还是原来的测试，以前大家在软件工程里提到各种测试方法（等价类划分法、边界值分析法等等）、测试分类（白盒、黑盒等等）还是继续适用的，所以放心，如果你是测试工程师，不懂敏捷测试理论也不会让你丢了测试工作的，你只要能发现Bug，发现好Bug，发现很多Bug就Ok了。当然对于测试主管甚至再高层就不这么想了，呵呵，为啥原因呢，下面会慢慢为您解答。

 

那既然测试还是原来的测试，那还要敏捷测试干嘛呢，其实跟敏捷开发一样，敏捷测试你也需要从它的发展来理解它。很久很久以前（当然，也不是太久，也就是上个世纪的事情），即使在国外也还沉醉在瀑布开发中，所以在那个时候，测试呢，就一直躲在开发过程的最后，产品开发完成了以后，就开始大规模测试，测试完成，软件就发布了，就像练功夫一样，一气呵成，打完收工。

 

 

当然，后来发生的事情，我们现在也早已知晓，（唉，历史啊历史，人就像历史长河中的一滴水，如果不能扬名，那唯一结果就是被蒸发被遗忘，悲哉！（感慨一下先！））：

 

一开始的软件一个软盘就能搞定，没有多少代码量，所以出问题的几率就不高，测试放在最后一点问题都没有，但是随着软件越来越庞大，大家就慢慢发现问题了，如果一开始设计有问题，或者有重要功能做错了而直接影响到其他相关功能也出错，这类事情只能在最后的测试阶段才能被发现，虽然说测试就是为了发现Bug，但是这类问题发现得太晚带来最直接的结果就是代码需要大改，时间需要延期，成本需要增加，下面这个图就可以看出来，一个Bug发现的越早修复的成本越小，为什么呢，因为你想好了，一个Bug其实也就是一些代码，刚写的时候，它可能比较独立，或者只跟少数几个其他功能有关，也相对好找，但是一旦到了中后期，这部分代码可能被其他很多功能调用，你修了这个地方，那个地方调用时可能就会出问题，所以你就得把相关地方都去看一遍，如果漏了一个地方，不好意思，可能是个大Bug，所以你需要花费大量时间，体力，财力去修复，如果你在刚做完的时候就发现了，轻车熟路马上就可以改完，五分钟的事情。

 

 

 

我们公司以前（大约2006年之前）也是采用瀑布模型来开发产品的，所以测试当然也是瀑布测试了，对于测试人员来说，最直接的现象就是，平常很空，开发完成的时候就忙得要死，一轮接着一轮的测试周期，所以经常连着几周都在测试，经常加班；而开发呢，开发时很忙，测试时更忙，因为一方面有大量Bug过来，另一方面很多Bug都是很早之前产生的，要修复起来特别麻烦，还得去查原来的代码，焦头烂额的，更郁闷的是，经常发现有些功能没做对，不是客户所要的。所以也许开发过程就一个月，但是测试过程却花了两个月，最后到头来，客户说，这个产品不是我们想要的。

 

痛定思痛，做些改变吧，奥巴马都说了，We need CHANGE，所以大家就想啊想，想出一个V模型来，什么是V模型呢，且听下回分解。

 

 

(未完待续)