1、在国外，资深的软件测试人员大多是手动测试，他们厉害之处在于测试用例的设计，但在国内，很多测试人员都把自动化测试当成很厉害的资本，为什么？作为一名曾经的测试管理者，我也被问过无数次这类问题，我的看法很简单：1、无论是自动化测试还是手工测试，其核心永远是测试用例。无效的用例，用任何方法去测试，都不会达到良好的测试目的。2、自动化测试的目的是节约人力成本及时间成本，把枯燥的回归测试自动化起来，缩短项目周期。任何为了自动化测试而自动化的项目，都是耍流氓。3、我见过资深的测试人员，对业务，对行业的了解不亚于我这名产品经理，可以轻易指出设计中的不足以及逻辑盲点。也见过号称牛逼哄哄的自动化测试人员，连 TC
2、P 和 UDP 的都区分不来，遇到 WebService 就束手无策。企业需要各式各样的人才，自动化测试人员不比任何其他测试人员更高一等，大家只是分工不同。说点自己的不成熟看法。 将自动化测试当成很了不起的资本，源于国内对 Coding 的崇拜，譬如一个 Dev 跟一个 QA 放在一起，大家的第一直观印象就是前者的技术能力比较强。 实际上，这个问题分两面看： 1. 自动化测试能力是不是资本？ 是，当然是。测试自动化是软件测试的大方向。作为其核心组件的自动化测试的引入将 QA 从繁重的重复劳动中解放出来，完成靠人力难以组织的测试，优化测试资源，提高测试效率。优秀的自动化测试框架、完备的自动化测试
3、脚本集、丰富的自动化测试工具将使得测试的效率倍增，对产品质量保证起到积极作用。一个有自动化测试脚本、框架、工具开发能力的 QA，更有竞争力是一件无可厚非的事情。 从招聘方的角度看，就如同两台配置差不多的笔记本，一台多出俩 USB 口并有一个 HDMI，当然会优先选了，虽然他也不一定用得到。 2. 自动化测试人员一定强于手工测试人员？ 不一定。我接触过的自动化测试的 QA 大致有两种：其一，专职 automation，他们从进公司开始就定位为自动化测试人员，有的公司的 automation team 甚至都不隶属于测试团队，他们从进公司开始就几乎只接触脚本和工具，自动化的需求对于他们就等于一个开
4、发需求。这类的测试人员对产品本身了解并不多，且不深。更倾向于一个开发人员的工作方式。其二，既做手工，也写过一些自动化脚本。这一类人实际上仍然算是手工测试人员，但会小范围参与到一些简单脚本开发，多数是在已有的测试框架上进行的搭积木的工作，缺乏创新空间。对于这两类QA，前者因为很大程度上仍工作在一个 Dev 的模式下，可能存在的缺陷主要在测试的方法、感觉和思维方面，后者则完全可以作为一个手工测试人员去做横向比较。国内自动化测试的现状，使得投放入市场的自动化测试人员，以第二种类型的居多，且目前国内普遍的测试情况仍然是手工测试比例为重，所以如果招聘方简单地用是否做过自动化测试来过滤人才的话，也许会错过
5、真正适合职位的测试人才。而测试人员如果单纯为博取一个名头而局限于第二种状态的话，对自身真正的自动化测试能力的提高也没有太多好处。 关于手工测试顺便说点，必须肯定手工测试对于一个测试人员成长的重要性，参与手工测试可以了解架构、熟悉产品、培养测试的感觉。测试感觉和思维，说起来貌似很浮云，但从事过测试的人应该很清楚，同样的一个测试任务，交给一个具有良好的测试感觉、思维缜密的人和交给一个把测试当成体力劳动的人会有什么样的产出差异。手工测试不应该只被等同为手工执行测试，其更重要的部分应该是测试的架构和用例设计。所有的测试执行都是以测试用例为基础，测试用例设计的好坏，对测试效率、测试覆盖率、defect
6、发现几率产生直接影响。测试用例设计中会用到很多方法去优化和评估，涉及到离散数学、概率等领域知识的应用，是个挺值得下功夫的领域，对于一个手工测试人员的自我增值也是有帮助的。 不好意思。 。 。跑题了。一个个人单独拿到讨论没什么意义，看看公司吧。Google 的测试工程师有手工测试技能，但是肯定不是以手工测试为主的；Facebook 没有专职的测试工程师，也肯定不是以手工测试为主的；Microsoft 算是在软件测试方向上偏传统，而且建立测试队伍的念头足够长了，你猜他们是以手工测试为主吗？国内的软件测试行业是从 90 年后后期才开始真正发展起来的（记得我 98 年进入测试行业时，有测试团队的国内公
7、司都屈指可数） ，90 年代后期正好是自动化测试开始蓬勃发展的时候，从这一点上来说，国内的软件测试行业其实是站到了一个好的起点上（当然，由于缺乏积淀和对自动化测试的理解不足，很多企业内的所谓的自动化测试进行得并不顺利，这些故事有时候我可以给大家讲讲讲我的经历） 。测试的价值不在于体现测试工程师的厉害，也不在于通过发现缺陷寻求满足感。在我看来，测试的价值就和其他所有组织内的岗位一样，是看你能否为组织产生可见的价值。动不动就拉出两条线，国外：xxxxx，国内：xxxxx，这样的比较其实毫无意义，先不说国内测试方向做的好的企业虽少却不是没有，单说一点：测试在不产出被认可的价值时，如何能被公司和组织认
8、可？拥有手工测试技能，想要做一辈子手工测试，在国内并非不可能。只要你真的够牛 B，能够快速进入任何一个行业，能够搞出你的理论并能真正产生价值，我不相信你不会被接受（题外话，如果那位手工测试工程师能让我折服于你的技能，我保证给你不比任何开发工程师差的薪水） 。手工与自动化只是一种形式，真正的核心是测试用例、业务模型和测试分析。当企业的产品规模开始膨胀的时候，尤其是产品迭代加快是不是能及时得到测试验证支持是很重要的。这些靠手工测试是基本无法实现的，手工测试会严重的拖慢产品进度，而且无法保证全局质量。没有对覆盖率，测试分析等进一步的数据挖掘，一切深入的问题也无法被手工测试人员发现。手工测试与简单的操
9、作自动化只是测试的初级阶段，将来也许会有云测试与智能化测试，大数据测试，这些新的测试手段都是围绕测试用例，业务模型与测试分析来做的。没有良好的coding 能力，就无法发挥电脑的潜能，也无法做更深入的数据挖掘。目前的很多公司的测试是有问题的。大部分的自动化测试的问题是成本高，只是简单的 check，没有绑定覆盖率，没有做测试建模、盲目的追求 case 数量，自动化分层不合理，ui 自动化测试比重太大，导致作用有限。而手工测试也是只覆盖基本的业务，根本不了解细节上的风险。bug 不仅仅是因为需求和业务引起的，还可能由设计，架构，代码以及操作系统特性引起的。而且测试人员的执行是否到位也是值得考察的
10、。我在阿里百度都遇到过手工测试人员因为工期紧张，用例太多，草草结束测试的事情。所以，手工测试重要，但是不能重点依靠。自动化能够提供全局的把控和质量验证，价值还是很可观的。而做好自动化还需要更多的深入的工作。毫不讳言，我们整个国内还没有几家公司能真正做到测试建模，目前只是做到了最基础的测试用例+自动化+覆盖率而已。对于手工测试，我举个最简单的例子，百度的一些产品，需要在 chrome 浏览器，firefox 浏览器，ie6/7/8/9，360 浏览器，搜狗高速浏览器上做测试。如果开发只修改了几行代码，在不依赖新测试模式，新技术和自动化的情况下，只靠手工测试，几乎是不能避免 bug 的。在银行，金
11、融，国企，以及传统企业里面，经常会看到工作了七八年的手工测试人员，而且他们的产品更新很慢，体验很差。而在互联网里面，则很少看到，但是互联网的产品体验要比传统企业优秀的多。不可否认，手工测试里面有不少高手，但是缺乏了自动化，缺乏了大数据分析，缺乏了测试建模，将很难为产品线带来更多的价值。所以自动化是很重要的资本。只是整个行业，懂业务，懂测试，懂开发的人太少了。大多数的人，都是其中的两者结合体。1. 国内大多数的互联网公司，还是有一条鄙视链的，其中一条就是做开发的鄙视做测试的。我遇到很多人，包括面试过的候选人，以及见过的部分管理者，对于测试这份工作发自肺腑的鄙视都是掩饰不住的。2.你去问一些测试同
12、行，你为什么选择做测试，有些人就会说，呃，我编程不行，又想做互联网行业，测试好入门啊。3.跟任何一个工种一样，测试的分布大概也是个金字塔，下面聚集着一大帮的底层纯执行人员，流水一样的来，流水一样的走。愿意往上走的人不多，能好好走的人就更少了。4.做事的思路、思考问题的角度、设计方案的制定，有些人不觉得这些也是重要的技术，会写几个方法和函数，感觉就牛逼的不得了了。5.如果一定要跟国外比的话，嗯，国内的压力确实也要大很多，人力的压力、薪酬的压力、产品迭代的 压力，甚至加班的压力（估计着） ，可能也是个原因吧。在中国的很多 IT 企业，工作强度以及工作量远胜国外，所以你需要在短期内执行大量的测试案例
13、，如果你只会手动测试，那么你很可能根本就没有时间把所有案例都测试一遍。手动测试员要么是把大部分的时间将消耗在执行测试案例，而非设计测试案例上，要么就是每轮都凭自己的经验判断而漏测很多点。而对于自动测试来说，测试的案例是日积月累的，测试过的案例在以后每轮测试中都被反复使用，你只需要专注与设计新的测试案例，而旧的测试案例已经进入了自动测试，它在每次迭代中都会被自动执行了，换句话说，自动测试的测试人员可以用更少的精力去执行测试，于是就可以把更多的精力放在设计测试案例上。这样，自动测试往往就可以意味着更好的测试案例设计。人的精力是有限的。无论对于自动测试还是手动测试人员，测试案例的设计都重要，他们只是
14、在执行测试案例这个环节具有不同的技能而已。但对于迭代开发来说，一个软件如果你需要测试 50-100 次甚至更多的次数，自动测试凡是设计过一次的案例以后都可以直接执行，自动测试可以专注于新测试案例的开发以及实现，而手动测试每次都得手动执行以前设计过的所有案例，效率上明显降低，而且漏测的情况基本上难免。我个人觉得自动测试对中国的 IT 来说非常重要。至于国外是否重要我不清楚，如果一个测试人员一个星期就那点事情可做，有充分的足够的时间每次都手动执行所有案例，工作的时间压力很小，也许他是没有动力实施自动测试的，但这并不能成为手动测试比自动测试更优的论点跟理由。自动化测试和手动测试都是不可缺少的，两者相
15、辅相成，简单说说我对自动化测试和手动测试的体会：首先，我认为自动化测试的主要目的并不是为了发现产品的 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。 我始终认为最好的测试是将软件缺陷消灭在摇篮里，测试的根基、金字塔的
16、底座是独立的单元测试，由开发人员负责，可以最小成本的发现潜在的 BUG，也就是说 DEV 是最好的 QA。自动化测试和持续集成是重要的手段，确保对产品质量的可控性。 版本控制软件也非常重要。极大提高我们的工作效率简单所以下我工作的情况：之前在 BlackBerry Enterprise Service 实习，负责 BES 产品发布之前的测试，BES 是面向企业的产品，产品质量和稳定性是产品赖以生存的根本，因为我们非常重视软件测试。我的主要工作是以手动测试和 fix verification 为主，不和产品代码打交道。可以说虽然是发布前最后一关，但依然发现很多产品中 BUG， 任何一个 BUG
17、都直接影响客户体验。由于各种限制，手动测试不可能覆盖产品所有方面，因此对产品的了解、丰富的测试经验、制定详细的测试用例对于手动测试非常重要， 也是考察一个手动测试工程师主要的方面。对产品的了解可以更容易找到产品的薄弱环节；丰富的测试经验可以更快的发现 BUG；而详细的测试计划可以帮助我们发现更多的 BUG。我认为手动测试发现了产品中的大部分 BUG。目前我在一家北美某游戏公司温哥华分舵，team 主要是负责为公司大部分游戏提供 online service,游戏整合 online service SDK 使其与 server 交互。 简单说说 QA team 的情况，一个senior dev
18、负责开发和维护测试框架，两个 senior QA 带一群 QA，还有一个做 build 系统的。我们的日常工作基本属于自动化测试，手动测试可能交给有游戏 TEAM 了吧。由于产品太复杂、公司没钱等一系列因素，还未实现完全的持续集成，基本上还在依靠 nightly regression，因此还是以天为单位，而不是以敏捷测试中每次 code checkin 为单位。更可恶的事情是 xbox, ps的自动化测试还没有整合到 build 系统里，所以本屌丝要经常要手动 load 测试程序。 吐槽一些对现在工作中的感悟：1、大家都知道，用 c+写的产品编译时间都非常长，即使我们有 incredibuil
19、d 这种 NB 的TOOL, build 一次完整的产品和自动化测试的工具也要半小时左右，如果产品或者测试工具出现以下编译错误就会 BLOCK 所有的工作。产品坏了我们可以 revert，但是测试工具坏了有可能是产品 code 改变，或者是工具本身的问题。 investigate 要花时间，fix 也花时间。这一点非常影响工作效率。2、不是说自动化测试就不会发现 BUG，每次回归测试结果都一堆错误。但重点是！你要花时间分析到底是测试用例的问题，测试框架的问题，还是真是产品的 BUG， 每天看Log 简直把眼睛都看瞎了。3、自动化测试用例不是一层不变，产品 feature 变了，测试用例要改变。
20、很多时候测试用例fail 了，很有可能是测试用例没有更新。4、我认为我们目前最重要的问题是 DEV 没有写单元测试的习惯！所以自动化测试系统并非神器，它非常娇贵的，你要花时间是维护它、呵护它、关爱它，它才是成为你手中的利器。最后，简单说一下招聘过程。 虽然我们的工作是 QA，但面试的基本内容是 C+的概念、算法、编码能力。仅仅会问一些简单的测试概念。这也从一个侧面反映出 QA 不要懂产品逻辑，还要懂产品代码！PS：深感国内软件测试发展的不成熟，以后回国可咋找工作啊，好了不吐槽了，第一次回答问题，流水账请见谅，洗洗睡吧，明天继续上班。现在对测试人员的开发技术能力要求越来越高了，互联网时代全面到来
21、一个影响吧。（1）提高测试效率，缩短上线响应时间的需要；（2）测试对象复杂，理解设计和业务场景的需要；（3）解决不可测问题的需要；其实测试人员是做测试的程序员，这个是不是会得到大家的认可呢？我觉得现在好像还没有，慢慢的会明白，测试人员就是做测试的程序员，本质上面也是开发工程师过了四年重新回来理解这个话题甭管自动化、性能、安全、黑盒还是神马的，都要理解业务逻辑、了解被测对象，都是为产品服务的，都是可以掌握的技能。我想这个问题很显而易见：1，我现在工作的公司是纯正的 IT 技术型企业，说白了 Coding 技术是王道，因此-a) 公司的小领导，领导的领导基本上都是开发出生（Coding 被重视）因
22、此-领导会提拔，喜爱技术牛 B 的测试或者开发人员。不怎么懂 coding 的测试人员只能被鄙视。结论：所以大家都去钻研技术，钻研自动化测试2. 我绝对属于不懂技术，手工测试成长起来的人员，在我测试的很多产品里里面，通过手工测试，设计了一些非常精妙的测试用例，从而发现了 bug，但是我手工测试能力不会得到领导的认可，衡量我测试水平的标准也不是基于我发现一些奇怪但是重要的 bug。我对产品的了解，设计用例的发散思维和能力无法被具象衡量，而搭建自动化测试框架以及编写自动化测试脚本是多么具象的能力啊。因此，我每天也在研究自动化测试，对于手工测试我也从心底厌恶，反正手工测了，测出来bug 也没人认可，
23、大家都觉得手工测试很简单，很傻。结论：手工测试的设计测试用例的能力真不好衡量，但是写脚本写代码的能力确实直观好衡量的，在崇尚技术的公司更是如此，所以我要学习代码。P.S. 能告诉你们，我是学英语出生的吗，个中辛酸苦辣只有自己知道。另外，补充一下，一些逻辑非常复杂的 senario（非常规业务流程）很难用自动化脚本实现，因为太费时费力了，用手工测试来执行一些奇葩的 senario 更灵活方便可以发现很多问题。另外表态一下，手工和自动化缺一不可，手工是基础，自动化是锦上添花，等待产品稳定之后需要添加自动化。测试最重要的还是对系统以及需求的理解吧。至于是不是自动化，更多是取决于产品的生命有多长，以及
24、自动化后成本有没有减少。 关于对系统以及需求的理解，这个是测试工程师最基本的要求，但是很多测试工程师现在都只是知道怎么跑 case，把自己变成一个自动化测试脚本，而不是去理解整个系统。好比你搞 web测试，只是测那些页面跳转会如何之类的，那基本上测不出什么 bug 来的。即便能测出，也不过是运气问题。但是如果你理解了后台和前台的交互，有哪些数据，哪些地方可能会溢出之类的，那会更容易找到 bug。 对需求的理解，也是很重要的，我见过做性能测试，有些测试工程师不理解产品需要的开机时间是多少，觉得反正没有具体的要求就没所谓。而有些则觉得很重要，拼命提 CQ 要求修改的。最后在客户验证的时候，发现后者
25、的理解是正确的。这些很模糊的东西，更多需要个人理解才可以获得。或者说，这叫经验。 自动化测试的目的更多是减少测试时间，把更多的时间放在设计用例，以及理解需求和系统的阶段上。但是如果做一个以后都不会再做的产品，还开发了一堆自动化测试的脚本，并且在软件里面写了一堆 log，那基本上是费时费力却得不到任何实质上的帮助，因为开发这堆脚本和log 的时间，已经够测试几轮了。 国内对自动化测试的向往，无非是因为国内测试人员玩的都是苦力活，而不是技术活。你随便找一个测试的，你问他对系统了解多少，多半是只会执行 case 的人而已。甚至乎，这些人在完成了任务之后，基本上就不再学习了。-分割一下，一些内容和题目
26、有关系，但是不是太大。写得也很乱。-近年来国外有个叫做 SBMT(Session based test management)的东西，建议大家看看。有条件的公司建议实行一下。这种测试方法严格得区分开了 checking 跟 testing，对测试人员的要求很高。并且 SBMT 里面不存在固定的所谓的测试用例。现存的测试用例的测试方法是按照 ieee 以及几本一九七几年写的老书确立起来的，虽然名曰为Best Practice，但是实际上是效率很低的。因为一个测试用例测过几遍之后，其信息量几乎为0。根据信息论，越确定的东西，其信息量越低。我实在搞不懂一个 check 了几百遍都没问题的东西为啥要用
27、人来 check 而不用机器来 check。严格意义上来讲，自动化测试应该叫做自动化检查。它只是 checking 而已。什么叫做checking？checking 就是按照需求文档一条条打勾。什么叫做 testing？testing 就是探索产品本身的结构以及分析产品可能的问题。SBMT 是通过认知论的方法，触发测试人员的思考，让测试人员自己去了解系统。一般 SBMT 会有一个 charter(即要测的功能)，几个 Mission（想要达到的目标）和一份 note。格式如下：Charter:To test WORDMission:1. To find out memory leak scen
28、ario in word.2. To find out several boundary values of word. Note:1. I blah blah.通过 Mission，一般测试人员需要为了达到这个目标而想一些测试用例，而这些测试用例的建立则不得不依赖于思考，而不是之前已经写好的脚本。测试人员必须把自己的思考和测试步骤写成 Note。当然这也解决了测试工作无聊的这个事实。另外，testing 的本质目的只是提供产品的信息而已，是一个“辅助”功能，不是一个生产功能。产品的质量完全不能通过 testing 来保证，所以才需要用到工具和流程，这才是测试需要进化的方向：想办法给工具和流程
29、提意见，改进（或创造）有利的工具和流程，把测试本身提供的信息 Build 进产品里面去。测试这个职业，这几十年来几乎没有啥进步，所有提升软件质量的方法都是 dev 提出来的。如果测试工程师再不把自己的 testing build into code，我感觉这个职业很快会被 dev 或者某些工具所兼顾，平均薪水会越来越低（现在已经不高了） 。说到手工测试，大家脑子里浮现出一副测试人员点页面的场景，感觉很没有技术含量，实际上我们所轻视的只是不看代码，不分析场景的测试方式，但已习惯采用简单粗暴的是自动化还是手工来区分测试人员水平高低。当然想想你们公司的开发是不是整天忙着写代码，写完也不自测丢给测试去
30、测，本来 coding 和 test 是紧密联系起来的过程，程序员需要有开发能力也要有测试意识，测试人员负责测试也需要有相等的技术能力，但结果呢，大家变成了蜜蜂，有的人只负责采蜜，有的人负责交配，完全割裂开来了，于是同样是程序员便有了高低贵贱国外的测试人员更趋向于回答如何消除 bug，如何提高测试效率这个核心问题，采用手工或者自动化只是可采用的方式之一，像 whittaker 大牛的探索性软件测试 ，介绍了探索性测试的思想，而实践上更偏向手工测试，而另外一本书说了测试人员可以将测试思想融入测试工具提供给开发。在个人实践中，手工测试和自动化需要采用哪种是权衡以后的结果，手工测试很灵活，而会写代码
31、，能够用自动化测试也是一件很幸福的事，这让测试人员有了更多的测试方法和选择的余地，如果有个测试点，但手工测试很麻烦或异常模拟不出，这件事是不是很痛苦？如果自动化跑一遍用例只要半小时，而手动跑一遍要半天，这件事是不是很痛苦？手工测试被人吐槽为低效、低技术含量，然后自动化是否就是银弹了呢。用例生成的自动化，用例执行的自动化，结果判断的自动化，大家口口声声所说用上了 nx 的自动化是完全实现了自动化呢，还是只实现了其中的部分，在实现的过程中投入和产出是否合理（开发平台和维护用例的成本其实蛮高的，我已经被开发上特性搞得监控用例挂掉弄的烦死了）最后，我觉得很多人对于测试的理解并不深（包括我自己） ，身边
32、的不少人对测试抱有轻视或悲观的态度，测试不会死，但测试人员的确需要改变80%的 bug 是通过手工测试发现的。 。这点应该不可否认。 。自动化测试不是发现 bug 的过程。而是证明之前提交的 bug 已经修改。 。并且没有引入新的 bug。 。而测试工程师是做什么的。测试工程师是为了发现 bug 的存在。 。所以孰轻孰重很显而易见了。 。再者自动化测试要消耗的人力时间成本较手工测试多的多的多。 。投入(自动化脚本编辑) 高产出(发现的 bug 数量)少。 。单凭自动化测试工程师听着比手工测试工程师名号帅气多了。 。而争着戴自动化测试的帽子。 。很可笑手动或自动测试只是方法，关乎效率和覆盖面；而测试用例的设计是核心，决定是否能发现设计或者实现上的缺陷。根本不是一个层面的东西吧，没法放在一起比较。更深层次的问题是测试工程师的资深、厉害与否更在于对系统内在的理解，用户使用场景的认识，这和测试方法没有多少关系。
