软件测试基础

想要tm

已于 2023-09-01 14:45:43 修改

阅读量310

点赞数

文章标签：功能测试

于 2023-08-23 22:55:53 首次发布

本文链接：https://blog.csdn.net/qq_63486261/article/details/132437421

版权

该博客围绕软件测试展开，介绍了软件测试分类、质量模型、生命周期模型、测试过程模型等基础知识，阐述了多种测试用例设计方法，如等价类划分法、边界值法等，还提及软件缺陷相关内容，以及电商项目测试的前置工作、流程，最后介绍了非功能测试的相关要点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

day 01

软件测试分类

按测试阶段划分：

单元测试、集成测试、系统测试、验收测试

单元测试：又称模块测试，针对软件设计中程序模块测试（可能是个函数，也可能是个类）

集成测试：又称组装测试，通常在单元测试的基础上，将所有模块进行有序的、递增的测试，重点测试不同模块的接口测试。

系统测试：将软件看成一个整体进行测试，测试的依据是软件需求说明书。

验收测试：经验软件是否符合用户需求的测试，在最终用户的角度来测试。

α测试：内测版本，通常只在软件开发者之间交流

β测试：公测版本，用户进行公测的版本

γ测试：软件正式发行的候选版，接近于正式发布的版本

按是否覆盖代码划分：

黑盒测试、白盒测试、灰盒测试

黑盒测试：只测试功能，不关注功能的具体实现方式

白盒测试：不但要关注功能，还要关注代码是如何实现的

灰盒测试：介于黑盒和白盒之间的测试，功能测试的同时，会关注一部分代码的测试

按是否运行：

静态测试、动态测试

静态测试：不运行软件，静态的观察软件是否符合预期，主要是外观设计等。

动态测试：运行软件，在运行过程中测试。

按是否自动化测试：

手工测试、自动化测试

手工测试：通过测试工程师手工对软件进行测试

自动化测试：通过编程写代码，通过程序自动测试软件是否有Bug

更多：

冒烟测试、回归测试、随机测试、探索测试

冒烟测试：对软件最基本的流程和工作做一个粗略的测试，看最基本的流程是否能够跑通。（测试人员拿到软件后第一步的测试）

回归测试：当修复一个Bug后，把之前的测试用例在新的代码下进行再次测试。

随机测试：主要是对被测软件的一些主要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。

探索测试：一边了解和学习项目，一边去测试项目

软件质量模型

功能性：

功能的正确性

功能的安全性

功能的依从性

可靠性：

软件要有容错性（出现异常，可以正确的处理）

出现错误后可以很快恢复

易用性：

软件界面是否流畅

提示是否友好

用户使用功能是否得当

性能：

软件一定是要高效的

维护性：

软件一定是要可维护的

可移植性：

软件要适应不同的系统

软件生命周期模型

瀑布模型

设计分为：概要设计和详细设计

概要设计：用到的具体技术点、大致模块划分

详细设计：详细到可以为编码做支持；类和类关系，类的设计；函数设计；各个接口的细节；数据库表的关系，字段关系

瀑布模型的特点：

1、线性模型，每一步都是按顺序来执行

2、文档驱动，每一步都要有文档产出，不能缺失

瀑布模型的优缺点

优点：

1、开发的各个阶段比较清晰

2、当前一阶段完成后，只需关注后续阶段

缺点：

1、依赖于早期的需求检查，不适应需求的变化

2、风险往往在后期显现，失去早纠正的机会

快速原型模型

特点：

一边确定需求一遍实现

优缺点：

优点：

避免瀑布模型的缺点，可以适应早期的需求变化

缺点：

适合小型项目

螺旋模型

特点：

每一步都引入了风险评估

优缺点：

优点：

螺旋模型很大程度上是一种风险驱动的方法体系

缺点：

采用螺旋模型需要具有相当丰富的风险评估经验和专门知识

测试过程模型

v模型

从研发的瀑布模型而来

其中存在的对应关系

单元测试-->编码；集成测试-->详细设计；系统测试-->概要设计；验收测试-->需求分析

v模型的优缺点：

优点：

包含了底层和高层的测试过程

每个步骤都是文档驱动的

缺点：

和研发瀑布一样，不能适应需求的改变

w模型

W模型增加了软件开发各阶段中同步进行的验证和确认活动。

