51Testing软件测试论坛

标题: 敏捷了，自动化测试怎么搞？（2010-8-16）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2010-8-16 14:14
标题: 敏捷了，自动化测试怎么搞？（2010-8-16）（获奖名单已公布）
敏捷了，自动化测试怎么搞？

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

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

作者: aishifu1 时间: 2010-8-16 16:26
占位。

作者: kakamissyou 时间: 2010-8-16 22:40
标题: 没有自动化支持，敏捷怎么能搞好？
没有自动化支持，敏捷怎么能搞好？

作者: xiaoyaoke 时间: 2010-8-17 08:46
标题: 回复 3# 的帖子
顶，一语道破玄机

作者: crazymartin 时间: 2010-8-17 10:25
3楼威武

作者: havards 时间: 2010-8-17 10:34
感觉最近的每周一问质量不行了

作者: michaelwxm 时间: 2010-8-17 10:42
TDD吧

作者: hsjzfling 时间: 2010-8-17 14:07
敏捷测试过程中的自动化目前在国内来看基本上还只是停留在概念阶段，据我所知，目前不少公司也都在尝试过程中，而实际的实践中能取得比较理想成果的，极为有限。而国外不少同仁也都对此持观望甚至抵触的态度。比如advanced QTP论坛的administrator Meir大大就认为敏捷过程中的自动化是完全不现实的，理由就是sprint间隔时间内没办法完成一个完整自动化过程的设计，而频繁的变更会导致自动化资源的大量浪费，ROI上无任何前景可言。

从我个人观点来看，没必要保持如此的悲观，但更不能过于乐观。敏捷过程是IT发展的产物，自动化从概念上来看是确认一个sprint成功的重要一关。敏捷过程需要有自动化测试，但却不能盲目让自动化介入，否则很可能适得其反。

个人略作了下小结，由于敏捷模式的种种特色，敏捷过程中的自动化实现所需要满足的条件比常规的自动化测试活动苟刻的多，除了普通自动化过程必须具备的条件之外，主要还有以下几点：

1、对于自动化工程师的要求更高，除了解决种种突发异常的自动化技能以外，还需要对项目的业务知识有比较多的了解。
在敏捷模式中，文档不会像传统的模式中那样完备，测试的case可能会相对简易，不少内容都只是口口相传，敏捷团队的成员也不可能专门派一个人出来辅助自动化工程师解决业务问题，那么就要求自动化工程师对于业务知识比较了解了，就算对项目了解有限，但至少要有背景知识，大多数情况下能理解一句话中所包含甚至是隐含的一系列业务操作。

2、项目成员结构上，自动化工程师需要成为敏捷团队的一员，而不是编外人士。理由很简单，敏捷团队经常会召开类似头脑风暴的会议，一个短暂而激烈的会议足以决定一个变更，然后大家立马投入工作中。这时自动化工程师若作为编外人士，那很可能就得不到这第一手的消息了，很可能吭哧吭哧好不容易码完的脚本还没跑过就得改了。

3、对于项目、产品的要求。被测系统必须是非常适合自动化的，在自动化脚本开发过程中不应当遇到被某个技术实现难倒的问题，敏捷模式下是没可能有几天甚至一周的时间去处理某个自动化的技术细节的。这就需要在接受项目前做自动化可行性评估的时候考虑周全，是否有某些核心的功能无法被自动化，可以接受多少功能不被自动化。
另外各story间不能有太强的依赖，因为很可能自动化工程师无法完成对所有功能的自动化，而一个story的需求变更也不应导致其它story有太多变化。

4、对于BA的要求。BA需要对产品的主要功能非常了解，非常清楚哪些功能是不太会变更，而哪些部分是不太有把握的，同时对客户也要有一定的掌控能力。这样除了提供主要的测试点以外，还能结合变更来给同为最高级别的测试点附加上自动化优先级，在很大的程度上避免自动化工程师的重复劳动。

总的来说，要实施自动化，对团队的成员素质要求非常高，也要求成员间的配合比较默契。说实话，真的很难，但并不是不可实现。

作者: msnshow 时间: 2010-8-17 20:37
敏捷也只是相对的吧，整个项目可能一部分还是可以考虑自动化的，自动化无非的减少重复劳动成本，提高效率，所以可以拿项目中比较固定，且重复高的来做自动化

作者: zsselina 时间: 2010-8-18 14:50
标题: 回复 1# 的帖子
敏捷测试需要高度自动化，因为频繁迭代
具体的自动化包括以下几方面：
1、静态的自动化，具体做法就是单元测试结合每日构建，这其中包括了代码检查，以及一些可以用工具检查的白盒级别的测试，工具包括checkstyle, pmd等等
每日构建工具可以使用hudson
2、测试中的自动化，根据软件类型的不同，可以在迭代前期逐步将高度重复的测试工作自动化实现。可以考虑用自动化工具：rob, rft, qtp等，或者代码实现,java等，代码实现的基础是单元测试代码
LX补充，谢谢

