软件测试基础

一、软件测试概述

什么是软件：软件=数据+文档+程序

软件的分类：系统软件和应用软件

软件架构分类：C/S(Client-Server）和 B/S（Browser-Server）架构。

软件测试的定义：使用人工和自动化手段来测试或运行某个系统的过程。

软件测试的目的：在于检验他是否满足归档的需求或弄清预期结果与实际结果之间的差别。

软件的声明周期：问题的定义、规划开发方与需求方讨论、需求分析、软件设计、软件编码、软件测试（单元测试、继承测试、系统测试、验收测试）、运营维护。

软件测试流程：

需求分析和测试计划：
- 理解软件需求和功能规格，确定测试范围和测试目标。
- 制定测试计划，包括测试策略、资源需求、进度安排等。
测试设计：
- 根据需求和设计文档，制定测试用例和测试数据。
- 设计测试环境和搭建测试基础设施。
测试执行：
- 执行测试用例，记录测试结果和缺陷。
- 进行回归测试，验证修复的缺陷是否有效，确保系统其他部分未受影响。
缺陷管理：
- 报告缺陷并进行跟踪管理，包括缺陷的提交、验证、关闭等流程。
- 根据严重性和优先级对缺陷进行分类和处理。
测试报告和总结：
- 撰写测试报告，总结测试覆盖率、通过率、未通过率等指标。
- 分享测试结果和建议，为项目决策提供支持。
测试结束和评估：
- 完成测试任务，评估测试过程中的效率和效果。
- 进行测试经验总结，为后续项目提供改进建议。

二、软件缺陷

1、概念

软件缺陷又称为“BUG”。即计算机软件或程序中存在某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。

2、缺陷的表现形式

没有实现产品规格说明书中所要求的功能模块；
出现了产品规格说明书指明不应该出现的错误；
实现了产品规格说明书中没有提到的功能需求；
没有实现产品规格说明书中没有明确提及但应该实现的目标；
软件难以理解、不易使用、运行缓慢、用户体验不好；

3、产生缺陷的原因

产品规格说明书没有写或者写的不够全面，经常更改，以及开发小组没有进行很好的沟通，造成对软件规格需求说明书的不理解。
没有做设计或者设计不好，经常发生变动导致和产品规格需求说明书一样的问题。
主要就是上面两种。

4、缺陷的几种类型

需求解释有错误
用户需求定义错误
需求记录错误
设计说明有误
编码说明有误
程序代码有误
测试有误
问题修改不正确
不正确的结果是由于其他的缺陷而产生的

5、缺陷的属性

缺陷标识：唯一
缺陷类型：缺陷种类
缺陷严重程度：因缺陷引起的故障对软件产品的影响程度
缺陷优先级：缺陷必须被修复的紧急程度
缺陷状态：通过跟踪修复过程的进展情况
缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段
缺陷来源：引起缺陷的原因
缺陷根源：反正错误的原因

三、测试的主流技能及工具

功能测试：主要验证程的功能序是否满足要求。Xmind

自动化测试：使用代码或工具代替手工对项目进行测试。Selenium

接口测试：使用代码或者工具对服务端提供的接口进行测试。Postman或Jmeter

性能测试：模拟多人使用软件，查找性能瓶颈。Jmeter或LoadRunner

四、测试分类

1、按测试阶段分类

单元测试：对程序源代码每个单元进程测试。
集成测试：又称接口测试，针对模块之间访问地址进行测试。
系统测试：对整个系统进行测试，包括功能、非功能（兼容性，文档等）测试。
验收测试：主要分为内测、公测、使用不同用户来发掘项目缺陷。

2、按代码可见度分类

黑盒测试：不关注源代码，针对程序UI功能进行测试，源代码不可见，UI功能可见（系统测试)。黑盒测试方法：等价类边界值，因果图，判定表，错误推测法。
灰盒测试：针对程序部分代码进行测试，部分源代码可见，功能不可见（接口测试）。
白盒测试：针对程序源代码进行测试，全部代码可见，UI功能不可见（单元测试）。

3、按软件是否运行分类

1) 静态测试：不运行程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

代码测试：主要测试代码是否符合相应的标准和规范；
界面测试：主要测试软件的实际界面与需求中的说明是否符合；
文档测试：主要测试需求说明是否符合用户的实际需求；

2) 动态测试：通过运行被测程序，检查运行结果和预期结果的差异，并分析运行效率、正确性、健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。

黑盒测试：基于程序的输入和输出的测试方法，不考了程序的内部实现，只关注程序的功能和性能是否符合需求。
白盒测试：基于程序内部结构和代码的测试方法，通过检查程序的内部逻辑和代码覆盖率等来评估程序的正确性。
灰盒测试：黑盒测试和白盒测试的结合体，既要考虑程序的输入和输出，又考虑程序的内部结构和代码覆盖率等。

4、按测试组织分类

开发方测试：验证测试/α 测试。
用户测试：β 测试。
第三方测试

5、按测试类型分类

1）功能测试：

主要针对产品需求说明书对软件进行测试，验证软件功能是否符合需求，包括对原定功能的检验以及测试软件是否存在冗余功能、遗漏功能。

2）界面测试：

主要对系统的界面进行测试，测试用户界面是否友好，软件是否方便易用，系统设计是否合理，界面主要位置是否正确等问题。

3）性能测试：

