引言

本文将讲解软件的概念、软件的生命周期、软件测试方法、软件测试常见模型、软件测试的覆盖率及软件测试规范，一步步带你进入软件测试大门。

一、软件基础

1.1 软件

1 软件的概念

软件是计算机系统中与硬件相互依存的另一部分，它是包括：程序、数据及其相关文档的完整集合

程序是按事先设计的功能和性能要求执行的指令序列

数据是使程序能正常操作信息的数据结构

文档是与程序开发，维护和使用有关的图文材料

2 软件十大特性

1）形态特性

软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它却是毫无意义的。

2）智能特性

软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题。

3）开发特性

尽管已有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当分量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素。

4）质量特性

软件是由人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件。

5）生产特性

与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限。

6）管理特性

由于上面5）特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特

7）环境特性

软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性。

8）维护特性

软件投入使用以后需要进行维护，但这种维护与传统行业产品的维护概念有着很大差别，维护体现在升级、优化、功能更新等方面。甚至可以全盘重构。

9）废弃特性

与硬件不同，软件并不是由于被“用坏”而被废弃的

10）应用特性

软件的应用极为广泛，如今它已渗透入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位

3 软件的分类

1.2 软件生命周期

1 基本概念

软件的生命周期，又称软件的生存周期。它是按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段。

每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产处高质量的软件。

2 生命周期流程

1）软件的一生

• 问题定义：确定好要解决的问题是什么（what）
• 可行性研究：确定该问题是否存在一个可以解决的方案（技术手段实现）
• 需求分析： 深入具体的了解需求
• 概要设计：设计出实现目标系统的几种可能方案，设计程序的体系结构
• 详细设计：详细的设计每个模块，确定实现模块功能所需的算法和数据结构
• 编码和单元测试
• 综合测试
• 软件维护

2）举例：余额宝

1.3 软件开发模型

1 基本概念

由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模式的变更。

2 各模型

1）瀑布模型

流程：计划 -> 需求分析 -> 设计 -> 编码 -> 测试 -> 运行维护

特点：

（1）软件开发的各项活动严格按照线性方式进行

（2）当前活动接受上一项活动的工作结果

（3）当前活动的工作结果需要进行验证

缺点：

（1）由于开发模型是线性的，增加了开发的风险

（2）早期的错误可能要等到开发后期的阶段才能发现

2）原型模型

流程：客户与开发公司紧密联系，开发周期长。开发会受到需求变更的影响。（重点在需求，边开发边改）

特点：

（1）实现客户与系统的交互

（2）进一步细化待开发软件需求

（3）开发人员可以确定客户的真正需求是什么

3）螺旋模型

流程：制定计划 -> 风险分析 -> 实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试） -> 客户评估

特点：

（1）螺旋模型是将瀑布模型与快速原型模型结合起来

（2）强调了其他模型所忽视的风险分析

（3）每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估

缺点：

（1）强调风险分析，但要求许多客户接受并相信这种分析，是不容易的。

4）敏捷模型

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。以人为本，每个阶段沟通多，重沟通，少文档，增加效率。

特点：

（1）短周期开发

（2）增量开发

（3）由程序员和测试人员编写的自动化测试来监控开发进度

（4）通过口头沟通、测试和源代码来交流系统的结构和意图

（5）编写代码之前先写测试代码，也叫做测试先行（测试先行）

缺点：

（1）团队的组建较难，人员素质要求较高

（2）对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试

3 阿里系开发模型变迁史

1.4 软件开发文档

• 需求分析文档
• 概要设计文档
• 详细设计文档
• 测试设计文档
• 测试用例
• 测试报告

二、软件测试基础

2.1 软件测试

1 定义与目的

经典定义：软件测试（Software Testing），在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

标准定义：软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

软件测试目的：在于发现问题，检查系统是否满足需求。

2 软件测试方法和分类

1）按生命周期划分

​ ①单元测试

​ ②冒烟测试

​ ③集成测试

