玉林专业软件测试培训网站
软件测试培训机构达内经典语录：贫穷是不需要计划的，致富才需要一个周密的计划——并去实践它。.
软件测试该学些什么技能？职业选择方向又有哪些？
软件测试该学些什么技能？职业选择方向又有哪些？测试，是动词、名词。测试行为，一般发生于为检测特定的目标是否符合标准而采用专用的工具或者方法进行验证，并最终得出特定的结果。多么生动的描述啊！
如果说开发的任务是建造一座房子，那么测试的任务就是对房子的材料，设计图纸(文档)，外观，抗震性，舒适性等等进行综合验证，并得出一份“质检报告”。
一、测试职位具体划分
1、功能测试工程师
功能测试重心就是测试用例的设计。而测试用例的设计，取决于测试人员对产品需求的理解;对产品需求的理解取决于测试人员对业务的“接受”程度。这也是功能测试发展往往会遇到“瓶颈”的原因，过多的项目只不过是在反复地学习不同的业务;因此功能测试工程师往往要具备一定的测试管理能力，掌握一定的测试策略，发展通道一般是管理方向。
2、性能测试工程师
产品，实际上是指产品的功能和质量两个方面。功能是构成竞争力的首要要素。用户购买某个产品，首先是购买它的功能，也就是实现其所需要的某种行为的能力。质量是指产品能实现其功能的程度和在使用期内功能的保持性，质量可以定义为“实现功能的程度和持久性的度量”。
性能测试往往要求测试工程师不但具备对产品基本的功能以及业务知识，还要对产品所“在”(部署)的环境有必须的了解。这就要求性能测试工程师必须掌握一定的系统知识，如服务器硬件知识(CPU、MEM、NETWORK、IO)，数据库(ORACLE，MYSQL)，中间件(TOMCAT，NGINX)，操作系统等知识。
3、自动化测试工程师
反复的手工测试势必会让测试人员开始思考人生。工作中几乎每个测试人员都会遇到过一些重复性比较高，而且必须要做的工作，如回归测试，冒烟测试等;顾名思义，自动化测试就是为了把测试人员从一些重复性高，而且需求变化不大的工作中解放出来;比如web自动化测试，可以通过selenium编写测试脚本，一次写完，就可以反复用到需求变动不大的任务中。
4、测试开发工程师
测试开发岗位，工作的目的就是为了更高效，更快捷地让测试工程师进行测试工作;测试开发岗位一般要求一定的开发能力，解决问题的能力尤为重要。比如我们项目组的测试开发小伙伴就经常开发一些脚本自动生成工具给我们使用，这也直接提高了我们的测试效率，间接地缩短了测试周期，可以更好更快地交付产品给客户使用。
二、测试需要掌握哪些技能
把自己工作中接触到的和非接触的到的知识罗列一下。
1、开发能力：JAVA(集合，泛型，基础知识，调试，代码阅读)，JavaScript/CSS/HTML(基础知识，能结合知识实现项目)，Python(基础知识);
2、框架：Spring Boot，Spring MVC;Vuejs;
3、开发成果：可以单独开发JAVAWEB后台系统，前端项目;管理系统;
4、兴趣爱好：机器学习(理解常用的机器学习知识与算法原理，以及简单机器学习实现);
5、计算机网络知识：TCP/IP协议(HTTP，DNS);
6、操作系统：LINUX服务器常用指令，服务器硬件指标分析，shell编程基础;
7、中间件：TOMCAT，NGINX(负载均衡，结合keepalive高可用架构)，Mycat(分表分库)，Redis，Zookeeper;
8、数据库：Oracle/MySQL，复杂查询;
9、测试工具：JMeter，Postman等;
10、版本管理：GIT,SVN;
11、调度工具：JENKINS(理解);
12、大数据：Hadoop(理解架构)，Hive;
以上知识，都是工作中接触到的并且运用到的，当然测试工作中有些可能不需要精通掌握，只仅限于“使用”。
软件测试培训达内荣誉：2004年10月，荣获中关村科技园区管委会“中关村优秀留学人员创业企业”.
玉林专业软件测试培训网站
达内软件测试培训学校励志语录：之前欠时间的债太多，得还。.
软件测试中破坏性测试思维的思考
No.1
破坏性思维解释
所谓破坏性思维，是指逢事"往坏处想"的思维方式和习惯。具体而言，就是对周围的事物持排斥、抵制、否定的态度和心态，让人看到的是眼前一团漆黑，对事物的前途难抱希望。
No.2
软件测试中破坏性测试思维
通过上述释义可以知道破坏性思维，这个在生活中不是一个好的现象。那么它要应用在软件测试中，它会产生什么效果呢?
这里说的软件测试中破坏性思维和软件测试中的破坏性测试不是同一个东西。破坏性测试是破坏系统以检查软件质量。软件测试中破坏性测试思维是一种突破自己思维边界以一些独特的角度来考量系统的一种思维方式。这种思考，会发现好多测试中隐藏的暗柱，能提出一些比较建设性的意见，能极大的提高系统的健壮性。
No.3
破坏性测试思维的效用
随着技术发展，系统也越来越大，如果测试人员一直按部就班、循规蹈矩的进行早期已经设定好的测试，而不进行一些探索测试，这样虽然可以满足当前任务要求，能确保系统能够比较好的运行。但是仅仅是这样，那么测试人员如何成长呢?如何突破自身设限呢?
虽然软件测试这个行业入门低，但是如果在工作过程中，缺乏学习与总结能力，那势必会把自己陷入困局。而避免自己陷入困局，且能不断拓宽自己能力的一个能力之一就是“破坏性测试思维”。例如：当你给你一登录输入框，不同的人测试的方法和思考方法也会不一样，那产生预期也是不一样的，常用对输入框的是：输入框长度、支持输入的类型、超长输入、为空等这些测试点，那你脑子是否产生过类似字样的想法：
1. 输入一个js或sql，会产生什么效果呢?在后台会以什么样的形式存储呢?
2. 系统在正常网络下工作正常，系统在弱网下会如何工作呢?数据会不会丢失呢?
3. 系统在突然断电，然后重启之后会产生什么情况呢?
就像上述这类比较独特的思考，跳脱出测试模块，站在系统之外发散思维，并给这种发散思维找出依据点。这个过程你会发现测试原来可以这么有趣、原来测试还可以这样思考，虽然这种发散的测试点，可能无法落地且可能不符合业务逻辑，但是那有什么关系呢，这种思考会加深你对系统的理解、丰富你思考方式。
No.4
破坏性测试思维优缺点
在测试中使用破坏性思维思考，可能会产生以下问题：
1. 扩大测试范围、增加测试难度。
2. 对被测系统缺乏信心
3. 当发现一些比较严重的测试点需要测试时，会延长测试时间，增加时间消费
每个事物都有其两面性，都有其比较偏重的使用场景。破坏性测试思维与探索测试进行结合，会产生比较好、甚至意想不到的的效果。一般会出现如下效果：
1. 加深对系统实现的了解，增加经验。
2. 容易发现自己的测试短板，便于自己查漏补缺
3. 能够挖掘一些比较好的测试点，增强系统抗风险能力
No.5
破坏性测试思维讨论
上述是个人在测试过程中，破坏性测试思维的想法，由于想法可能不是很成熟，存在很多的描述性问题，本文主要想阐明的观点是：“测试过程中不要自我设限，打破固有测试思考壁垒”。
达内软件测试培训学校励志语录：真正能走过风雨的，唯热爱与坚守。。
玉林专业软件测试培训网站
达内软件测试培训学校励志语录：任何人都可以变得狠毒，只要你尝试过嫉妒。。测试其实很重要
最近，在网上看到过一个调查，调查的内容是“程序员在项目开发中编写单元测试的情况”。当然，至于调查的结果，我想聪明的你已经可以猜到了。高达 58.3% 的比例，一般情况下不写单元测试，只有偶尔的情况才会写写。16.6% 的程序员从来都不写单元测试。只有很少的一部分程序员才会在自己的代码中进行单元测试，并保证方法测试通过。看到这些，你想到了什么？
测试其实很重要
1、单元测试现状
虽然，这个调查可能会有些片面性，但这也基本反应了国内程序员的开发现状，很少有程序员能够比较认真的去编写单元测试。而且，甚至有的程序员根本就不知道为什么要写单元测试(这一点让我很郁闷)。他们经常会说，公司里不是有测试人员嘛，测试应该是他们要做的事，我们的工作只是开发(这位仁兄肯定没有学过软件工程)。当然，这些并不是偶然的，正如佛经里边说的“因果循环”，有果必有因。那么，到底是什么原因，导致程序员对单元测试这么不感冒呢?
2、错误认知
通过与几个朋友的讨论，以及网上的调查，主要有这几种原因，导致程序员对单元测试很排斥，或许说很不以为意。
不知道怎么编写单元测试
项目没有要求，所以不编写
单元测试价值不高，完全是浪费时间
业务逻辑比较简单，不值得编写单元测试
不管怎样，集成测试将会抓住所有的 bug，用不着进行单元测试
在项目的前期还是尽量去编写单元测试，但是越到项目的后期就越失控
为了完成编码任务，没有足够的时间编写单元测试。编写单元测试会导致不能按时完成编码任务，导致项目延期
很显然，这几种原因归根结底，无外乎就是不了解单元测试，自认为很聪明，自己懒不想去测试，对项目的时间、进度把控不好。
3、解析原因
不知道怎么编写单元测试
这个问题在于，还没有接触过单元测试，同时，也没有体会过企业级的代码开发。不知道同时也不了解单元测试能带给你什么。设想一下，当你开发完一个功能模块的时候，你如何确定你的模块没有 bug 呢?如果涉及到具体的业务，你会执行 debug 模式，然后一点一点的深入到代码中去查看吗?如果你一直都是这样，那么你早就已经 OUT 了。赶快去了解一下单元测试的工具吧，你会收获很大的。
项目没有要求，所以不编写
这个问题反映出了一种现象，同时也是一种习惯。项目有没有要求，只能说明项目的管理上不严格，并不是程序员不编写单元测试的理由。他们在以往的开发中，并没有养成写单元测试的好习惯。可想而知，他们的代码质量，我就不敢恭维了。给个建议，尝试着写漂亮的代码，之所以因为漂亮，是指得健康、简洁、健壮。当然，完成漂亮的代码就离不开单元测试了。
单元测试价值不高，完全是浪费时间
这种说法其实是错误的。为什么这么说呢?在日常的开发中，代码的完工其实并不等于开发的完工。如果没有单元测试，那么如何保证代码能够正常运行呢?测试人员做的只是业务上的集成测试，也就是黑盒测试，对单个的方法是没有办法测试的，而且，测试出的 bug 的范围也会很广，根本不能确定 bug 的范围，还得去花时间来确定 bug 出在什么地方。难道这就不浪费时间了吗?甚至，这样的方式，时间浪费的会更多。
业务逻辑比较简单，不值得编写单元测试
所谓的业务逻辑比较简单，其实是相对的。当你对某一块业务逻辑很熟悉的时候，你自然会认为它很简单。然而，单元测试的必要性并不是仅仅在于测试代码的功能是否正确，还在于，当其他同事在了解你的业务的时候，能够很快的通过单元测试来熟悉代码的功能，甚至不用去读代码，就能够知道它做了哪些事情。因此，写单元测试不仅是解放了自己，更方便了别人。
项目前期还在尽量写测试，到了后期就失控了
这种问题的原因在于，对项目进度、项目中的技术点研究时间、人员的沟通、业务需求的熟悉程度等没有把控好。这个问题的出现并不是个人的问题，而是反映了项目管理中存在的问题。当然，个人的原因也存在，就是如何在有限的时间里，提高效率。这一点需要大家好好思考一下了。我的建议，多做计划，根据实际情况变更计划。多和项目组长、组成员进行沟通。及时反应项目中存在的问题。
为了完成编码任务，没有足够的时间编写单元测试
这个问题在于，程序员领取的任务较为复杂，或者自己的开发效率有待提高。其实，开发任务是包括编码和单元测试的。在领任务的时候，应该跟据自身的能力，跟组长或经理沟通好，以便留出一定的测试时间。当然，提高自己的编码效率也是很有必要的。至于如何提高开发效率，网上有很多这样的文章，这里就不再赘述了。
4、单元测试的重要性
测试常常是程序员十分厌倦的一个活动。测试能给我们带来什么?了解这些是非常重要的，测试不可能保证一个程序是完全正确的，但是测试却可以增强我们对程序完整的信心，测试可以让我们相信程序做了我么期望它做的事情。测试能够使我们尽早的发现程序的 bug 和不足。
一个 bug 被隐藏的时间越长，修复这个 bug 的代价就越大。在《快速软件开发》一书中已引用了大量的研究数据指出：最后才修改一个 bug 的代价是在 bug 产生时修改它的代价的10倍。
当然，我们主要讨论的是单元测试。单元测试是一个方法层面上的测试，也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。在开发中，对于自己开发的模块，只有在通过单元测试之后，才能提交到 SVN 库 或者 Git 库。
5、测试的应用
正是由于测试在开发中的重要地位，才会在IT界刮起了 TDD 的旋风。TDD，也就是测试驱动开发模式。它旨在强调在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。
6、测试工具
JUnit 在日常开发中还是很常用的，而且 Java 的各种 IDE (Eclipse、MyEclipse、IntelliJ IDEA)都集成了 JUnit 的组件。当然，自己添加插件也是很方便的。JUnit 框架是 Java 语言单元测试当前的一站式解决方案。这个框架值得称赞，因为它把测试驱动的开发思想介绍给 Java 开发人员并教给他们如何有效地编写单元测试。
TestNG，即Testing Next Generation，下一代测试技术。是根据JUnit和NUnit思想，采用 jdk 的 annotation 技术来强化测试功能并借助XML 文件强化测试组织结构而构建的测试框架。TestNG 的强大之处还在于不仅可以用来做单元测试，还可以用来做集成测试。
俗话说，一屋不扫，何以扫天下。开发中，我们自己的代码都不能保证功能的正确性，那么还有什么效率可言呢?做再多的任务，写再多的代码也只不过是在搭鸡窝，做着机器一样的重复的工作。IT界有一个原则，DRY原则 —— Don't Repeat Yourself !只有通过对自己的工作不断的检查，不断的测试，才能不断的突破，不断的脱颖而出，当然，你才能不断的提高。
达内软件测试培训学校励志语录：总会有一个人是第一，我为什么不能是那一个人呢。。
玉林专业软件测试培训网站
软件测试培训达内荣誉：2012年11月，荣获商务部“2012年商务部重点联系服务外包培训机构” .
