一款软件的诞生经历很多个阶段，每个阶段都有不同的人员参与，所以最终产品会或多或少的问题，因此为了保证软件的可用性，所以，我们必须经过测试环节，减少软件的问题。
哪个程序员也不敢说写的程序没有bug！但是我们使用的软件，基本上很少见到bug，这和软件测试是分不开的。
so，一个提供业务访问的软件，必须在严格测试，通过层层测试环境才可以正式的上线。就像游戏一样，也基本是先提出内测版，最后才是公测版，就是公司在验证程序的正确性！！
发展前景
就目前而言，相对于国外的软件测试行业来说，国内的测试行业稍显落后，所以国内的软件测试行业对于专业的测试人员需求慢慢变大。
装逼语录
有人喜欢创造世界，所以，他们做了程序员。
有人喜欢拯救世界，所以，他们做了测试员。
其他
首先，开发不是不能做测试，甚至有的测试人员之前都做过开发。
而是说，软件测试和软件开发分属软件行业中两个不同的技术方向。所以，一个半吊子开发不如一个专业的测试！这就是专业度的问题了。
从测试力度来说，软件对于开发人员来说，那就是自己的孩子，我家孩子怎么可能有毛病？你家孩子才有毛病！这就会导致自己测试自己写的软件，下手可能不够狠！
GlenfordJ.Myers在《软件测试的艺术》一书中有这样的一个定义：测试是为了发现错误而执行程序的过程。
另外，软件专家温伯格和CemKaner也提出了自己对软件测试的理解，在温伯格的《完美软件》一书中提到：测试是一个获取信息的过程，用来降低决策风险。CemKaner教授也提出：软件测试是一种技术调查，其目的是向关系人提供有关产品（软件、系统或服务）质量的实验信息。
说点人能听懂的。当你写的代码越多，你就越认同测试，曾经听过一个很贴切的比喻：写程序的人就像在造没有护栏的桥，自己去走那肯定安全无虞，那怕摸黑也不至于掉河里去；测试则像给桥修护栏的，让桥的普通使用者也能像开发那样来去自如。从这一点上说，测试远比开发重要。
通过测试工作可以发现并修复软件中存在的缺陷，从而提高用户对产品的使用信心。
测试可以通过记录软件运行过程中产生的一些数据，从而为决策提供数据支持。
测试可以降低同类型产品开发遇到的问题风险。
在20世纪50年代，英国计算机科学家图灵已提出了程序测试的定义，测试是验证程序正确性的一种实验形式。直到60-70年代，软件危机出现后，人们意识到测试的意义。软件测试慢慢的发展起来......
软件复杂度
程序代码的复杂度，软件产品的并发性，复杂性越来越高，对程序的正确性检测也越来越高
行业竞争大
由于用户审美提升与需求越来越高，现在一个新闻类app，就有百度新闻，网易新闻，趣头条，今日头条，各家公司都想做到完美，用户喜欢自己的产品，那就得从易用性，美观性，趣味性，快速性，等等等等方面超过其他的产品，那么大公司都会配备专门的功能测试岗位，性能测试岗位，乃至于更强大的测试开发岗位。
国外的软件测试基本成熟，软件企业非常重视软件测试部门。测试流程化体系严谨。一线大公司还会成立软件测试中心，服务于子公司的软件开发。
通过软件测试暴露软件中隐藏的错误和问题，便于考虑是否使用该产品。例如我们去买手机，总得反反复复的观察，这个手机的CPU性能怎么样？内存是多大的？拍照怎么样？但是，反复观察有xx用？领导不换iPhoneX，你能用的上iPhone8？
软件开发者的角度通过软件测试证明软件中不存在错误和问题，给与自己产品质量足够的信心。
一个成功的测试，是不懈的挖掘软件的错误，不断的完善产品。
满足用户需求是产品成功的关键点。
确保交付的产品符合用户的需求。
在产品上线前尽可能的发现和修复bug。
用户角度
软件中的Bug非常令人讨厌。但同时有缺陷的软件还有可能造成重大甚至致命的事故。下面是一些非常有名的软件事故：
因此公司中进行软件测试，是必须的！
测试原则是指在执行测试工作时必须要遵守的一些规则：
对于当前的测试行业来说，我们最常测试的主体就是软件（主体功能），但需要我们测试的也不仅仅是功能需求测试。我们可以将软件分为三个部分组成：
一款软件的诞生会经历不同的过程，我们将整个过程分为不同的阶段，然后每个阶段都会有相应的测试对象。那么每个阶段我们能进行什么测试呢？
所谓的软件架构，简单理解为是用来指导软件开发的一种思想，目前来说，最常见的两种架构模式：
两种架构的比较：
再来补充两个知识点：
浏览器
浏览器本质上是一款软件，安装在操作系统之上，为用户提供网页浏览服务，目前，世界主流的五大生产厂商：
国内的浏览器及内核：
对于浏览器来说，最核心的技术，就是浏览器内核，当然，仅做了解即可。
图片
常见的图片类型有：
项目组一般由项目经理领导并负责指定项目计划，分配任务。
参与人员：
生活中，到处都是测试案例，比如你买个手机，买个显示器，都要测试一下，开关机、屏幕是否有漏光，按键是否好使、这些都是测试用例。
我们需要知道测什么和怎么测这两个问题。
测试用例的定义
测试用例（TestCase）是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否满足某个特定需求，通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的重要依据。
举个例子
比如我们买个电脑，要进行测试。
测试的前提条件
按下开机键，相当于输入一组测试数据，执行的条件是，是否达到开机的前提条件，比如电池是否有电，或者外接电源是否接入。
测试过程
按下开机键。
预期结果
当我们按下开机键，顺利的启动成功，那么在有电的前提下，启动成功就是我们的预期结果。
通过上面的测试过程，就会发现，测试用例主要解决的就是测什么？怎么测？
测试用例的优势在于：
测试环境(TE)
测试环境内容包括
测试环境设计原则
测试环境所需的知识
测试用例的八大要素
输出测试用例
最后，上图：
测试用例力度
测试用例可以写的很简单，当然也可以写的非常复杂。
测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。ps:大多数的测试团队编写的测试用例的力度介于两者之间。
测试用例的本质测试用例的设计本质（测什么？怎么测？）应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。基于需求的测试用例设计：
不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。
计划书是什么
测试计划是一个叙述了预定的测试活动的范围、途径、资源以及进度安排的文档，我们亲切地称为测试计划书。此文档确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。
为什么要指定测试计划书
定制测试计划使得软件测试是有计划，有组织的软件质量保证活动。如果没有计划，工作就会很松散，随意。
测试计划
测试流程规范
测试计划书内容包含哪些内容
产品的质量目标
测试活动的质量目标
人力资源
测试环境资源配置硬件资源：服务器，计算机，手机，打印机软件资源：不同平台的操作系统，数据库软件，多种浏览器网络环境：在什么网络环境下测试，是内网还是外网测试工具：都是使用哪些工具
风险指：不可预料的后果，如事件，危险，威胁等特殊情况的发生。
客观性风险：
1.任务送达
2.分析测试任务
3.资源规划
4.制定测试计划
5.评审测试计划
what对象
why原因
who有谁参与
where场所
how方法
计划是死的，人是活的....
这年头，没有图过不了啊，虽然朕不看！
最后，来看软件计划报告。软件测试基础流程：一般是测试主管编写测试计划，测试计划是指在做完需求分析后，在开始整个测试工作之前的准备计划工作。
遵循5W+1H原则进行测试：
测试报告范围：
5W1H思想很流行啊！因为我们将基于这个思想来阐述软件的兼容性测试！
向前兼容性测试(forwardcompatibilitytesting)：测试的应用程序或软件在新的或即将到来的版本，并且应用程序的早期版本能够打开较新版本中的文件并忽略早期版本中未实现的功能。比如USB1.0能够兼容USB3.0，或者是MSoffice2003能够使用转换器打开MSoffice2007的文件，并忽略MSoffice2007的新功能。
向后兼容性测试(backwardcompatibilitytesting)：测试的应用程序或者软件处于旧版本，并且应用程序的新版本能够顺利处理旧版本的程序数据。比如说USB3.0兼容USB1.0，或者MSoffice2007能够打开MSoffice2003的文件。
当build已经相对稳定的时候就进行兼容性测试。
以浏览器兼容性测试实例展开，讨论在软件兼容性测试中要测试什么：
综上所述，对于浏览器的兼容性测试，我们要验证的是页面、字体大小和样式、特殊字符的编码、图像对齐与否、页面的头尾、页面对齐与否、文本对齐与否、控件的对齐情况、页面的放大放小测试、数据库提交信息验证、HTML视频播放格式验证、外部网站开发的插件验证、关闭cookies和javascript后的页面验证等。还有其他的验证内容，可以通过探索性测试中提到的一些方法，进行测试。如破坏测试法，懒汉测试法，一送一测试法，配角测试法，卖点测试法，指南测试法，超模测试法等等，可以将探索性测试用于软件的兼容性测试，更加有方向的进行兼容性测试。
在执行兼容性测试之前要理解，在什么平台，怎样的环境，去验证哪个软件的兼容性，去根据对软件以及环境的认识，去制定有测试计划和测试策略的testplan(Testplan中包括了TestScope,TestStrategy,Hardware,TestSchedule)，引入一些常用的测试方法，如探索性测试，手工测试，自动化测试，冒烟测试等方法，将软件的兼容性测试做活，不那么生硬，尽可能的找到更多之前没有发现的bug。指定完testplan，就是执行这一轮的兼容性测试，配置相应的环境，采用局部自动化测试+手工测试的原则，去检测软件是否存在兼容性问题，完成这一轮CT，后signoff。
错误观念：软件测试不需要版本控制测试人员在测试过程中发现的bug提交给开发人员，开发人员在对提交的bug进行修改，bug修改后开发人员会将修改后的代码放入当前的软件版本之中，这样一来二去，会导致软件测试版本发布过于频繁，测试版本不稳定，导致修改过的bug再次出现，测试重复、失效和混乱。测试进度无法保证，同时不便于追溯跟踪问题。原因是：对于修改过的代码，不能够保证他们一定是正确的，很可能在开发人员修改过之后，仍然是错误的，或者在修改过之后仍然会给软件带来别的问题，测试人员对新提交的代码以及之前的代码都要再次进行验证，进行排错，来确保不会因此而带来新的隐患，新的漏洞，导致大量重复测试。引入版本控制的好处：提高开发和测试的效率，提高软件版本稳定性，便于追溯问题。
版本控制对象开发提交给测试的产品版本。测试人员提交的bug到了开发人员手中之后，开发人员针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本，而不能直接替换到现有的测试版本中去。版本控制定义测试版本的交付在专人控制之下，对每次测试的版本有明确的标识（新增加的功能、修复的bug等），不同版本可以看到稳定度趋势，每个版本的测试状态。
强化测试准入条件测试启动条件：功能是否开发完成、有没有进行自测（自测报告，避免出现版本质量太差）、软件版本说明（清楚每一次版本更新都修改了什么，会对哪些功能造成影响）。开展冒烟测试：保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断，如果最基本的测试都有问题则直接打回。
（开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。）
冒烟测试的通过标准：基本的功能和流程通过就可以。（测试场景/点可以提供）软件提测后注意事项：非bugfix的修改，必须周知（如重构），Bugfix涉及的代码，代码review，明确回归范围，减少质量隐患。
版本控制文档管理工作版本信息、测试记录、测试结果（开发和测试活动的追溯）
最后，就是要做到及时沟通
这个没的说，效率和质量。
开发文档和产品需求文档生成或者变动后请周知一下，保证测试用户及时编写和维护。测试环境最好是专人维护（开发、运维、测试），频繁和擅自发布新功能或者修改是不可取的。保证版本的统一性很重要。测试人员提交的bug到了开发人员手中之后，开发人员针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本，而不能直接替换到现有的测试版本中去。代码提交，review后再部署，直接打包部署的代码不能保证完整（提交冲突，合代码后发布失败等）
扯了半天淡，我们用什么来做测试呢？测试管理工具（项目流程管理）
功能测试工具（自动化脚本测试）（黑盒）
性能测试工具（黑盒）
代码测试工具（白盒测试）
开源测试管理工具：
开源功能自动化测试工具：
开源性能自动化测试工具：
情商素养
专业技能
软件基础知识
业务能力
互联网行业的薪资水准相对较高，入行一年超过其他行业薪资很正常。互联网行业究竟有哪些职位呢，又分别适合哪些传统行业转型？