软件测试系列——概述,用例设计
软件测试概述
软件测试是为了向利益相关者提供有关被测软件产品或服务质量的信息而进行的调查。软件测试还可以提供客观,独立的软件视图,以使企业能够理解和理解软件实施的风险。测试技术包括执行程序或应用程序的过程,目的是发现软件错误(错误或其他缺陷),并验证软件产品是否适合使用。
软件测试涉及软件组件或系统组件的执行,以评估一个或多个感兴趣的属性。通常,这些属性指示受测组件或系统的程度:
- 满足指导其设计和开发的要求
- 正确响应各种输入
- 在可接受的时间内执行其功能
- 足够可用
- 可以在预期的环境中安装和运行,并且
- 达到利益相关者期望的总体结果
由于即使是简单的软件组件,可能进行的测试数量实际上都是无限的,因此所有软件测试都使用某种策略来选择在可用时间和资源上可行的测试。结果,软件测试通常(但不是排他性地)试图执行程序或应用程序,目的是发现软件错误(错误或其他缺陷)。测试工作是一个反复的过程,因为当一个错误被修复时,它可以阐明其他更深层次的错误,甚至可以创建新的错误。
from baidu
什么是软件
软件是控制计算机硬件工作的工具
软件的两种分类
- 应用软件
- 系统软件
软件的基本组成
常分为
- 页面或客户端
- 代码服务器
- 数据服务器
测试的主流技术
- 功能测试
- 自动化测试
- 接口测试
- 性能测试
测试分类
按照阶段
- 单元测试:针对程序源码进行测试
- 集成测试:又称接口测试,针对模块之间访问地址进行测试
- 系统测试:对整个系统进行测试包括功能、兼容、文档等
- 验收测试:主要分为内测、公测,使用不同的人群发掘项目缺陷
按照代码可见度
- 黑盒测试:源码不可见,功能可见
- 灰盒测试(集成测试):部分源码可见,功能不可见
- 白盒测试(单元测试):源码可见,功能不可见
质量模型
是衡量一个“优秀”软件的维度
8大衡量标准
- 功能性
- 性能
- 兼容性
- 易用性
- 可靠性
- 安全
- 可维护性
- 可移植性
测试流程
- 需求评审:确保各部门需求理解一致
- 计划编写:测什么,谁来测,怎么测
- 用例设计:验证项目是否符合需求的操作文档
- 用例执行:项目模块开发完成开始执行用例文档实施测试
- 缺陷管理:对缺陷进行管理的过程
- 测试报告:实施测试结果文档
用例
用例是用户使用的案例
例如:系统是否卡顿,是否发热等
测试用例
为测试项目而设计的执行文档
测试用例的作用
- 防止侧漏
- 实施测试的标准
测试用例的编写标准(格式)
- 用例编号
- 用例标题
- 项目/模块
- 优先级
- 前置条件
- 测试步骤
- 测试数据
- 预期结果
用例编号格式
项目_模块_编号
用例标题格式
预期结果(测试点)
项目/模块格式
所属项目或模块
优先级格式
重要程度即优先级(P0~P4,P0最高)
前置条件格式
执行此条用例需要的前置操作
测试步骤格式
测试步骤顺序(1. xxx,2.xxx)
测试数据格式
需要操作的数据,空不填
有则需要尽量易于理解,使用json格式
预期结果格式
期望达到的结果,直接语言描述
如何设计用例
等价类划分法
在所有测试数据中,具有某种共同特征的数据集合进行划分,用于解决穷举场景
分类
- 有效等价类:满足要求的数据集合
- 无效等价类
步骤
- 明确需求
- 确定有效和无效等价类
- 提取数据编写测试用例
边界值分析法
等价类基础上对于边界范围的测试数据输入的地方,常用于测试最大、最小、大小等类型,多是输入框类的测试
边界范围节点
选取正好等于、刚好大于、搞好小于边界的值作为测试数据
- 上点:边界上的点(等于)
- 离点:距离上点最近的点(刚好大于,刚好小于)
- 内点:范围内的点(区间范围内的数据)
步骤
- 明确需求
- 确定有效和无效等价类
- 确定边界范围值
- 提取数据编写测用例
边界值优化(开内闭外)
使用开内闭外原则
如:[56,1001)
我们只需要测试55、1000两个离点即可无需测试55、57、1000、1002四个了
判定表法
用于测试有条件依赖关系的场景
等价类边界值分析法主要关注单个输入类条件的测试
并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试
实际是以表格的形式表达多条件逻辑判断的工具
判定表的组成
- 条件桩:列出问题中的所有条件,列出条件的次序无关紧要,列出条件对应的取值,所有可能情况下的真假值
- 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束,列出条件项的、各种取值情况下应该采取的动作结果
判断规则
- 判定表中贯穿条件项和动作项的一列就是一条规则
- 假设有n个条件,每个条件的取值有两个(0,1),全组合有2的n次方种规则
步骤
- 明确需求
- 构建判定表
- 提取数据编写用例
判定表的格式
条件1 | xxx |
---|---|
条件2 | xxx |
条件… | xxx |
操作 | xxx |
操作… | xxx |
场景法
场景法也可以叫流程图法,是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例
意义
用户使用角度
用户平时使用的不是单个功能,而是多个功能组合起来进行使用
测试人员角度
平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试
步骤
- 明确需求
- 根据流程图获取用例
错误推断法
根据经验推测系统可能会出现的问题
- 时间紧任务量大时,根据之前项目类似经验找出易出错的模块重点测试
- 实践宽裕通过该方法列出之前出现问题较多的模块再次测试
根据经验列举出可能出现问题的清单,根据清单分析问题可能原因,推测发现缺陷
实际上是当所有测试都已经结束,但是距离上线还有一段时间时,可以采用该方法推测错误进行复测