测试基础

时间 2019-11-17

标签测试基础繁體版

原文原文链接

目录javascript

为何须要软件测试？回到顶部

不少时候：css

每当LOL更新一个新英雄或者某个英雄太强，场场五杀，因为过度变态，游戏玩家纷纷投诉，这个英雄太bug了！赶忙把刀妹削弱了！这个英雄的手太长了，让咱们削弱刀妹吧！
菜逼如你在玩火热的吃鸡（绝地求生）时，要不是有系统保护，可能在落地以前就被干死了，落了地还没见着人，就被啪啪啪给打死了，你确定大喊一声，这他娘的有bug！快把老子的8倍镜拿过来，看看是哪一个菜逼开的枪！！！
再好比你们如今都喜欢用微信支付宝，若是你滴扫一下，你的微信提示你扣款了998元，可是商家说没收到，咋办？是跑路仍是再交一次钱？这个就是严重的bug！！

一款软件的诞生经历不少个阶段，每一个阶段都有不一样的人员参与，因此最终产品会或多或少的问题，所以为了保证软件的可用性，因此，咱们必须通过测试环节，减小软件的问题。html

哪一个程序员也不敢说写的程序没有bug！可是咱们使用的软件，基本上不多见到bug，这和软件测试是分不开的。前端

so，一个提供业务访问的软件，必须在严格测试，经过层层测试环境才能够正式的上线。就像游戏同样，也基本是先提出内测版，最后才是公测版，就是公司在验证程序的正确性！！java

为何选择软件测试行业？回到顶部

发展前景python

就目前而言，相对于国外的软件测试行业来讲，国内的测试行业稍显落后，因此国内的软件测试行业对于专业的测试人员需求慢慢变大。mysql

装逼语录linux

有人喜欢创造世界，因此，他们作了程序员。ios

有人喜欢拯救世界，因此，他们作了测试员。程序员

其余

知乎上已经有了优秀的答案。

为何不让开发本身作测试？回到顶部

首先，开发不是不能作测试，甚至有的测试人员以前都作过开发。

而是说，软件测试和软件开发分属软件行业中两个不一样的技术方向。因此，一个半吊子开发不如一个专业的测试！这就是专业度的问题了。

从逻辑角度来讲，开发人员大多数时间都在思考如何实现具体的功能。而做为测试人员，大多数时间都站在用户的角度思考如何挑出软件的问题。

从测试力度来讲，软件对于开发人员来讲，那就是本身的孩子，我家孩子怎么可能有毛病？你家孩子才有毛病！这就会致使本身测试本身写的软件，下手可能不够狠！

什么是测试？回到顶部

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很是使人讨厌。但同时有缺陷的软件还有可能形成重大甚至致命的事故。下面是一些很是有名的软件事故：

1962年，水手号火箭的致命BUG。经济损失：1850万美圆
1962年，携带空间探测器的水手1号火箭前往金星，在起飞后不久就偏离了预约航线。任务控制在起飞293秒后摧毁了火箭。事故的原由就在于一名程序员把一条手写的公式抄写为错误的计算机代码。从而将火箭引导偏离了航向。
1979年，新西兰航空公司的一架客机因计算机控制的自动飞行系统发生错乱，撞上了阿尔卑斯山，致使257名乘客遇难。几乎引起的第三次世界大战.。
1983年, 苏联导弹预警系统错误地报告遭到美国发射的5枚导弹攻击. 但幸运的是,当时的负责人认为若是美国真的要攻击的话, 发射的决不仅是5枚导弹. 最终没有酿成大灾难。
2012年，苹果IOS 6系统首次使用地图服务，因为诸多定位出现错误，引起大批量用户投诉，48小时内有1000万个用户投诉Google地图。
拼多多近期出现一个重大bug，程序员误改了代码，本来100元的中国移动充值卡，一分钱就能够购买，很短的时间内就损失了大量金额财产，这已经触犯了刑事责任。

所以公司中进行软件测试，是必须的！

