自动化测试当成很厉害的资本，为什么？

lsekfe

在国外，资深的软件测试人员大多是手动测试，他们厉害之处在于测试用例的设计，但在国内，很多测试人员都把自动化测试当成很厉害的资本，为什么？

hhways

。。。。

mjq1991

哎，每个方向做成了大牛才会有傲气的资本

buzhi45

请看清中国处于社会主义初级阶段的基本国情，100年不变。。。

fj950953qwe

我竟然全部看完了，我的天.........

Miss_love

回复 18# Lothario


    1楼以外都是评论

Lothario

哪些是评论？

thjk2009testing

比较赞成楼主的观点或者是转载的观点。手工测试在一些自动化无法达覆盖的地方可以很好的体现并且相应速度快，但是确实有重复性、大数据、周期长等方面的缺点。但是手工测试需要较高的个人素质和充足的个人业务或者行业经验，而这个是很难在短期内被人看到的且很难衡量，导致市场向导就是如果测试人员会一个或者多个自动化测试工具这个可以衡量的能力，就会被人认为比较牛。需求决定了市场。。。

愚人

回复 1# lsekfe


    市场导向……向钱看
如果国外的市场导向也是重自动化，估计资深的也会是自动化

千里

把两个技术都弄明白，就明白了哪个更厉害了

wosshizi

看着很想睡觉。
长篇大论，一堆所谓的专业名词，时不时飙出个鸟语，看了几节直接看评论，一般评论比较有意思。

lsekfe

我也想看看其他人怎么说。
gaha 发表于 2014-7-18 16:53

    下面都是热帖中的评论，你也可以看下~

gaha

我也想看看其他人怎么说。

lsekfe

这个是书还是？
Miss_love 发表于 2014-7-18 15:04

    我网上转载的一个热帖~~

lsekfe

LZ居然问这个问题？现在国内测试行业的这个情况，还不是你们这些商家炒作出来的？动不动就喊着高薪高新的， ...
gaha 发表于 2014-7-18 16:25

    这个只是我网上转载的资料，让大家看看~如果你觉得扯淡不扯淡这个请你放心心里谢谢~

gaha

LZ居然问这个问题？现在国内测试行业的这个情况，还不是你们这些商家炒作出来的？动不动就喊着高薪高新的，动不动就教这个工具那个工具。一帮非信息专业的人，觉得自己学了学工具的初级知识，就认为自己是高级人才了，扯淡吗不是？
切！

Miss_love

这个是书还是？

lsekfe

这个我是网上最近热点的话题，大家有建议和想法可以互勉下~

lsekfe

手工与自动化只是一种形式，真正的核心是测试用例、业务模型和测试分析。
当企业的产品规模开始膨胀的时候，尤其是产品迭代加快是不是能及时得到测试验证支持是很重要的。这些靠手工测试是基本无法实现的，手工测试会严重的拖慢产品进度，而且无法保证全局质量。
没有对覆盖率，测试分析等进一步的数据挖掘，一切深入的问题也无法被手工测试人员发现。

手工测试与简单的操作自动化只是测试的初级阶段，将来也许会有云测试与智能化测试，大数据测试，这些新的测试手段都是围绕测试用例，业务模型与测试分析来做的。没有良好的coding能力，就无法发挥电脑的潜能，也无法做更深入的数据挖掘。

目前的很多公司的测试是有问题的。
大部分的自动化测试的问题是成本高，只是简单的check，没有绑定覆盖率，没有做测试建模、盲目的追求case数量，自动化分层不合理，ui自动化测试比重太大，导致作用有限。

而手工测试也是只覆盖基本的业务，根本不了解细节上的风险。bug不仅仅是因为需求和业务引起的，还可能由设计，架构，代码以及操作系统特性引起的。而且测试人员的执行是否到位也是值得考察的。我在阿里百度都遇到过手工测试人员因为工期紧张，用例太多，草草结束测试的事情。

所以，手工测试重要，但是不能重点依靠。自动化能够提供全局的把控和质量验证，价值还是很可观的。而做好自动化还需要更多的深入的工作。毫不讳言，我们整个国内还没有几家公司能真正做到测试建模，目前只是做到了最基础的测试用例+自动化+覆盖率而已。

对于手工测试，我举个最简单的例子，百度的一些产品，需要在chrome浏览器，firefox浏览器，ie6/7/8/9，360浏览器，搜狗高速浏览器上做测试。如果开发只修改了几行代码，在不依赖新测试模式，新技术和自动化的情况下，只靠手工测试，几乎是不能避免bug的。

