敏捷了，自动化测试怎么搞？（2010-8-16）（获奖名单已公布）

默默巫

敏捷了，自动化测试怎么搞？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	hsjzfling	价值50元的礼品	8#
二等奖	maguschen	300论坛积分	28#

JaifyTesting

虽然不是很东，顶了

SariyaLee

学习了。

A_little_love

学习中，

fjstc3441

敏捷测试需要高度自动化,这两个非但不矛盾，反而切合的非常紧

dennyqiang

单元测试和基于界面的功能测试都应该做好自动化，敏捷测试需要用自动化来协助的。

敏捷不单单是技术上的，还应该是管理和流程上，缺一不可。

dishiwujian

经常是1-2周内做一个WEB项目，自动化测试意义不大，可重用性也很低。
只有一些较底层的东西可以启用自动化了，像检索那些。
但是检索的代码基本也是重用的，新旧版看两眼都能发现问题，并不必维护一个脚本花费高……

愚人

二者都不懂，坐下慢慢看……

maguschen

这个问题有点大，我现在所处的公司也是应用了敏捷开发，下面分享一下我们公司做自动化测试的一些经验
首先，敏捷开发并不是部分同学想象中的那样，没有文档没有需求，开发来了就干，干几个月就丢给客户一个版本让他们用去，我们公司一般6个星期是一个release周期，在这6个星期里面，可以做的事情是非常多的

• 需求，需求通常来自于PM，在一个release周期的开始，QA通常没太多事情需要做，比较重要的工作就是跟PM沟通当前feature的一些情况，在这个时候，QA可以做一些自动化测试的准备。例如在某个release里面我知道在接下来的测试当中我需要频繁地比较CSV文件，那么作为QA就应该在项目还不是很紧张的时候就开支准备自动化测试的脚本，例如刚才说的这个CSV文件比较工作
• 开始开发，如果公司是实时TDD开发，那么这个时候QA可以做的事情大概有2个，帮助开发写单元测试用例，并且实施自动化测试（主要是单元测试），另一个是review（虽然不是自动化测试的内容）
• 正式提交测试，OK，这个时候是我们QA比较忙的时候了，这时候很有可能出现几个情况，1. 跟我的预想一样，我真的需要一个CSV文件比较工作，并且只需要这一个工具，并且我已经完成了，那么就可以进行测试了。2. 可能有一些新的自动化测试需求跑出来了，例如每天晚上自动比较几万个CSV文件并且把测试结果发给相关的人，这时候作为QA，在考虑资源允许的情况下，应该尽早完成这个工具，而不是每天晚上爬起来看结果并非法邮件
• 发布完毕以后，回过头来看工具，是否有值得改进的地方，是否能够改进一下就能够给整个Team使用

以上算是一个release周期里面的一些微观的工作，宏观上来说需要做点什么事情呢？


现在提到的敏捷开发，都有一个很突出的特点，就是产品快速交付给客户，为了快速交付这个目的，公司里面每个团队都作出了努力，那么具体到QA团队，肯定就是要在保持测试质量得到保证的前提下，尽可能地缩减测试所需要的时间，使得产品按时按质交付。要达到这个目的，总靠一些AD-HOC的工作（例如刚才提到的突然写个CSV比较工具）是不可能达到要求的，那应该如何进行呢？

敏捷开发也是开发，产品不是孙悟空，不会某一天就从石头里面爆出来了。在产品开发的前期（例如0.1, 0.2版本之类），尽可能地想办法搭建一个自动化回归测试的框架，这个框架的特点有：1. 快速完成回归测试； 2.能够快速地添加测试用例并且跑起来；3.能够随着产品的演化而不断改进（不能是那种用1~2个release就要扔的东西）；4.维护的成本要低（在一个release周期里面如果自动化测试需求有变化，不应该需要超过1个星期的时间才能改好，当然翻天覆地的变化除外）

综上所述， 我认为在敏捷开发里面的自动化测试是有2条路线，并且这2条路是并行的，缺一不可

• 至少一个自动化回归测试框架，保证release前能够对产品进行覆盖较为全面的回归测试
• 工作中*不断地*开发自动化测试工具，提高自己的生产率

以上两点的目的很简单，就是要在保持产品质量处于一个较高水平的情况下，帮助公司尽可能地快速交付新版本的产品




个人愚见，欢迎讨论

liulinzhu

原帖由 kakamissyou 于 2010-8-16 22:40 发表
没有自动化支持，敏捷怎么能搞好？

自动化一定程度上能推动敏捷，但两者是两码事，不要混淆了。

mitutu

敏捷测试中如果有迭代，采用自动化的方式可以节省一部分重复手工测试时间
可以事先约定好，控件元素标准化，然后基本保持不变，可以减少后期调试脚本的时间

huguxiang

首先，楼主的问题比较模糊，敏捷是指敏捷式开发吧？不是指敏捷测试吧？没听说过有敏

捷式测试的，所以本人姑且认为是敏捷式开发了。据我了解的话，现今大部分公司不是做产

品的都是敏捷式开发，因为敏捷式开发可以节省时间成本。在敏捷式开发的前提下，自动化

测试就显得更为繁琐，而且成本会高出很多。依我个人有以下几点分析：
   （1）前期不适宜进行自动化测试
  从实际出发，敏捷式开发业务变动比较大，往往前提调研内容跟试运行之后程序都

会有所变动，如果前期就进行自动化测试，那么估计修改脚本的时间比修改源代码的时间还

多，因为前面的版本实在不太稳定。所以前期不适宜进行自动化测试。
   （2）自动化测试时机
  什么时候可以进行自动化测试呢？本人认为当版本比较稳定的时候，或者业务相对

稳定的时候，才进行自动化测试，而且自动化测试一定要简化，不能全面覆盖，主要业务功

能写脚本进行自动化测试就可以了，而非全面覆盖，不然测试要么无法顺利进行，要么时间

太长成本太高，导致公司效益降低。
   （3）不进行自动化测试
  敏捷式开发有他的优点也有他的弊端，往往敏捷式开发都是针对一些小项目，项目

金额不是很多的，如果大部分时间花在自动化测试上面，那么将是得不偿失的。如果客户对

软件的要求不是很高，个人觉得没必要进行自动化测试，qtp,loadrunner这些软件好是好，

但是毕竟是软件，没有人脑这么灵活。可以有针对性的进行功能测试，性能测试。

hoppaoy594

敏捷了。。。。
学习！

velata

原帖由 danmy 于 2010-8-23 14:18 发表
问题的提出应该是针对系统测试阶段的自动化测试而言，因为敏捷要求的频繁迭代，已经要求有自动化程度非常高的单元测试代码，TDD也是基于此。从另一层面上说，敏捷测试更多强调的是单元测试的成效，所以传统的自动化测 ...

嗯 我倒是对“自动化测试”的理解狭隘了！如果TDD做好、做强大了，也能满足要求。
不管啥活动，都是为了提高项目质量滴。。。

yolanguo

做自动化首先要考虑ROI，这个项目是不是适合自动化，适合怎样的自动化，前台的，性能的，还是sever端的？
然后根据不同的需求选择不同的自动化工具或者自动化框架。
至于敏捷开发，要视具体情况而定吧
比如用QTP，对于一些稳定的功能模块，再每次迭代时，做自动化，能够减轻测试的许多工作。

daring1226

自动化跟不跟敏捷没有直接的关系，只是敏捷的响应变化的速度快，敏捷中的模式更加体现了更早的、更快、更加频繁的测试，开发和测试之间的配合更加紧密等而已；
敏捷只是进行更加快的响应和步伐，敏捷中的测试自动化显得尤为重要了，

自动化，还是一样根据产品实际的情况去架构自动化，采用什么样工具辅助，怎么样做到自动比对和验收设计；

kukulsz

支持#8楼

candy_girl

围观，learning

danmy

问题的提出应该是针对系统测试阶段的自动化测试而言，因为敏捷要求的频繁迭代，已经要求有自动化程度非常高的单元测试代码，TDD也是基于此。从另一层面上说，敏捷测试更多强调的是单元测试的成效，所以传统的自动化测试的方式方法在敏捷团队中受到的挑战非常大。完全的自动化测试因为系统的迭代频繁基本是不可能的。所以此处自动化测试还是更重在提高测试效率，通过一系列辅助测试工具或针对功能模块的黑盒测试代码来简化操作、释放人力。

velata

原帖由 michaelwxm 于 2010-8-17 10:42 发表
TDD吧

TDD跟自动化测试是两码事吧？
TDD只是测试驱动开发，先编写测试脚本，通过不断的编写代码使得测试通过，主要还是在单元测试层面的。
而自动化测试会偏向验证功能，其中还有很大一部分是测试场景设计、测试数据设计。