软件测试定义:使用技术手段验证软件是否满足需求
1.常见测试分类
1.1 按测试阶段划分
单元测试:针对程序源代码进行测试
集成测试:又称接口测试,针对模块之间访问地址进行测试。
系统测试:对整个系统进行测试包括功能、兼容、文档等测试。
验收测试:主要分为内测、公测,使用不同人群来发掘项目缺陷。
1.2 按代码可见度划分
分为:黑盒测试,灰盒测试,白盒测试
2.质量模型
说明:衡量一个优秀软件的维度
质量模型:功能、性能、兼容、易用、安全、可靠性、移植性、维护性
3.测试流程
- 需求评审: 确保各部门需求理解一致
- 计划编写: 测什么、谁来测、怎么测
- 用例设计: 验证项目是否符合需求的操作文档
- 用例执行: 项目模块开发完成, 开始执行用例文档实施测试
- 缺陷管理: 对缺陷进行管理的过程
- 测试报告: 实施测试结果文档
4.用例
4.1 什么是用例
用例: 用户使用的案例
4.2 什么是测试用例
测试用例: 是为测试项目而设计的执行文档
4.3 测试用例的作用
- 防止漏测
- 执行测试的标准
4.4 用例测试编写格式
- 用例编号: 项目_模块_编号
- 用例标题: 预期结果(测试点)
- 模块/项目: 所属项目或模块
- 优先级: 表示用例的重要程度或者影响力p0-p4 (p0最高) 重要程度由用户的使用频率决定
- 前置条件: 要执行此条用例,有哪些前置操作
- 测试步骤: 描述操作步骤
- 测试数据: 操作的数据,没有的话可以为空
- 预期结果: 期望达到的结果
5.软件开发模型
5.1 瀑布模型
瀑布模型
- 需求分析
研发分析需求说明书
判断需求的可实现性
- 概要设计
用到具体的技术点
大致模块划分
- 详细设计
详细到可以为编码做支持
类和类关系, 类的设计
函数设计
各个接口的细节
数据库表的关系, 字段关系
- 编码
依托于详细设计进行编码操作
- 测试
- 维护
上线后也是需要持续维护
特点:
1.是线性模型的一种,在所有模型中占有重要地位,是所有其他模型的一个基础;
2.每一个阶段执行-一次,文档驱动,按线性顺序进行软件开发。
优缺点:
- 优点
-
- 每个阶段很清晰
- 只需要关注后续阶段
- 缺点
-
- 依赖于需求,不能适应需求变化
- 风险到项目后期才体现,失去早期纠正的机会
5.2 螺旋模型
优点:引入风险分析
缺点:风险分析需要专业的知识和人员
5.3 增量模型
对于每一个小的需求,也就是增量,无须等到所有需求都出来,分开进行编码和测试、分开上线
5.4 迭代模型
开发迭代是一次完整地经过所有工作流程的过程 ,每一个迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集
5.5 敏捷模型
敏捷宣言:
1、个体以及互动而不是过程和工具
2、可用的软件而不是完整的文档
3、客户合作而不是合同谈判
4、应对变更而不是遵循计划
scrume
三大角色
scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成
-
- 其中product owner负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。
- scrum master负责召开各种会议,协调项目,为研发团队服务。
- 研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品。
6.测试过程模型
6.1 测试v模型
优点:
包含了底层和高层的测试过程
每个步骤都是文档驱动的
缺点:
和研发瀑布模型一样, 不能适应需求的改变灵活性比较低
6.2 测试w模型
6. 设计测试用例的方法
6.1 等价类划分法
说明:在所有测试数据中, 具有某种共同特征的数据集合进行划分。
分类:
有效等价类: 满足需求的数据集合
无效等价类: 不满足需求的数据集合
例:6-8位账号,有效等价为6-8位,无效等价为小于6,大于8,
只取其中一个为代表
步骤:
1.明确需求
2.确定有效和无效等价类
3.提取数据编写测试用例
适用场景:
针对: 需要有大量数据测试输入,但是没法穷举测试的地方。
输入框
下拉列表
单选复选框
典型代表: 页面的输入框类测试。
案例:电话
要求:
- 区号:空或者是三位数字
- 前缀码:非“0”且非“1”开头的三位数字
- 后缀码:四位数字
此时根据有效等价和无效等价,得出共有10个用例(将有效数据进行合并,得2个,将无效数据每个都进行控制变量,得到8个)
6.2 边界值划分法
边界值法作为一种等价类法的补充,通过选择边界值点编写测试用例
6.3 判定表法
案例: 验证“若用户欠费或者关机,则不允许主被叫”功能的测试
说明:
- 等价类边界值分析法主要关注单个输入类条件的测试
- 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。
定义: 是一种以表格形式表达多条件逻辑判断的工具
组成:
- 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
- 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。
- 条件项:列出条件对应的取值,所有可能情况下的真假值。
- 动作项:列出条件项的、各种取值情况下应该采取的动作结果。
步骤:
1、明确需求
2、画出判定表
1) 列出条件桩和动作桩
2) 填写条件项,对条件进行全组合
3) 根据条件项的组合确定动作项
4) 简化、合并相似规则(有相同的动作)
3、根据规则编写测试用例
使用场景:
- 有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系
- 判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
6.4 场景法
流程图:
流程图对测试人员有什么作用?
1、能够看懂流程图,设计业务用例
2、当需求文档信息不全是,能够根据需求,梳理出流程
网页版工具: ProcessOn思维导图流程图-在线画思维导图流程图_在线作图实时协作
Windows工具: visio
提示: 业务用例是根据流程图来梳理的,需要先了解流程图
介绍:
- 说明:
-
-
- 场景法也可以叫流程图法, 是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例。
-
- 意义:
-
-
- 用户使用角度: 用户平时使用的不是单个功能,而是多个功能组合起来进行使用
- 测试人员角度: 平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试
-
适用场景:
根据实际的应用场景, 来测试业务用例,可以使用场景法
案例(ATM取款流程):
最左边的那条全部通过业务线路,称为冒烟测试用例,只有冒烟测试通过,程序才具有可测性
6.5 错误推测法
定义:通过经验雅测系统可能出现的问题
思想:根据经验列举出可能出现问题的清单,根据清单分析问题可能原因,推测发现缺陷
场景: 1、时间紧任务量大时,根据之前项目类似经验找出易出错的模块重点测试
2、时间宽裕通过该方法列出之前出现问题较多的模块再次测试
应用场景: 当项目用例都执行完毕,且BUG修复完成,离上线还有一段时间,在这段时间中可是使用错误推测
法复测主要业务或测试未覆盖的功能。
7.缺陷
7.1 用例执行
说明: 执行结果与用例的期望结果不一致(含义),为缺陷 。
7.2 缺陷相关概念
定义:软件在使用过程中存在的任何问题都叫软件的缺陷,简称bug。
判定标准:
软件未实现需求(规格)说明书中明确要求的功能--少功能
软件出现了需求(规格)说明书中指明不应该出现的错误--功能错误
软件实现的功能超出需求(规格)说明书指明的范围--多功能
软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求--隐性功能错误
软件难以理解,不易使用,运行缓慢,用户体验不好--不易使用
产生的原因:
需求阶段: 需求描述不易理解,有歧义、错误等
设计阶段: 设计文档存在错误或者缺陷
编码阶段: 代码出现错误
运行系统: 软硬件系统本身故障导致软件缺陷
生命周期:
7.3 缺陷要素
核心内容:
缺陷描述: 发现缺陷以后如何描述,让别人看的懂。
缺陷提交: 指派人、优先级、类型、
类型:
7.4 缺陷流程
缺陷报告示例:
缺陷的跟踪流程:
提交缺陷注意事项:
- 可重现:缺陷可以复现
- 唯一性:一个缺陷上报一个问题
- 规范性:符合公司或者项目要求
缺陷编写规范:
- 准确,具体,简洁易懂,次序清晰
7.5 缺陷管理工具
禅道介绍:
特点:
国产、免费、开源、简单、轻量级
三管融合(产品管理、项目管理、质量管理)
禅道特点:
- 三权分立:
-
- 产品部门一构想者
- 研发部门一执行者
- 测试部门一保证者
- 四角协同:
-
- 产品经理
- 项目经理
- 研发团队
- 测试团队
禅道使用流程: