测试小白入门-03测试理论知识看这一篇就够了

佳佳不爱上班

已于 2024-09-01 21:26:47 修改

阅读量1.2k

点赞数 23

分类专栏： 01测试理论文章标签：功能测试面试单元测试模块测试测试覆盖率测试用例

于 2024-09-01 21:18:39 首次发布

本文链接：https://blog.csdn.net/m0_55605424/article/details/141787374

版权

01测试理论专栏收录该内容

3 篇文章 0 订阅

订阅专栏

前言

本文主要介绍测试入门的基础知识，适合在校大学生或者想转行软件测试的同学，作为一个软件测试基础知识的扫盲。实习生面试的时候，如何设计一个功能的测试用例，一般会问的比较多，所以这块需要重点掌握。

一、软件开发过程模型

瀑布开发模型（熟悉）

(1)是线性模型的一种，在所有模型中占有重要位置，是所有其他模型的一个基础。
(2)每一个阶段执行一次，按线性顺序进行软件开发。
(3)需求分析-设计-编码-实现-软件测试-完成-维护
(4)测试阶段处于软件实现后，必须在代码完成后留出足够的时间给测试活动，否则将导致测试不充分，很对问题到最后才暴露。
(5)优点:

开发的各个阶段比较清晰
强调早期计划以及需求调查
适合需求稳定的产品开发

(6)缺点:

依赖于早期的需求调查，不适应需求的变化/单一流程不可逆
风险往往延至后期才显露，失去及早纠正的机会/问题在项目后期才开始暴露
前面未发生的错误会传递并扩散到后面的阶段，可能导致项目失败。
改良:每个阶段可以加入小的迭代模型。

快速原型模型（理解）

(1)在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

第一步:建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么?
第二步:在第一步的基础上开发出用户满意的软件产品。

(2)快速分析-需求说明-构造原型-原型-运行原型-评价原型-修改意见。
(3)优点:克服瀑布模型的缺点，更好的满足用户的需求并减少由于软件需求不明确带来的项目开发风险，适合预先不能确定定义需求的软件系统的开发。

(4)缺点:不适合大型系统的开发，适合开发小型的，灵活性高的系统。前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

螺旋模型(了解)

(1)将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，螺旋模型沿着螺旋线旋转，在坐标的四个象限上分别表示了4个方面的活动。
(2)定制计划-风险分析-实施开发-客户评估

二、测试模型

测试V模型（代表性）

1.示意图

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

2.单元测试

模块测试，针对单一的程序模块进行的测试。
定义:在C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指一个窗口一个菜单。

3.集成测试

组装测试，在单元测试的基础上，对所有模块块进行测试。重点测试不同模块的接口部分。

4.系统测试

将整个软件系统看作一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
系统测试在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等

5.验收测试

α测试(开发环境):内测版本，现在说的CB，内部交流版本，存在很多bug。一般而言，该版本的bug较多，普通用户最好不要安装。
β测试(实际环境):公测版本，对所有用户开放的测试版本，面向所有用户，通过用户的反馈再去修改细节。
γ测试:软件版本正式发行的候选版，该版本已经相当成熟了，与正式版本相差无几，成为正式版本候选。

6.优缺点

优点:测试v模型包含了底层测试(单元测试)又包含了高层测试(系统测试)。v模型清楚的标识出了软件开发和测试的各个阶段。自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。
缺点:自上而下的顺序导致了测试工作在编码之后就导致错误不能及时的进行修改，实际工作中，需求经常变化，v模型步骤反复重复，返工量比较大，灵活度比较低。
改良:每个步骤都可以进行小的迭代工作

测试W模型（中大型企业）

1.示意图

需求分析-概要设计-详细设计-编码-集成-实施-交付
验收/系统测试设计-集成测试设计-单元测试设计-单元测试-集成测试-系统测试-验收测试

2.优点

伴随着整个开发周期，需求和设计同样要测试，更早的介入测试，可以发现初期的缺陷，修复成本低，分阶段工作，方便项目整体管理。

