标签：天气 图灵 bugfree 定制 开发人员 事故 视频播放 设置 集合
目录
很多时候：
一款软件的诞生经历很多个阶段，每个阶段都有不同的人员参与，所以最终产品会或多或少的问题，因此为了保证软件的可用性，所以，我们必须经过测试环节，减少软件的问题。
哪个程序员也不敢说写的程序没有bug！但是我们使用的软件，基本上很少见到bug，这和软件测试是分不开的。
so，一个提供业务访问的软件，必须在严格测试，通过层层测试环境才可以正式的上线。就像游戏一样，也基本是先提出内测版，最后才是公测版，就是公司在验证程序的正确性！！
发展前景
就目前而言，相对于国外的软件测试行业来说，国内的测试行业稍显落后，所以国内的软件测试行业对于专业的测试人员需求慢慢变大。
装逼语录
有人喜欢创造世界，所以，他们做了程序员。
有人喜欢拯救世界，所以，他们做了测试员。
其他
知乎上已经有了优秀的答案。
首先，开发不是不能做测试，甚至有的测试人员之前都做过开发。
而是说，软件测试和软件开发分属软件行业中两个不同的技术方向。所以，一个半吊子开发不如一个专业的测试！这就是专业度的问题了。
从逻辑角度来说，开发人员大多数时间都在思考如何实现具体的功能。而作为测试人员，大多数时间都站在用户的角度思考如何挑出软件的问题。
从测试力度来说，软件对于开发人员来说，那就是自己的孩子，我家孩子怎么可能有毛病？你家孩子才有毛病！这就会导致自己测试自己写的软件，下手可能不够狠！
Glenford J. Myers在《软件测试的艺术》一书中有这样的一个定义：测试是为了发现错误而执行程序的过程。
另外，软件专家温伯格和Cem Kaner也提出了自己对软件测试的理解，在温伯格的《完美软件》一书中提到：测试是一个获取信息的过程，用来降低决策风险。Cem Kaner教授也提出：软件测试是一种技术调查，其目的是向关系人提供有关产品（软件、系统或服务）质量的实验信息。
除此之外，IEEE（电气和电子工程师协会，全称是Institute of Electrical and Electronics Engineers）和ISO（国际标准化组织，全称是International Organization for Standardization）也不甘落后的发表了自己的看法。1983年IEEE曾这样定义软件测试：软件测试是使用人工或者自动化手段来运行或者测试定某个系统的过程，检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别，从这个定义中我们可以看出，软件测试不仅为了发现错误，而且需要验证软件是否满足了规定的需求。ISO 29119标准也尝试标准化软件测试。提到： Software testing should focus on providing information about a software product and finding as many defects as possible, as early as possible in development process, under given constraints of costs and schedule，其中有两个重要的观点：一个是尽可能的早（early），一个是成本（cost）受限。测试发现bug应尽可能的早，这样造成的影响越小，修复成本越低。而测试活动往往是在时间和人力成本受限的情况下进行，在有限的资源下，测试人员应该有的放矢，对测试对象的进行选择排序，测试技术进行选择组合使用，这也是测试策略方面的东西。
说点人能听懂的。当你写的代码越多，你就越认同测试，曾经听过一个很贴切的比喻：写程序的人就像在造没有护栏的桥，自己去走那肯定安全无虞，那怕摸黑也不至于掉河里去；测试则像给桥修护栏的，让桥的普通使用者也能像开发那样来去自如。从这一点上说，测试远比开发重要。
总结，软件测试的定义：通过手工或者相关工具，对被测对象进行测试操作。从而验证实际与预期结果是否存在差异。
通过测试工作可以发现并修复软件中存在的缺陷，从而提高用户对产品的使用信心。
测试可以通过记录软件运行过程中产生的一些数据，从而为决策提供数据支持。
测试可以降低同类型产品开发遇到的问题风险。
这个标题让我想起了我喜欢的一首歌Shallow，学什么习，这个天气不适合学习，只适合Move your body，是不是很happy。OK，让我们随着音乐的节奏回到.......
在20世纪50年代，英国计算机科学家图灵已提出了程序测试的定义，测试是验证程序正确性的一种实验形式。
直到60-70年代，软件危机出现后，人们意识到测试的意义。软件测试慢慢的发展起来......
软件复杂度
程序代码的复杂度，软件产品的并发性，复杂性越来越高，对程序的正确性检测也越来越高
行业竞争大
由于用户审美提升与需求越来越高，现在一个新闻类app，就有百度新闻，网易新闻，趣头条，今日头条，各家公司都想做到完美，用户喜欢自己的产品，那就得从易用性，美观性，趣味性，快速性，等等等等方面超过其他的产品，那么大公司都会配备专门的功能测试岗位，性能测试岗位，乃至于更强大的测试开发岗位。
国内处于起步和迅猛发展的阶段。
大公司非常重视测试，初创型小公司对测试关注较少。
主要还是手工测试为主，自动化测试为辅。
国外的软件测试基本成熟，软件企业非常重视软件测试部门。
测试流程化体系严谨。
一线大公司还会成立软件测试中心，服务于子公司的软件开发。
通过软件测试暴露软件中隐藏的错误和问题，便于考虑是否使用该产品。
例如我们去买手机，总得反反复复的观察，这个手机的CPU性能怎么样？内存是多大的？拍照怎么样？但是，反复观察有xx用？领导不换iPhone X，你能用的上iPhone 8？
软件开发者的角度
通过软件测试证明软件中不存在错误和问题，给与自己产品质量足够的信心。
一个成功的测试，是不懈的挖掘软件的错误，不断的完善产品。
满足用户需求是产品成功的关键点。
确保交付的产品符合用户的需求。
在产品上线前尽可能的发现和修复bug。
用户角度
快看，摇了半天，终于有人加我微信了！
软件中的Bug非常令人讨厌。但同时有缺陷的软件还有可能造成重大甚至致命的事故。下面是一些非常有名的软件事故：
因此公司中进行软件测试，是必须的！
测试原则是指在执行测试工作时必须要遵守的一些规则：
二八理论，即对于软件的功能来说，核心功能占20%，非核心功能占80%（当然，不是绝对的）。那么在测试中，我们会集中测试20%的核心功能。所以，这部分发现缺陷的概率会远高于80%非核心部分。也因此我们遇到的缺陷就都会集中在20%的核心功能这块。3 * 3测试出代码不等于9，把这个缺陷提交给开发，开发随后解决了这个bug，那我们再测试的时候，就不要用3 * 3来测试了，因为开发在改bug的时候，想法设法的让3 * 3 = 9，所以，同样的用例，软件会对它产生免疫。对于当前的测试行业来说，我们最常测试的主体就是软件（主体功能），但需要我们测试的也不仅仅是功能需求测试。我们可以将软件分为三个部分组成：
一款软件的诞生会经历不同的过程，我们将整个过程分为不同的阶段，然后每个阶段都会有相应的测试对象。那么每个阶段我们能进行什么测试呢？
所谓的软件架构，简单理解为是用来指导软件开发的一种思想，目前来说，最常见的两种架构模式：
B/S，浏览器和服务端。C/S，客户端和服务端。两种架构的比较：
B/S架构的数据都是由服务器端处理，浏览器只负责展示结果，所以对于服务端压力相对较大，而C/S架构的客户端可以承担一些数据处理，所以执行效率高。B/S架构的数据都根据HTTP协议进行的，所以安全性相对于C/S架构来说，安全性相对低一些。B/S架构的升级只需升级服务端即可，而C/S架构则需要两端都需要升级更新。B/S架构来说，C/S架构的客户端也需要自己开发，所以成本会高一些。再来补充两个知识点：
浏览器
浏览器本质上是一款软件，安装在操作系统之上，为用户提供网页浏览服务，目前，世界主流的五大生产厂商：
国内的浏览器及内核：
对于浏览器来说，最核心的技术，就是浏览器内核，当然，仅做了解即可。
图片
常见的图片类型有：
项目组一般由项目经理领导并负责指定项目计划，分配任务。
参与人员：
生活中，到处都是测试案例，比如你买个手机，买个显示器，都要测试一下，开关机、屏幕是否有漏光，按键是否好使、这些都是测试用例。
我们需要知道测什么和怎么测这两个问题。
测试用例的定义
测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否满足某个特定需求，通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的重要依据。
举个例子
比如我们买个电脑，要进行测试。
测试的前提条件
按下开机键，相当于输入一组测试数据，执行的条件是，是否达到开机的前提条件，比如电池是否有电，或者外接电源是否接入。
测试过程
按下开机键。
预期结果
当我们按下开机键，顺利的启动成功，那么在有电的前提下，启动成功就是我们的预期结果。
通过上面的测试过程，就会发现，测试用例主要解决的就是测什么？怎么测？
测试用例的优势在于：
测试环境(TE)
测试环境内容包括
测试环境设计原则
测试环境所需的知识
测试用例的八大要素
输出测试用例
最后，上图：
测试用例力度
测试用例可以写的很简单，当然也可以写的非常复杂。
测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
ps:大多数的测试团队编写的测试用例的力度介于两者之间。
测试用例的本质
测试用例的设计本质（测什么？怎么测？）应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
基于需求的测试用例设计：
及时响应变更比遵循计划更有价值这一原则体现出来。不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。
计划书是什么
测试计划是一个叙述了预定的测试活动的范围、途径、资源以及进度安排的文档，我们亲切地称为测试计划书。
此文档确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。
为什么要指定测试计划书
定制测试计划使得软件测试是有计划，有组织的软件质量保证活动。如果没有计划，工作就会很松散，随意。
测试计划
测试流程规范
参考：http://www.testclass.net/post/test_level
测试计划书内容包含哪些内容
产品的质量目标
测试活动的质量目标
人力资源
测试环境资源配置
硬件资源：服务器，计算机，手机，打印机
软件资源：不同平台的操作系统，数据库软件，多种浏览器
网络环境：在什么网络环境下测试，是内网还是外网
测试工具：都是使用哪些工具
风险指：不可预料的后果，如事件，危险，威胁等特殊情况的发生。
客观性风险：
1.任务送达
2.分析测试任务
3.资源规划
4.制定测试计划
5.评审测试计划
what 对象
when 时间
why 原因
who 有谁参与
where 场所
how 方法
计划是死的，人是活的....
这年头，没有图过不了啊，虽然朕不看！
最后，来看软件计划报告。
软件测试基础流程：一般是测试主管编写测试计划，测试计划是指在做完需求分析后，在开始整个测试工作之前的准备计划工作。
遵循5W + 1H原则进行测试：
测试报告范围：
5W1H思想很流行啊！因为我们将基于这个思想来阐述软件的兼容性测试！
软件兼容性测试既是测试被测试软件能够与操作系统、网络环境、浏览器、相关其他软件（包括数据库）、外接设备等能够友好合作，不出现UI界面显示异常、同等分辨率下显示异常、改变颜色及显示大小改变、排版出错、CSS格式及颜色错误、滚动条相关问题、内容或者标签重叠、表格或者框架不完整等等兼容性软件缺陷。兼容性测试包括向前兼容性测试和向后兼容性测试。
向前兼容性测试(forward compatibility testing)：测试的应用程序或软件在新的或即将到来的版本，并且应用程序的早期版本能够打开较新版本中的文件并忽略早期版本中未实现的功能。比如USB1.0能够兼容USB3.0，或者是MS office2003能够使用转换器打开MS office2007的文件，并忽略MS office2007 的新功能。
向后兼容性测试(backward compatibility testing)：测试的应用程序或者软件处于旧版本，并且应用程序的新版本能够顺利处理旧版本的程序数据。比如说USB3.0兼容USB1.0，或者MS office 2007能够打开MS office 2003的文件。
从兼容性测试的概念中得知，软件的运行与操作系统类型及版本（windows、linux、mac等）、浏览器种类及版本（IE、火狐、谷歌等）、网络环境的带宽、数据库种类和版本（SQL、DB2、MySQL、Oracle等）、外接设备（打印机、传真机等）、其他相关软件（MS office、SharePoint等）等因素有关，那么最终用户使用的环境我们不得而知，但在资源和时间有限的情况下，我们要尽可能的模拟用户使用的环境去确保我们的开发软件能够正确使用。所以兼容性测试是检查的是所有平台的应用程序的工作方式。通常开发团队和测试团队的测试是在单一平台中进行展开。但是，一旦发布应用程序，客户可以在不同的平台测试我们的产品，他们可能会发现在应用程序中的错误，要减少这些问题，在所有平台上测试应用程序是很重要的。换句话说，当最终的用户发现了应用程序的缺陷，这需要花费很多时间去开发补丁包去弥补错误的后果，但是经常发布产品补丁包会使用户感觉不安，所以产品的兼容性测试是无可避免的。
当build已经相对稳定的时候就进行兼容性测试。
以浏览器兼容性测试实例展开，讨论在软件兼容性测试中要测试什么：
综上所述，对于浏览器的兼容性测试，我们要验证的是页面、字体大小和样式、特殊字符的编码、图像对齐与否、页面的头尾、页面对齐与否、文本对齐与否、控件的对齐情况、页面的放大放小测试、数据库提交信息验证、HTML视频播放格式验证、外部网站开发的插件验证、关闭cookies和javascript后的页面验证等。还有其他的验证内容，可以通过探索性测试中提到的一些方法，进行测试。如破坏测试法，懒汉测试法，一送一测试法，配角测试法，卖点测试法，指南测试法，超模测试法等等，可以将探索性测试用于软件的兼容性测试，更加有方向的进行兼容性测试。
测试人员和最终用户。测试人员只能模拟出大部分用户使用的环境进行软件的兼容性测试，尽可能的使大多数的用户在使用中出现较少的问题，由于时间和资源的有限性，不能够模拟出所有用户的环境，所以兼容性测试前期是测试人员进行的大范围的扫除盲点，加上后期用户的共同努力，来提升软件质量。
在执行兼容性测试之前要理解，在什么平台，怎样的环境，去验证哪个软件的兼容性，去根据对软件以及环境的认识，去制定有测试计划和测试策略的test plan (Test plan中包括了Test Scope, Test Strategy, Hardware, Test Schedule )，引入一些常用的测试方法，如探索性测试，手工测试，自动化测试，冒烟测试等方法，将软件的兼容性测试做活，不那么生硬，尽可能的找到更多之前没有发现的bug。 指定完test plan，就是执行这一轮的兼容性测试，配置相应的环境，采用局部自动化测试 + 手工测试的原则，去检测软件是否存在兼容性问题，完成这一轮CT，后signoff。
转载：软件兼容性测试
错误观念：软件测试不需要版本控制
测试人员在测试过程中发现的bug提交给开发人员，开发人员在对提交的bug进行修改，bug修改后开发人员会将修改后的代码放入当前的软件版本之中，这样一来二去，会导致软件测试版本发布过于频繁，测试版本不稳定，导致修改过的bug再次出现，测试重复、失效和混乱。测试进度无法保证，同时不便于追溯跟踪问题。
原因是：对于修改过的代码，不能够保证他们一定是正确的，很可能在开发人员修改过之后，仍然是错误的，或者在修改过之后仍然会给软件带来别的问题，测试人员对新提交的代码以及之前的代码都要再次进行验证，进行排错，来确保不会因此而带来新的隐患，新的漏洞，导致大量重复测试。
引入版本控制的好处：提高开发和测试的效率，提高软件版本稳定性，便于追溯问题。
版本控制对象
开发提交给测试的产品版本。
测试人员提交的bug到了开发人员手中之后，开发人员针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本，而不能直接替换到现有的测试版本中去。
版本控制定义
测试版本的交付在专人控制之下，对每次测试的版本有明确的标识（新增加的功能、修复的bug等），不同版本可以看到稳定度趋势，每个版本的测试状态。
制定合理版本发布计划，加强版本控制管理
协商测试版本发布及发布频率：制定版本进度计划，该计划中包括开发团队提交不同版本的计划时间、每个版本中新增功能模块列表、提交版本的要求、修复的bug列表等。
测试版本发布基础：代码评估（代码review），版本控制的文档（标识新增或修改的功能、修复的bug、能够很方便的跟踪和监控测试版本的执行）
测试启动条件：功能是否开发完成、有没有进行自测（避免出现版本质量太差）、软件版本说明。
提测后注意事项：非错误修正（Bug fix）的修改，必须说明（如代码重构）；错误修正涉及的代码，明确回归范围和影响范围（避免修复bug是修改共同文件，引起全局问题）。
强化测试准入条件
测试启动条件：功能是否开发完成、有没有进行自测（自测报告，避免出现版本质量太差）、软件版本说明（清楚每一次版本更新都修改了什么，会对哪些功能造成影响）。
开展冒烟测试：保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断，如果最基本的测试都有问题则直接打回。
（开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。）
冒烟测试的通过标准：基本的功能和流程通过就可以。（测试场景/点可以提供）
软件提测后注意事项：非bug fix的修改，必须周知（如重构），Bug fix涉及的代码，代码review，明确回归范围，减少质量隐患。
强化bug管理
bug内容（发现版本，对应人员，发现模块，回归次数，bug关闭的版本号），可以分析不同版本和不同模块bug走势。
发现此次迭代范围外的之前遗留的bug，测试记录后，和开发及项目管理人员商讨是否解决，解决方式（代码限制OR操作说明中限制），是否占用此次迭代的开发时间。
版本控制文档管理工作
版本信息、测试记录、测试结果（开发和测试活动的追溯）
最后，就是要做到及时沟通
这个没的说，效率和质量。
测版本最多不超过4轮测试
一般控制在3轮。一般在2到3个版本时，就很难发现缺陷。版本越多，质量隐患越大。
保证开发和测试的独立性
打的包，部署的环境。测试环境和开发环境分开，尽量做到测试数据不会被开发人员修改。
明确测试需求
需求功能点全部实现，如果有需求不能在规定时间完成，需要在需求阶段提出，而不是在测试阶段完善需求，从而加长了开发和测试时间，影响效率。
细化提测标准
开发到什么程度可以接受测试。
预测试
达到送测标准，在服务器上取下测试的版本，编译、部署后，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。
控制需求的变更
变更了软件需求一定要有记录和说明，相应的测试用例及时追加和维护。
进行bug分级
界面和易用性的bug等到开发完成和重要bug解决完毕再改。
增强质量意识
上线前临时改代码修复问题或者临时口头追加的变动要有记录，要通知一下。
开发文档和产品需求文档生成或者变动后请周知一下，保证测试用户及时编写和维护。
测试环境最好是专人维护（开发、运维、测试），频繁和擅自发布新功能或者修改是不可取的。保证版本的统一性很重要。
测试人员提交的bug到了开发人员手中之后，开发人员针对这些bug进行修复工作，并且将修改后的代码放入程序中，作为新的软件版本，而不能直接替换到现有的测试版本中去。
代码提交 ，review后再部署，直接打包部署的代码不能保证完整 （提交冲突，合代码后发布失败等）
扯了半天淡，我们用什么来做测试呢？
测试管理工具（项目流程管理）
功能测试工具（自动化脚本测试）（黑盒）
性能测试工具（黑盒）
代码测试工具（白盒测试）
开源测试管理工具：
开源功能自动化测试工具：
Web Application Testing in Ruby，发音类似water。它是一种基于网页模式的自动化功能测试工具。开源性能自动化测试工具：
情商素养
专业技能
软件基础知识
业务能力
互联网行业的薪资水准相对较高，入行一年超过其他行业薪资很正常。
互联网行业究竟有哪些职位呢，又分别适合哪些传统行业转型？
标签：天气 图灵 bugfree 定制 开发人员 事故 视频播放 设置 集合
原文地址：https://www.cnblogs.com/saoqiang/p/11846038.html
