测试复习(自用)-Toy模板网

这篇具有很好参考价值的文章主要介绍了测试复习(自用)。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

测试复习

通识/基础/概念

什么是软件测试

验证软件特性是否满足用户的需求

专业名词

需求
- 满足用户期望或正式文档（合同、标准、规范）所具备的条件和权能，包含用户需求和软件需求
  - 用户需求
  - 软件需求
- 是测试人员开展软件测试工作的依据
- 如何让测试人员更好了解需求呢
  - 从需求分析阶段测试人员就介入（测试应当贯穿软件的生命周期）
bug
- 什么是bug
  - 规格说明存在且正确的时候，程序和规格说明之间的不匹配才是错误
  - 当需求规格说明书没有提到的功能，以用户为标准判断：程序没有实现最终用户合理预期的功能要求时，就是软件错误
- 如何描述一个bug(简单了解，笔试)
  - 标题
  - 发现bug的版本
  - 发现bug的环境
  - 发现bug的步骤
  - 期望的结果
  - 实际的结果
  - 其他
    - bug类型
    - bug等级
- bug的级别(具体要看企业的bug定级标准文档)
  - 崩溃
  - 严重
  - 一般
  - 次要
- bug的生命周期
  - New
    - 新发现bug，未经评审决定是否指派给开发人员修改
  - Open
    - 确认是bug，并且认为需要进行修改，指派给相应的开发人员
  - Fixed
    - 开发人员修改后标识为修改状态，有待测试人员的回归测试验证
  - Rejected
    - 认为不是bug，拒绝修改
  - Delay
    - 认为暂时不需要修改或暂时不能修改，则延后修改
  - Closed
    - 修改状态的bug，经测试人员的回归测试验证通过，则关闭bug
  - Reopen
    - 经验证bug仍然存在，则重新打开bug，开发人员重新修改
  - 具体流程

软件开发的生命周期

需求分析
- 分析用户需求是否合理（技术可行性、市场可行性）
- 产出软件需求文档
计划
- 指定需求执行计划
- 产出计划文档
设计
- 将需求细化成任务，进行技术设计（设计哪些接口，采用哪些技术）
- 产出设计文档
编码
- 开发人员按照需求文档以及设计文档来进行编码
测试
- 测试人员参考测试用例，执行测试
运行维护
- 项目上线后对产品进行线上维护
测试是如何贯穿软件的整个生命周期的
- 需求分析
  - 分析需求逻辑是否合理，是否符合用户行为习惯。还要站在开发人员角度思考技术实现难度，针对技术难度来合理调整需求
- 计划
  - 根据需求文档编写测试计划/方案
- 设计
  - 适当了解设计，合理的进行测试用例的设计和调整
- 编码
  - 专业的白盒测试人员可以执行单元测试，完善、细化测试用例以及调整测试计划和方案
- 测试
  - 测试人员参考测试用例执行测试
- 运行和维护
  - 测试往往是最了解需求的人，进行产品的演示和功能的介绍，期间记录大家的反馈建议，反馈给产品经理，成为一个新的用户需求

软件测试的生命周期

需求分析
- 站在用户的角度：需求逻辑是否正确，是否符合用户的需求和行为习惯
- 站在开发人员的角度：需求是否可以实现，或实现起来的难度大小
测试计划
- 指定测试计划：测试工时、人力安排等
测试设计、测试开发
- 设计测试用例（经验丰富的白盒测试人员可以开始单元测试）
测试执行
- 参考测试用例来执行测试
测试评估
- 测试人员需要记录测试，做好缺陷管理，进行测试的评估

跟开发产生争执了怎么办

具有批判性思维，反思是不是自己bug描述的不够清楚
bug等级一定要有理有据
合理友好的进行沟通，站在用户的角度反问，假如你是用户，你能接受吗？
不仅能够提问题，最好也能够给出解决方案
组织bug评审，邀请代表参加bug评审：产品代表、开发代表、测试代表
- 如何解决bug
- 如何预防类似的bug

常用模型

开发模型