软件测试常见的误区回到顶部

调试和测试是同样的。
测试组应该为保证质量负责。
过度依赖beta测试（验收测试）。
把测试做为新员工入职的一个过渡过程。
把不合格的开发人员安排作测试。
关注于测试的执行而忽略测试的设计。
测试自动化是万能的。
测试是能够穷尽的。
测试为了保证软件的正确性。
测试是枯燥乏味，缺少创造力的工做。
过渡测试度量软件的质量。

软件测试的主要工做回到顶部

检查代码，评审开发文档。
进行测试设计、写做测试文档、测试计划、测试方案、测试用例等等。
执行测试、发现软件缺陷，提交缺陷报告，并追踪缺陷修复的过程。

测试原则回到顶部

测试原则是指在执行测试工做时必需要遵照的一些规则：

测试证实软件存在缺陷，不管执行什么样的测试操做，都能保证当前软件是有缺陷的。
不能执行穷尽测试，有些功能是没有办法将全部的状况都罗列出来，因此任何的测试操做都有结束的时间。
缺陷存在群集现象，首先要了解一个二八理论，即对于软件的功能来讲，核心功能占20%，非核心功能占80%（固然，不是绝对的）。那么在测试中，咱们会集中测试20%的核心功能。因此，这部分发现缺陷的几率会远高于80%非核心部分。也所以咱们遇到的缺陷就都会集中在20%的核心功能这块。
某些测试须要依赖特殊的环境，毋庸置疑，有些测试依赖极端的条件，这种条件有时候很难知足。
测试应尽早介入，越早的发现和解决软件存在的缺陷，咱们应该尽量的尽早展开测试。
杀虫剂现象，一样的测试用例不能重复执行屡次，由于软件会对它产生免疫。好比说，你用3 * 3测试出代码不等于9，把这个缺陷提交给开发，开发随后解决了这个bug，那咱们再测试的时候，就不要用3 * 3来测试了，由于开发在改bug的时候，想法设法的让3 * 3 = 9，因此，一样的用例，软件会对它产生免疫。
不存在缺陷谬论，任何软件不多是完美的。

测试对象回到顶部

对于当前的测试行业来讲，咱们最常测试的主体就是软件（主体功能），但须要咱们测试的也不只仅是功能需求测试。咱们能够将软件分为三个部分组成：

功能集合
使用说明书
配置数据

一款软件的诞生会经历不一样的过程，咱们将整个过程分为不一样的阶段，而后每一个阶段都会有相应的测试对象。那么每一个阶段咱们能进行什么测试呢？

需求分析阶段，各类需求规格说明书，好比说以当前的技术手段可否实现，市场上是否存在相似的软件。这个时候会产生相应的说明书。
软件架构设计，由CTO或一把手，整体构建软件的架构，而后生成API接口文档（接口测试），而后交由专门的开发去具体实现。
具体编码阶段，这个时候，咱们的测试对象就是源代码，（但这对测试水平要求过高），因此，咱们会进行相应的白盒测试、单元测试。
系统功能使用，软件功能主体测试，也就是目前测试行业作的作多的一种测试，测试人员充当用户进行软件使用、测试。

软件架构回到顶部

所谓的软件架构，简单理解为是用来指导软件开发的一种思想，目前来讲，最多见的两种架构模式：

B/S，浏览器和服务端。
C/S，客户端和服务端。

两种架构的比较：

效率，B/S架构的数据都是由服务器端处理，浏览器只负责展现结果，因此对于服务端压力相对较大，而C/S架构的客户端能够承担一些数据处理，因此执行效率高。
安全，B/S架构的数据都根据HTTP协议进行的，因此安全性相对于C/S架构来讲，安全性相对低一些。
升级，B/S架构的升级只需升级服务端便可，而C/S架构则须要两端都须要升级更新。
开发成本，相对于B/S架构来讲，C/S架构的客户端也须要本身开发，因此成本会高一些。

再来补充两个知识点：

