敏捷只是进行更加快的响应和步伐，敏捷中的测试自动化显得尤为重要了，
自动化，还是一样根据产品实际的情况去架构自动化，采用什么样工具辅助，怎么样做到自动比对和验收设计； 做自动化首先要考虑ROI，这个项目是不是适合自动化，适合怎样的自动化，前台的，性能的，还是sever端的？
然后根据不同的需求选择不同的自动化工具或者自动化框架。
至于敏捷开发，要视具体情况而定吧
比如用QTP，对于一些稳定的功能模块，再每次迭代时，做自动化，能够减轻测试的许多工作。 原帖由 danmy 于 2010-8-23 14:18 发表 http://bbs.51testing.com/images/common/back.gif
问题的提出应该是针对系统测试阶段的自动化测试而言，因为敏捷要求的频繁迭代，已经要求有自动化程度非常高的单元测试代码，TDD也是基于此。从另一层面上说，敏捷测试更多强调的是单元测试的成效，所以传统的自动化测 ...
嗯 我倒是对“自动化测试”的理解狭隘了！如果TDD做好、做强大了，也能满足要求。
不管啥活动，都是为了提高项目质量滴。。。 敏捷了。。。。
学习！
敏捷式开发下如何运用自动化测试
首先，楼主的问题比较模糊，敏捷是指敏捷式开发吧？不是指敏捷测试吧？没听说过有敏捷式测试的，所以本人姑且认为是敏捷式开发了。据我了解的话，现今大部分公司不是做产
品的都是敏捷式开发，因为敏捷式开发可以节省时间成本。在敏捷式开发的前提下，自动化
测试就显得更为繁琐，而且成本会高出很多。依我个人有以下几点分析：
（1）前期不适宜进行自动化测试
从实际出发，敏捷式开发业务变动比较大，往往前提调研内容跟试运行之后程序都
会有所变动，如果前期就进行自动化测试，那么估计修改脚本的时间比修改源代码的时间还
多，因为前面的版本实在不太稳定。所以前期不适宜进行自动化测试。
（2）自动化测试时机
什么时候可以进行自动化测试呢？本人认为当版本比较稳定的时候，或者业务相对
稳定的时候，才进行自动化测试，而且自动化测试一定要简化，不能全面覆盖，主要业务功
能写脚本进行自动化测试就可以了，而非全面覆盖，不然测试要么无法顺利进行，要么时间
太长成本太高，导致公司效益降低。
（3）不进行自动化测试
敏捷式开发有他的优点也有他的弊端，往往敏捷式开发都是针对一些小项目，项目
金额不是很多的，如果大部分时间花在自动化测试上面，那么将是得不偿失的。如果客户对
软件的要求不是很高，个人觉得没必要进行自动化测试，qtp,loadrunner这些软件好是好，
但是毕竟是软件，没有人脑这么灵活。可以有针对性的进行功能测试，性能测试。 敏捷测试中如果有迭代，采用自动化的方式可以节省一部分重复手工测试时间
可以事先约定好，控件元素标准化，然后基本保持不变，可以减少后期调试脚本的时间 原帖由 kakamissyou 于 2010-8-16 22:40 发表 http://bbs.51testing.com/images/common/back.gif
没有自动化支持，敏捷怎么能搞好？
自动化一定程度上能推动敏捷，但两者是两码事，不要混淆了。 这个问题有点大，我现在所处的公司也是应用了敏捷开发，下面分享一下我们公司做自动化测试的一些经验
首先，敏捷开发并不是部分同学想象中的那样，没有文档没有需求，开发来了就干，干几个月就丢给客户一个版本让他们用去，我们公司一般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前能够对产品进行覆盖较为全面的回归测试[*]工作中*不断地*开发自动化测试工具，提高自己的生产率以上两点的目的很简单，就是要在保持产品质量处于一个较高水平的情况下，帮助公司尽可能地快速交付新版本的产品
个人愚见，欢迎讨论:) 二者都不懂，坐下慢慢看…… 经常是1-2周内做一个WEB项目，自动化测试意义不大，可重用性也很低。
只有一些较底层的东西可以启用自动化了，像检索那些。
但是检索的代码基本也是重用的，新旧版看两眼都能发现问题，并不必维护一个脚本花费高…… 单元测试和基于界面的功能测试都应该做好自动化，敏捷测试需要用自动化来协助的。
敏捷不单单是技术上的，还应该是管理和流程上，缺一不可。 敏捷测试需要高度自动化,这两个非但不矛盾，反而切合的非常紧 学习中， :dizzy:学习了。 虽然不是很东，顶了
页:
1
[2]
