软件测试理论基础

最新推荐文章于 2024-08-05 19:17:04 发布

孤独的咬杀君

最新推荐文章于 2024-08-05 19:17:04 发布

阅读量1.4k

点赞数

分类专栏：软件测试

本文链接：https://blog.csdn.net/Devil_DiabLo/article/details/113954930

版权

软件测试专栏收录该内容

5 篇文章 0 订阅

订阅专栏

本文介绍了软件测试的基础知识，包括软件测试的目的、软件生命周期模型、测试流程和模型，以及测试用例设计方法。强调了软件测试的重要性，如发现错误、降低风险、提升软件质量。并探讨了不同测试阶段、模型的优缺点，如瀑布模型、螺旋模型、敏捷开发等，以及测试用例设计中的等价类划分、边界值分析等方法。同时，还涵盖了缺陷管理和报告的要素。

摘要由CSDN通过智能技术生成

软件测试人员的价值体现

1.问题单数量
2.测试用例数量

一. 软件测试

1.1 软件

软件 = 程序 + 数据 + 文档

软件的分类：
按层次划分：系统软件、应用软件
按组织划分：商业软件、开源软件
按结构划分：单机软件、分布式软件

1.2 软件测试及其目的

1.2.1 软件测试的定义

正向思维：使自己确信产品是能够正常工作的评价一个程序和系统的特性或能力，并确定它是否达到期望的结果，软件测试就是以此为目的的任何行为。
反向思维：测试是发现错误而执行一个程序或者系统的过程
测试是为了证明一个产品有错，而不是证明产品无错
一个成功的测试是发现了以前未发现的错误的测试
如果测试工作中未发现缺陷，这个工作就是没有价值的
IEEE定义：在规定条件下运行系统和构建的过程：观察和记录结果，并对系统或构件的某些方面给出评价。分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件的特性。
广义软件测试：软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行的测试，而不仅仅是对程序的运行测试。

确认：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现（Exit）
验证：通过检查和提供客观证据来证实指定的需求是够满足（需求满足）

1.2.2 软件测试目的

1.以最少的人力、物力和时间找出软件中潜在的错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患带来的商业风险
2.同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复相同的错误
3.采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量

	测试	调试
主体	测试人员	开发
目标	找缺陷	将错误修改正确
方法	等价类、边界值…	程序和逻辑算法
思路	反向思维	正向思维

二. 软件生命周期和模型

2.1 软件危机和软件工程

2.1.1 软件危机

软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

2.1.2 软件工程

工程：标准化

软件工程的两方面内容
1.软件开发技术：软件开发方法学、软件工具、软件工程环境
2.软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划

引起软件危机的主要问题是软件质量问题
软件工程主要解决的就是软件质量问题
软件测试是软件质量管理体系中一个非常重要的手段

2.2 软件生命周期

在这里插入图片描述

2.3 软件生命周期模型

2.3.1 瀑布模型

最早提出的软件开发的过程模型
优点：
1.为项目提供了按阶段划分的检查点
2.当一个阶段完成后，只需要关注后续阶段
缺点：
1.各阶段的划分完全固定，阶段之间产生大量文档，极大增加了工作量。
2.线性开发，用户等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3.瀑布模型不适应用户需求的变化

2.3.2 螺旋模型

引入其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失
螺旋模型更适合大型的昂贵的系统级的软件应用

2.3.3 迭代模型

迭代：强调开发的深入
开发迭代是一次完成经过所有工作流程的过程：需求分析、设计、实施、测试
优点：

降低了在一个增量上的开支风险
降低了产品无法按照既定进度进入市场的风险
加快了整个开发工作的进度
迭代过程这种模式使适应需求的变化会更容易些

2.3.4 敏捷开发模型

敏捷宣言：
个体互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

2.3.5 增量模型

将软件分割为独立模块，分批次完成和交付。
优点：优先抢占市场，根据客户需求响应变化
缺点：打破原有的软件结构框架，可能带来一定风险

2.3.6 快速原型模型

原型：一个模型，可以模拟操作、简单那运行。
工具：Axure

三. 软件测试流程和模型

3.1 软件测试流程

在这里插入图片描述

3.2 软件测试过程模型

3.2.1 V模型

缺点和不足：

v模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽略了测试对需求分析、系统设计的验证
需求的满足情况一直到后期的验收测试才被验证
没有体现出“尽早地和不断地进行软件测试”的原则

3.2.2 W模型

优点：

测试的活动与软件开发同步进行
测试对象不仅仅是程序，包括需求和设计
尽早发现软件缺陷可降低软件开发的成本
局限性：
在w模型中，需求、设计、编码等活动被视为串行的，这样就无法支持>灵活的迭代。

3.3.3 H模型

H模型

H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
H模型揭秘了一个原理：软件测试是一个独立流程（外包）
H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以展开，并且不同的测试活动可按照某个次序先后进行，也可以反复进行。

3.3.4 X模型

x模型定位了探索性测试，这是不事先计划的特殊类型的测试，这一方式往往能够帮助有经验的测试人员在测试计划之外发现更多的软件错误

3.3 软件测试过程理念

尽早测试
全面测试
全过程测试
独立、迭代的测试

四. 软件测试分类与原则

4.1 软件测试分类

4.1.1 按照开发阶段划分

单元测试：模块测试，是针对软件设计的最小单位–程序模块进行正确性>校验的测试工作。从程序内部结构出发设计测试用例。单元测试都是由开发人员自己完成的（交叉）。
集成测试：组合测试，比较多的涉及到接口测试，是一个持续不断的过程。
确认测试：确认功能是否实现（冒烟测试），一般不作为正式测试环节
系统测试：全面的（系统功能测试，模拟所有的软件用户操作），全方位的（和系统硬件的联系、和系统软件的联系、和其他软件的联系）
验收测试：决定是够接受和拒收系统。
分为三个阶段
$\alpha$ 测试：软件开发商验收
$\beta$ 测试：软件使用商验收
$\gamma$ 测试：软件使用商寻求第三方进行测试

4.1.2 按照代码运行划分

1.静态测试：不实际运行被测试对象

代码测试：代码是否符合相应的标准规范
界面测试：
文档测试：

2.动态测试：运行被测试对象

4.1.3 按照软件特性划分

功能测试
逻辑功能测试、界面测试、易用性测试、安装卸载测试、兼容性测试
性能测试
安全性测试

4.1.4 按照测试技术分类

黑盒测试
白盒测试：读懂代码，实现方式能够优化
灰盒测试（接口测试）

4.1.5 按照测试运行主体分类

1.手动测试
2.自动化测试

4.1.6 其他测试分类

回归测试：
冒烟测试：
随机测试：测试人员基于经验和直觉的测试，发现一些边缘性错误
猴子测试：把自己当成不懂产品的笨蛋或者小动物，随便乱点，没有任何主观的想法参与进来，让一些意想不到的操作造成错误的结果。

4.2 软件测试原则

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

五. 测试用例及设计

5.1 测试用例

5.1.1 测试用例模板

用例编号
用例名称
预制条件
测试步骤
测试数据
预期结果
测试结果
测试人
依赖用例
备注

5.1.2 测试用例作用

有效性：测试用例是测试人员测试过程中的重要参考依据
可重复性：良好的测试用例具有重复使用的功能
易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。
可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。

5.1.3 测试用例编写注意事项

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

5.2 黑盒测试用例设计方法

测试数据选择

5.2.1 等价类划分

把输入域划分成若干部分，从每个部分中选取代表数据
参考步骤：
1.划分有效等价类、无效等价类
2.对于有效等价类，根据实际情况，选择合适的分类条件进行划分。
3.分类越细致越好。

5.2.2 边界值分析

5.2.3 因果图法

因果关系：等非或与

约束条件：互斥、包含、唯一、要求、屏蔽

案例：

在这里插入图片描述

因果图的缺点：
当原因结果很多时，他们之间的连线会很多，导致可读性差。适用于局部小功能分析。
优点：发现设计中不足的情况
注意：需求中未描述的异常情况不能写在因果图中（图中黄色部分不该有）

5.2.4 判定表法

1.分析条件和动作

2.写入条件桩、动作桩、条件项、动作项

3.对判定表进行简化和优化

5.2.5 场景法

基本流：
备选流：
例如：ATM机取款

5.2.6 正交试验法

多因素多水平
使用的基本步骤：
1.确定因素
2.确定水平
3.选择正交表
特定因素水平数才有正交表，实际中选择最接近的。
举例：

5.2.7 功能图法（状态迁移图）

1.识别出可进行的操作
IP1：输入账号
IP2：输入密码
IP3：点击登陆
IP4：点击关闭按钮
2.定义空闲状态
QQ登陆界面
3.给空闲加状态
4.针对新状态进行分析，循环所有新增状态，直到没有新状态产生为止。

5.状态过程列表化，编写用例。

5.2.8 测试大纲法

一般用于快速测试

5.2.9 探索性测试法

基于测试人员的经验与直觉的测试方法
探索性测试也需要有测试用例

5.2.10 猴子测试法

无需测试用例
随便测试，无意识行为
问题难以复现

5.3 用例设计方法综合选择

首先进行等价类划分
在任何情况下都必须使用边界值分析法
如果输入条件有组合的情况，一开始就使用因果图判定表法。
参数配置类软件，使用正交试验法选择较小的组合方式达到最佳效果
通过不同时期条件的有效性设计不同的测试数据，使用状态迁移图
对于业务流清晰的系统，使用场景法贯穿整个测试案例过程

个人理解：
1.测试数据
2.测试逻辑
3.测试流程
4.测试最优性能
所有测用例设计方法都是融合使用的，一个界面中也可以使用多种测试方法设计用例。

5.4 成对测试-PairWise

成对测试

5.4.1 成对测试基本原理

原理：缺陷往往是由一个参数或两个参数的组合所导致的
方法：
1)每个因子的水平值都能被测试到
2)任意两个因子的各个水平值组合都能被测试到

5.4.2 筛选法

从笛卡尔积到PairWise
1：从笛卡尔积底部开始筛选，作为当前行
2：如果上面的所有行包含了当前行的所有Pair，则移除该行
3：由下至上所有行筛选完成后，等到Pairwise用例

5.4.3 正交拉丁方算法

正交拉丁方在组合测试中的应用分析

使用多重正交拉丁方来组合得来测试用例
1.一般要求水平数相同
2.当水平数不同时：增加行或列，添加无效值
3.不存在足够的拉丁方时：阶数扩展，添加无效值
4.因素数远大于水平数：分块处理

5.4.4 其他算法

AETG算法
IPO算法
Williams算法
PSST算法
Kobayashi算法

六. 缺陷和缺陷报告

6.1 缺陷

6.1.1 缺陷的定义

所有不满足需求的，超出需求的都是缺陷
没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷
1.软件未实现产品说明书要求的功能
2.软件出现了产品说明书指明不应该出现的功能
3.软件实现了产品说明书未提到的功能
4.软件未实现产品说明书未明确提及但应该实现的目标
5.软件难以理解、不易使用、运行缓慢、（从测试角度看）最终客户会认为不好的