【功能测试】软件测试基础
文章目录
- 前言
- 1 测试基础
-
- 1.1 软件测试定义
- 1.2 软件生命周期
- 1.3 常见测试模型
- 1.4 软件质量模型
- 1.5 软件测试分类
- 1.6 软件环境介绍
- 1.7 软件测试流程
-
- 1.7.1 需求评审
- 1.7.2 需求分析
- 1.7.3 编写测试计划
- 1.7.4 提取功能点
- 1.7.5 编写用例并进行评审
- 1.7.6 冒烟测试
- 1.7.7 执行测试用例
- 1.7.8 BUG提交管理
- 1.7.9 编写测试报告
- 总结
前言
该文章主要阐述软件测试定义、测试用例以及测试方法，测试缺陷、禅道，测试文档。
1 测试基础
1.1 软件测试定义
软件测试是使用人工或者是自动的手段 来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。（IEEE协会定义）
1.2 软件生命周期
计划
- 确定开发目标
- 完成项目可行性研究
- 项目进度预估安排
- 制定实施计划
需求分析
- 分析整理项目需求项
- 依据需求项编写需求规格说明书（SRS）
- 制作产品原型
设计
- 完成项目概要设计
- 完成项目详细设计
编码
- 依据设计说明书完成代码编写
测试
- 单元测试：对程序的最小单元或者是一个类进行测试的过程。
- 集成测试：对模块与模块之间调用接口进行测试的过程
- 系统测试：对完成编译的系统整体进行测试的过程
- 验收测试：交付给客户或者最终客户时，和客户一起完成的测试
运维
- 产品部署
- 运行维护
- 功能升级
- 性能提升
1.3 常见测试模型
1.传统瀑布模型
特点：过程串行 工作测试后置，修改成本巨大
2.V模型
特点：测试过程细化，但是测试仍然后置，没有解决风险问题
3.W模型
特点：测试开发分离，对过程中的需求文档等文档进行测试，测试工作前置，大大降低项目质量风险。
4.敏捷模型
特点：适应现在互联网企业的“短频快”开发节奏设计的模型
迭代：每个迭代叫做一个sprint ，周期一般是一个月
1.4 软件质量模型
八大质量属性
外部质量：功能性、可靠性、易用性、性能效率、兼容性、安全性
内部质量：可移植性、维护性
- 实例：如何测试一个水杯质量？
功能性：是否漏水、水容量、水杯保温性、水杯刻度是否和国标一致等
可靠性：易坏、保温时长、杯子的耐热性和耐寒性等
易用性：外观完整美观、喝水是否漏水、方便携带、防滑
安全性：材质无毒、高温无毒、与其他物质是否会产生毒性
可移植性：多处可使用
兼容性：果汁、白酒
效能：倒水时长
可维护测试：是否容易分解、是否容易修复
1.5 软件测试分类
测试阶段划分：单元测试、集成测试、系统测试、验收测试
是否查看源代码：黑盒测试、灰盒测试、白盒测试
是否运行划分：静态测试、动态测试
是否自动化：手工测试、自动化测试
其他测试：冒烟测试、验收测试、回归测试、探索测试
附：验收测试：α测试（内测版本）β测试（公测版本，对所有用户开放）
1.6 软件环境介绍
开发环境：开发人员为联调程序而搭建的环境
测试环境：测试人员为测试程序而搭建的环境
准生产环境（预发布环境/灰度）：测试人员为模拟生产环境而搭建的环境
生产环境（线上环境）：用户访问的系统所部署的环境
1.7 软件测试流程
需求评审-需求分析-编写测试计划-提取功能点-编写测试用例-进行用例评审-冒烟测试-执行测试用例-BUG提交管理-编写测试报告
1.7.1 需求评审
目的：保证需求说明书的完整准确 保证项目团队对需求理解一致
会议地址及时间安排：项目经理PMO（产品人员）提前协助安排好，然后邮件通知
参会人员：相关开发、测试、产品、项目经理
会议进度把控：项目经理或者产品把控
会议前测试准备工作：提前了解需求，标明不理解、有歧义的地方、待会议提出
会议中：提出疑问，做好笔记
1.7.2 需求分析
继续熟悉产品需求规格说明书，了解业务背景以及同行的参考
1.7.3 编写测试计划
作用：有效的测试计划会驱动测试工作的完成，使测试执行、测试分析、以及测试报告工作开展的更加顺利
目的：明确工作内容，工作周期、工作风险等，保障测试工作有序进行，提高测试的工作效率，保证测试任务高质量完成
测试工作安排：资源分配、人员分配
测试范围：测试点优先级 重点关注
测试策略：测试技术和方法
测试开始/测试完成/测试上线指标：冒烟通过/测试报告发布/BUG修复率达到90以上
项目延期风险预防：人员风险、测试环境风险、测试广度、测试深度、回归测试、需求变更、测试时间压缩（开发占用测试时间）
1.7.4 提取功能点
如何提取：
功能性需求
1、根据需求说明书梳理功能点（琢磨每句话）
2、根据业务流程，梳理功能点
3、需求中明确规定不可用的功能
非功能需求
性能要求：响应时间、兼容性、用户体验、UI界面等
1.7.5 编写用例并进行评审
- 测试用例定义
为验证软件是否符合需求而设计的一组输入，执行条件，有预期结果的文档 - 编写流程
需求分析-提取测试点-编写测试用例-评审测试用例-修改测试用例 - 测试用例的作用
验证软件是否满足需求；提高测试覆盖率，避免遗漏测试场景；工作量的衡量 - 测试用例写作要点
测试用例编号：要具有易识别性
项目：用例所属项目
模块：用例所属模块
用例标题：简单描述测试点
用例级别：高（基本功能、影响客户数量大、涉及金额数量等），中、低（界面优化等）
前提条件：执行用例所需要的前提条件
数据输入：数据准备，测试当前用例需要的数据
操作步骤：执行当前用例的步骤
预期结果：理想中的结果
实际结果：测试时的结果
测试用例方法：- 等价类：定义：在某个输入域集合，每个输入条件都是等效的，如果某一个输入不会导致问题，则集合其他输入条件进行测试也不可能发现问题。有效等价类：有意义、正确的输入 无效等价类：无意义、错误的输入
- 边界值：上点，离点
- 判定法
- 流程分析法（场景分析法）
- 错误猜测法（探索性测试）
用例评审参与人员：产品、开发、测试
1.7.6 冒烟测试
正向主流程走一遍
1.7.7 执行测试用例
原则：前紧后松
时间充足的情况下：所有用例都执行
时间不足的情况下：按照优先级从高到低执行
1.7.8 BUG提交管理
- 缺陷定义
软件没有实现产品说明书功能，软件实现产品说明书没有功能，从最终用户角度出发感知产品 - 缺陷严重程度
致命：软件意外退出、crash、数据丢失等
严重：某个功能失效，导致其他多个相关功能失效、阻塞流程问题
一般：单个功能失效
轻微：界面显示相关问题 - 缺陷优先级
紧急：需要立即修复
高：当天修复
中：两天修复
低：上线前修复或不修复或延期 - 缺陷整体流程
测试提交BUG指派给开发（bug状态：激活）
开发修改BUG指派给测试（bug状态：解决）
测试回归BUG（bug修复-关闭；没修复好，重新激活） - 常见问题
不能重现的缺陷：
一定要提交缺陷库：附加复现概率、操作步骤、日志等
不可重现的缺陷关闭时不能只在一个版本上检测缺陷是否修复 - 禅道使用
网站下载开源版测试
创建产品-创建项目-设置团队成员-创建版本-提交BUG-开发修复BUG-重新打开或关闭BUG - 回归测试
目的：检查软件缺陷是否确实被修复，是否引进新的缺陷
完成回归：工作量大
选择性回归：只测试被修改或者可能影响的部分
分为3中方法如下：
覆盖修改法：改哪里测试哪里，时间紧，项目急的情况
周边影响法：常用方法
指标达成法：先设置指标，达成即可 - 验收测试
以用户为主的测试，分为α测试和β测试
α测试：内测，用户在开发环境下测试，开发人员在场，受控
β测试：公测，实际使用环境测试测试，开发人员不在，又称灰度测试
1.7.9 编写测试报告
测试结束的标志
主要内容：测试工作过程和结果、风险说明、缺陷汇总和分析、测试工作总结和改进
总结
重点：软件生命周期、软件质量模型、缺陷管理、禅道使用