浏览器

浏览器本质上是一款软件，安装在操做系统之上，为用户提供网页浏览服务，目前，世界主流的五大生产厂商：

IE（Windows Internet Explorer）：IE4以上版本都是Trident内核。因为垄断性，IE在很长一段时间内没有更新，致使两个后果：一是IE与W3C标准脱节，二是Trident内核大量的bug问题没获得及时解决。因此这就给了其余浏览器机会，好比firefox等。也正是这些缘由，使Web前端开发人员大费折，特别是IE6正处在新旧交替的关键地方（已经逐渐被舍弃），目前微软家的最新浏览器edge的内核也是采用谷歌家的内核了。
Chrome（Google Chrome）：谷歌浏览器以前一直使用苹果的webkit内核，可是如今它与苹果内核分道扬镳，本身开创了新的blink内核，这个内核也在被欧鹏（opera浏览器）共同采用和开发。
Safari（苹果）：使用的是苹果公司本身的内核webkit
Opera（欧朋）：最开始是presto，目和Chrome一块儿使用blink。
Firefox（Mozilla Firefox）：gecko。

国内的浏览器及内核：

搜狗浏览器：兼容模式（IE：Trident）和高速模式（webkit）
傲游浏览器：兼容模式（IE：Trident）和高速模式（webkit）
QQ浏览器：普通模式（IE：Trident）和极速模式（webkit）
360极速浏览器：基于谷歌（Chromium）和IE内核
360安全浏览器：IE内核

对于浏览器来讲，最核心的技术，就是浏览器内核，固然，仅作了解便可。

图片

常见的图片类型有：

jpg（jpeg），能够高度保留图片色彩信息的图片格式，常见与互联网客户端。
png，该类型的图片，能够实现透明。
gif，图片所占体积小，能够实现动图。
psd，分层的图片。

常见项目组织架构回到顶部

项目组通常由项目经理领导并负责指定项目计划，分配任务。

参与人员：

分析人员。
设计人员。
开发人员。
测试人员。
配置管理人员。软件研发过程的仓库管理员，包括产品，文档等等。
SQA，软件质量保证，监控整个软件研发过程。

软件测试用例回到顶部

生活中，处处都是测试案例，好比你买个手机，买个显示器，都要测试一下，开关机、屏幕是否有漏光，按键是否好使、这些都是测试用例。

咱们须要知道测什么和怎么测这两个问题。

什么是测试用例回到顶部

测试用例的定义

测试用例（Test Case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否知足某个特定需求，经过大量的测试用例来检验软件的运行效果，它是指导测试工做进行的重要依据。

举个例子

好比咱们买个电脑，要进行测试。

测试的前提条件

按下开机键，至关于输入一组测试数据，执行的条件是，是否达到开机的前提条件，好比电池是否有电，或者外接电源是否接入。

测试过程

按下开机键。

预期结果

当咱们按下开机键，顺利的启动成功，那么在有电的前提下，启动成功就是咱们的预期结果。

经过上面的测试过程，就会发现，测试用例主要解决的就是测什么？怎么测？

为何须要测试用例回到顶部

测试用例的优点在于：

避免盲目测试，提升测试效率，使测试活动规范有序
减轻测试设计的工做量，减小回归测试的复杂程度
根据测试用例的多少和执行难度，估算测试工做量，便于追踪项目的时间进度和资源分配。

测试用例的意义回到顶部

测试用例是软件测试的核心。
- 软件测试的重要性是毋庸置疑的，测试用例是测试工做的指导，是软件测试质量稳定的根本保障。
- 影响软件测试的因素不少，如软件自己的复杂程度，开发质量，测试方法和技术的运用。也有客观因素存在，如人员变更，环境，情绪等。
评估测试结果的基准。
测试用例的经过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否能够经过，可否达到上线的标准。
保证测试的时候不遗漏测试功能点。能够对测试工做进行牵引。
在编写测试用例的过程，能够熟悉需求，对系统架构或者业务流程有一个总体深刻的了解。