​ ④系统测试

​ ⑤验收测试

2）按测试方法划分

白盒测试

​ ①静态分析：直接看代码、分析代码逻辑，不运行代码。

​ ②动态分析：执行代码。包括：
​ 逻辑覆盖测试，包括：语句覆盖、判定覆盖、条件覆盖、路径覆盖

​ 插桩测试

黑盒测试

​ ①功能测试：界面测试、冒烟测试、回归测试、业务测试、兼容性测试、易用性测试

​ ②自动化测试：WEB自动化测试、接口自动化测试

​ ③性能测试：性能测试、负载测试、压力测试、容量测试、并发测试、持久性测试

​ ④安全测试：手动臊面、自动化审计

灰盒测试

3）其他

随机测试、探索性测试、α测试、β测试

a测试：内部验收测试 客服、运维人员、客户方测试

b测试：内测后的公测

2.2 软件测试生命周期

1 项目进程与生命周期

1）测试生命周期：

单元测试：开发人员自测

集成测试：模块与模块之间的测试

模块间的接口联调，开发人员内部交互。A与B开发的模块之间进行调试

冒烟测试：主要功能流程的测试

烟筒是否可用，点把柴火。从功能测试中，筛选出用户使用最多的功能进行测试

系统测试：使用测试用例

验收测试：用户、需求方来测试

2）软件项目：20%功能为核心功能，有80%的用户使用！测试时，侧重测试20%的核心功能。

3）常见术语

C/S：C指的是客户端（Client）、S指的是服务器端（Server），如：QQ、各种网络游戏。

B/S：B指的是浏览器（Brower）、S指的是服务器（Server），如：搜狐、新浪等门户网站。B/S与C/S区别：便于维护和升级，是测试的重点；不需要安装客户端（Client），只需要有浏览器，就可直接使用

缺陷（bug、defect）：软件中（包括程序和文档）不符合用户需求的问题

测试环境：软件测试环境是软件运行的平台，包括：软件、硬件和网络的集合。用一个等式来表示：测试环境=软件+硬件+网络

测试用例（Test Case）：在测试执行之前设计的一套详细的测试方案、包括：测试环境、测试步骤、测试数据和预期结果。用一个等式来表示：测试用例=输入+输出+测试环境。其中：

• 输入：包括测试数据和操作步骤
• 输出：指的是期望结果
• 测试环境：指的是系统环境设置

冒烟测试（Smoke Testing）：在对一个新版本测试进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

α测试：验收测试的一种，指的是由：用户、测试人员、开发人员等共同参与的内部测试

β测试：验收测试的一种，指的是内测后的公测，即：完全交给最终用户测试

2.3 软件测试模型

1 V模型

瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。

V模型基于瀑布模型后期才能发现错、改错的缺点进行改进，在软件开发时开发活动和测试活动几乎同时开始，这两个并行的动态的过程就会极大的减少bug和error出现的几率。

2 W模型

一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或敏捷开发模型。

W模型从V模型演化而来，实际上开发是V，测试时并行的V；相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题。

3 其他模型：H模型、X模型

H模型：

真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。为了解决V模型和W模型存在的问题，有专家提出了H模型。

H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

X模型：

4 各模型总结

V模型：各流程环环相扣。测试在编码最后测试，前期开发错误，后期不容易更改

W模型：测试过程伴随整个开发周期，测试与开发同步执行

H模型：测试活动完全独立出来，贯穿整个开发周期，尽早准备尽早执行，某个阶段能测试就测试

X模型：分块化，探索式的测试

2.4 软件测试覆盖率

1 定义及特点

定义：覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量。覆盖率 = （至少被执行一次的item数） / item的总数

特点：

1）通过覆盖率数据，可以检测我们的测试是否充分

2）分析出测试的弱点在哪方面

3）指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加

4）覆盖率的审核：抽样验收

2 黑盒测试的覆盖率

分为两个方面：需求覆盖和用例覆盖

黑盒测试

