总结一下知乎上几位答主的答案
- 自动化测试和手动测试都是不可缺少的，两者相辅相成
- 无论是自动化测试还是手工测试，其核心永远是测试用例。无效的用例，用任何方法去测试，都不会达到良好的测试目的。
- 自动化更多是取决于产品的生命有多长，理论上所有的手工测试都可以自动化，但应考虑使用自动化工具带来的效率上的增益能不能抵消设计编写自动化工具的消耗。
人的精力是有限的，自动测试的测试人员可以用更少的精力去执行测试，于是就可以把更多的精力放在设计测试案例，以及理解需求和系统的阶段上。 - 设计用例的发散思维和能力无法被具象衡量，而搭建自动化测试框架以及编写自动化测试脚本是具象的能力。
- 目前国内普遍的测试情况仍然是手工测试比例为重，虽然不应该简单地用是否做过自动化测试作为唯一衡量标准，但企业在不了解测试人员具体能力的情况下，反映在简历上更希望应聘者是个多面手。
- 作为一个测试人员，从谋取自身利益的方面考虑的话，应该看你所使用的测试手段能不能产出被企业认可的价值，这个要根据公司具体情况而定，是更追求质量还是速度，对测试人员的要求侧重点是不一样的。
自动化测试和手动测试都是不可缺少的，两者相辅相成，简单说说我对自动化测试和手动测试的体会：首先，我认为自动化测试的主要目的并不是为了发现产品的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。自动化测试和持续集成是重要的手段，确保对产品质量的可控性。 版本控制软件也非常重要。极大提高我们的工作效率。
单元测试->持续集成-》接口组件测试-》功能级别组件测试-》持续迭代-》部署测试-》 用户体验性测试
简单所以下我工作的情况：之前在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不要懂产品逻辑，还要懂产品代码！
作者：金阳链接：https://www.zhihu.com/question/19721142/answer/22918933来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
测试最重要的还是对系统以及需求的理解吧。至于是不是自动化，更多是取决于产品的生命有多长，以及自动化后成本有没有减少。 关于对系统以及需求的理解，这个是测试工程师最基本的要求，但是很多测试工程师现在都只是知道怎么跑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 WORDMission: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或者某些工具所兼顾，平均薪水会越来越低（现在已经不高了）。
作者：maxSonic
链接：https://www.zhihu.com/question/19721142/answer/13458098
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
说点自己的不成熟看法。 将自动化测试当成很了不起的资本，源于国内对Coding的崇拜，譬如一个Dev跟一个QA放在一起，大家的第一直观印象就是——前者的技术能力比较强。 实际上，这个问题分两面看： 1. 自动化测试能力是不是资本？ 是，当然是。测试自动化是软件测试的大方向。作为其核心组件的自动化测试的引入将QA从繁重的重复劳动中解放出来，完成靠人力难以组织的测试，优化测试资源，提高测试效率。优秀的自动化测试框架、完备的自动化测试脚本集、丰富的自动化测试工具将使得测试的效率倍增，对产品质量保证起到积极作用。一个有自动化测试脚本、框架、工具开发能力的QA，更有竞争力是一件无可厚非的事情。 从招聘方的角度看，就如同两台配置差不多的笔记本，一台多出俩USB口并有一个HDMI，当然会优先选了，虽然他也不一定用得到。 2. 自动化测试人员一定强于手工测试人员？ 不一定。我接触过的自动化测试的QA大致有两种：其一，专职automation，他们从进公司开始就定位为自动化测试人员，有的公司的automation team甚至都不隶属于测试团队，他们从进公司开始就几乎只接触脚本和工具，自动化的需求对于他们就等于一个开发需求。这类的测试人员对产品本身了解并不多，且不深。更倾向于一个开发人员的工作方式。其二，既做手工，也写过一些自动化脚本。这一类人实际上仍然算是手工测试人员，但会小范围参与到一些简单脚本开发，多数是在已有的测试框架上进行的搭积木的工作，缺乏创新空间。对于这两类QA，前者因为很大程度上仍工作在一个Dev的模式下，可能存在的缺陷主要在测试的方法、感觉和思维方面，后者则完全可以作为一个手工测试人员去做横向比较。国内自动化测试的现状，使得投放入市场的自动化测试人员，以第二种类型的居多，且目前国内普遍的测试情况仍然是手工测试比例为重，所以如果招聘方简单地用是否做过自动化测试来过滤人才的话，也许会错过真正适合职位的测试人才。而测试人员如果单纯为博取一个名头而局限于第二种状态的话，对自身真正的自动化测试能力的提高也没有太多好处。 关于手工测试顺便说点，必须肯定手工测试对于一个测试人员成长的重要性，参与手工测试可以了解架构、熟悉产品、培养测试的感觉。测试感觉和思维，说起来貌似很浮云，但从事过测试的人应该很清楚，同样的一个测试任务，交给一个具有良好的测试感觉、思维缜密的人和交给一个把测试当成体力劳动的人会有什么样的产出差异。手工测试不应该只被等同为手工执行测试，其更重要的部分应该是测试的架构和用例设计。所有的测试执行都是以测试用例为基础，测试用例设计的好坏，对测试效率、测试覆盖率、defect发现几率产生直接影响。测试用例设计中会用到很多方法去优化和评估，涉及到离散数学、概率等领域知识的应用，是个挺值得下功夫的领域，对于一个手工测试人员的自我增值也是有帮助的。
作者：朱杉
链接：https://www.zhihu.com/question/19721142/answer/13327483
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
这两者不冲突，设计测试用例自然是最重要的，但是同等重要的还有贯彻执行这个测试用例。换句话说就是所谓执行力。在中国的很多 IT 企业，工作强度以及工作量远胜国外，所以你需要在短期内执行大量的测试案例，如果你只会手动测试，那么你很可能根本就没有时间把所有案例都测试一遍。手动测试员要么是把大部分的时间将消耗在执行测试案例，而非设计测试案例上，要么就是每轮都凭自己的经验判断而漏测很多点。而对于自动测试来说，测试的案例是日积月累的，测试过的案例在以后每轮测试中都被反复使用，你只需要专注与设计新的测试案例，而旧的测试案例已经进入了自动测试，它在每次迭代中都会被自动执行了，换句话说，自动测试的测试人员可以用更少的精力去执行测试，于是就可以把更多的精力放在设计测试案例上。这样，自动测试往往就可以意味着更好的测试案例设计。人的精力是有限的。无论对于自动测试还是手动测试人员，测试案例的设计都重要，他们只是在执行测试案例这个环节具有不同的技能而已。但对于迭代开发来说，一个软件如果你需要测试 50-100 次甚至更多的次数，自动测试凡是设计过一次的案例以后都可以直接执行，自动测试可以专注于新测试案例的开发以及实现，而手动测试每次都得手动执行以前设计过的所有案例，效率上明显降低，而且漏测的情况基本上难免。我个人觉得自动测试对中国的 IT 来说非常重要。至于国外是否重要我不清楚，如果一个测试人员一个星期就那点事情可做，有充分的足够的时间每次都手动执行所有案例，工作的时间压力很小，也许他是没有动力实施自动测试的，但这并不能成为手动测试比自动测试更优的论点跟理由。
作者：pansz
链接：https://www.zhihu.com/question/19721142/answer/16102001
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
