软件测试理论

最新推荐文章于 2025-08-27 14:25:42 发布

原创最新推荐文章于 2025-08-27 14:25:42 发布 · 5.5k 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

软件测试学习笔记

python学习

软件测试理论

IEEE定义软件测试

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

正向思维：软件正常操作，达到预期结果

反向思维：软件反常操作，破坏性操作软件，出现错误

确认与验证：

确认：检查提供证据证实实现了特定功能

验证：检查提供证据证实指定需求满足

测试与调试

测试：找bug，等价类边界值，反向思维

调试：对错误进行修改，程序和逻辑算法，正向思维

软件设计模型

**瀑布模型：**计划（项目计划）-需求分析（需求规格说明书）-设计（概要设计、详细设计）-编码-测试-运行维护

严格执行时间顺序，前阶段不完成后阶段不开始。测试放在编码之后

**螺旋模型：**精密昂贵的系统适合
在这里插入图片描述

迭代模型：包括产品发布（稳定可执行的版本）的全部开发活动和使用该发布的所有其他元素，强调开发的深入。

开发迭代是一个完整经过所有工作流程：需求分析、设计、实施、测试

敏捷开发模型：

客户合作、响应变化，工作的软件、个体互动高于一切

在这里插入图片描述

增量模型：

软件分割为独立模型，分批次完成交付，打破原有软件框架会带来一定风险，一般和迭代模型一起使用，软件增加功能优化了什么，修复了什么

快速原型模型：

原型是模拟操作同时简单运行。

产品经理通过AXur等软件，制作无法交互的原型，软件的原始模型，ui设计页面展示等，客户通过后，开发测试依照这个进行运作

软件测试流程

获取测试需求-编写测试计划-指定测试方案-开发与设计测试用例-执行测试-提交缺陷报告-测试分析与评审-提交测试总结-准备下一轮测试

软件测试过程模型

V模型：

测试靠后

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

W模型：

在这里插入图片描述

H模型：

只针对测试过程，测试活动完全独立出来，将测试准备活动和测试执行活动清晰体现出来

测试外包公司

x模型：

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

单独定义了探索性测试，这一方面能帮助有经验的测试人员在测试计划之外发现软件错误

软件测试过程理念

尽早测试、全面测试（开发、测试、用户参与到测试）、全过程测试（要关注开发过程，测试过程全跟踪）、独立的迭代的测试（测试循环往复且独立）

软件测试按模块分类

单元测试：

模块测试程序模块进行正确性检验，测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试

集成测试：

集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统

冒烟测试（确认测试）：

有效性测试，模拟环境下，验证原件的所有功能和性能及其他特性是否与用户预期一致

系统测试:

真实环境测试

系统与验收：

软件测试按照代码测试分类

静态测试：

不实际运行被测对象，只是静态的检查程序代码、界面、文档中可能存在错误

动态测试：

实际运行被测对象，输入对应数据，检查实际输出结果和预期结果是否相符

软件测试按照软件本身特性划分

功能测试：

黑盒测试一种，检查实际软件功能是否符合用户需求

逻辑功能测试、界面测试、易用性测试（软件功能有效性、效果）、安装卸载测试、兼容性测试

性能测试：

软件在指定时间空间条件下是否能满足要求，时间性能和空间性能

安全性测试：

验证系统中保护机制能否在实际应用中对系统的保护使之不受各种因素干扰

回归测试：

对于一个新版本软件进行测试时，重复执行之前某一个重要版本的所有测试用例，证明之前版本错误被修复，确认是否引发新的缺陷

冒烟测试（可靠性测试）：

在进行大规模系统测试前，先验证软件基本功能能否实现是否具备可靠性，确认测试

随机测试：

错误推断法，依靠直觉经验进行操作

猴子测试：

把自己当成笨蛋或者第一次使用的客户，进行瞎操作，没有主观想法进行测试

软件测试按照测试技术分类

黑盒测试

白盒测试

灰盒测试：

介于黑白之间，关注输入输出正确性，同时也关注内部代码表现，但是不完全像白盒一样关注

软件测试在不同阶段的侧重点

加粗表示着重点

	单元	集成	确认	系统	验收
测试技术	黑盒、白盒	黑盒、白盒、灰盒	黑盒、白盒	黑盒、白盒	黑盒、白盒
代码运行	动态、静态	动态、静态	动态、静态	动态、静态	动态、静态
软件特性	功能、性能、安全	功能、性能、安全	功能、性能、安全	功能、性能、安全	功能、性能、安全
其他测试			冒烟测试	回归测试	随机测试

软件测试的原则

·所有测试的标准都是建立在用户需求之上。
·软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。
·事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。·软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。
·穷举测试是不可能的。
·第三方进行测试会更客观，更有效。
·软件测试计划是做好软件测试工作的前提。
·测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计
测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
·对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。
·重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等)·应当把“尽早和不断地测试”作为测试人员的座右铭
·回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见·测试应从“小规模”开始，逐步转向“大规模”。（防止缺陷由于模块调用的集群效应）
·不可将测试用例置之度外，排除随意性。
·必须彻底检查每一个测试结果。
·一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
·对测试错误结果一定要有一个确认的过程。

软件测试的测试用例

定义与作用

简单地说，测试用例就是:
·设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果
·如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内

·软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题己修改完成。

测试用例要有有效性、可复用性、可管理性、可评估性，易组织性

模板内容

用例编号：项目名称_模块名称功能名称编号

测试时间人员

测试内容

优先级

前置条件（需要用到其他用例进行预置操作）

输入

