需求经常变化，如何做自动化测试？
不要说，对于一些不经常变化的做自动化测试，那好象也没什么意义，因为在测试中，那些不经常变化的发布版本后，很少有问题，
如果你在去做自动化，其实不是在提高效率，而是降低效率，浪费时间啊

郁闷？

应用自动化不错的公司的朋友们，能指点一下吗？

这是个自动化测试如何实现的问题。个人认为自动化测试应该主要用于回归测试，恰恰是测试已有功能，而非新增功能。

假设开发了一个全新的软件，每隔一段时间软件版本升级一次。结合软件开发周期，自动化测试可以如下方式实现：

软件首次发布
- 功能测试，由QA手工完成测试；
- 自动化测试脚本设计与开发，针对软件的现有功能，由自动化测试人员完成；

软件升级发布
- 功能测试，由QA手工完成新增特性的功能测试；
- 回归测试，由QA通过上次开发的自动化测试脚本完成；
- 自动化测试脚本维护，设计和开发针对新增功能的脚本（供下次回归测试使用）；

在整个软件生命周期里，手工测试和自动化测试是互为补充并且交替前进的。

winfood ，谢谢
分析的很不错，如果是对于是增加新功能，按照你说的做，应该可以
但是我这个是：经常是对原有的功能进行改变．很少增加新功能的。这就不好做了
可能根本不适合做自动化．

从你说的情况看，实施自动化测试的效益可能不明显。

需求频繁的变动，不适合用自动化

自动化测试
（1）从语法上来讲，自动化是用来修饰测试的，也就是说测试才是最终目的，而自动化只是手段之一。
（2）如果指的是功能性的自动化，那么在Build频繁变动的时候，如果想用自动化，那么可以利用工具去实现一些主要流程，当然是成本不太大的情况下，比如电子商务的网站，打比方说一个订票系统，我就完全可以去录制一个订票过程来辅助我做订票流程这一块的测试。当然，我和大家的意见一样，在Build稳定 进入回归阶段的时候，自动化测试才能更好的发挥作用

估计你要放弃做自动化测试的打算了

呵呵，
还是有时间的话，将一些不经常变动的模块做一下自动化把，
不过感觉就是没什么实际作用，反正这些不经常变动的基本上不会出错的。

还有其他的地方可以做自动化啊，
比如我想测试一下翻页功能是否正常，
总不能一条一条的添加数据从而达到记录超过一页的效果啊

分析的不错，不过公司的人的职责没分那么明确，一个人得是多面手，悲哀

引用:

还是有时间的话，将一些不经常变动的模块做一下自动化把，
不过感觉就是没什么实际作用，反正这些不经常变动的基本上不会出错的。

“不经常变动的基本上不会出错”这句话可以说不应该从 测试人员嘴里说出来，这样的话开发人员说的更频繁。
这些不经常变动的功能 或许在考虑优先级的情况下，当前Build不需要测试，但是真正进入回归阶段是必须测试的。
当然，如果时间充足，每个Build都做回归更好了

引用:

还有其他的地方可以做自动化啊，
比如我想测试一下翻页功能是否正 ...

这里要验证的是翻页功能，那么添加数据就是一个 前置条件了，那么自动化工具完全可以辅助我们去做造数据这个工作

1， 需求经常变化 是需求管理应该考虑的问题，这不是 QTP能解决的问题；
2，不知道你说的“需求变化”具体是什么意思，是原有的业务逻辑有了变化，还是新增了什么功能？如果是前者，那么 QTP可能发挥不了什么作用；如果是后者，那么 QTP录制的脚本一样可以使用呀。

请 参考 http://bbs.51testing.com/thread-64600-1-15.html
http://bbs.51testing.com/thread-71779-1-3.html

自动化测试不能代替手工测试!

我们公司现阶段还处于手工测试,唉,太落后了

学习了

在过渡中。。。