作者: wuxiongyu 时间: 2010-8-18 16:23
标题: 学习了，
学习了

作者: ChinaTNT 时间: 2010-8-19 11:03
看了，学习了，思考中。。。。

作者: wushuigen2008 时间: 2010-8-21 17:25
敏捷开发确实需要很实用

作者: TIB 时间: 2010-8-22 10:56
敏捷开发离不开自动化测试，GUI层的自动化测试开发和维护成本较高，单元测试和集成测试的自动化是首先应该考虑的

作者: jenny_land 时间: 2010-8-22 11:11
你是要做什么自动化呀,qtp是做回归测试的，loadrunner是做性能测试的；
qtp记录的是客户端的操作，loadrunner记录的是客户端与服务器之间的操作；
qtp的工作流程是：录制脚步-设置组合条件的参数化（datatable/随机）-设置检查点-迭代-新版本回放
loadrunner的工作流程是：录制脚步（一个虚拟用户）-参数化-检查点-集合点-关联-设置事物-建立多个虚拟用户-运行
只是个人理解而已

作者: velata 时间: 2010-8-22 22:31
这个问题还是得看自动化的目的是什么，不同的目的有不同的做法。
目的1：回归之前的功能，确保之前的功能没有因为本次迭代新开发的代码而损坏。
目的2：测试本次迭代中的新功能。

先说第一种，由于在团队中还有其他的功能测试人员存在，所以当前迭代的功能不需要立即开始自动化编码，可以等到下个迭代，功能、界面稳定后再开始对当前迭代的功能进行实现。在这种情况下自动化测试的压力相对就不会很大了。

对于第二种目的，可能会比较麻烦。根据实践个人觉得有以下两种方式：
1)在开发人员进行新功能开发（或老功能维护）前，跟自动化测试工程师先讨论好开发思路，测试工程师准备case、数据，等新功能开发完成后，测试工程师再开始脚本开发。
2)自动化测试工程师只负责自动化测试框架的搭建、公共功能自动化脚本开发、对开发人员的培训（自动化测试框架方面），当新功能的自动化测试脚本由开发人员来编写。

不论是第一种目的还是第二种都应注意，当敏捷活动中有持续集成，那么自动化测试还需要跟持续集成结合起来，每集成一次，自动化脚本就运行一遍。（如果集成的频率非常高的话，可能要注意自动化测试脚本的效率或者是脚本的裁剪、筛选）

[ 本帖最后由 velata 于 2010-8-22 22:40 编辑 ]

作者: velata 时间: 2010-8-22 22:35

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

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

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

作者: candy_girl 时间: 2010-8-24 08:52
围观，learning

作者: kukulsz 时间: 2010-8-24 15:19
支持#8楼

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

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

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

作者: velata 时间: 2010-8-25 18:32

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

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

作者: hoppaoy594 时间: 2010-8-26 10:54
敏捷了。。。。
学习！

作者: huguxiang 时间: 2010-8-26 11:24
标题: 敏捷式开发下如何运用自动化测试
首先，楼主的问题比较模糊，敏捷是指敏捷式开发吧？不是指敏捷测试吧？没听说过有敏

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

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

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

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

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

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

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

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

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

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

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

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

作者: liulinzhu 时间: 2010-8-27 09:45

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

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

作者: maguschen 时间: 2010-8-29 16:19
这个问题有点大，我现在所处的公司也是应用了敏捷开发，下面分享一下我们公司做自动化测试的一些经验
首先，敏捷开发并不是部分同学想象中的那样，没有文档没有需求，开发来了就干，干几个月就丢给客户一个版本让他们用去，我们公司一般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前能够对产品进行覆盖较为全面的回归测试
工作中*不断地*开发自动化测试工具，提高自己的生产率

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

个人愚见，欢迎讨论

作者: 愚人 时间: 2010-8-29 20:14
二者都不懂，坐下慢慢看……

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

作者: dennyqiang 时间: 2010-8-31 09:38
单元测试和基于界面的功能测试都应该做好自动化，敏捷测试需要用自动化来协助的。

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

作者: fjstc3441 时间: 2010-8-31 11:03
敏捷测试需要高度自动化,这两个非但不矛盾，反而切合的非常紧

作者: A_little_love 时间: 2011-7-20 14:35
学习中，

作者: SariyaLee 时间: 2011-7-29 14:15

学习了。

作者: JaifyTesting 时间: 2011-7-29 15:38
虽然不是很东，顶了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)