前期由于界面变化太大，如果录制脚本，那么后期的维护量很大
到了后期，页面比较稳定了，但是测试也已经到了后期，自动化的功能测试也没有多大的意义了

我们没有自动化测试
但是就个人理解 自动化测试比较偏重测试性能
所以等到后期才开始是没有问题的
系统还没完整的时候测性能没什么意义啦~

但是比如一些边界问题通过功能测试就会容易发现问题，例如循环20次等，这种测试通过手工就不会全面，通常循环2、3次就不错了，那么这个边界值就不会达到。

系统测试的时候会用用到自动化测试，脚本录好，晚上放那跑就行了。

如果自动化测试脚本不涉及到页面，脚本维护量会小一些，但是如果涉及到的话，维护量就比较大了。
偶卖糕的，你们公司是属于哪种情况呢。学习……

把你的想法和实践过程贴出来啊``呵呵,,期待中..

不好意思，几天没上来
对于自动化测试，由于我的开发功力不高，最早的时候是自己写点小程序，直接调用函数或功能，然后对比数据库中的数据查看是否正确，但是对于界面上显示的数据我无能为力，写不出那么好的程序，这样就漏掉了数据库中的数据正确，但是界面上显示的数据错误这种现象，而这种现象又是常见的。
后来就用wr做功能的自动化测试，但是界面总是一改再改，然后我的脚本也是维护量特别大，由于测试人少，总共2人，最后我们放弃了，因为工作量太大了。现在又回到了最早的手工测试，当然自动化测试永远也不能完全代替手工测试，但是又有些不甘心一遍一遍的重复测试（因为有时候虽然表面上看功能和界面没有变化，但实际上算法改变或者由于修改其他的功能或许引发错误）。

我看咱们坛子里测试人员很多，所以跟大家交流，大家都是如何进行功能的自动化测试的？

个人意见，自动化测试不应该只仅仅局限于具体的测试实现过程，比如具体的WR、LR等等，还可以包括测试生命周期其他的工具使用，比如：可以有工具来实现缺陷的跟踪，比如可以有一个软件来对测试的文档进行管理，比如测试需求是否是根据软件需求来的，之间的对应关系，然后测试用例是根据什么测试需求来的，测试记录是使用的什么测试用例来进行测试的，等等……

我觉得楼上说的应该属于测试管理范畴 而不是自动化测试
现在的公司有打算做自动化测试
个人理解：
如果开发是迭代式的，那么在每个稳定的迭代版本上就可以开始自动化测试。所谓稳定是指
1、界面固定不变了
2、关键路径上的功能不变了
3、如果涉及到流程，则要保证流程的每个节点都不会改变
这样在每日构建的基础上实行自动化测试应该是比较有效率有成效的
因为自动化测试的目的不是再为了找错误，而是为了确保关键功能的正确。

楼上的说的好好,学习了
现在正在研究自动化测试,感觉比较难理清思路,希望有啥好经验可以分享...