3.缺点

开发和测试依然是线性的关系，需求的变更和调整依然不方便，如果没有文档，根本无法执行，对于项目组人员的技术要求更高。

4.定义

开发一个v，测试一个v组合起来的模型.

测试H模型（了解）

1.优点

除了测试执行外，还有很多工作，测试完全独立，贯穿整个生命周期，并与其他流程并发进行。软件测试可以尽早准备，具有很强的灵活性。

2.缺点

管理型要求高，技能要求高，整个项目组的人员要求非常高。
总结:v模型适用于中小企业，w模型适用于中大型企业，H模型人员要求非常高，很少有公司使用。

三、测试方法分类

在这里插入图片描述

是否覆盖源代码

1.黑盒测试

黑盒测试:又称数据驱动测试，完全不考虑内部机构和特性，注重软件的功能需求(不管代码)。软件的整体功能和性能进行黑盒测试

功能测试：
1、逻辑功能测试
2、界面测试
3、易用性测试
4、安装测试

性能测试：
1、时间性能
2、空间性能
3、一般性能
4、稳定性
5、负载测试
6、压力测试

2.白盒测试

白盒测试:把盒子打开研究里面的程序结构和源代码。
软件的源代码采用白盒测试
软件公司往往采用黑盒测试和白盒测试相结合的方式

是否运行

1.静态测试

不实际运行被测软件，而只是静态地检查程序代码，界面或者文档中可能存在的错误过程。

2.动态测试

实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否想符合的过程。

是否覆盖源代码

1.单元测试
2.集成测试
3.系统测试

是否自动化

1.人工测试
2.自动测试

其他

1.回归测试
2.冒烟测试
3.随机测试

针对重要功能、新增加的功能、特殊情况、以前发现过重大bug的模块进行二次测试，也叫探索测试，它可以结合回归测试来使用

4.验收测试

α测试 β测试 γ测试

四、编写测试用例的方法

1.等价划分类

（1）等价类划分法

是一种重要的黑盒测试方法，不需要考虑程序的内部结构，只需要考虑程序的输入规格即可。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

(2)等价类的划分

有效等价类:符合《需求规格说明书》，输入合理的数据集合。
无效等价类:不符合《需求规格说明书》，输入不合理的数据集合。

(3)思考步骤

1、先确定有效和无效等价类
2、有效等价类就是题目条件，两端的极值(边界值)要判断，中间随意一个值也要判断。
3、无效等价类先划分与条件相反的情况，在找到特殊情况(中文、英文、符号、空格、空)。
4、注意:一般是一个框输入正确的值，另一个输入错误的值。根据需求判断预期结果。

（4）例子

例子1
题目:测试QQ账号，账号的要求是6-10位正整数。

有效等价类:
1、长度在6-10位之间的整数
无效等价类:
1、长度小于6
2、长度大于10
3、负数
4、小数
5、英文
6、中文
7、空格
8、特殊字符

例子2
问题:城市号码由三部分组成,分别是
地区码:空白或是3位数字
前缀:非0且非1开头的三位数字。
后缀:4位数字。

例子3
问题:
用户名长度为3-19:字母开头
登录名称:非空
密码:非空
确认密码:值和密码相同

在这里插入图片描述
(5)等价划分类总结

测试文本框的程序可以考虑如下的情况:
1、文本框要求输入的长度
2、输入的类型
3、组成规则
4、是否为空
5、是否重复-区分大小写
6、是否去除空格

2.边界值

（1）边界值

边界值分析法也是一种常见的黑盒测试方法。
大量的错误是发生在输入或者输出范围的边界上，而不是在输入范围的内部。
有效数据和无效数据的边界点，往往作为程序员编写程序的判断点，是程序员容易犯错误的地方，也是测试人员重点测试的内容。

（2）具体测试用例书写思路

找到边界值和它两端的值，分别进行测试。