• 用例覆盖：针对测试人员

• 需求覆盖：针对测试人员、产品方

白盒测试：针对开发人员

1）需求覆盖

定义：它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大。通过设计一定的测试用例，要求每个需求点都被测试到。

计算公式：需求覆盖 = （被验证到的需求数量） / （总的需求总数）

2）用例覆盖

定义：主要体现在我们每轮测试验证通过的用例数在总用例中的比重

计算公式：用例覆盖 = （验证通过的用例数量）/ （总的用例总数）

3 测试覆盖率的应用

1）简单的测试覆盖率

• 定义：本次测试执行的用例数 / 所有用例数。此时覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%
• 覆盖率审核：抽样验收

2）基于产品的测试覆盖率

• 定义：已测试需求点 / 设计所有需求数。以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%
• 覆盖率审核：抽样验收

3）基于白盒的测试覆盖率

• 定义：大多工具判断语句覆盖，即：单元测试代码行 / 总代码行。更多考察研发人员；更多时候要求覆盖率达到80%。
• 缺陷：覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景

4）基于自动化的测试覆盖率

• 定义：自动化覆盖的测试场景（测试用例）/ 所有测试场景（用例）
• 特点：80/20原则。比如：用户80%的时间在使用20%的功能，20%的功能就可以支撑起用户最关键的业务场景，自动化测试的用例选择更着重于这20%的核心功能
• 用途：自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计

5）测试覆盖率的最终意义

应用最多的地方在：测试停止标准

单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试

在短迭代、DevOps中，更强调单元测试覆盖率来评估不断增加的代码数量

三、综合知识

3.1 测试团队组织架构

分为金字塔管理模式、矩阵化管理模式

3.2 测试人员知识体系

3.3 测试原则及规范

1 测试原则

原则1：所有测试都应追溯到用户需求

产品缺陷的80%以上是在产品开发过程中的需求定义阶段引入的，如果需求得到了准确的验证，则可以消除80%的返工问题，节省总项目投入费用的45%。

原则2：尽早启动测试工作

原则3：Pareto法则应用于软件测试

Pareto（帕累托）法则是由意大利经济学家帕累托提出的，又称为28效率法则。

测试中的Pareto法则是说一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出其余缺陷中的80%，最后4%的缺陷可能只有在用户大范围、长时间使用后才会暴露出来。

原则4：穷举测试时不可能的

由于很少有机会对一个应用软件进行所有可能的测试，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。

原则5：杀虫剂怪事

软件测试越多，其对测试的 免疫力越强的现象。

为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷

原则6：前进两步，后退一步

测试中的一个基本问题是：缺陷修复总会以（20-50）%的几率引入新的缺陷。

每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以隐蔽的方式被破坏。

原则7：三心二意

三心：细心、信心、耐心

团队合作意识、时刻保持怀疑的态度且有缺陷预防意识

2 测试规范

3.4 软件工程标准

1 基本概念

国内通用的软件工程标准主要有：ISO9000及CMM

ISO9000系列标准：是ISO国际标准化组织TC/176技术委员会制定的所有国际标准，其核心标准是质量保证标准（ISO9001/2/3）和质量管理标准（ISO9004）

CMM（Capability Maturity Model）即软件能力成熟度模型，是向软件组织提供如何增加对其开发和维护软件过程的控制能力。

2 详解

1）ISO9000

ISO9000系列标准的基本思想，最主要的有两条：

一是控制的思想，即：对产品形成的全过程，从采购原材料、加工制造到最终产品的销售、售后服务进行控制

二是预防的思想，通过对产品形成的全过程进行控制以及建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格产品

2）CMM

CMM准确来说不是标准，只是对过程能力的评估结果。CMM对软件企业的评估从初始级开始，共分为5级，一级一级的改进，一级一级的向上提高。等级的上升过程是一个动态渐进的过程

CMM是专为软件开发组织设计的，侧重于软件开发和改进的过程，在产品的设计和开发的细节做了较多的要求。