自动化测试和手动测试都是不可缺少的，两者相辅相成，简单说说我对自动化测试和手动测试的体会：首先，我认为自动化测试的主要目的并不是为了发现产品的BUG。 它一个重要的目的是为了确保软件产品在开发和维护过程中，团队对产品有更直观的掌握，消除代码中的错误，即make the system run properly, eliminate bug earlier, which in result raises confidence of the development and the whole team。 而手动测试是为了break the system，即发现BUG。 我始终认为最好的测试是将软件缺陷消灭在摇篮里，测试的根基、金字塔的底座是独立的单元测试，由开发人员负责，可以最小成本的发现潜在的BUG，也就是说DEV是最好的QA。自动化测试和持续集成是重要的手段，确保对产品质量的可控性。 版本控制软件也非常重要。极大提高我们的工作效率。<img src="https://pic2.zhimg.com/068056a416383d7c0d75b875e2c435b9_b.jpg" data-rawwidth="1050" data-rawheight="585" class="origin_image zh-lightbox-thumb" width="1050" data-original="https://pic2.zhimg.com/068056a416383d7c0d75b875e2c435b9_r.jpg">简单所以下我工作的情况：之前在BlackBerry Enterprise Service实习，负责BES产品发布之前的测试，BES是面向企业的产品，产品质量和稳定性是产品赖以生存的根本，因为我们非常重视软件测试。我的主要工作是以手动测试和fix verification为主，不和产品代码打交道。可以说虽然是发布前最后一关，但依然发现很多产品中BUG， 任何一个BUG都直接影响客户体验。由于各种限制，手动测试不可能覆盖产品所有方面，因此对产品的了解、丰富的测试经验、制定详细的测试用例对于手动测试非常重要， 也是考察一个手动测试工程师主要的方面。对产品的了解可以更容易找到产品的薄弱环节；丰富的测试经验可以更快的发现BUG；而详细的测试计划可以帮助我们发现更多的BUG。我认为手动测试发现了产品中的大部分BUG。目前我在一家北美某游戏公司温哥华分舵，team主要是负责为公司大部分游戏提供online service,游戏整合online service SDK 使其与server交互。简单说说QA team的情况，一个senior dev负责开发和维护测试框架，两个senior QA带一群QA，还有一个做build系统的。我们的日常工作基本属于自动化测试，手动测试可能交给有游戏TEAM了吧。由于产品太复杂、公司没钱等一系列因素，还未实现完全的持续集成，基本上还在依靠nightly regression，因此还是以天为单位，而不是以敏捷测试中每次code checkin为单位。更可恶的事情是xbox, ps的自动化测试还没有整合到build系统里，所以本屌丝要经常要手动load测试程序。 吐槽一些对现在工作中的感悟：1、大家都知道，用c++写的产品编译时间都非常长，即使我们有incredibuild这种NB的TOOL, build一次完整的产品和自动化测试的工具也要半小时左右，如果产品或者测试工具出现以下编译错误就会BLOCK所有的工作。产品坏了我们可以revert，但是测试工具坏了有可能是产品code改变，或者是工具本身的问题。 investigate要花时间，fix也花时间。这一点非常影响工作效率。2、不是说自动化测试就不会发现BUG，每次回归测试结果都一堆错误。但重点是！！！！！你要花时间分析到底是测试用例的问题，测试框架的问题，还是真是产品的BUG， 每天看Log简直把眼睛都看瞎了。3、自动化测试用例不是一层不变，产品feature变了，测试用例要改变。很多时候测试用例fail了，很有可能是测试用例没有更新。4、我认为我们目前最重要的问题是DEV没有写单元测试的习惯！所以自动化测试系统并非神器，它非常娇贵的，你要花时间是维护它、呵护它、关爱它，它才是成为你手中的利器。最后，简单说一下招聘过程。 虽然我们的工作是QA，但面试的基本内容是C++的概念、算法、编码能力。仅仅会问一些简单的测试概念。这也从一个侧面反映出QA不要懂产品逻辑，还要懂产品代码！PS：深感国内软件测试发展的不成熟，以后回国可咋找工作啊，好了不吐槽了，第一次回答问题，流水账请见谅，洗洗睡吧，明天继续上班。作者: lsekfe 时间: 2017-8-23 11:35
作者：Monkey
链接：https://www.zhihu.com/question/19721142/answer/16099915
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
测试最重要的还是对系统以及需求的理解吧。至于是不是自动化，更多是取决于产品的生命有多长，以及自动化后成本有没有减少。 关于对系统以及需求的理解，这个是测试工程师最基本的要求，但是很多测试工程师现在都只是知道怎么跑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或者某些工具所兼顾，平均薪水会越来越低（现在已经不高了）。