测试用例的生命周期回到顶部

测试环境设计回到顶部

测试环境(TE)

为了运行被测软件、完成测试工做所必须的硬件、软件和网络环境的集合。
稳定可控的测试环境可使测试人员花费较少的时间，完成测试用例的执行。

测试环境内容包括

硬件环境
软件环境
网络环境
测试数据
测试工具

测试环境设计原则

尽量用真实的环境，少用模拟器和虚拟机。
机器配置根据软件不一样，不得低于软件运行最低要求。
选择主流的操做系统以及软件平台，例如ios系统 Android系统。
测试环境要干净、独立、排除干扰。例如无用的杀毒软件，无用的播放器等等，性能测试中，突然蹦出个漏洞修复程序，那必然影响测试结果。

测试环境所需的知识

常见操做系统安装使用
安装程序所需驱动，解决驱动报错问题
数据库使用
浏览器调试
模拟器和虚拟机的使用
系统镜像和备份与还原工具的使用

测试用例的八大要素

用例编号：产品名字-测试阶段
测试项目：对应一个功能模块
测试标题：直接对测试点进行细化得出
重要级别：高/中/低
预置条件：须要知足一些前提条件，不然用例没法执行
测试输入：须要加工的输入信息，根据具体状况设计
操做步骤：明确给出每一个步骤的描述，执行人员根据该步骤执行工做
预期结果：根据预期输出对比实际结果，判断被测对象是否符合需求。
实际结果：根据实际结果，填写报告。(可写可不写)

输出测试用例

excel
word
HTML

最后，上图：

测试力度回到顶部

测试用例力度

测试用例能够写的很简单，固然也能够写的很是复杂。

最简单的测试用例是测试的纲要，仅仅指出要测试的内容。
测试用例写的过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并无进行“设计”，只是须要把测试的功能模块记录下来而已，它的做用仅仅是在测试过程当中做为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。
最复杂的测试用例则会指定输入的每项数据，期待的结果即检验方法，具体到界面元素的操做步骤，指定测试的方法和工具等。

测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另外一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思惟。
ps:大多数的测试团队编写的测试用例的力度介于二者之间。

测试用例的本质
测试用例的设计本质（测什么？怎么测？）应该是在设计的过程当中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导未来的测试。
基于需求的测试用例设计：

基于需求的用例场景来设计测试用例是最直接有效的方法，由于它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
要把测试用例当成活的文档，由于需求是活的，善变的。所以在设计测试用例方面应该要把敏捷方法的及时响应变动比遵循计划更有价值这一原则体现出来。

不要认为测试用例设计是一个阶段，测试用例的设计也须要迭代，在软件开发的不一样阶段都要回来从新评审和完善测试用例。

软件测试计划书回到顶部

计划书是什么

测试计划是一个叙述了预约的测试活动的范围、途径、资源以及进度安排的文档，咱们亲切地称为测试计划书。
此文档确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。

为何要指定测试计划书

定制测试计划使得软件测试是有计划，有组织的软件质量保证活动。若是没有计划，工做就会很松散，随意。

测试计划的意义回到顶部

测试计划

测试范围
测试策略
测试资源
测试进度
测试风险

测试流程规范

测试模型
传统金字塔形
冰淇淋模型
菱形模型
测试过程改进

参考：http://www.testclass.net/post/test_level

测试计划书内容包含哪些内容

人力以及时间资源分配
责任划分
风险控制

测试目标回到顶部

产品的质量目标

测试已实现的产品是否达到设计的要求。
产品规定的操做是否实现，运行是否稳定。

测试活动的质量目标

全部的测试用例所有执行。
全部自动化脚本都已经经过。
全部严重级别的缺陷已经被修复。

资源配置回到顶部

人力资源

须要多少名测试人员
测试人员须要具有什么技能
是否须要岗前培训