助兴步骤

预期结果

实际结果

备注（附件）

测试用例按照纵度和深度划分，按照测试分类：功能、界面、性能、安全、接口

测试用例需要经常更新，尤其是发现过缺陷的用例

测试用例必须是确定项，请使用二元对立是或否相关

软件测试工程师要获取跟产品相关的知识才能更好设计测试用例

软件测试用例的测试目的必须明确，不能一次测试测试多个点。

用例依赖（预置条件）可以跨越模块

用例编写要求

·不要设计“穷举测试用例”
·在详细测试用例与有效测试时间中找到平衡点·好的测试用例应该多关注“反向测试问题”·测试用例库应该不断更新和维护
·测试用例可以复用，但要注意数据有效性与环境变化·测试用例是设计出来的，不是写出来的
·多去学习经验丰富的测试工程师所设计的测试用例
·针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法

软件测试黑盒测试用例设计

按照测试数据分类

等价类划分

程序输入域划分诺干成分，从每个部分选取代表性数据作为测试用例。每一类代表性数据作用等价于这一类其他值。反之某一类例子没有错误这这一类也不会查出错误

原则

·在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类（输入要求字符8位，必须要@字符，则无效等价类为大于8位的字符和不含有@字符的）
·在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类
·在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类·在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类
·在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
·在确知己划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
无效等价类的测试数据一般出现一次就可以了

边界值

特定的数据

划定软件输入过程中跨界范围

按照测试步骤分类

因果图

便于发现设计上的缺陷，原因不对结果必定不对，没有原因出结果更加不对，如果原因正确结果没有达到预期就是产品设计不对

适用于多种输入条件组合的测试方式

根据输入条件的组合、约束条件和输出条件的因果关系，分析输入条件的各种组合情况进行测试用例设计，考虑实际业务的内在联系

因果图的原因与结果：

1、恒等，原因A成立，结果B一定成立

2、非，原因A成立时结果B一定不成立

3、或，原因ABC有一个成立结果D一定成立

4、与，原因ABC都成立结果D一定成立

·因果图原因与原因，结果与结果的约束条件:

根据功能说明在因果图中加上约束条件
·其中互斥、包含、唯一、要求时对原因的约束，屏蔽是对结果的约束。他们的含义如下

**·互斥:**表示不同时为1，即a，b，c中至多只有一个1
·**包含:**表示至少有一个1，即a，b，c中不同时为o
·唯一:表示a，b，c中有且仅有一个1
·要求:表示若a=1，则b必须为1。即不可能a=1且b=0
·**屏蔽:**表示若a=1，则b必须为o

当原因和结果很多时，关系会很多，用例很多，因果图可读性差劲了

不要设计缺少部分原因的结果测试用例，设计测试用例不能把缺陷设计进去

如：饮料机需要投币按按钮才能给饮料，我们不能设计按下按钮出饮料的测试用例

在这里插入图片描述

判定表

应用场合：多逻辑条件下内容与结果的分析

组成：

条件桩，列出问题的所有条件与次序无关
动作桩，列出问题可能采取的所有行动与次序无关
条件项，列出针对条件桩的所有可能的真假取值与次序无关
动作项，列出条件项所需要的动作与次序无关

步骤：

识别操作条件和对应动作

分析条件组合数量：n个条件，每个条件分成立和不成立情况，最后组合数量是2的n次方

简化有优化结果，排除不存在情况（像上面按按钮直接出现饮料）

实例演示

·需求:订购单的检查。
·如果金额超过500元，又未过期，则发出批准单和提货单;·如果金额超过500元，但过期了，则不发批准单;
·如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。"

（1）分析条件和动作

条件1	条件2	动作
金额>500	过期	发出批准单和提货单
金额>500	未过期	不发批准单
金额<=500	过期	发出批准单和提货单发出通知单
金额<=500	未过期	发出批准单和提货单

（写入条件桩和动作桩）

实际条件按照上面的来会有16种，扣掉互斥条件和不可能发生的情况，实际能使用的就只有四种（分别用0、1表示满足和不满足）

金额500	超过	0	1	0	1
	不超过
时效	过期	1	0	0	1
	未过期
发出动作	批准单	1	1	1	0
	提货单	1	1	1	1
	通知	1	0	0	0

第三列00110需要删掉，因为这种情况没有原因，自然没有结果，所以属于无效用例

金额500	超过	0	1	1
	不超过
时效	过期	1	0	1
	未过期
发出动作	批准单	1	1	0
	提货单	1	1	1
	通知	1	0	0

判定表规则适用规则
·规格说明以判定表的形式给出，或很容易转换成判定表·条件的排列顺序不影响执行哪些操作
·规则的排列顺序不影响执行哪些操作
·当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则·如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

正交实验

深度的等价类划分，数独，每一行每一列的同一个数字出现次数相等；任意两列的数字对出现的次数也是相等的

大量实验中找到合适实验组合，挑选一部分代表性数据进行实验

基本思想:
·在一项试验中，把影响试验结果的量称为试验因素(因子)，简称因素。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。
·每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，能有效地比较试验结果并找出最优的试验条件。
·在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中。

实验操作步骤：

分析所有可能影响结果的因素（软件需求说明、功能说明、界面等所有可能因素）

分析每个因素的水平数量，充分利用边界值，等价类（隐形需求和显性需求都算）

选中正交表，只有特定因素和水平数进行组合才有相应的正交表。（正交表因素数和水平数一般要大于实际的因素数和水平数）

影响实验的因素：

每个因素的不同取值（水平）

在这里插入图片描述