w模型的优缺点

优点：

1、强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试

2、更早地介入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复

缺点：

使用起来技术复杂度高，对于需求和设计的测试要求高，实践起来困难

H模型

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

H模型的优缺点

优点：

1、开发的H模型揭示了软件测试除测试执行外，还有很多工作；

2、软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；

3、软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；

4、软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

缺点：

1、管理型要求高

2、技能要求高

3、测试就绪点分析困难

4、对于整个项目组的人员要求非常高

X模型

X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

X模型的优缺点

X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

测试用例

定义：

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期结果的文档。

测试用例八大要素：

用例编号：项目名_模块名_编号

用例标题：预期结果(测试点)

测试项目

优先级：P0~P4，P0最高（每个公司都不同，自己判断优先级的高低）

前置条件：执行该用例前的准备步骤

测试数据

执行步骤

预期结果

案例：测试计算器

day 02

测试用例设计方法

等价类划分法

定义：在所有测试的数据中，具有某种共同特征的数据子集

等价类分为：

1、有效等价类：满足需求

2、无效等价类：不满足需求

有效和无效各取其一即可

执行步骤：

1、明确需求

2、确定有效和无效等价类

3、编写用例

案例1：

QQ账号:6~10位自然数

测试用例

案例2：

确定有效无效等价类

测试用例（注意测试数据必须要和上面的数据一样，本案例用例是复制的）

边界值法

对具有输入限制范围的用例，如输入长度在6~10之间

上点：边界上的点(如：6,10)

离点：距离上点的最近的点，开内闭外（如：5，11）

内点：范围内的点（如：8）

一般将等价划分法和边界值法结合起来，等价划分法关注类型，边界值法关注长度

判定表法

对具有多依赖关系的输入输出

组成：

条件桩：列出问题中所有条件

动作桩：列出问题中所有的动作

条件项：条件的真假值

动作项：对应条件真假下的动作

步骤：

1、明确需求

2、画判定表

3、编写用例

假设有n种条件，则有2的n次方条用例

案例：

因果图法

因---------->输入条件

果---------->输出结果

定义：

用图解的方法表示输入的各种组合，写出判定表，从而设计相应的测试用例

适用范围：适用于分析程序输入条件的各种组合情况，以及输入与输出之间的依赖关系

基本符号：

C表示原因，E表示结果

基本步骤：

1、明确需求

2、画出因果图

3、将因果图转换为判定表

案例：

因果图法详解https://zhuanlan.zhihu.com/p/129342944

正交表法

对组合量很大的测试方法，正交表法就是能够使用最小的测试过程集合获得最大的测试覆盖率

正交表概念：

一般的正交表标记为：$L_n(m^k)$，有另一种表达方式 $L_ {n}(m^k)$

n表示行数

k表示列数

m是列的取值个数

如：$L_9(3^4)$,表示9行4列，每列3个取值个数，叫做4因素3水平

设计步骤：

1、明确需求

2、画出正交表

1) 先确定列数(因素，有几个输入就行)

2)确定每一列的取值(水平，某列的取值)

2)根据因素数与水平数选取正交表

3)用需求中的文字代替正交表中的字母

水平数取决的是最多取值的列数的取值个数

3、写出测试用例

正交表一行就是一个用例

正交表设计工具：

正交表测试用例自动生成工具--Allpairs的使用（详细）_正交表在线生成器_测翻D_Fire的博客-CSDN博客https://blog.csdn.net/DFireTesting/article/details/107862049 案例1（每列取值相同）：

字体：仿宋、楷体、华文彩云

样式：粗体、斜体、下划线

颜色：红色、绿色、蓝色

字号：20、30、40

正交表如下：

4因素3水平

编写用例即可。

案例2（第一列取值多）：

字体：仿宋、楷体、华文彩云

样式：粗体、斜体、下划线

颜色：红色、绿色、蓝色

字号：20、30、40

4因素16水平

案例3（第二列取值最多）：

字体：仿宋、楷体、华文彩云

样式：粗体、斜体、下划线、删除线

颜色：红色、绿色、蓝色

字号：20、30、40

4因素16水平

场景法

场景法是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
场景法测试https://blog.csdn.net/weixin_42885805/article/details/86560451 步骤：

1、明确需求

2、画流程图

3、编写用例

