软件测试理论

1.软件的生命周期

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

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

软件生命周期：

1.问题定义（客户、产品经理）- 确定号要解决的问题是什么（what）
2.可行性研究（产品经理）- 确定该问题是否有解决的方案（技术能实现）
3.需求分析（产品经理）- 深入具体的了解用户的需求
4.概要设计（开发）- 设计实现目标系统的几种可能方案，设计程序架构
5.详细设计（开发）- 详细设计每个模块，确定实现模块功能的算法和数据结构
6.编码和单元测试（开发）
7.综合测试（测试）
8.软件维护（运维）

举例：余额宝的诞生
1.普惠金融与互联网金融的融合（问题定义）
2.T+0是否可以实现；是否合规（可行性研究）
3.细分story，充值业务怎么处理、取出钱逻辑业务怎么处理（需求分析）
4.流程和架构设计（概要设计）
5.详细设计（开发）- 详细设计每个模块，确定实现模块功能的算法和数据结构
6.编码和单元测试（开发）
7.综合测试（测试）
8.软件维护（运维）

2.软件开发模型

有边做边改、瀑布、原型、螺旋、敏捷模型

边做边改

谨慎考虑

瀑布模型（客户只在前期参与）

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

特点：

1. 严格线性进行
2. 当前活动接受上一项的工作结果

缺点：

1. 由于严格线性，增加开发风险
2. 早期的错误可能等到开发或测试后期阶段才能发现

原型模型（客户一直在参与）

先给客户一个demo样例，根据客户需求，开发来变更，开发受需求影响较大。

特点：

1. 实现客户与系统的交互
2. 进一步细化待开发软件需求
3. 开发人员可以确定客户的真正需求是什么

螺旋模型（结合瀑布和原型）

制定计划 → 风险分析 →实施工程(需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试)→ 客户评估

特点：

1. 螺旋模型是将瀑布和原型结合起来
2. 强调了其他模型所忽视的风险分析
3. 每次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估

缺点：

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

敏捷模型（基于螺旋模型）

是一种以人为核心、迭代、循序渐进的开发方法，重沟通，少文档

特点：

1. 短周期开发
2. 增量开发
3. 由程序员和测试人员编写的自动化测试来监控开发进度
4. 通过口头沟通、测试和源代码来交流系统的结构和意图
5. 测试代码之前先写测试代码，也叫做测试先行

缺点：

1. 团队的人员素质要求较高，团队组建较难
2. 对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试（web自动化、接口自动化）

3.软件开发文档

开发和测试阶段的文档

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

4.测试方法在软件生命周期的影响

1. 编程阶段-单元、白盒测试为主
2. 编程完成阶段-集成测试为主-开发联调（接口、日志）
3. 提前测试阶段-集中在核心功能，冒烟测试为主（自动化测试、手动测试）web和接口
4. 测试阶段-系统测试（黑盒测试为主，自动化/接口测试为辅）-根据性能、安全测试
5. 验收阶段- 验收测试-测试配合用户或需求

5.软件测试概念

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

6.软件测试方法和分类

6.1按生命周期划分

1. 单元测试 (开发编码过程中)
2. 冒烟测试 (对主要功能进行简单测试的集合)
3. 集成测试 (模块间测试)
4. 系统测试 (测试用例来完成测试)
5. 验收测试 (多种类型)

6.1.1软件生命周期各测试方法对比

	单元测试	集成测试	冒烟测试	系统测试	验收测试
测试阶段	编码后	单元测试完成后	提测后	冒烟测试通过后	发布前
测试对象	最小模块	模块间的接口	整个系统	整个系统	整个系统
测试人员	白盒测试或开发	白盒测试或开发(两个开发人员各自模块或同一个开发人员开发人员两个模块)	黑盒测试	黑盒测试	最终用户或需求方
测试依据	代码、注释、详细设计文档	单元测试模块、概要设计文档	冒烟测试用例	需求说明文档、测试方案、测试用例	用户需求、验收标准
测试方法	白盒测试	黑盒与白盒结合	黑盒测试(手工与自动化结合)	黑盒测试	黑盒测试

6.2按测试方法划分

• 白盒测试
  • 静态分析(无需执行代码,只需看代码分析逻辑)
  • 动态分析
    • 逻辑覆盖测试
      • 语句覆盖
      • 判定覆盖
      • 条件覆盖
      • 路径覆盖
    • 插桩测试(mock测试)
• 黑盒测试
  • 功能测试
    • 界面测试
    • 冒烟测试
    • 回归测试
    • 业务测试
    • 兼容性测试
    • 易用性测试
  • 自动化测试
    • Web自动化测试
    • 接口自动化测试
  • 性能测试(广义)
    • 性能测试(狭义)
    • 负载测试
    • 压力测试
    • 容量测试
    • 并发测试
    • 持久性测试
  • 安全测试
    • 手动臊面
    • 自动化审计
• 灰盒测试(很少使用)

6.3其他

• 随机测试
• 探索性测试
• α测试 (验收测试)
• β测试 (验收测试)

