测试基础
测试基础
为什么需要软件测试？
回到顶部
很多时候：
- 每当LOL更新一个新英雄或者某个英雄太强，场场五杀，由于过分变态，游戏玩家纷纷投诉，这个英雄太bug了！赶紧把刀妹削弱了！这个英雄的手太长了，让我们削弱刀妹吧！
- 菜逼如你在玩火热的吃鸡（绝地求生）时，要不是有系统保护，可能在落地之前就被干死了，落了地还没见着人，就被啪啪啪给打死了，你肯定大喊一声，这他娘的有bug！快把老子的8倍镜拿过来，看看是哪个菜逼开的枪！！！
- 再比如大家现在都喜欢用微信支付宝，如果你滴扫一下，你的微信提示你扣款了998元，但是商家说没收到，咋办？是跑路还是再交一次钱？这个就是严重的bug！！
一款软件的诞生经历很多个阶段，每个阶段都有不同的人员参与，所以最终产品会或多或少的问题，因此为了保证软件的可用性，所以，我们必须经过测试环节，减少软件的问题。
哪个程序员也不敢说写的程序没有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非常令人讨厌。但同时有缺陷的软件还有可能造成重大甚至致命的事故。下面是一些非常有名的软件事故：
- 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、DB2、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
- 架构师
- 运营