例子:
在这里插入图片描述

（3）例子

在这里插入图片描述

在这里插入图片描述

先判断边界值：-1 0 1 59 60 61 99 100 101
其他值：小于0 大于100 中英文、小数、特殊符号、空格、空

密码框案例：
在这里插入图片描述

边界值：

7个数字和字母
8个数字和字母
9个数字和字母
23个数字和字母
24个数字和字母
25个数字和字母

特殊：

中文
小数
特殊字符
空格
空

无效：

7个数字/8个数字/9个数字
23个数字/24个数字/25个数字
7个字母/8个字母/9个字母
23个字母/24个字母/25个字母

在这里插入图片描述

正常：-1 0 1 9 10 11
根据实际情况：商品信息不会显示负，所以0 1 9 10 11
等价划分和边界值相辅相成。

3.因果图

（1）定义

是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

（2）特点

考虑输入条件的相互制约以及组合关系
考虑输出条件对输入条件的依赖关系。
因:输入条件
果:输出条件，出结果
适用于输入条件之间有相互制约，相互依赖的情况。

（3）因果图符号
在这里插入图片描述

在这里插入图片描述

（4）因果图法基本步骤

利用因果图导出测试用例需要经过以下几个步骤:

①找出所有的原因，原因即输入条件或输入条件的等价类。
②找出所有的结果，结果即输出条件。
③明确所有输入条件之间的制约关系以及组合关系。
哪些条件不能组合到-起，哪些条件可以组合到一起
④明确所有输出条件之间的制约关系以及组合关系。
，哪些输出结果不能同时输出，哪些输出结果可以同时输出
⑤找出什么样的输入条件组合会产生哪种输出结果
⑥把因果图转换成判定表/决策表。
⑦为判定表/决策表中的每-列表示的情况设计测试用例。

（5）案例分析

在这里插入图片描述

4.判定表

1.定义

根据因果图绘制判定表
因果图是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例。但有时因画因果图非常麻烦，影响测试效率，直接写判定表，进而编写测试用例。

2.判定表的组成

条件桩:问题的所有条件
动作桩:问题的所有输出
条件项:针对条件桩的取值
动作项:条件项的各种取值情况下的输出结果。

3.制作步骤

1、列出所有的条件桩和动作桩
2、填入条件项
3、填入动作项，得到初始的判定表
4、简化判定表，合并相似的规则也就是相同的动作

4.例子

在这里插入图片描述

5.场景法

1.定义

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程。
当拿到一个测试任务时，我们并不是先关注某个控件的边界值、等价类是否满足要求，
而是先要关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。
当业务流程测试没有问题 ,也就是该软件的主要功能没有问题时，我们再重点从边界值、等价类等方面对控件进行测试
在冒烟测试时也主要采用场景法进行测试

2.用例场景定义

场景法中两个重要的概念

基本流（正确的操作）

按照正确的业务流程来实现的一条操作路径(模拟正确的操作
流程)

备选流（错误的操作）

导致程序出现错误的操作流程(模拟错误的操作流程)

用例场景是用来描述流经用例路径的过程，这个过程从
开始到结束遍历用例中所有基本流和备选流。

3.用例场景产生的背景

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景。而同事件不同的触发顺序和处理结果形成事件流。
将这种在软件设计方面的思想引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。
在使用场景法设计测试用例时，需要覆盖系统用例中的主成功场景和扩展场景，并且需要适当补充各种正反面的测试用例和考虑出异常场景的情形。当使用场景法测试程序没有问题时，可以再使用边界值、等价类方法对账号、密码进行更加细致、完整的测试。

4.例子

在这里插入图片描述

6.流程分析法

1.定义

流程分析法

流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。
在白盒测试中，路径就是指函数代码的某个分支组合，路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。
在黑盒测试中，若将软件系统的某个流程看成路径的话，则可以针对该路径使用路径分析的方法设计测试用例。

优点:

降低了测试用例设计难度，只要搞清楚各种流程，就可以设计出高质量的测试用例来，而不需要太多测试方面的经验;
在测试时间较紧迫的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。

2.流程分析法的步骤

第一步:详细了解需求;
第二步:根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系;
第三步:画出业务流程(产品经理使用Axure软件制作) ;
第四步:写用例，覆盖所有的路径分支。

3.例子
在这里插入图片描述

在这里插入图片描述

第四步:用例设计写用例，覆盖所有的路径分支。

需求描述及流程图中，ATM取款机的提示信息对应于测试用例中的预期输出部分，用户的操作对应测试用例中的测试步骤部分。原则是一条有效路径使用一个测试用例覆盖。依据业务流程图确定测试路径，即需要测试的业务流程。

其主要包含三个方面:

a)正常流程，取款成功(基本流程) :对应一一次性取款成功:
b)错误流程，取款失败(分支流程) :对应取款失败，包括退卡，吞卡;
c)异常流程，取款成功(循环流程) :对应取款中间出现意外，比如密码输
入错误但是最终成功取钱的情况。

流程分析法总结

流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试等。
流程分析法重点在于测试流程。因此，一般每个流程用一个测试用例验证。
流程测试没有问题并不能说明系统功能没有问题，还需要针对每步功能进行测试。对于包含复杂流程的系统，只有功能点和处理流程都进行测试覆盖，才算是比较充分的测试。

7.错误推断法

1.错误推测法

错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。

2.基本思想

基本思想是列举出可能犯的错误或错误易发生的清单，然后根据清单编
写测试用例;这种方法很大程度上是凭经验进行的，即凭人们对过去所
作测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷。
采用错误推测法，最重要的是要思考和分析测试对象的各个方面，多
参考以前发现的Bug的相关数据、总结的经验，个人多考虑异常的情况、
反面的情况、特殊的输入，以一个攻击者的态度对待程序，才能够设计出
比较完善的测试用例。

8.正交表

1.正交排列法概述

正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。当可能
的输入数据或者输入数据的组合数量很大时，由于不可能为每个输入组合
都创建测试用例，可以采用这种方法。

2.正交排列表重要概念

正交试验设计

是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。

正交表的概念
正交表: 一种特制的表，一般的正交表记为: Ln(mk)

n是表的行数，也就是需要测试组合的次数
K是表的列数，表示控件的个数(因素的个数，或因子个数)
m是每个控件包含的取值个数(各因素的水平数，即各因素的状态数)
如: L, (34)

有4个控件
每个控件有3个取值
9为需要测试的组合个数
叫4因素3水平

3.正交排列法的使用步骤

正交排列法的使用步骤

1.根据所测程序中控件的个数(因素)以及每个控件的取值个数(水平)，选取一个合适的正交排列表。
2.把控件及其取值列举出来，并对其进行编号
3.把控件及其取值映射到正交排列表中

把正交排列表中的ABCD (因子)分别替换成4个控件
把每列中的1.2, 3 (状态)分别换成这个控件的3个取值(水平)，排列顺序要按照表中给出的顺序。

4、根据映射好的正交排列表编写测试用例

4.例子

案例:字符属性设置程序

窗体中有多个控件(字体、字符样式，颜色、字号)，每个控件有多个取值
字体：工仿宋、楷体、华文彩云
字符样式:粗体、斜体、下划线
颜色:红色、绿色、蓝色
字号: 20号、30号、40号
3的4次方=81种
四个控件3个选项

在这里插入图片描述

例子：
五个因素，2个选项
Ctrl+F 选择可替换

9.混合正交表

1.定义

在实际工作中，很多情况都是因素和水平不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表;。

在这里插入图片描述 2.使用步骤

在这里插入图片描述

10.总结

1、如果测试功能和流程，要使用场景法。
2、需要输入数据的地方，我们要使用等价类划分法，要注意配合边界值法来做详细测试。
3、如果有条件组合的情况，我们要使用因果图制作出判定表。
4、配置类软件，组合比较多的，我们要使用正交表来科学的选择测试用例。
5、如果没有达到覆盖标准，就要增加一些测试用例。
6、依靠经验追加一些测试用例(错误推断法)。