7.软件测试常用术语

C/S:

C指的是客户端(Client)S指的是服务器端(Server),这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ、和各种网络游戏就属于C/S结构的软件。

B/S:

B指的是浏览器(Browser)，S指的是服务器(Server)这种软件同样是基于局域网或互联网的，它与结C/S结构软件的区别就在于，不需要安装客户端(client)，只需要有浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点。

缺陷(Bug/Defect):

软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题

测试环境:

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

测试用例(Test Case):

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

其中，
“输入”包括测试数据和操作步骤
“输出”指的是期望结果
“测试环境”指的是系统环境设置

冒烟测试(Smoke Testing)

在提测阶段,在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

α测试 (验收测试)

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

β测试 (验收测试)

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

6.软件测试模型

6.1 V模型

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

V模型就是在这点改进了瀑布模型，在软件开发的生存期开发活动和测试活动几乎同时开始，这两个并行的动态的过程就会极大的减少bug和error出现的几率。

6.2 W模型

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

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

6.3 H模型

真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。

为了解决V模型和W模型存在的问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

6.4 X模型

7.软件测试环境

7.1搭建

7.1.1 本地测试环境配置

例如:

1. 配置java环境(下载jdk并配置环境变量)
2. 下载并安装中间件(tomcat、jetty或其他)
3. 安装数据库并导入初始化脚本

7.1.2Docker模式

1. 构建属于自己的image
2. 一键deploy

7.1.3依赖第三方平台(自研环境资源管理)

依赖第三方平台(如蚂蚁金融云)

7.2落地

考虑点:用途、使用成本、维护成本

基本架构:
研发环境:用于研发自测、集成测试

测试环境:用于日常单系统或两两微服务之间测试，可同时集成自动化测试回归

联测环境:完备环境，用于大型联测

外联环境(如果有需求):稳定版本环境，用于外部商户等联调

灰度/沙箱环境:用于生产数据测试，仿真测试

8.测试设计与测试用例

8.1测试设计

测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。

8.2测试用例

测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体操作产生何种结果的文档。

测试用例应该具有可重复性、可验证性和需求可追踪性

8.2.1测试用例设计包括以下关键点

• 前提条件，如项目或局部测试环境的需求，及其交付计划
• 测试步骤
• 测试数据
• 预期结果

8.2.2测试用例模板

序号	模块名称	测试子项	用例名称(测试意图)	用例级别	预置条件	测试步骤	预期结果	测试结果	缺陷编号	备注
1
2
3
4
5
6
7
8
9

8.2.3测试用例常用设计方法

• 等价类划分法(最常用)
• 边界值法
• 因果图设计与判定表设计法
• 正交试验法

8.2.3.1 等价类划分法

概念:

• 等价类划分的办法是把程序的输入域划分成若干部分
• 然后从每个部分中选取少数代表性数据当作测试用例
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值

等价类划分原则:

• 如果输入条件规定了取值的范围或值的个数(范围-99至99)，则可确定一个有效等价类和两个无效等价类

• 如果一个输入条件说明了一个“必须成立”的情况，则可划分一个有效等价类和一个无效等价类

• 如果输入条件规定了输入数据的一组可能的值，而且程序是用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类

• 如果我们确知，已划分的某等价类中的各元素(例子)在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类

• 在确立了等价类之后，建立等价类表，列出所有划分出的等价类

基于等价类划分的用例设计:

• 明确测试对象，非测试对象保证正确

• 为每个等价类规定一个惟一的编号

• 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖

• 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖

实战:
一、两位整数加法计算器

测试两个参数的值相加后的结果是否正确
其中:输入的数值在-99到99之间大于99或小于-99的输入应被拒绝，并显示错误信息

STEP1：划分成三个部分，一个有效等价类，两个无效等价类。

STEP2：建立等价类表
在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，以便在编写测试用例的时候有所依据

STEP3：确定测试用例

STEP4：细化等价类划分

STEP5：完善测试用例

二、余额宝转出

测试需求:余额宝提现到银行卡增加新规则:快速到账(2小时)日限额1w元，超过1w元只能选择普通到账。

编写最终测试用例

三、三角形判断

一个程序读入3个整数，把这三个数值看做一个三角形的3条边的长度值
这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的

1.编写等价类表

序号	功能项	有效等价类	编号	无效等价类	编号
1	三角形判断	是正整数且两条边之和大于第三边且三边相等 是正整数且两条边之和大于第三边且两边相等 是正整数且两条边之和大于第三边且三边不等	1 2 3	有负数或两条边之和小于第三边 有负数或两条边之和等于第三边	4 5
2.编写测试用例

测试用例编号	输入数值	所属等价类	预期输出
1	1，1，1	1	正确输出：等边三角形
2	2，2，1	2	正确输出：等腰三角形
3	4，2，3	3	正确输出：普通三角形
4	1，1，3	4	错误信息
5	-1，1，3	4	错误信息
6	1，1，2	5	错误信息
7	-1，3，2	5	错误信息

8.2.3.2 边界值法