瀑布模型
- 是其他所有模型的基础框架
- 特点：线性的开发流程，不能应对需求的变化
- 缺点
  - 测试被后置
    - 风险往往在后期的测试阶段才能被发现，因而失去了及早纠正的机会
    - 必须在代码完成后有足够的时间预留给测试活动，否则导致测试不充分，从而缺陷直接遗留给用户
  - 最大的缺陷是，产品要很迟才能被看到
- 适用于固定的小项目
螺旋模型
- 引入全流程的风险评估，每次分析完后后，都会生成一个新的原型
- 适用于规模庞大、复杂度高、风险大的项目
- 缺点：时间拉长，人力、资金耗费大
敏捷模型
- 敏捷宣言（了解）
- scrum
  - 三个角色
    - 产品经理
      - 收集用户需求，编写需求文档，对产品负责
    - 项目经理
      - 召开各种会议，协调项目，为团队研发服务
    - 研发团队
      - 开发人员、测试人员、UI人员等
  - 五个会议
    - 发布计划会议
      - 制定出这一期要完成的stroy列表，sprint backlog
    - 迭代计划会议
      - 任务分解，划分负责人，初步工时
    - 每日例会
      - 了解项目进度，预知风险并规避
      - 产出物：可交付的软件
    - 演示会议
      - 迭代结束后，展示成果。期间记录反馈，由po整理成新的story
      - 产出物：新的user story
    - 回顾会议
      - 项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果
- 特点：轻流程、轻文档、重目标、重产出
增量模型和迭代模型
- 增量模型
  - 逐块构造
  - 先画头，再画身体，再画四肢
- 迭代模型
  - 反复求精
  - 先画轮廓，再完善其他细节

测试模型

V模型
- 特点
  - 明确标注了测试的类型
  - 明确标注了测试阶段和开发阶段的关系
- 缺点
  - 风险别推迟到测试的时候才发现，失去及早纠正的机会
  - 必须给测试留足够的时间，不然风险会遗留给用户
W模型
- 特点：测试从需求阶段就开始介入了
- 缺点
  - 上一个阶段完成，下一个阶段才能开始
  - 开发模型和测试模型也保持着一种前后的线性关系
  - 重文档、重过程 => 不支持敏捷模型

测试用例

解决了测什么，怎么测
是为了实施测试而面向被测试的系统提供的一组集合
- 测试环境
  - 操作系统版本
  - 浏览器版本
- 测试步骤
- 测试数据
- 预期结果
为什么要设计测试用例
- 围绕软件需求来设计测试用例
  - 解决了重复测试的问题
  - 原则：避免用后即弃

设计测试用例的万能公式

界面测试
- 看得到的都要测试
功能测试
性能测试
- eg登录注册的响应时间，千万人同时访问接口
兼容性测试
- 系统版本
- 软件版本
- 终端
- 不同浏览器
易用性测试
- 产品是否简单易上手、方便使用
安全测试
- 针对物品来说
  - 本身是否有毒
  - 其他干扰环境下是否有毒有害
- 针对一个软件功能来说
  - sql注入
  - xxs漏洞
  - 越权（垂直越权、水平越权）
其他测试（根据测试对象的特性）

设计测试用例的方法

基于需求设计测试用例
- 需求分析
- 需求有哪些功能呢个
- 设计测试点
- 设计测试用例
等价类
- 针对需求输入范围划分成若干个等价类，从其中一个等价类取出一个用例，若该测试用例通过，则认为该测试用例所在的等价类是通过的
- 步骤
  - 确定有效等价类和无效等价类
  - 编写测试用例
边界值
- 通常是对等价类的补充
- 设计边界值测试用例的时候，需要加上边界值＋次边界值
判定表法
- 一种表达逻辑判断的工具
- 为什么别人写的因果图，而你使用判定表？
  - 根据因果图画判定表，我认为画因果图很多余，而且因果图在设计测试用例的时候并没有多大意义
- 步骤
  - 确认输入和输出条件
  - 找出输入条件和输出条件的关系
  - 画判定表
  - 根据判定表编写测试用例
