软件测试基础学习笔记

2023-12-13 06:08:47

软件及测试

定义

软件:控制计算机工作的工具
软件测试:使用技术手段验证软件是否满足使用需求
测试目的:减少软件缺陷,保障软件的质量

测试分类

按照测试阶段划分:

  • 单元测试:针对程序的源代码进行测试(一般由开发进行)
  • 集成测试:又称接口测试,针对模块之间的访问地址进行测试
  • 系统测试:对整个系统进行测试,包括功能、兼容、文档等测试
  • 验收测试:主要分为内测、公测,使用不同人群来发掘项目缺陷

按照代码可见度划分:

  • 黑盒测试:代码不可见,UI功能可见
  • 灰盒测试:部分源代码可见,功能可见
  • 白盒测试:全部代码可见

质量模型

说明:衡量一个优秀软件的维度

  • 功能性:
    • eg:需求:10个功能;每个功能详情
      • 功能数量正确
      • 功能正确实现
      • 错误处理情况(eg密码错误等)
  • 性能:
    • eg:需求:预估每日在线20w
      • 服务器每秒处理请求数
      • 服务器硬件配置是否满足
  • 兼容性
    • 浏览器:谷歌、IE、苹果、火狐、欧朋
    • 操作系统:win7、win8、win10、其他
    • 手机:分辨率、品牌、系统、网络、其他
  • 易用性
    • 简洁、友好、流畅、美观
  • 可靠性
    • 无响应
    • 卡顿、响应时间慢
    • 死机、系统崩溃
  • 安全
    • 传输加密
    • 存储加密
  • 可移植性
    • 网站数据迁移
  • 可维护性

测试流程

  1. 需求评审:各部门需求理解保持一致;测试需落地需求中有多少功能,哪些是核心功能;
  2. 计划编写:测什么、谁来测、怎么测
  3. 用例设计:验证项目是否符合需求的操作文档
  4. 用例执行:项目开发完成后开始执行用例文档实施测试
  5. 缺陷管理:对缺陷进行管理的过程
  6. 测试报告:实施测试结果文档

测试用例

  • 用例:用户使用的案例
  • 测试用例:为测试项目而设计的执行文档
  • 测试用例的作用:
    • 防止漏测
    • 实施测试的标准
  • 用例设计:
    • 8大要素:用例编号、用例标题、项目/模块、优先级、前置条件、测试步骤、测试数据、预期结果
    • 设计编写格式:
      • 用例编号:项目_模块_编号
      • 用例标题:预期结果(测试点)
      • 项目/模块:所属项目或模块
      • 优先级
      • 前置条件:执行该用例需要的前置操作
      • 测试步骤:描述操作步骤
      • 测试数据:有就写,没有就不写
      • 预期结果

练习:
需求:QQ登录

  1. 账号为空
  2. 账号为注册
  3. 密码为空
  4. 密码错误
用例编号用例标题模块优先级前置条件测试步骤测试数据预期结果
QQ_login_001账号为空,登录失败登录p11、打开登录页面; 2、网络正常1、输入账号;2、输入密码;3、点击登录账号:空;密码“123”登录失败,提示账号不可为空

测试用例设计方法

等价类

场景:对穷举场景设计测试点
说明:在所有测试数据中,具有某种共同特征的数据集合进行划分
分类:

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

步骤:

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

eg、验证qq号的合法性,要求6-10位自然数
需求:长度:6-10位; 类型:自然数
有效等价:6-10位自然数
无效等价:小于6位自然数;大于10位自然数;6-10位非自然数;空
提取数据:7位:1234567;5位:12345;13位:1234567890123

边界值

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

  • 上点:边界上的点(刚好等于)
  • 离点:距离上点最近的点(刚好大于、刚好小于)
  • 内点:范围内的点

步骤:

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

优化:
结论:7个点优化为5个点
上点:必选(不考虑区间开闭)
内点:必选(建议选择中间的点)
离点:开内闭外(开区间选择内部离点,闭区间选择外部离点)

判定表法

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

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

规则:

  • 判定表中,贯穿条件项和动作项的一列就是一条规则
  • 假设有n个条件,每个条件的取值有两个,那么有2的n次方种规则

步骤:

  1. 明确需求
  2. 画判定表
  3. 提取数据编写用例

场景法

定义:场景法也叫流程图法,是用流程图来描述用户的使用场景,然后通过覆盖流程路径来设计测试用例
意义:

  • 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用
  • 测试人员角度:平时都是单个功能点进行测试,容易忽略多个功能的组合测试

说明:

  1. 覆盖业务测试需要使用流程图法
  2. 先测试业务,在测试单功能、单模块、单页面
  3. 业务用例需要流程图来梳理,需要学会画流程图和看懂流程图

错误推荐法

应用场景:当项目用例都执行完毕,且bug修复完成,离上线还有一段时间,可以使用错误推荐法去复测主要业务 或 未覆盖的业务

缺陷

定义:软件在使用过程中存在的任何问题都是缺陷,简称bug
标准:

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

缺陷产生的原因:

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

缺陷的生命周期:需求规格说明(可能产生bug)->设计(可能产生bug)->编码(可能产生bug)->测试(发现bug)->故障分类->故障隔离->故障解决(可能产生bug)
缺陷核心内容:

  • 标题:描述缺陷的核心问题
  • 预置条件:缺陷产生的前提
  • 缺陷的复现步骤
  • 预期结果
  • 实际结果
  • 必要附件:日志、截图、视频等

缺陷的提交要素:编号、严重程度、优先级、bug类型、缺陷状态
缺陷类型:功能错误、界面UI错误、兼容性、数据、易用性、改进建议、架构

文章来源:https://blog.csdn.net/weixin_40417029/article/details/134961339
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。