主要测试系统的性能是否满足用户需求，即在特定的运行条件下验证系统的能力状态。性能测试主要是通过自动化的测试工具来模拟正常、峰值、异常负载状况、对系统的各项吸能指标进行测试。

4）强度测试：

迫使系统在异常的资源配置下运行，目的是找出因资源不足或者资源争用而导致的错误。

5）压力测试：

主要是在超负荷环境中，检验系统是否能够正常运行。

6）安全测试：

测试系统防止非法入侵的能力。

7）兼容性测试：

测试软件在不同的平台、不同的工具软件或者相同的工具软件不同的版本下的兼容性。

8）安装测试：

主要校验软件是否可以正确安装，安装文件的各项设置是否有效，安装后是否影响整个计算机系统，卸载软件时是否可以卸载干净，卸载软件之后是否影响整个计算机系统。

9）文档测试：

主要检查内部文档或外部分档的清晰性和准确性。

五、常见的软件测试过程模型

1、瀑布模型

优点：

为项目提供了按阶段划分的检查点
当前一阶段完成后，只需要关注后续阶段
提供了一个模版

缺点：

不适应用户需求的变化（很重要）
各个阶段的划分完全固定，阶段之间产生大量文档
开发模型为线型，用户只有等到整个过程结束才能看到开发成果，增加开发风险（线性过程太理想化）

2、V模型

V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

单元测试的目的是根据详细设计说明书验证单元模块是否符合要求，发现代码编写过程中存在的问题。
集成测试的目的是根据概要设计说明书验证各个模块是否已经集成到一起，各个模块之间的接口是否存在问题。
系统测试的目的是根据需求说明书验证软件是否符合用户的需求，系统是否能够正常工作。

V模型的局限性是把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现缺陷。

3、W模型

w模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
缺点：不能支持迭代、自发性以及变更调整。

4、螺旋模型

5、敏捷开发模型

以人为核心、快速迭代、循序渐进的开发模式。

强调以人为本，专注于“尽早地、持续性地”交付对客户有价值的软件。

用于开发和维持复杂产品，把一个大项目分为多个相互联系但也可独立运行的小项目，分别完成，在此过程中软件一直处于可使用状态。

（图片来自于网络）

敏捷开发团队三个主要工作方法：

① 将所有个体作为一个整体进行工作

② 工作以短迭代周期的方式进行

③ 每一次迭代完成都交付结果，并关注业务优先级。

敏捷开发模式的四个基本核心思想：

1. 重视面对面的沟通，人与人实际交流胜过任何网络工具

2. 将时间精力花费在可运行的程序上，能执行的产品胜过编译全面的文档，它强调了原型和demonstration等的重要性。

3. 鼓励团队合作，提升工作激情，敏捷开发可以把需求、开发、测试等团队成员整合为一个整体。

4. 团队适应能力强，适应环境变化，拒绝按部就班。

优点：

1、用户很快可以看到一个基线架构版的产品。

2、敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

缺点：

1、敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动太大，维护难度增加，特别项目存在新手比较多时，老员工比较累。

2、需要项目中存在经验较强的人，否则大项目中容易遇到瓶颈问题。

六、测试用例的设计

1、设计测试用例的万能思路

功能测试+界面测试+性能测试+兼容性测试+安全性测试+兼容性测试

例如：

2.设计测试用例的模板

用例编号

模块

用例标题

优先级

前提条件

操作步骤

预期结果

实际结果

zc_01

注册成功

稳定的网络环境

1.输入正确的手机号

2.输入正确的验证码

3.点击验证

提示“注册成功”

跳转到填写信息界面

3、设计测试用例的主要方法

3.1 等价类

将数据中某种共同特征的数据集合进行划分。

等价类划分的步骤：1.明确需求 2.确定有效/无效等价类 3.提取数据，编写测试用例。

需求：例如：未满十八岁禁止入内！！！

有效等价类：>= 18

无效等价类：<18

测试用例：

3.2 边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

3.3 因果图法

因果图是从需求中找出因（输入条件）和果（输出或程序状态的改变），通过分析输入条件之间的关系（组合关系、约束关系等）及输入和输出之间的关系绘制出因果图，再转化成判定表，从而设计出测试用例的方法。

条件和结果之间的关系：左侧节点表示输入状态即原因，右侧节点表示输出状态即结果

条件和条件之间的关系：

设计用例步骤：

找出所有原因，原因即输入条件或输入条件的等价类；找出所有的结果，结果即输出结果；
明确所有输入条件之间的关系；明确所有输出结果之间的关系
找出什么样的输入条件组合会出现哪种输出结果，画出因果图；
把因果图转换成判定表（决策表）；
为判定表（决策表）中的每一列表示的情况设计测试用例。

3.4 场景法

软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

场景法主要是模拟用户完成正常功能、核心业务逻辑的动作，以验证功能的正确性，以及模拟用户操作中出现的主要错误，以验证程序的异常处理能力。

场景法使用步骤：确定基本流和备用流

基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）

备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如1和3），也可以起源于另一个备选流（如2），或终止用例，不在加入到基本流中（如4）

上图生成的场景如下：

场景1：基本流
场景2：基本流备选流1
场景3：基本流备选流1 备选流2
场景4：基本流备选流3
场景5：基本流备选流3 备选流2
场景6：基本流备选流3 备选流2 备选流1
场景7：基本流备选流4
场景8：基本流备选流3 备选流4