- 适用于需要考虑输入之间的组合关系，不同的组合关系对应的输出结果不同
正交表法
- 步骤
  - 找到因素数和水平数
  - 用allpairs工具生成正交表
  - 根据正交表来编写测试用例
  - 补充测试用例
- 正交表达式
场景设置法
- 步骤
  - 基本事件流
  - 备用事件流
错误猜测法
- 依赖测试人员的个人工作经验
- 用到万能公式、弱网测试、异常测试

测试分类

按照测试对象分类

文档内存兼容性，界面易用可双安
界面测试（UI测试）
- 非软件
  - 颜色
  - 大小
  - 材质
  - 形状
  - 整体是否美观
- 软件
  - 尺寸、颜色、形状、整体适配清晰度
    - 输入框
    - 文本框
    - 滚动条
    - 按钮
    - 文字
    - 图片
可靠性测试（*）
- 可靠性 = 正常运行时间 / (正常运行时间＋非正常运行时间) * 100%，一般要求达到4个9或者5个9
容错性测试
- 指系统能够处理异常，用户的操作不至于系统崩溃，从而能够提高系统的可用性
文档测试
- 通常来说是需求评审阶段，测试人员需要进行需求分析（文档测试）
兼容性测试
- 浏览器兼容性
  - Chrome
  - Firefox
  - Edge
  - Safari
- 平台兼容性
  - PC端（Windows、Mac、Linux）
  - 移动端（安卓、苹果）
- 自身兼容性
  - eg.Chrome软件的1~103版本
- 其他软件兼容性
  - 其他软件的引流入口都不同
- 数据兼容性
易用性测试
- 软件需要具备简单易上手的特性
安装卸载测试
- 移动端很容易遗漏卸载测试
安全测试
- SQL注入
- XSS漏洞
- 越权
  - 垂直越权
  - 水平越权
性能测试
- 资源泄露
- 资源瓶颈（CPU、内存、网络、进程对比），采长补短
内存泄露测试
- 工具检查
  - 静态代码扫描工具
- 人工检查

按照是否查看代码划分

黑盒测试
- 把代码看做一个黑匣子，不关心内部结构和内部特性，只关心功能是否符合产品规格说明书
- 别称
  - 数据驱动测试
  - 功能测试
- 常见的黑盒测试设计测试用例的方法
  - 等价类
  - 边界值
  - 判定表
  - 正交法
  - 场景法
  - 错误猜测法
白盒测试
- 检查程序内部实现、检查程序的运行状态是否符合预期
- 别称
  - 逻辑驱动测试
  - 结果测试
灰盒测试
- 介于两者之间，既要关心内部构造和内部特性
- 通常用在集成测试
常见的测试方法有哪些？哪种用得更多？
- 黑盒测试和白盒测试，在工作中需要根据实际情况来结合黑盒测试和白盒测试。通常来说，测试人员使用黑盒测试要多一点
为什么不直接用灰盒测试？
- 灰盒测试没有白盒测试详细、完整，没有黑盒测试覆盖产品范围广，所以灰盒测试不能取代黑盒测试和白盒测试。
- 黑盒测试可以取代灰盒测试，但是不建议，需要消耗很大的代价

按照开发阶段划分

单元测试
- 针对系统最小单元进行测试
- 最小单元是人为规定的
集成测试
- 完成单元测试后，将模块和模块之间集成，按照功能来进行测试
冒烟测试
- 由测试人员来执行，检查系统主要功能/流程是否正常，评估软件/系统是否具备可测性的条件/标准
系统测试
- 集成测试完成后，测试人员准备项目环境，将程序看成一个整体，对程序/系统进行系统测试，保证系统功能符合产品规格说明书的要求
回归测试
- 对历史版本/功能进行测试，保证功能是符合要求的
- 随着功能迭代越来越多，版本越来越多，回归测试的难度相对于来说要大一些，需要借助自动化测试来进行回归测试
验证测试
- 通常是用户来进行验收测试，目的就是为了验证产品/程序是否符合用户的需求。实际上主要是由产品/运营来进行验收