五、软件缺陷

1.定义

缺陷就是软件的问题，最终表现为没有满足用户的需求。

2.哪些属于软件缺陷

软件缺陷是指存在于软件(程序、数据、文档)中的那些不符合用户需求的问题。

软件未达到需求规格说明书表明的功能
软件出现了需求规格说明书指明不会出现的错误
软件的功能超出了需求规格说明书指明的范围
软件未达到需求规格说明书虽未指明而应该达到的目标
软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好

3.缺陷的表现形式

软件缺陷的表现形式：

功能、特性没有实现或部分实现。
设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
产品实际结果和所期望的结果不- 致。
没有达到需求规格说明书所规定的性能指标等。
运行出错，包括运行中断、系统崩溃、界面混乱等。
数据不正确、精度不够、不完整或格式不统一。
用户不能接受的其他问题，如存取时间过长、界面不美观。
硬件或系统软件上存在的其他问题。

4.软件缺陷的状态

1、提交-测试人员提交了一个缺陷给程序员。
2、打开一待处理。
3、拒绝—程序员认为不是缺陷或者重复，就可以修改状态为拒绝。
4、修复一程序员修复缺陷后提交的一个状态。
5、关闭一测试人员经过回归测试后，认为此缺陷已经解决，将其关闭。
6、推迟一可以放在后续版本解决的问题，但是要详细写出修复的日期或版本。

5.软件缺陷的严重程度划分

1、Low—表面性错误，如错别字。
2、Medium—影响一个相对独立功能、仅仅发生再特定条件上、与需求定义不一
致、断断续续出问题。
3、High—功能点没有实现、不符合用户需求、导致数据丢失。
4、VeryHigh—频繁死机、大部分功能不能使用。
5、Critical—系统瘫痪、异常退出、死循环、严重的计算错误。

6.软件测试的优先级

1、Low——时间和资源允许的情况下修复μ
2、Medium——不会延迟发布，会在以后修复u
3、High——会制约开发和测试的进行，需要在发布之前修复←
4、VenyHigh——影响系统，产生严重影响。
5、Urgent——导致系统几乎不可用。

7.软件缺陷分类

1、系统缺陷。
2、数据缺陷。
3、数据库缺陷。
4、接口缺陷。
5、功能缺陷。
6、安全性缺陷。
7、兼容性缺陷。
8、性能缺陷。
9、界面缺陷。
10、建议。

8.缺陷报告注意事项

1、尽量保证缺陷可以重现。
2、简洁、准确、完整。
3、一个缺陷报告只写一个缺陷。

9.缺陷书写规范

1、标题简洁、提供缺陷的本质信息即可。
2、复现的步骤要详细，用数字编号。
3、实际结果要描述清楚复现后的结果。
4、列出期望结果。
5、提供附件。
6、提供严重性属性和其它公司需要填写的属性。

注意:要避免一些常见错误。
(1)避免使用情绪化语言和强调标点符号。
(2)避免使用模糊的词语。
(3)避免使用自认为幽默的语言，直接描述问题即可。
(4)避免提交不确定的缺陷:

在这里插入图片描述
ps:一般公司会使用jira、禅道、自建系统，特殊情况下，会使用excel表，根据公司习惯来

在这里插入图片描述
10.缺陷的跟踪

新提交的缺陷为“新建”状态，在确认有效之后变为“打开”状态，开发人员修
改后变为“已修复”状态，此时测试人员需要回归测试，如果验证问题已解决，
状态为“已解决”，如果问题依然存在，状态为“打开”;如果开发人员任务此缺
陷可以延期修改，状态为“延期”;注意此时必须由项目相关人员讨论确定后，才
可以延期处理，否则状态继续为“打开”。

11.缺陷密度