软件测试理论

软件测试理论

功能测试，什么是功能呢？比如登陆功能、注册功能、评论功能等。

1. 测试基础

1.1 软件及测试

image-20240628183415069

软件测试：使用技术手段验证软件是否满足需求。

软件测试的目的：减少软件缺陷，保证软件质量。

1.2 主流技术

功能测试

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

image-20240628192659282

自动化测试

使用代码或者工具代替手工，对项目进行测试。

image-20240628192849877

接口测试

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

image-20240628193058323

性能测试

模拟多人使用软件，查找服务器缺陷。

image-20240628193550503

1.3 测试分类

按测试阶段划分

image-20240628194408737

按代码可见度划分

image-20240628194606920

1.4 质量模型

质量模型用来衡量一个优秀软件的维度。

从以下几个点进行衡量：功能性、性能、兼容性、易用性、可靠性、安全、可维护性、可移植性。

功能、性能、兼容、易用、安全最重要。

例子

需求：

  • 开发一款网络游戏（要求：10个主功能）
  • 游戏支持web（浏览器）端、App端
  • 游戏上线后预计每日20w用户玩家在线

功能性

需求：10个功能、功能详情

测试：功能数量为10个、功能正确实现、错误处理情况

性能

需求：预计每日在线人数20w

测试：服务器每秒处理请求数、服务器硬件配置是否满足

兼容性

兼容多种浏览器，如：谷歌、IE、火狐、欧朋、苹果

兼容多种操作系统，如：Win系统（win7、win8、win10）、MacOS等

兼容多种移动端，如分辨率、品牌、系统、网络等

易用性

简洁、友好、流畅、美观

可靠性

无响应、卡顿、死机

安全

信息传输、信息存储

1.5 测试流程

需求评审：确保各部门需求理解一致

计划编写：测什么、谁来测、怎么测

用例设计：验证项目是否符合要求的操作文档

用例执行：项目模块开发完成开始执行用例文档实施测试

缺陷管理：对缺陷进行管理的过程

测试报告：实施测试结果文档

1.7 测试用例

用例：用户使用的案例。

测试用例：为测试项目而设计的执行文档。

测试用例的作用：

  • 防止漏侧
  • 实施测试的标准

用例设计编写格式

用例编号：用例的唯一标识符（项目_模块_编号）

用例标题：用例的测试内容，格式为：预期结果（测试点）

项目/模块：用例所属的项目或模块

优先级：用例先执行还是后执行（P0～P4，P0最高，用户最常用的功能最重要）

前置条件：执行用例的前置条件

测试步骤：描述执行用例的操作步骤

测试数据：用例执行过程中所需的数据，没有的话可以为空

预期结果：用例期望得到的结果

案例练习

需求：QQ登陆

  • 账号为空
  • 账号未注册
  • 密码为空
  • 密码错误

测试用例：

image-20240630173516900

2. 测试设计

实现目标：

  • 能对穷举场景设计测试点
  • 能对限定边界规则设计测试点
  • 能对多条件依赖关系进行测试设计点
  • 能对于项目业务进行设计测试点

2.1 等价类划分

解决穷举场景问题。

说明：在所有测试数据中，具有某种共同特征的数据集合进行划分。

分类：

  • 有效等价类：满足需求的数据集合
  • 无效等价类：不满足需求的数据集合

步骤：

  • 明确需求
  • 确定有效和无效等价类
  • 提取数据编写测试用例

案例：验证QQ账号长度的合法性

要求：6～10位自然数

步骤：

  • 明确需求：6～10位自然数
  • 有效等价类：8位，无效等价类：3位、12位。
  • 提取数据编写测试用例：有效等价类：12345678，无效等价类：123、123456789012，共三条测试用例

案例：验证某城市电话号码正确性

要求：

1.区号：空或者是三位数字

2.前缀码：非“0”且非“1”开头的三位数字

3.后缀码：四位数字

步骤：

  • 明确需求，长度、类型、规则

  • 确定有效和无效等价类

    image-20240630182230136

  • 设计数据编写用例

    image-20240630185026322

    有效数据共2条，无效数据共8条。所以共需10个测试用例才可以覆盖。

    测试用例：

    image-20240630185947935

等价类划分法使用场景：需要有大量数据测试输入，但是没有办法穷举测试的地方。

  • 输入框
  • 下拉列表
  • 单选复选框

2.2 边界值分析法

解决限定边界问题。

边界范围节点

选取正好等于、刚好大于、刚好小于边界的值作为测试数据。

  • 上点：边界上的点（正好等于）
  • 离点：距离上点最近点点（刚好大于、刚好小于）
  • 内点：范围内点点（区间范围内点数据）

边界值法设计用例步骤

  • 明确需求
  • 确定有效和无效等价类
  • 确定边界范围值
  • 提取数据编写测试用例

案例

需求：通过边界值法验证标题长度的合法性。

要求：标题长度大于0，小于等于30个字符。

步骤：

  • 明确需求：通过边界值法验证标题长度的合法性。标题长度大于0，小于等于30个字符。

  • 确定有效和无效等价类

    有效等价类：长度大于0，小于等于30个字符

    无效等价类：长度大于0，小于等于30个数字

  • 确定边界范围

    上点：0位，30位

    离点：-1位，1位，29位，31位

    内点：15位

  • 提取数据编写测试用例

    image-20240701110231667