测试环境资源配置
硬件资源：服务器，计算机，手机，打印机
软件资源：不一样平台的操做系统，数据库软件，多种浏览器
网络环境：在什么网络环境下测试，是内网仍是外网
测试工具：都是使用哪些工具

风险控制回到顶部

风险指：不可预料的后果，如事件，危险，威胁等特殊状况的发生。

客观性风险：

客观性因素，没法规避的风险：
人手不够了，短时间也没法招到合适的人
同事生病请假了
开发团队不能如期交付代码
测试环境所需的环境，脚本，数据等没有提供好，没法进行。
没法彻底控制风险，只能遵循规律，下降风险形成的影响。

如何制定测试计划回到顶部

1.任务送达

测试经理接到软件测试需求书和需求说明

2.分析测试任务

充分理解被测试软件的需求。
评估被测试软件的进度，状态，复杂度和风险

3.资源规划

组件测试团队
准备人力资源

4.制定测试计划

研究肯定测试计划的各项内容

5.评审测试计划

测试团队共同参与评审测试计划。

5W1H方法回到顶部

what 对象

测试什么
测试是什么类型
被测软件有什么特色
测试环境是什么

when 时间

何时开始测
何时提交缺陷报告
何时结束测试

why 缘由

为何要作此项测试

who 有谁参与

软件提供给谁去用
谁来执行测试用例

where 场所

在哪里进行软件测试
测试到哪个步骤算是完成

how 方法

如何进行测试
如何编写测试用例书
如何控制风险

工做经验之谈回到顶部

计划是死的，人是活的....

目的性引导去规划测试进度，而不只仅是为了写计划而计划。
保证本身的计划书能够随着变化而调整。
测试计划须要整个测试团队来共同评审和执行。

图解软件测试计划回到顶部

这年头，没有图过不了啊，虽然朕不看！

软件计划报告回到顶部

最后，来看软件计划报告。
软件测试基础流程：通常是测试主管编写测试计划，测试计划是指在作完需求分析后，在开始整个测试工做以前的准备计划工做。

遵循5W + 1H原则进行测试：

why 测试目的
what 测试范围
when 测试进度安排
who 测试人员
where 测试环境
how 测试方法测试工具
产品测试风险评估

测试报告范围：

测试范围
测试环境
遗留bug
测试用例覆盖率
bug统计与分析
风险检测
版本测试评估
发布的建议

软件兼容性回到顶部

5W1H思想很流行啊！由于咱们将基于这个思想来阐述软件的兼容性测试！

what，什么是软件兼容性测试回到顶部

软件兼容性测试既是测试被测试软件可以与操做系统、网络环境、浏览器、相关其余软件（包括数据库）、外接设备等可以友好合做，不出现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的文件。

why，为何要进行软件兼容性测试回到顶部

从兼容性测试的概念中得知，软件的运行与操做系统类型及版本（windows、linux、mac等）、浏览器种类及版本（IE、火狐、谷歌等）、网络环境的带宽、数据库种类和版本（SQL、DB二、MySQL、Oracle等）、外接设备（打印机、传真机等）、其余相关软件（MS office、SharePoint等）等因素有关，那么最终用户使用的环境咱们不得而知，但在资源和时间有限的状况下，咱们要尽量的模拟用户使用的环境去确保咱们的开发软件可以正确使用。因此兼容性测试是检查的是全部平台的应用程序的工做方式。一般开发团队和测试团队的测试是在单一平台中进行展开。可是，一旦发布应用程序，客户能够在不一样的平台测试咱们的产品，他们可能会发如今应用程序中的错误，要减小这些问题，在全部平台上测试应用程序是很重要的。换句话说，当最终的用户发现了应用程序的缺陷，这须要花费不少时间去开发补丁包去弥补错误的后果，可是常常发布产品补丁包会使用户感受不安，因此产品的兼容性测试是无可避免的。

when，何时开始软件兼容性测试回到顶部

当build已经相对稳定的时候就进行兼容性测试。

where，软件兼容性测试都要测什么回到顶部