在银行，金融，国企，以及传统企业里面，经常会看到工作了七八年的手工测试人员，而且他们的产品更新很慢，体验很差。而在互联网里面，则很少看到，但是互联网的产品体验要比传统企业优秀的多。

不可否认，手工测试里面有不少高手，但是缺乏了自动化，缺乏了大数据分析，缺乏了测试建模，将很难为产品线带来更多的价值。所以自动化是很重要的资本。只是整个行业，懂业务，懂测试，懂开发的人太少了。大多数的人，都是其中的两者结合体。

lsekfe

测试最重要的还是对系统以及需求的理解吧。至于是不是自动化，更多是取决于产品的生命有多长，以及自动化后成本有没有减少。
关于对系统以及需求的理解，这个是测试工程师最基本的要求，但是很多测试工程师现在都只是知道怎么跑case，把自己变成一个自动化测试脚本，而不是去理解整个系统。好比你搞web测试，只是测那些页面跳转会如何之类的，那基本上测不出什么bug来的。即便能测出，也不过是运气问题。但是如果你理解了后台和前台的交互，有哪些数据，哪些地方可能会溢出之类的，那会更容易找到bug。
对需求的理解，也是很重要的，我见过做性能测试，有些测试工程师不理解产品需要的开机时间是多少，觉得反正没有具体的要求就没所谓。而有些则觉得很重要，拼命提CQ要求修改的。最后在客户验证的时候，发现后者的理解是正确的。这些很模糊的东西，更多需要个人理解才可以获得。或者说，这叫经验。
自动化测试的目的更多是减少测试时间，把更多的时间放在设计用例，以及理解需求和系统的阶段上。但是如果做一个以后都不会再做的产品，还开发了一堆自动化测试的脚本，并且在软件里面写了一堆log，那基本上是费时费力却得不到任何实质上的帮助，因为开发这堆脚本和log的时间，已经够测试几轮了。
国内对自动化测试的向往，无非是因为国内测试人员玩的都是苦力活，而不是技术活。你随便找一个测试的，你问他对系统了解多少，多半是只会执行case的人而已。甚至乎，这些人在完成了任务之后，基本上就不再学习了。

-----------分割一下，一些内容和题目有关系，但是不是太大。写得也很乱。------------

近年来国外有个叫做SBMT(Session based test management)的东西，建议大家看看。有条件的公司建议实行一下。这种测试方法严格得区分开了checking跟testing，对测试人员的要求很高。并且SBMT里面不存在固定的所谓的测试用例。
现存的测试用例的测试方法是按照ieee以及几本一九七几年写的老书确立起来的，虽然名曰为Best Practice，但是实际上是效率很低的。因为一个测试用例测过几遍之后，其信息量几乎为0。根据信息论，越确定的东西，其信息量越低。我实在搞不懂一个check了几百遍都没问题的东西为啥要用人来check而不用机器来check。
严格意义上来讲，自动化测试应该叫做自动化检查。它只是checking而已。什么叫做checking？checking就是按照需求文档一条条打勾。什么叫做testing？testing就是探索产品本身的结构以及分析产品可能的问题。
SBMT是通过认知论的方法，触发测试人员的思考，让测试人员自己去了解系统。
一般SBMT会有一个charter(即要测的功能)，几个Mission（想要达到的目标）和一份note。格式如下：

Charter:
To test WORD
Mission:
1. To find out memory leak scenario in word.
2. To find out several boundary values of word.
Note:
1. I blah blah...

通过Mission，一般测试人员需要为了达到这个目标而想一些测试用例，而这些测试用例的建立则不得不依赖于思考，而不是之前已经写好的脚本。测试人员必须把自己的思考和测试步骤写成Note。当然这也解决了测试工作无聊的这个事实。

另外，testing的本质目的只是提供产品的信息而已，是一个“辅助”功能，不是一个生产功能。产品的质量完全不能通过testing来保证，所以才需要用到工具和流程，这才是测试需要进化的方向：想办法给工具和流程提意见，改进（或创造）有利的工具和流程，把测试本身提供的信息Build进产品里面去。


测试这个职业，这几十年来几乎没有啥进步，所有提升软件质量的方法都是dev提出来的。如果测试工程师再不把自己的testing build into code，我感觉这个职业很快会被dev或者某些工具所兼顾，平均薪水会越来越低（现在已经不高了）。