敏捷了，自动化测试怎么搞？（2010-8-16）（获奖名单已公布）
敏捷了，自动化测试怎么搞？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单奖项获奖名单奖励答案链接一等奖hsjzfling价值50元的礼品8#二等奖maguschen300论坛积分28# 占位。
没有自动化支持，敏捷怎么能搞好？
没有自动化支持，敏捷怎么能搞好？回复 3# 的帖子
顶，一语道破玄机 3楼威武 感觉最近的每周一问质量不行了 TDD吧 敏捷测试过程中的自动化目前在国内来看基本上还只是停留在概念阶段，据我所知，目前不少公司也都在尝试过程中，而实际的实践中能取得比较理想成果的，极为有限。而国外不少同仁也都对此持观望甚至抵触的态度。比如advanced QTP论坛的administrator Meir大大 就认为敏捷过程中的自动化是完全不现实的，理由就是sprint间隔时间内没办法完成一个完整自动化过程的设计，而频繁的变更会导致自动化资源的大量浪费，ROI上无任何前景可言。从我个人观点来看，没必要保持如此的悲观，但更不能过于乐观。敏捷过程是IT发展的产物，自动化从概念上来看是确认一个sprint成功的重要一关。敏捷过程需要有自动化测试，但却不能盲目让自动化介入，否则很可能适得其反。
个人略作了下小结，由于敏捷模式的种种特色，敏捷过程中的自动化实现所需要满足的条件比常规的自动化测试活动苟刻的多，除了普通自动化过程必须具备的条件之外，主要还有以下几点：
1、 对于自动化工程师的要求更高，除了解决种种突发异常的自动化技能以外，还需要对项目的业务知识有比较多的了解。
在敏捷模式中，文档不会像传统的模式中那样完备，测试的case可能会相对简易，不少内容都只是口口相传，敏捷团队的成员也不可能专门派一个人出来辅助自动化工程师解决业务问题，那么就要求自动化工程师对于业务知识比较了解了，就算对项目了解有限，但至少要有背景知识，大多数情况下能理解一句话中所包含甚至是隐含的一系列业务操作。
2、 项目成员结构上，自动化工程师需要成为敏捷团队的一员，而不是编外人士。理由很简单，敏捷团队经常会召开类似头脑风暴的会议，一个短暂而激烈的会议足以决定一个变更，然后大家立马投入工作中。这时自动化工程师若作为编外人士，那很可能就得不到这第一手的消息了，很可能吭哧吭哧好不容易码完的脚本还没跑过就得改了。
3、 对于项目、产品的要求。被测系统必须是非常适合自动化的，在自动化脚本开发过程中不应当遇到被某个技术实现难倒的问题，敏捷模式下是没可能有几天甚至一周的时间去处理某个自动化的技术细节的。这就需要在接受项目前做自动化可行性评估的时候考虑周全，是否有某些核心的功能无法被自动化，可以接受多少功能不被自动化。
另外各story间不能有太强的依赖，因为很可能自动化工程师无法完成对所有功能的自动化，而一个story的需求变更也不应导致其它story有太多变化。
4、 对于BA的要求。BA需要对产品的主要功能非常了解，非常清楚哪些功能是不太会变更，而哪些部分是不太有把握的，同时对客户也要有一定的掌控能力。这样除了提供主要的测试点以外，还能结合变更来给同为最高级别的测试点附加上自动化优先级，在很大的程度上避免自动化工程师的重复劳动。
总的来说，要实施自动化，对团队的成员素质要求非常高，也要求成员间的配合比较默契。说实话，真的很难，但并不是不可实现。 敏捷也只是相对的吧，整个项目可能一部分还是可以考虑自动化的，自动化无非的减少重复劳动成本，提高效率，所以可以拿项目中比较固定，且重复高的来做自动化
回复 1# 的帖子
敏捷测试需要高度自动化，因为频繁迭代具体的自动化包括以下几方面：
1、静态的自动化，具体做法就是单元测试结合每日构建，这其中包括了代码检查，以及一些可以用工具检查的白盒级别的测试，工具包括checkstyle, pmd等等
每日构建工具可以使用hudson
2、测试中的自动化，根据软件类型的不同，可以在迭代前期逐步将高度重复的测试工作自动化实现。可以考虑用自动化工具：rob, rft, qtp等，或者代码实现,java等，代码实现的基础是单元测试代码
LX补充，谢谢
学习了，
学习了 看了，学习了，思考中。。。。 敏捷开发确实需要很实用 敏捷开发离不开自动化测试，GUI层的自动化测试开发和维护成本较高，单元测试和集成测试的自动化是首先应该考虑的 你是要做什么自动化呀,qtp是做回归测试的，loadrunner是做性能测试的；qtp记录的是客户端的操作，loadrunner记录的是客户端与服务器之间的操作；
qtp的工作流程是：录制脚步-设置组合条件的参数化（datatable/随机）-设置检查点-迭代-新版本回放
loadrunner的工作流程是：录制脚步（一个虚拟用户）-参数化-检查点-集合点-关联-设置事物-建立多个虚拟用户-运行
只是个人理解而已 这个问题还是得看自动化的目的是什么，不同的目的有不同的做法。
目的1：回归之前的功能，确保之前的功能没有因为本次迭代新开发的代码而损坏。
目的2：测试本次迭代中的新功能。
先说第一种，由于在团队中还有其他的功能测试人员存在，所以当前迭代的功能不需要立即开始自动化编码，可以等到下个迭代，功能、界面稳定后再开始对当前迭代的功能进行实现。在这种情况下自动化测试的压力相对就不会很大了。
对于第二种目的，可能会比较麻烦。根据实践个人觉得有以下两种方式：
1)在开发人员进行新功能开发（或老功能维护）前，跟自动化测试工程师先讨论好开发思路，测试工程师准备case、数据，等新功能开发完成后，测试工程师再开始脚本开发。
2)自动化测试工程师只负责自动化测试框架的搭建、公共功能自动化脚本开发、对开发人员的培训（自动化测试框架方面），当新功能的自动化测试脚本由开发人员来编写。
不论是第一种目的还是第二种都应注意，当敏捷活动中有持续集成，那么自动化测试还需要跟持续集成结合起来，每集成一次，自动化脚本就运行一遍。（如果集成的频率非常高的话，可能要注意自动化测试脚本的效率或者是脚本的裁剪、筛选）
[ 本帖最后由 velata 于 2010-8-22 22:40 编辑 ] 原帖由 michaelwxm 于 2010-8-17 10:42 发表 http://bbs.51testing.com/images/common/back.gif
TDD吧
TDD跟自动化测试是两码事吧？
TDD只是测试驱动开发，先编写测试脚本，通过不断的编写代码使得测试通过，主要还是在单元测试层面的。
而自动化测试会偏向验证功能，其中还有很大一部分是测试场景设计、测试数据设计。 问题的提出应该是针对系统测试阶段的自动化测试而言，因为敏捷要求的频繁迭代，已经要求有自动化程度非常高的单元测试代码，TDD也是基于此。从另一层面上说，敏捷测试更多强调的是单元测试的成效，所以传统的自动化测试的方式方法在敏捷团队中受到的挑战非常大。完全的自动化测试因为系统的迭代频繁基本是不可能的。所以此处自动化测试还是更重在提高测试效率，通过一系列辅助测试工具或针对功能模块的黑盒测试代码来简化操作、释放人力。 围观，learning 支持#8楼
页:
[1]
2