边界值法优化

7个点优化为5个点

  • 上点：必选（不考虑区间开闭）
  • 内点：必选（建议选择中间范围）
  • 离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

边界值法使用场景

  • 在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
  • 常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
  • 典型代表：有边界范围大输入框类测试

2.3 判定表法

解决多条件依赖关系问题。

等价类边界值分析法主要是关注单个输入类条件的测试。并未考虑输入条件之间的各种组合、输入条件与输入结果之间有相互制约关系的测试。

判定表是一种以表格形式表达多条件逻辑判断的工具。

组成：

  • 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
  • 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
  • 条件项：列出条件对应的取值，所有可能情况下的真价值。
  • 动作项：列出条件项的、各种取值情况下应该采取的动作结果。

如验证“用户欠费或者关机，则不允许主被叫“功能的测试。

image-20240701113431647

规则：

  • 判定表中贯穿条件项和动作项的一列就是一条规则
  • 假设有n个条件，每个条件的取值有两个(0,1)，全组合含有2的n次方中规则

判定表法设计用例步骤

  • 明确需求
  • 画出判定表
    • 列出条件桩和动作桩
    • 填写条件项，对条件进行全组合
    • 根据条件项的组合确定动作项
    • 简化、合并相似规则（有相同的动作）
  • 根据规则编写测试用例

案例

  • 明确需求

    1.如果金额大于5000元，又未过期，则发出批准单和提货单

    2.如果金额大于5000元，但过期了，则不发批准单与提货单

    3.如果金额小于等于5000元，则不论是否过期都发出批准单和提货单

    4.在过期的情况下，不论金额大小还需要发出通知单

  • 画出判定表

    image-20240701115734674

  • 根据规则编写测试用例

    image-20240701121849141

判定表法使用场景

  • 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

  • 判定表一般适用于组合数量较少的情况（比如4个条件以下）。如果条件超过4个，就不适合覆盖所有条件，应采用正交法来解决。

2.4 场景法

解决项目业务测试问题。场景法也叫流程图法。

覆盖业务测试需要使用流程图，先测业务，再测试单功能、单模块、单页面。

流程图对测试人员对作用：

  • 梳理业务用例
  • 当需求文档信息不全时，能够根据需求，梳理出流程

案例

ATM取款流程

image-20240701153621098

ATM机取款流程图

image-20240701153752625

  • 开始->验证银行卡不成功->结束
  • 开始->验证银行卡成功->验证密码错误3次->结束
  • 开始->验证银行卡成功->验证密码成功->验证账户余额不满足->结束
  • 开始->验证银行卡成功->验证密码成功->验证账户余额满足->验证总取款金额不满足->结束
  • 开始->验证银行卡成功->验证密码成功->验证账户余额满足->验证总取款金额满足->验证ATM机余额不够用->结束
  • 开始->验证银行卡成功->验证密码成功->验证账户余额满足->验证总取款金额满足->验证ATM机余额够用->结束

用例编写

image-20240701155920384

2.5 错误推测法法

通过经验推测系统可能出现的问题。

思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷。

使用场景：

  • 时间紧任务量大，根据之前项目蕾丝经验找出容易出错的模块重点测试。
  • 实践宽裕通过该方法列出之前出现问题较多的模块再次测试。

3. 缺陷管理

3.1 缺陷

缺陷：软件在使用过程中存在的任何问题，简称bug。

缺陷的判定标准

  • 少功能：软件未实现需求（规格）说明书中明确要求的功能
  • 功能错误：软件出现了需求（规格）说明书中指明不应该出现的错误
  • 多功能：软件实现的功能超出需求（规格）说明书指明的范围
  • 隐性功能错误：软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求
  • 不易使用：软件难以理解，不易使用，运行缓慢，用户体验不好

缺陷产生的原因

  • 需求阶段：需求描述不易理解，有歧义、错误等。
  • 设计阶段：设计文档存在错误或者缺陷。
  • 编码阶段：代码出现错误。
  • 运行阶段：软硬件系统本身故障导致软件缺陷。

缺陷的生命周期

image-20240701171735129

缺陷的核心内容

  • 缺陷的标题：描述缺陷的核心问题
  • 缺陷的预期结果：希望得到的结果
  • 缺陷的预置条件：缺陷产生的前提
  • 缺陷的实际结果：实际得到的结果
  • 缺陷的复现步骤：复现缺陷的过程
  • 缺陷的必要附件：图片、日志等信息（证据）

缺陷提交要素

image-20240701172613364

软件缺陷类型

功能错误、错误界面（UI）、兼容性、数据、易用性、改进建议、架构

3.2 缺陷跟踪流程

image-20240702232158056

提交缺陷注意事项

  • 可重现：缺陷可以重复
  • 唯一性：一个缺陷上报一个问题
  • 规范性：符合公司或者项目要求

3.3 缺陷管理工具-禅道

地址：https://www.zentao.net/

特点：三管融合（产品管理、项目管理、质量管理）、国产、免费、开源、简单、轻量级

image-20240702233303101

image-20240702233817581

posted @ 2025-03-27 20:44  mango0219  阅读(50)  评论(0)    收藏  举报