以浏览器兼容性测试实例展开，讨论在软件兼容性测试中要测试什么：

CSS、HTML和XHTML验证
页面验证
字体大小和字体样式验证
带有HTML字符编码的特殊字符
全部图像对齐
页眉和页脚
页面对齐
控件对齐(项目符号、单选按钮、复选框应在各类浏览器上选中)。
应该正确地测试页面放大和缩小
验证提交给数据库的信息
HTML视频格式:视频格式应该验证,由于全部的IE9浏览器不支持全部格式的视频例子给mp4,只支持firefox支持mp4和.webm若是咱们Chrome那么它支持几乎mp4, .webm .ogm和其余视频格式。
文本对齐方式
Flash内容应该进行测试
在关闭cookie和浏览器Javascript时测试页面，在打开cookie和浏览器Javascript时测试页面
外部站点开发的插件:一些jQuery插件可能没法正常工做，好比IE8中的打印功能或播放视频时的旋转木马。
CMS兼容性:确保了解内容管理系统支持的浏览器，并主要关注该浏览器而不是其余浏览器。

综上所述，对于浏览器的兼容性测试，咱们要验证的是页面、字体大小和样式、特殊字符的编码、图像对齐与否、页面的头尾、页面对齐与否、文本对齐与否、控件的对齐状况、页面的放大放小测试、数据库提交信息验证、HTML视频播放格式验证、外部网站开发的插件验证、关闭cookies和javascript后的页面验证等。还有其余的验证内容，能够经过探索性测试中提到的一些方法，进行测试。如破坏测试法，懒汉测试法，一送一测试法，配角测试法，卖点测试法，指南测试法，超模测试法等等，能够将探索性测试用于软件的兼容性测试，更加有方向的进行兼容性测试。

who，谁来执行软件兼容性测试回到顶部

测试人员和最终用户。测试人员只能模拟出大部分用户使用的环境进行软件的兼容性测试，尽量的使大多数的用户在使用中出现较少的问题，因为时间和资源的有限性，不可以模拟出全部用户的环境，因此兼容性测试前期是测试人员进行的大范围的扫除盲点，加上后期用户的共同努力，来提高软件质量。

how，怎样执行兼容性测试回到顶部

在执行兼容性测试以前要理解，在什么平台，怎样的环境，去验证哪一个软件的兼容性，去根据对软件以及环境的认识，去制定有测试计划和测试策略的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后再部署，直接打包部署的代码不能保证完整（提交冲突，合代码后发布失败等）

转载：软件开发&测试版本控制说明

经常使用测试工具回到顶部

扯了半天淡，咱们用什么来作测试呢？
测试管理工具（项目流程管理）

惠普HP QC TD
国外工具 JIRA 使用最多，易用性强
国内工具禅道

功能测试工具（自动化脚本测试）（黑盒）

惠普HP QTP(脚本录制工具，解放重复的点击等工做) vbs语言脚本
Selenium

性能测试工具（黑盒）

HP LoadRunner (使用人数最多，易用，收费软件)
Apache Jmeter(免费)

代码测试工具（白盒测试）

JUnit

开源测试管理工具：

Bugfree，BugFree是借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug管理系统。简单实用、免费而且开放源代码(遵循GNU GPL)。命名BugFree 有两层意思：一是但愿软件中的缺陷愈来愈少直到没有，Free嘛；二是表示它是免费且开放源代码的，你们能够自由使用传播
Bugzilla，Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它能够管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。Bugzilla是一开源Bug Tracking System，是专门为Unix定制开发的。
TestLink，TestLink 是基于web的测试用例管理系统，主要功能是测试用例的建立、管理和执行，而且还提供了一些简单的统计功能。
mantis，缺陷管理平台Mantis，也作MantisBT，全称Mantis Bug Tracker。Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操做的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以知足中小型项目的管理及跟踪。更重要的是其开源，不须要负担任何费用。

开源功能自动化测试工具：

