2017年2月 总版技术专家分月排行榜第三
2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
2017年2月 总版技术专家分月排行榜第三
2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
2017年2月 总版技术专家分月排行榜第三
2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
2010年9月 挨踢职涯大版内专家分月排行榜第一
2010年12月 .NET技术大版内专家分月排行榜第二2010年10月 挨踢职涯大版内专家分月排行榜第二2010年8月 挨踢职涯大版内专家分月排行榜第二
本帖子已过去太久远了，不再提供回复功能。在开始之前先学习两个工具商业web自动化测试工具请学习QTP；QTP的学习可以跳过，我是跳过了的。开源web自动化测试工具请学习Selenium；我当年是先学watir，再学selenium
这里主要讲一些能让读者和普通菜鸟区别开来的东西，这些请和上面的两个工具穿插地学：基础：1.浏览器前端相关的简单技术基础：就是那些什么html、xml、css、javascript、等等，详见w3c教程网站2.学习使用一个单元测试框架或者叫做测试执行器，建议testNG，学完testNG，你应该具备了3小时学会任何一个测试执行器的能力，我用过的有testNG/Junit/Nunit/ruby unit test/python test unit/visual studio里的测试执行器、等等；3.学习一个语言的基本语法：静态语言建议java、动态语言建议python；只需要学基本语法，一般三个月之内都可以学完。我顺便学了一些ruby、groovy、shell脚本等。4.学习一两个版本控制工具的使用：svn和git； 我那时候还顺便学了hg，不过现在没多少人用了只要使用，很简单，请自己找资料5.学习page object设计模式：selenium官网有例子，极其简单； 理解这个设计模式花了一两天。用这个模式改写一个网站的全套回归测试用例花了我一个月。6.学习jenkins的使用：只要使用，很简单，请自己找资料； 这一点大概花费一个下午时间。7.学习自动化构建工具的使用：至少学ant和maven； 这个在学testNG时顺便掌握，只需要简单应用。提高：1.浏览器是怎么工作的：How browsers work &这个听说有中文翻译的，自己找吧。2.学习了解一个关键字驱动的测试执行器，建议robot&有前面的基础，这个大概学一个下午可简单掌握，深入掌握清熟读官方文档。3.学习了解一个BDD业务驱动的测试执行器，建议cucmber&个人对BDD持保留意见，有testNG的基础学这个大概一两个下午（这个是用ruby的，我假设你顺便学了ruby语法）。另外我顺便花了一两个下午看了看JBehave（Java的）、Spock（groovy的）。4.学习几个数据库的简单使用：mysql，mongodb； 这个w3cschool有教程。自己找。我其实还没看。5.学习服务器端的操作系统简单使用：linux，unix及shell脚本之类的； 这个比较费时间，推荐鸟哥的linux私房菜系列。6.学习其他的商业工具或自动化测试工具原理都是差不多的，大概有几十种可以学，但都差不多。这个我断断续续把网上能找到都看了看，大概看了几十种吧。其中不乏很奇葩的产品比如fit和fitness7.继续扩展学习各种开发框架、网络协议等。如果你想去巨头互联网公司做测试开发，学完这条才是刚刚开始；这也是为什么转型做专职的自动化测试、测试开发人员对很多手工测试人员而言这么困难。
当然互联网公司的测试开发前面的很多东西可以跳过不学。有的人跳过的东西太多了，就会开发出各种奇葩的测试框架/工具，但他反正可以做到这个职位了。
8.扩展到其他方向如app自动化、性能等等。如果想去新创业的互联网公司做测试开发，app的自动化肯定要学，但有前面的基础，学这个易如反掌。
其他可有可无的知识（主要用途是吹牛逼、给别人讲课、写文章吹牛逼）：
1.黑盒测试理论；一周入门，三个月精通。大部分人学到三个月就够了。觉得自己很懂的同学其实要知道你还不是很懂。因为这块挖深了可以挖出很多神奇但对找份好工作没多大用的理论知识。建议你到架构师层次再来深入学习这些理论以便更好地给人讲课、吹牛逼。
2.白盒测试理论；这个建议还是要懂一点的。比如桩啊驱动啊，覆盖率啊；工具方面可以自学sonar，并尝试和jenkins一起用，集成进一个小项目中。工具不学也没关系因为很少有公司用。个把月可以掌握。但一般在前述很多东西学习时顺便掌握。
3.自动化测试理论；这个N多的人其实压根都不懂。比如你跟他说个数据驱动、业务逻辑和测试实现分离、False alarm误报之类的自动化测试的专有名词他都不知道你说什么鬼。但这种人也可以做自动化测试，做测试开发，所以这个也就是可有可无的了。当然我建议还是要有。顺便你可以看下别人研究的自动化测试ROI的错误计算方法（因为大部分计算方法都是错误的）、自动化测试和手工测试的区别等等。还有什么基于模型的自动化测试设计理论、正交设计法和全配对（pariwise）设计法的异同等等。这些学了之后可以用于吹牛逼和给别人讲课。
4.测试管理理论、项目管理知识：你学了如果没机会也做不了管理。你不学有机会了也可以坐上管理的位子。
阅读(...) 评论()专家分享软件手工测试方法
时间： 10:00　来源：　作者：
有个朋友问到这个问题：“有多少是测试年限在
年以上但还仍然在做大量手工测试的，请
老师给指导一条明路”，
为了大家考虑，王老师在这里
在qq群里有个朋友问到这个问题：“有多少是测试年限在1年以上但还仍然在做大量手工测试的，请王老师给指导一条明路”，为了大家考虑，王老师在这里来分享一些的小技巧：手工测试工作并不比软件自动化测试设计，工具使用或开发简单很多。你可以每天反思总结自己在测试分析的方法及能力上——减少测试对象遗漏，测试设计的方法及能力上——测试深度和去冗余，取得了什么进步，这就是你每天的努力提升方向。&自动化和工具毕业生都可以快速掌握，但如何设计一套漏测少，冗余少的测试用例框架则需要你丰富的手工测试经验为基础；如何设计一套能缩短研发进度保障测试质量的测试策略需要丰富的手工测试经验为基础。王老师在2010年就开始开发自动化测试框架（可以让功能测试人员只需要会脚本的就可以完成自己的自动化测试脚本），一行一行写的，相比国内目前大多数搞自动化测试的人算走得早的吧，2013年时还参与给某大型厂商（测试有人当时）进行自动化测试咨询（自动化测试框架以外的自动化测试相关经验）。王老师从2012年唯自动化测试工作论，到后面慢慢淡化，逐渐从事了其他测试类型的工作后发现在测试领域自动化测试的重要性没我想得那么高，也没那么关键后，从2014年起完全离开了自动化测试领域，并发现了更多有价值更有意义更有挑战性的测试技术创新专题。现在他还在路上。要知道测试的根不是自动化，而是质量，在质量这一块手工测试经验人员是大有可为，也只有依赖你来大有可为，自动化测试的同事搞不定质量，也无法全局角度整体来提升效率，自动化测试提升的效率从整个研发周期和测试周期来看，只能算是局部优化。搞好测试策略，搞好用例冗余也都能整体提升测试效率。以上就是专家给大家分享的软件手工测试的小技巧，希望对从事手工测试的朋友，有帮助。更多的，请收藏（ctrl+d）我们。
最新开班信息
火热报名中
浅谈软件测试发展前景及薪资水平
免费咨询热线400-888-3682
免费咨询热线400-888-3682
免费咨询热线400-888-3682
北京顶测科技有限公司 京ICP备号-1北京总部地址：北京市朝阳区望京园601号9层 咨询电话：400-888-766958深圳分部地址：深圳市罗湖区莲塘街道莲塘莲花阁4栋3单元3层 &咨询电话：400-888-3682Copyright &论手工测试与自动化测试的优缺点_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
论手工测试与自动化测试的优缺点
上传于|0|0|文档简介
&&作业不会的可以参考哦
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩6页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢手工测试与自动化测试 - 简书
手工测试与自动化测试
总结一下知乎上几位答主的答案
自动化测试和手动测试都是不可缺少的，两者相辅相成
无论是自动化测试还是手工测试，其核心永远是测试用例。无效的用例，用任何方法去测试，都不会达到良好的测试目的。
自动化更多是取决于产品的生命有多长，理论上所有的手工测试都可以自动化，但应考虑使用自动化工具带来的效率上的增益能不能抵消设计编写自动化工具的消耗。人的精力是有限的，自动测试的测试人员可以用更少的精力去执行测试，于是就可以把更多的精力放在设计测试案例，以及理解需求和系统的阶段上。
设计用例的发散思维和能力无法被具象衡量，而搭建自动化测试框架以及编写自动化测试脚本是具象的能力。
目前国内普遍的测试情况仍然是手工测试比例为重，虽然不应该简单地用是否做过自动化测试作为唯一衡量标准，但企业在不了解测试人员具体能力的情况下，反映在简历上更希望应聘者是个多面手。
作为一个测试人员，从谋取自身利益的方面考虑的话，应该看你所使用的测试手段能不能产出被企业认可的价值，这个要根据公司具体情况而定，是更追求质量还是速度，对测试人员的要求侧重点是不一样的。
自动化测试和手动测试都是不可缺少的，两者相辅相成，简单说说我对自动化测试和手动测试的体会：首先，我认为自动化测试的主要目的并不是为了发现产品的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。自动化测试和持续集成是重要的手段，确保对产品质量的可控性。 版本控制软件也非常重要。极大提高我们的工作效率。
Paste_Image.png
单元测试-&持续集成-》接口组件测试-》功能级别组件测试-》持续迭代-》部署测试-》
用户体验性测试
简单所以下我工作的情况：之前在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不要懂产品逻辑，还要懂产品代码！作者：金阳链接：
测试最重要的还是对系统以及需求的理解吧。至于是不是自动化，更多是取决于产品的生命有多长，以及自动化后成本有没有减少。
关于对系统以及需求的理解，这个是测试工程师最基本的要求，但是很多测试工程师现在都只是知道怎么跑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链接：来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
说点自己的不成熟看法。
将自动化测试当成很了不起的资本，源于国内对Coding的崇拜，譬如一个Dev跟一个QA放在一起，大家的第一直观印象就是——前者的技术能力比较强。
实际上，这个问题分两面看：
1. 自动化测试能力是不是资本？
是，当然是。测试自动化是软件测试的大方向。作为其核心组件的自动化测试的引入将QA从繁重的重复劳动中解放出来，完成靠人力难以组织的测试，优化测试资源，提高测试效率。优秀的自动化测试框架、完备的自动化测试脚本集、丰富的自动化测试工具将使得测试的效率倍增，对产品质量保证起到积极作用。一个有自动化测试脚本、框架、工具开发能力的QA，更有竞争力是一件无可厚非的事情。 从招聘方的角度看，就如同两台配置差不多的笔记本，一台多出俩USB口并有一个HDMI，当然会优先选了，虽然他也不一定用得到。
2. 自动化测试人员一定强于手工测试人员？
不一定。我接触过的自动化测试的QA大致有两种：其一，专职automation，他们从进公司开始就定位为自动化测试人员，有的公司的automation team甚至都不隶属于测试团队，他们从进公司开始就几乎只接触脚本和工具，自动化的需求对于他们就等于一个开发需求。这类的测试人员对产品本身了解并不多，且不深。更倾向于一个开发人员的工作方式。其二，既做手工，也写过一些自动化脚本。这一类人实际上仍然算是手工测试人员，但会小范围参与到一些简单脚本开发，多数是在已有的测试框架上进行的搭积木的工作，缺乏创新空间。对于这两类QA，前者因为很大程度上仍工作在一个Dev的模式下，可能存在的缺陷主要在测试的方法、感觉和思维方面，后者则完全可以作为一个手工测试人员去做横向比较。国内自动化测试的现状，使得投放入市场的自动化测试人员，以第二种类型的居多，且目前国内普遍的测试情况仍然是手工测试比例为重，所以如果招聘方简单地用是否做过自动化测试来过滤人才的话，也许会错过真正适合职位的测试人才。而测试人员如果单纯为博取一个名头而局限于第二种状态的话，对自身真正的自动化测试能力的提高也没有太多好处。
关于手工测试顺便说点，必须肯定手工测试对于一个测试人员成长的重要性，参与手工测试可以了解架构、熟悉产品、培养测试的感觉。测试感觉和思维，说起来貌似很浮云，但从事过测试的人应该很清楚，同样的一个测试任务，交给一个具有良好的测试感觉、思维缜密的人和交给一个把测试当成体力劳动的人会有什么样的产出差异。手工测试不应该只被等同为手工执行测试，其更重要的部分应该是测试的架构和用例设计。所有的测试执行都是以测试用例为基础，测试用例设计的好坏，对测试效率、测试覆盖率、defect发现几率产生直接影响。测试用例设计中会用到很多方法去优化和评估，涉及到离散数学、概率等领域知识的应用，是个挺值得下功夫的领域，对于一个手工测试人员的自我增值也是有帮助的。作者：朱杉链接：来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
这两者不冲突，设计测试用例自然是最重要的，但是同等重要的还有贯彻执行这个测试用例。换句话说就是所谓执行力。在中国的很多 IT 企业，工作强度以及工作量远胜国外，所以你需要在短期内执行大量的测试案例，如果你只会手动测试，那么你很可能根本就没有时间把所有案例都测试一遍。手动测试员要么是把大部分的时间将消耗在执行测试案例，而非设计测试案例上，要么就是每轮都凭自己的经验判断而漏测很多点。而对于自动测试来说，测试的案例是日积月累的，测试过的案例在以后每轮测试中都被反复使用，你只需要专注与设计新的测试案例，而旧的测试案例已经进入了自动测试，它在每次迭代中都会被自动执行了，换句话说，自动测试的测试人员可以用更少的精力去执行测试，于是就可以把更多的精力放在设计测试案例上。这样，自动测试往往就可以意味着更好的测试案例设计。人的精力是有限的。无论对于自动测试还是手动测试人员，测试案例的设计都重要，他们只是在执行测试案例这个环节具有不同的技能而已。但对于迭代开发来说，一个软件如果你需要测试 50-100 次甚至更多的次数，自动测试凡是设计过一次的案例以后都可以直接执行，自动测试可以专注于新测试案例的开发以及实现，而手动测试每次都得手动执行以前设计过的所有案例，效率上明显降低，而且漏测的情况基本上难免。我个人觉得自动测试对中国的 IT 来说非常重要。至于国外是否重要我不清楚，如果一个测试人员一个星期就那点事情可做，有充分的足够的时间每次都手动执行所有案例，工作的时间压力很小，也许他是没有动力实施自动测试的，但这并不能成为手动测试比自动测试更优的论点跟理由。作者：pansz链接：来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
发表是最好的记忆}