纳尼？！怎么回帖看不到？？
我们公司目前的情况是，自动化测试的投入很大，有专门的TA部门。但是对于手动测试，自动化测试永远不会取代。而且对于接口比较复杂，应用程序界面比较多的案例，自动化很难调试的好。特别是对手动测试又不是很了解，就是对测试步骤不是很了解的情况下，自动化测试收效甚微。因为不能够准备的了解case设置时候的每一个check point，自动化实现的仅仅是case中写明的check point.实际上在手动的测试中，很多bug是意外或者牵连发现的。当然，自动化测试对于性能测试这点是手动测试无法媲美的。
写的不错
很多观念还是很赞同的。我与自动化测试同仁的路有点反过来，首先我是做自动化测试平台的开发，之后又开始做自动化测试框架开发，最后做QTP的自动化测试，有点顺序颠倒的意味。
1、在我做自动化测试平台的时候，我需要了解测试业务，测试流程，才能搭建更好的测试平台；
2、自动化测试框架的时候，需要了解产品业务框架、技术框架，才能写出适合自身产品特点的自动化测试框架；
3、最后做真正的测试，也就是QTP录制脚本，测试具体的业务的时候，才发现业务千差万别，QTP真心扩展性不强，给人了最便利的同时，但是也很局限人的思维。
自动化测试，反过来说就是测试自动化，既然测试可以自动化，那么其他一切手工可以做的，特别是符合一定的流程或者规范的东西都是可以自动化的，智能家具等，汽车还分为自动档和手动挡，余额宝都可以说用了自动化的理念，把人们买货币基金的过程自动化了，所以自动化的领域很宽，很酷，期待大家的探索。
其实因为Web浏览器以及窗体程序的标准化比较好，所有出现了通用的测试工具，QTP、selenium等工具，试想，如果没有HTML，http等规范协议，工具毫无意义。其实说白了，它们只是一种工具而已，萝卜白菜各有所爱！
很受启发，顶一个
自动化技术远没有成熟
自动化，目前正在学习中。。。
之前做了一段时间的selinium，对测试人员的编码能力有较高的要求。越到最后，感觉自己越倾向于开发新代码，而不是测试开发写的代码。由于自身能力有限，开发代码的速度远远没有开发人员那么快速高效，所以搞了一个星期，也就写出了一两个可以跑通的测试用例，所以最后还是放弃了。自动化远看很美好，真的要做好很难。
本帖最后由 langhai5212 于 2014-4-17 17:30 编辑
回复 20# CarlHW
完全同意20楼的兄弟说的，楼主一看就是没有大规模搞过自动化的。至少有两个观点我不同意，
相同成本下，自动化不一定能取得效果有可能是鸡肋。
相同效果下，自动化的财务成本正常情况下要比手工贵。
简单说一下，自动化不是发现bug的是发现问题，发现异常的。是不是bug还得由人来定。自动化之所以在
这个快节奏的背景下被重视，重要原因是它可以将测试前置到手工不能做的阶段。能够在非工作时间
执行，从而抢回时间来。使测试不再成为整个软件开发过程中的瓶颈。
其他的就不说了，这篇文章看似鼓舞人心，其实没什么营养。自动化做到什么程度要和组织的能力成熟度匹配
，再牛逼的技术，如果团队整体能力成熟度是个作坊级的，是不会有什么用的，反而自动化会成为鸡肋。
云层能来个一般情况下的ROI分析的列子么？
膜拜
看了霁哥的文章怎么感觉有点沉重啊...
感觉自动化要向前走,必须要将其放入整个软件生命周期,而不仅仅是测试周期中.
写的真好，顶了
:lol
学习了
对于我这个一直不敢涉足自动化的新手来说，给了我一定的勇气去探索、学习自动化。
用QTP作自动化使用描述性编程,这样不是会灵活很多么
写的不错，学习了
回复CarlHW
完全同意20楼的兄弟说的，楼主一看就是没有大规模搞过自动化的。至少有两个观点我不同意，
...
langhai5212 发表于 2014-4-17 17:21 http://bbs.51testing.com/images/common/back.gif
既然有人吐槽了，我觉得这是好事，我介绍一下这两个观点的角度。
1.
何为相同成本下，自动化能做的比手工更好。其实在这段的后面我就提到了和你相同的观点，自动化的目的是抢时间，手工的执行时间成本很高，自动化的执行时间成本很低，如果再一个相同的成本（时间或者总的成本）来考虑，自动化在大规模的核心或者关键业务上的自动化能够更全面的完成测试的执行任务，那么在时间不充分的情况下自动化肯定做得比手工好，至少效率可预估，质量可保证。
2.
何为相同效果下，自动化能比手工更省钱。也就是说在只是通过自动化完成手工测试的内容，那么不考虑使用自动化做探索或者模糊测试，那么如果公司成熟，从多次回归的角度来说一定自动化比手工省钱，当然你说1-2次这种测试显然手工有优势，但是如果你自动化熟悉了，你也知道其实做个自动化脚本真的比手工测试的时间会长很多，成本会高很多么？未必！特别是现在测试执行自动带录制回放的策略越来越多，某些情况可以认为就是验证一次就自动化脚本出来了。
这两点从传统行业例如汽车制造中也可以参考。
我对你这边有些不同的看法的地方在一下几点：
1.自动化发现的bug是不是bug?
自动化是手工用例的延续，如果自动化的检查不包含业务或者用例的预期结果，只是运行等待系统的某些异常或者脚本的异常，自然这个就是发现问题不是bug.这个取决去我前面提到的手工用例的完整度来提升自动化脚本的有效性。
2.自动化测试可以将测试前置到手工测试？
这个是我更不接受的部分。无论如何来说手工测试和自动化测试只是在执行策略上的不同，并没有前后之分！真的所谓的前置应该是设计，那么就算是代码阶段如果有好的单元测试用例，我也可以选择手工执行而未必使用自动化。
最后我支持的观点，自动化是一个整体能力的东西，不是一个简单技术，但是从测试的角度来说如果技术好了能推动的事情多，而本文的主题是提醒现在很多做自动化的人出发点都是为了逃避编程和新的技术而已。
ps.问题需要讨论。好久都没人来真的交流。希望和你的会话能继续下去。
