测试简介及基本流程

为什么需要测试

很多时候：

每当王者荣耀更新一个新英雄或者某个英雄太强，场场五杀，由于过分变态，游戏玩家纷纷投诉，这个英雄太bug了！赶紧削弱了！这个英雄的手太长了，让我们削弱他吧！
假如你在玩火热的吃鸡（绝地求生）时，要不是有系统保护，可能在落地之前就被干死了，落了地还没见着人，就被啪啪啪给打死了，你肯定大喊一声，这肯定有bug！垃圾游戏！！！
再比如大家现在都喜欢用微信支付宝，如果你滴扫一下，你的微信提示你扣款了998元，但是商家说没收到，咋办？是跑路还是再交一次钱？这个就是严重的bug！！

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

哪个程序员也不敢说写的程序没有bug！但是我们使用的软件，基本上很少见到bug，这和软件测试是分不开的。

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

为什么开发人员不自己做测试

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

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

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

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

什么是测试

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应尽可能的早，这样造成的影响越小，修复成本越低。而测试活动往往是在时间和人力成本受限的情况下进行，在有限的资源下，测试人员应该有的放矢，对测试对象的进行选择排序，测试技术进行选择组合使用，这也是测试策略方面的东西。

说点人能听懂的。当你写的代码越多，你就越认同测试，曾经听过一个很贴切的比喻：写程序的人就像在造没有护栏的桥，自己去走那肯定安全无虞，那怕摸黑也不至于掉河里去；测试则像给桥修护栏的，让桥的普通使用者也能像开发那样来去自如。从这一点上说，测试远比开发重要。

总结，软件测试的定义：

通过手工或者相关工具，对被测对象进行测试操作。从而验证实际与预期结果是否存在差异。

软件测试出现的原因

软件复杂度

程序代码的复杂度，软件产品的并发性，复杂性越来越高，对程序的正确性检测也越来越高

行业竞争大

由于用户审美提升与需求越来越高，现在一个新闻类app，就有百度新闻，网易新闻，趣头条，今日头条，各家公司都想做到完美，用户喜欢自己的产品，那就得从易用性，美观性，趣味性，快速性，等等等等方面超过其他的产品，那么大公司都会配备专门的功能测试岗位，性能测试岗位，乃至于更强大的测试开发岗位。

软件测试的作用

通过测试工作可以发现并修复软件中存在的缺陷，从而提高用户对产品的使用信心。

测试可以通过记录软件运行过程中产生的一些数据，从而为决策提供数据支持。

测试可以降低同类型产品开发遇到的问题风险。

软件测试的发展

国内处于起步和迅猛发展的阶段。大公司非常重视测试，初创型小公司对测试关注较少。主要还是手工测试为主，自动化测试为辅。

国外的软件测试基本成熟，软件企业非常重视软件测试部门。测试流程化体系严谨。一线大公司还会成立软件测试中心，服务于子公司的软件开发。

软件测试的目标

通过软件测试暴露软件中隐藏的错误和问题，便于考虑是否使用该产品。例如我们去买手机，总得反反复复的观察，这个手机的CPU性能怎么样？内存是多大的？拍照怎么样？

软件开发者的角度

通过软件测试证明软件中不存在错误和问题，给与自己产品质量足够的信心。
一个成功的测试，是不懈的挖掘软件的错误，不断的完善产品。
满足用户需求是产品成功的关键点。
确保交付的产品符合用户的需求。
在产品上线前尽可能的发现和修复bug。

用户角度

快看，摇了半天，终于有人加我微信了!

软件测试常见的误区

调试和测试是一样的。
测试组应该为保证质量负责。
过分依赖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）是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否满足某个特定需求，通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的重要依据。
	
比如我们买个电脑，要进行测试。
测试的前提条件：
	按下开机键，相当于输入一组测试数据，执行的条件是，是否达到开机的前提条件，比如电池是否有电，或者外接电源是否接入。

测试过程：
	按下开机键。

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

为什么需要测试用例

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

测试用例的意义

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

测试用例的生命周期

测试用例的八大要素

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

输出测试用例

excel
word
HTML

测试力度

测试用例力度

测试用例可以写的很简单，当然也可以写的非常复杂。

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

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

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

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

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

测试环境设计

测试环境(TE)

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

测试环境内容包括

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

测试环境设计原则

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

测试环境所需的知识

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

软件测试计划书

计划书是什么

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

为什么要指定测试计划书

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

测试计划的意义

测试计划流程

测试流程规范

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

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

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

测试目标

产品的质量目标

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

测试活动的质量目标

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

资源配置

人力资源

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

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

风险控制

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

客观性风险：

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

如何制定测试计划

1.任务送达

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

2.分析测试任务

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

3.资源规划

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

4.制定测试计划

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

5.评审测试计划

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

5W1H方法

what 对象

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

when 时间

什么时候开始测
什么时候提交缺陷报告
什么时候结束测试

why 原因

为什么要做此项测试

who 有谁参与

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

where 场所

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

how 方法

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

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

目的性引导去规划测试进度，而不仅仅是为了写计划而计划。
保证自己的计划书可以随着变化而调整。
测试计划需要整个测试团队来共同评审和执行。

常用测试工具

测试管理工具（项目流程管理）

惠普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设计(ps/ai/pr/ae)
前端设计（css/html/js）
后端（python/golang/java/c++）
DBA(mysql/oracle/mongodb/redis)
运维（linux）
测试（software testing）
算法工程师
大数据工程师（Hadoop）
Android、IOS(移动端开发)
架构师
运营
网络(路由交换/硬件存储等)
安全(渗透/web攻防/漏洞扫描)

最后更新于 2026-06-23

测试过程