每一条路径，都是一条用例

错误推测法

利用直觉和经验来推测项目中可能出现bug的地方，进行测试

使用场景：时间紧张，突发事件

day 03

软件缺陷

定义：

软件或程序中存在的各种问题或者错误

判断标准：

1、少功能

2、多功能

3、功能出错

4、软件应该具有隐形功能（需求书中虽未指明，而应该达到的目标）

5、认为软件难以理解、不易使用、运行速度慢、用户体验不好等

产生原因：

软件缺陷是不可避免的，主要原因如下：

1、需求解释、记录或者定义错误

2、设计文档说明存在错误或者拼写错误

3、编码说明、程序代码有误

4、硬件或者软件系统上存在错误

缺陷信息：

核心要素
- 标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功）
- 前置条件：描述缺陷出现依赖的相关基础条件
- 复现步骤：测试用例里面的执行步骤
- 实际结果：执行被测试软件过程中，系统给出的结果
- 预期结果：参照需求说明书，在测试用例中设计的预期结果
- 附件：方便开发定位bug的关键信息
基本要素
- 缺陷编号：缺陷的唯一性标志
- 缺陷状态:表示缺陷当前处于哪个阶段
- 缺陷所属模块：缺陷属于哪个被测的模块，根据产品进行具体的划分，如登录，注册
- 缺陷严重程度：该缺陷的破坏程度或影响程度，从技术的维度来衡量，bug的破坏力
- 缺陷的优先级：从业务的角度决定bug修改的先后顺序
- 缺陷类别：用于分类整理缺陷

缺陷的状态

缺陷严重程度：

缺陷的优先级

提交缺陷注意事项

可复现：缺陷可以复现

唯一性：一个缺陷报一个问题

规范性：符合公司或者项目要求

准确：描述的信息是正确的
具体：游戏界且是真实特定的
简洁易懂：描述简单容易理解
次序清晰：描述缺陷过程有条件，有先后顺序

缺陷报告的重要性

体现测试的一个专业性

多站在开发的角度去思考问题（换位思考）

缺陷书写规范

标题：应保持简洁、准确，提供缺陷的本质信息

复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤

实际结果：是执行复现步骤后软件的现象和产生的行为

预期结果：通常需要列出期望的结果是什么

附件：对缺陷描述的补充说明

缺陷跟踪（理论）

new新建状态

要提交一个缺陷，首先就是新建状态

open打开状态

确认缺陷有效后，为打开状态

fixed修复状态

由缺陷的处理人，把缺陷处理完之后设置为修复状态

closed关闭状态

回归测试成功后，一般由缺陷的发起人设置为关闭状态

reopen重新打开状态

一个已经关闭的缺陷再次出现，就要设置为重新打开状态

day 04

针对一个电商项目进行测试

前置工作：搭建本地测试环境

测试环境：

BS架构，浏览器-服务器

web server

硬件是一个服务器

安装服务器操作系统(linux,unix,windows server)

web服务(提供了并发，http协议支持)

Nginx，apache

数据库

mysql，orcale

业务功能开发

java，php，pytho，.net

Linux下的环境搭建

LNMP：Linux+Nginx+MySQL+PHP项目

Windows下的环境搭建

WAMP：Windows+Apache+MySQL+PHP项目

前置工作：熟悉项目

熟悉项目步骤：

了解项目业务特性

了解项目的用户

了解项目的模块

了解项目技术栈

熟悉项目的消息来源：

项目中已经存在的文档：需求说明书，用户使用手册，测试用例等

使用项目的现有环境：开发环境，测试环境，线上环境等

询问项目中的其他成员：测试组员/组长，开发人员，产品经理等。

1、业务特性：

tpshop是一个开源的电商平台

2、项目的用户

3、项目模块

也叫子系统

了解项目有多少模块，以及有多少子模块，模块和模块之间的关系

一般到模块的具体功能项，就不再细分了

4、项目的技术栈

5、熟悉项目中的数据库表

参考表说明书

参考表说明书能梳理表和表的关系

能梳理表字段和项目中具体功能的关系

项目测试流程

1、需求评审

软件需求：描述软件的功能

需求评审：项目相关人员就软件需求进行确认和评估的相关活动

目的：保证需求说明书的完整，准确；保证项目团队对需求的理解达成一致；

形式：需求评审会议

