说三道四技术文摘-感悟人生的经典句子
> 文档快照
我比较赞同前者软件测试自动化测试测试工程师开发与测试朱杉，软件测试豆瓣潜水员说点自己的不成熟看法。将自动化测试当成很了不起的资本，源于国内对Coding的崇拜，譬如一个Dev跟一个QA放在一起，大家的第一直观印象就是——前者的技术能力比较强。实际上，这个问题分两面看：1.自动化测试能力是不是资本？是，当然是。测试自动化
我比较赞同前者 软件测试自动化测试测试工程师开发与测试朱杉，软件测试 豆瓣潜水员说点自己的不成熟看法。
将自动化测试当成很了不起的资本，源于国内对Coding的崇拜，譬如一个Dev跟一个QA放在一起，大家的第一直观印象就是——前者的技术能力比较强。
实际上，这个问题分两面看：
1. 自动化测试能力是不是资本？
是，当然是。测试自动化是软件测试的大方向。作为其核心组件的自动化测试的引入将QA从繁重的重复劳动中解放出来，完成靠人力难以组织的测试，优化测试资源，提高测试效率。优秀的自动化测试框架、完备的自动化测试脚本集、丰富的自动化测试工具将使得测试的效率倍增，对产品质量保证起到积极作用。一个有自动化测试脚本、框架、工具开发能力的QA，更有竞争力是一件无可厚非的事情。 从招聘方的角度看，就如同两台配置差不多的笔记本，一台多出俩USB口并有一个HDMI，当然会优先选了，虽然他也不一定用得到。
2. 自动化测试人员一定强于手工测试人员？
不一定。我接触过的自动化测试的QA大致有两种：其一，专职automation，他们从进公司开始就定位为自动化测试人员，有的公司的automation team甚至都不隶属于测试团队，他们从进公司开始就几乎只接触脚本和工具，自动化的需求对于他们就等于一个开发需求。这类的测试人员对产品本身了解并不多，且不深。更倾向于一个开发人员的工作方式。其二，既做手工，也写过一些自动化脚本。这一类人实际上仍然算是手工测试人员，但会小范围参与到一些简单脚本开发，多数是在已有的测试框架上进行的搭积木的工作，缺乏创新空间。对于这两类QA，前者因为很大程度上仍工作在一个Dev的模式下，可能存在的缺陷主要在测试的方法、感觉和思维方面，后者则完全可以作为一个手工测试人员去做横向比较。国内自动化测试的现状，使得投放入市场的自动化测试人员，以第二种类型的居多，且目前国内普遍的测试情况仍然是手工测试比例为重，所以如果招聘方简单地用是否做过自动化测试来过滤人才的话，也许会错过真正适合职位的测试人才。而测试人员如果单纯为博取一个名头而局限于第二种状态的话，对自身真正的自动化测试能力的提高也没有太多好处。
关于手工测试顺便说点，必须肯定手工测试对于一个测试人员成长的重要性，参与手工测试可以了解架构、熟悉产品、培养测试的感觉。测试感觉和思维，说起来貌似很浮云，但从事过测试的人应该很清楚，同样的一个测试任务，交给一个具有良好的测试感觉、思维缜密的人和交给一个把测试当成体力劳动的人会有什么样的产出差异。手工测试不应该只被等同为手工执行测试，其更重要的部分应该是测试的架构和用例设计。所有的测试执行都是以测试用例为基础，测试用例设计的好坏，对测试效率、测试覆盖率、defect发现几率产生直接影响。测试用例设计中会用到很多方法去优化和评估，涉及到离散数学、概率等领域知识的应用，是个挺值得下功夫的领域，对于一个手工测试人员的自我增值也是有帮助的。
不好意思。。。跑题了。。。天顺，产品经理作为一名曾经的测试管理者，我也被问过无数次这类问题，我的看法很简单：1、无论是自动化测试还是手工测试，其核心永远是测试用例。无效的用例，用任何方法去测试，都不会达到良好的测试目的。2、自动化测试的目的是节约人力成本及时间成本，把枯燥的回归测试自动化起来，缩短项目周期。任何为了自动化测试而自动化的项目，都是耍流氓。3、我见过资深的测试人员，对业务，对行业的了解不亚于我这名产品经理，可以轻易指出设计中的不足以及逻辑盲点。也见过号称牛逼哄哄的自动化测试人员，连TCP和UDP的都区分不来，遇到WebService就束手无策。企业需要各式各样的人才，自动化测试人员不比任何其他测试人员更高一等，大家只是分工不同。段念，工程师这个问题也能上升到“国家的浮躁”和“个人的浮躁”，我对此深表佩服。先从问题说起吧。“在国外，资深的软件测试人员大多是手动测试”这句话的描述就非常有意思。怎么定义“资深”？如果说“资深”是指工作年限长，在社区混的脸熟的人，那这种情况再正常不过了。国外的软件测试起步比国内早的多，自动化测试是90年代以后才真正开始逐步成熟，那些年限长的，混得脸熟的自然是早早进入这个行业，并以手工测试为主的人。当然，各种测试的认证机构和组织的惯性自然也为这一情景贡献了力量。要说到测试这个行业的知名人士，James Whittaker算吧，你觉得他是“以手工测试为主”吗？别因为他写了本《探索式测试》就认为他只懂手工测试。Google的Copeland算吧，同样，你肯定没法断言他只会做手工测试。一个个人单独拿到讨论没什么意义，看看公司吧。Google的测试工程师有手工测试技能，但是肯定不是以手工测试为主的；Facebook没有专职的测试工程师，也肯定不是以手工测试为主的；Microsoft算是在软件测试方向上偏传统，而且建立测试队伍的念头足够长了，你猜他们是以手工测试为主吗？国内的软件测试行业是从90年后后期才开始真正发展起来的（记得我98年进入测试行业时，有测试团队的国内公司都屈指可数），90年代后期正好是自动化测试开始蓬勃发展的时候，从这一点上来说，国内的软件测试行业其实是站到了一个好的起点上（当然，由于缺乏积淀和对自动化测试的理解不足，很多企业内的所谓的自动化测试进行得并不顺利，这些故事有时候我可以给大家讲讲讲我的经历）。测试的价值不在于体现测试工程师的厉害，也不在于通过发现缺陷寻求满足感。在我看来，测试的价值就和其他所有组织内的岗位一样，是看你能否为组织产生可见的价值。动不动就拉出两条线，国外：xxxxx，国内：xxxxx，这样的比较其实毫无意义，先不说国内测试方向做的好的企业虽少却不是没有，单说一点：测试在不产出被认可的价值时，如何能被公司和组织认可？拥有手工测试技能，想要做一辈子手工测试，在国内并非不可能。只要你真的够牛B，能够快速进入任何一个行业，能够搞出你的理论并能真正产生价值，我不相信你不会被接受（题外话，如果那位手工测试工程师能让我折服于你的技能，我保证给你不比任何开发工程师差的薪水）。怨天尤人没有用，路是自己选的，大回报需要大投入，大投入未必能产生大回报。这不决定于环境，只决定于你能不能让自己的努力产生被人认可的回报。vczh，专业造轮子，资深汕头人。github id: vczh这跟好的程序员都因为自己代码写的好而觉得自己好，而不好的程序员要装B都得说“我用了xyz所以我牛逼”的事情我觉得是完全一致的……至于说测试这个事情，为什么国内跟国外差距太明显，说白了就是因为我们穷啊。dev和test需要的人数和花的时间是差不多的，如果他们不肯付出双倍代价，自然就没有什么人给他【安心】做自动化测试了。自动化测试是需要积累的，不是一个项目要上就上，另一个项目重头来的。叶赫华，IT职业规划师关于软件性能测试这个工作以及发展方向，这里有个优酷视频，讲软件性能测试的发展趋势的，应该对了解和进一步提高性能测试技能和方向有所帮助，可以看看：
【道E轩-第17集】软件性能测试职业发展趋势（上）
/v_show/id_XOTMyNjEzNjQw.html
黄延胜，测试架构师手工与自动化只是一种形式，真正的核心是测试用例、业务模型和测试分析。当企业的产品规模开始膨胀的时候，尤其是产品迭代加快是不是能及时得到测试验证支持是很重要的。这些靠手工测试是基本无法实现的，手工测试会严重的拖慢产品进度，而且无法保证全局质量。没有对覆盖率，测试分析等进一步的数据挖掘，一切深入的问题也无法被手工测试人员发现。手工测试与简单的操作自动化只是测试的初级阶段，将来也许会有云测试与智能化测试，大数据测试，这些新的测试手段都是围绕测试用例，业务模型与测试分析来做的。没有良好的coding能力，就无法发挥电脑的潜能，也无法做更深入的数据挖掘。目前的很多公司的测试是有问题的。大部分的自动化测试的问题是成本高，只是简单的check，没有绑定覆盖率，没有做测试建模、盲目的追求case数量，自动化分层不合理，ui自动化测试比重太大，导致作用有限。而手工测试也是只覆盖基本的业务，根本不了解细节上的风险。bug不仅仅是因为需求和业务引起的，还可能由设计，架构，代码以及操作系统特性引起的。而且测试人员的执行是否到位也是值得考察的。我在阿里百度都遇到过手工测试人员因为工期紧张，用例太多，草草结束测试的事情。所以，手工测试重要，但是不能重点依靠。自动化能够提供全局的把控和质量验证，价值还是很可观的。而做好自动化还需要更多的深入的工作。毫不讳言，我们整个国内还没有几家公司能真正做到测试建模，目前只是做到了最基础的测试用例+自动化+覆盖率而已。对于手工测试，我举个最简单的例子，百度的一些产品，需要在chrome浏览器，firefox浏览器，ie6/7/8/9，360浏览器，搜狗高速浏览器上做测试。如果开发只修改了几行代码，在不依赖新测试模式，新技术和自动化的情况下，只靠手工测试，几乎是不能避免bug的。在银行，金融，国企，以及传统企业里面，经常会看到工作了七八年的手工测试人员，而且他们的产品更新很慢，体验很差。而在互联网里面，则很少看到，但是互联网的产品体验要比传统企业优秀的多。不可否认，手工测试里面有不少高手，但是缺乏了自动化，缺乏了大数据分析，缺乏了测试建模，将很难为产品线带来更多的价值。所以自动化是很重要的资本。只是整个行业，懂业务，懂测试，懂开发的人太少了。大多数的人，都是其中的两者结合体。陈晔，测试业界打杂第一人这个其实很正常。国内国外国情不同。我举几个例子打假就知道了。国外：可以有很多钻研软件测试直到60,70岁的。他们善于钻研软件设计，善于总结，并且能够最终能够发布一套自己领悟出来的设计方法。并造福于各个个人，企业，领域。国内：对于软件测试的认知的错误，越来越多的年轻人涌入这个圈子。但是结果就是做了2,3年开始转管理，或者打退堂鼓。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－国外：国家，企业，个人大部分能够清楚的认识到测试的根本价值在于何处，能够满足dev，test最基本的温饱，从而让大家更自由的，更发散的进行思考问题国内：国家，企业，个人大部分就不知道软件测试是干嘛的，价值在哪里。并且薪资也不能满足最基本的温饱，大家都是为了工作，为了钱而去学习，去奋斗。根本就没有人生可言。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－开发学习代码是为了更好的做好产品，调整性能。测试学习代码不是为了去写产品，不是为了去和开发比或者为了体现自己多少的厉害。测试学习代码的本质在于更好的理解产品，理解逻辑，然后能够深入的去设计case。我一直强调，你去测试一个东西，你不了解业务，不了解产品。如何进行测试呢？一个产品不是你肉眼看到的所有就代表你知道怎么去测试了！总而言之，国家的浮躁带动了个人的浮躁，个人的浮躁推动了国家的浮躁。这个国家就是中国知乎用户，@网易有道，测试管理。1.国内大多数的互联网公司，还是有一条鄙视链的，其中一条就是做开发的鄙视做测试的。我遇到很多人，包括面试过的候选人，以及见过的部分管理者，对于测试这份工作发自肺腑的鄙视都是掩饰不住的。2.你去问一些测试同行，你为什么选择做测试，有些人就会说，呃，我编程不行，又想做互联网行业，测试好入门啊。3.跟任何一个工种一样，测试的分布大概也是个金字塔，下面聚集着一大帮的底层纯执行人员，流水一样的来，流水一样的走。愿意往上走的人不多，能好好走的人就更少了。4.做事的思路、思考问题的角度、设计方案的制定，有些人不觉得这些也是重要的技术，会写几个方法和函数，感觉就牛逼的不得了了。5.如果一定要跟国外比的话，嗯，国内的压力确实也要大很多，人力的压力、薪酬的压力、产品迭代的 压力，甚至加班的压力（估计着），可能也是个原因吧。pansz，欢迎评论这两者不冲突，设计测试用例自然是最重要的，但是同等重要的还有贯彻执行这个测试用例。换句话说就是所谓执行力。在中国的很多 IT 企业，工作强度以及工作量远胜国外，所以你需要在短期内执行大量的测试案例，如果你只会手动测试，那么你很可能根本就没有时间把所有案例都测试一遍。手动测试员要么是把大部分的时间将消耗在执行测试案例，而非设计测试案例上，要么就是每轮都凭自己的经验判断而漏测很多点。而对于自动测试来说，测试的案例是日积月累的，测试过的案例在以后每轮测试中都被反复使用，你只需要专注与设计新的测试案例，而旧的测试案例已经进入了自动测试，它在每次迭代中都会被自动执行了，换句话说，自动测试的测试人员可以用更少的精力去执行测试，于是就可以把更多的精力放在设计测试案例上。这样，自动测试往往就可以意味着更好的测试案例设计。人的精力是有限的。无论对于自动测试还是手动测试人员，测试案例的设计都重要，他们只是在执行测试案例这个环节具有不同的技能而已。但对于迭代开发来说，一个软件如果你需要测试 50-100 次甚至更多的次数，自动测试凡是设计过一次的案例以后都可以直接执行，自动测试可以专注于新测试案例的开发以及实现，而手动测试每次都得手动执行以前设计过的所有案例，效率上明显降低，而且漏测的情况基本上难免。我个人觉得自动测试对中国的 IT 来说非常重要。至于国外是否重要我不清楚，如果一个测试人员一个星期就那点事情可做，有充分的足够的时间每次都手动执行所有案例，工作的时间压力很小，也许他是没有动力实施自动测试的，但这并不能成为手动测试比自动测试更优的论点跟理由。金阳，安安静静的写代码自动化测试和手动测试都是不可缺少的，两者相辅相成，简单说说我对自动化测试和手动测试的体会：首先，我认为自动化测试的主要目的并不是为了发现产品的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不要懂产品逻辑，还要懂产品代码！PS：深感国内软件测试发展的不成熟，以后回国可咋找工作啊，好了不吐槽了，第一次回答问题，流水账请见谅，洗洗睡吧，明天继续上班。知乎用户，互联网搜索引擎现在对测试人员的开发技术能力要求越来越高了，互联网时代全面到来一个影响吧。（1）提高测试效率，缩短上线响应时间的需要；（2）测试对象复杂，理解设计和业务场景的需要；（3）解决不可测问题的需要；其实测试人员是做测试的程序员，这个是不是会得到大家的认可呢？我觉得现在好像还没有，慢慢的会明白，测试人员就是做测试的程序员，本质上面也是开发工程师PennyCao，摆放强迫症和选择恐惧症患者...。。。maxSonic，专职是黑测试，副业是做开发测试最重要的还是对系统以及需求的理解吧。至于是不是自动化，更多是取决于产品的生命有多长，以及自动化后成本有没有减少。
关于对系统以及需求的理解，这个是测试工程师最基本的要求，但是很多测试工程师现在都只是知道怎么跑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或者某些工具所兼顾，平均薪水会越来越低（现在已经不高了）。opama，i am just going down说到手工测试，大家脑子里浮现出一副测试人员点页面的场景，感觉很没有技术含量，实际上我们所轻视的只是不看代码，不分析场景的测试方式，但已习惯采用简单粗暴的是自动化还是手工来区分测试人员水平高低。当然想想你们公司的开发是不是整天忙着写代码，写完也不自测丢给测试去测，本来coding和test是紧密联系起来的过程，程序员需要有开发能力也要有测试意识，测试人员负责测试也需要有相等的技术能力，但结果呢，大家变成了蜜蜂，有的人只负责采蜜，有的人负责交配，完全割裂开来了，于是同样是程序员便有了高低贵贱
国外的测试人员更趋向于回答如何消除bug，如何提高测试效率这个核心问题，采用手工或者自动化只是可采用的方式之一，像whittaker大牛的《探索性软件测试》，介绍了探索性测试的思想，而实践上更偏向手工测试，而另外一本书说了测试人员可以将测试思想融入测试工具提供给开发。在个人实践中，手工测试和自动化需要采用哪种是权衡以后的结果，手工测试很灵活，而会写代码，能够用自动化测试也是一件很幸福的事，这让测试人员有了更多的测试方法和选择的余地，如果有个测试点，但手工测试很麻烦或异常模拟不出，这件事是不是很痛苦？如果自动化跑一遍用例只要半小时，而手动跑一遍要半天，这件事是不是很痛苦？
手工测试被人吐槽为低效、低技术含量，然后自动化是否就是银弹了呢。用例生成的自动化，用例执行的自动化，结果判断的自动化，大家口口声声所说用上了nx的自动化是完全实现了自动化呢，还是只实现了其中的部分，在实现的过程中投入和产出是否合理（开发平台和维护用例的成本其实蛮高的，我已经被开发上特性搞得监控用例挂掉弄的烦死了）
最后，我觉得很多人对于测试的理解并不深（包括我自己），身边的不少人对测试抱有轻视或悲观的态度，测试不会死，但测试人员的确需要改变大魔头-诺铁，软件手艺人，诺铁@新浪微博，ThoughtWork…一般来说物以稀为贵，相对于只会重复点点鼠标的测试人员来说，会写自动化测试的是较少的，所以贵。至于你说的那种资深测试，就好比西游记里的人参果，稀到没有了，就成神话了徐新伟，保持好奇心,你关注现实的能力就会有所改善首先，如果真的有人像问题描述的那样“认为自动化测试技高一筹”，只能说明，那个人是测试外行。至于测试工作，个人觉得，其实无外乎两点，测试的质量和测试的效率，测试质量主要靠测试用例来保证，而测试的效率可以通过自动化来提高。所以，最后的问题是，如果没有了质量，追求效率有意义么？匿名用户作为测试人员，从业6-7年，我第一次有冲动想回答一下这个问题，也和大家做个探讨。我想这个问题很显而易见：1，我现在工作的公司是纯正的IT技术型企业，说白了Coding技术是王道，因此--》
a) 公司的小领导，领导的领导基本上都是开发出生（Coding被重视）
领导会提拔，喜爱技术牛B的测试或者开发人员。不怎么懂coding的测试人员只能被鄙视。
结论：所以大家都去钻研技术，钻研自动化测试2. 我绝对属于不懂技术，手工测试成长起来的人员，在我测试的很多产品里里面，通过手工测试，设计了一些非常精妙的测试用例，从而发现了bug，但是我手工测试能力不会得到领导的认可，衡量我测试水平的标准也不是基于我发现一些奇怪但是重要的bug。
我对产品的了解，设计用例的发散思维和能力无法被具象衡量，而搭建自动化测试框架以及编写自动化测试脚本是多么具象的能力啊。
因此，我每天也在研究自动化测试，对于手工测试我也从心底厌恶，反正手工测了，测出来bug也没人认可，大家都觉得手工测试很简单，很傻。结论：手工测试的设计测试用例的能力真不好衡量，但是写脚本写代码的能力确实直观好衡量的，在崇尚技术的公司更是如此，所以我要学习代码。P.S. 能告诉你们，我是学英语出生的吗，个中辛酸苦辣只有自己知道。另外，补充一下，一些逻辑非常复杂的senario（非常规业务流程）很难用自动化脚本实现，因为太费时费力了，用手工测试来执行一些奇葩的senario更灵活方便可以发现很多问题。另外表态一下，手工和自动化缺一不可，手工是基础，自动化是锦上添花，等待产品稳定之后需要添加自动化。白云，生活就是一种简单，心静了就平和了。。80%的bug是通过手工测试发现的。。这点应该不可否认。。自动化测试不是发现bug的过程。。而是证明之前提交的bug已经修改。。并且没有引入新的bug。。而测试工程师是做什么的。。测试工程师是为了发现bug的存在。。所以孰轻孰重很显而易见了。。再者自动化测试要消耗的人力时间成本较手工测试多的多的多。。投入(自动化脚本编辑)高产出(发现的bug数量)少。。单凭自动化测试工程师听着比手工测试工程师名号帅气多了。。而争着戴自动化测试的帽子。。很可笑。。莎莎目前国内的测试环境，在掌握自动化测试的情况下再来比较测试思想是比较靠谱的。Fan，水深潜水，水浅冒泡手动或自动测试只是方法，关乎效率和覆盖面；而测试用例的设计是核心，决定是否能发现设计或者实现上的缺陷。根本不是一个层面的东西吧，没法放在一起比较。更深层次的问题是测试工程师的资深、厉害与否更在于对系统内在的理解，用户使用场景的认识，这和测试方法没有多少关系。
备案号： 说三道四