Watir，Watir全称是Web Application Testing in Ruby，发音相似water。它是一种基于网页模式的自动化功能测试工具。
Selenium，Selenium 是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操做同样。支持的浏览器包括IE（7, 8, 9, 10, 11），Mozilla Firefox，Safari，Google Chrome，Opera等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否可以很好得工做在不一样浏览器和操做系统之上。测试系统功能——建立回归测试检验软件功能和用户需求。支持自动录制动做和自动生成 .Net、Java、Perl等不一样语言的测试脚本。
MaxQ，是开源的Web功能测试工具。
WebInject，WebInject是一个用于自动测试web应用程序和web服务的免费工具。它能够用来测试具备HTTP接口的各个系统组件(JSP、ASP、CGI、PHP、AJAX、servlet、HTML表单、XML/SOAP Web服务、REST等)，而且能够用做测试工具来建立一套[HTTP级别]自动化功能、验收和回归测试。测试工具容许您运行许多测试用例并收集/报告结果。WebInject提供实时结果显示，也能够用于监视系统响应时间。WebInject能够用做一个完整的测试框架，由WebInject用户界面(GUI)控制。能够选择，它能够用做一个独立的测试运行器(文本/控制台应用程序)，能够从其余测试框架或应用程序集成和调用它。

开源性能自动化测试工具：

Jmeter，Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件作压力测试，它最初被设计用于Web应用测试，但后来扩展到其余测试领域。它能够用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器，等等。JMeter 能够用于对服务器、网络或对象模拟巨大的负载，来自不一样压力类别下测试它们的强度和分析总体性能。另外，JMeter可以对应用程序作功能/回归测试，经过建立带有断言的脚原本验证你的程序返回了你指望的结果。为了最大限度的灵活性，JMeter容许使用正则表达式建立断言。Apache jmeter 能够用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。它能够用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不一样压力类型下的总体性能。你可使用它作性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
OpenSTA，OpenSTA是一个免费的、源代码开放的性能测试工具,基于CORBA(Common Object Request Broker Architecture)的结构体系。它是经过虚拟一个代理服务器,使用专用脚本控制语言,记录经过代理服务器的一切HTTP/Straffic。测试工程师经过分析OpenSTA的性能指标收集器收集的各项性能指标,以及HTTP数据,对被测试系统的性能进行分析。
DBMonster， DBMonster 是一个Java的开源项目，经过JDBC方式链接数据库，所以能够在任何支持Java和JDBC的平台上运行。DBMonster开发的原意是为数据库开发者服务，能够协助产生大量的规则或不规则数据，便于数据库开发者基于这些数据进行数据库的调优。DBMonster经过两个XML文件（配置文件和 schema文件）控制数据产生的行为，配置文件指明须要链接的数据库、链接使用的用户名和口令、须要操做的sheme、重试次数等全局设置，而 scheme文件则指明针对每张数据表的每一个字段产生数据的规则。
Web Application Load Simulator，LoadSim是一个web应用程序负载模拟器。它容许您建立模拟并在web服务器上运行这些模拟。

软件测试工程师回到顶部

软件测试工程师的技能要求回到顶部

情商素养

责任心
良好的沟通能力，协做能力
耐心与细心
严谨的态度和态度

专业技能

软件工程学
软件测试流程
软件测试技术
软件测试管理
软件开发基础

软件基础知识

计算机硬件了解
操做系统
数据库
网络

业务能力

对产品需求的了解
业务的逻辑清晰
站在用户角度思考产品

软件测试工程师的职业发展回到顶部

互联网职业分类回到顶部

互联网行业的薪资水准相对较高，入行一年超过其余行业薪资很正常。
互联网行业究竟有哪些职位呢，又分别适合哪些传统行业转型？

产品经理（Product Manager）
UI设计
前端设计（css/html/js）
后端（python/golang/java）
DBA(mysql/oracle)
运维（linux）
测试（software testing）
算法工程师
大数据工程师（Hadoop）
Android、IOS
架构师
运营