参与人员：产品人员；开发人员；测试人员；UI设计人员

2、编写测试计划与测试方案

测试计划核心内容：明确测试目标与测试范围

执行计划的角色与职责

任务的进度安排与资源分配

风险估计和应急计划

测试的准入/准出标准

测试方案核心内容：测试策略

测试环境的规划

测试工具的设计和选择

3、测试用例设计与评审

4、测试执行与Bug跟踪

5、编写测试报告

day 05

编写测试用例的步骤

1、需求分析

2、整理测试点

测试点是测试中需要关注的具体功能点

测试点的作用是用来拆分需求，辅助编写测试用例

3、编写测试用例

编写测试用例的原则

1、能看懂

2、能执行

测试结果的几种状态说明

1、pass----通过

2、fail----失败

3、block----阻塞

4、N/A----忽略

轮播图(banner)测试

需求：

整理测试点：

编写测试用例：

导航栏测试

需求：

整理测试点：

测试用例：

购物车测试

会员管理(顶部区域测试)

需求：

测试点：

测试用例：

会员管理(添加会员测试)

需求：

当测一个数据时，其他的数据必须保证正确

测试点：

会员管理(会员列表测试)

需求：

测试点：

抢购功能测试

day 06

状态迁移法

图与数：

根节点----树干最根部的节点

叶子节点----树杈最末梢的节点

分支节点---处于主干与分支部分的节点(有叉的地方)

状态迁移法

定义：

首先要找出被测对象的所有状态，然后再分析各个状态之间的转换，据此编写用例。

注意：

状态迁移法不保证单个功能的正确性，仅保证状态间的转换是否与需求描述一致

适用场景：

在业务流程中涉及到了复杂的业务场景(即业务状态的迁移)，而这些业务场景在需求说明书中往往不能够完全阐述清楚，容易出现遗漏。

使用步骤：

1、明确状态节点

分析被测对象的需求规格说明书，明确被测对象的状态节点数量

2、绘制状态迁移图

利用圆形表示状态节点，有向箭头表示状态间的迁移关系

3、绘制状态迁移树

根据状态迁移图的节点和箭头绘制状态迁移树（首先确定起始节点及终止节点）

4、抽取测试路径设置用例

1) 找到所有的叶子节点

2) 一条路径就是根节点到叶子节点所走的路线

3) 一条路径对应一条测试用例

案例1：

1、绘制状态迁移图

2、绘制状态迁移树

预定->已取消

预定->已支付->已取消

预定->已支付->已出票->已取消

预定->已支付->已出票->已使用

4条路径即4条测试用例

案例2：

1、绘制状态迁移图

2、绘制状态迁移树

4条路径即4条用例

多个输入条件场景--减少测试用例的五个规则

1、长度或范围

2、数据类型

3、规则

4、是否必填

5、是否可以重复

例：

day 07

功能测试与数据库

1、执行用例过程中，有时需要到数据库验证数据的准确性与完整性

2、进行bug定位时，有时需要到数据库查看数据的详细信息

day 08

非功能测试

非功能测试主要包含：兼容性、界面测试、易用性、性能、安全性

兼容性测试

兼容性指软件对不同平台、不同环境、不同分辨率的适应能力

应用场景：

项目对这些有所要求

关注点：

不同的操作系统：Windows、Linux、mac等

相同的操作系统不同的版本：win7、win8、win10等

不同的浏览器：edge、chrome、firefox等

相同浏览器不同的版本：

其他常用的浏览器：

不同的分辨率

界面测试

一般情况，直接依据产品原型图以及UI效果图，进行对比验证，确认一致

如果没有原型图和UI效果图，可以通过以下几个方面考虑：

导航测试、图形测试、内容测试、整体界面风格测试

易用性测试

指用户使用软件时是否感觉方便。简单说就是：易懂、易学、易用、吸引人。

关注点：

项目难易程度、适用人群、用户的计算机水平

性能测试

通过测试工具模拟多种正常、峰值以及异常负载条件对系统的各项性能指标进行测试

适用场景：

对软件的性能有要求；用户量大的项目

目的：

验证软件系统是否能够达到预期的性能指标

发现软件系统中存在的性能瓶颈，以便优化软件

验证稳定性：在一个生产的负荷下测试一定的时间，评估系统的稳定性是否满足需求