软件测试
软件测试的定义
使用人工或自动的手段运行或测试软件得到实际结果,找 BUG、发现缺陷,检验软件是否满足预期的需求。
-
软件是否符合设计要求
-
软件是否符合用户的实际需求
软件测试的目的
以最小的人力、物力、时间成本,找出软件中潜在的错误与缺陷。
软件测试的原则
-
测试应尽早介入。缺陷越早发现,修改所需成本越低。
-
无法穷尽测试。
-
缺陷是必然的,没有发现缺陷也不能证明没有缺陷。
-
80% 的用户只用到 20% 的功能。
测试流程
-
需求分析
阅读需求文档、产品文档、设计说明书,分析真正的需求。
-
制定测试计划、方案
- 制定测试的范围、进度安排、人力物力安排、测试策略、风险评估…
为什么去做、何时去做、谁去做、怎么做、做哪里、如何去做。
- 针对测试的目标选取测试工具,注重测试的重点。
-
设计测试用例
-
执行测试用例
-
打印测试报告,进行评估
开发模型
瀑布模型
计划时期
- 问题定义
- 可行性研究
开发时期
- 需求分析
- 大概设计
- 详细设计
- 编码
- 测试
运行时期
- 维护
特点
- 一个阶段完成以后才能进入下一个阶段
- 每个阶段都有一个检查点,比对文档,发现是否不合理,可以保证质量
- 前一阶段完成后,只需关注后续阶段
缺点
- 每个阶段都是确定的,不适合需求模糊或经常变动的系统,灵活性差
- 用户需要较长时间的等待
增量模型
规格说明 -> 设计 -> 实现和集成 -> 交付客户
不是等待整个系统开发完成,每次只是增加了一个小的功能,就交付给客户。
快速原型
快速分析 -> 构造 -> 运行 -> 评价
快速实现了一个很小的需求,适合需求不明确的软件系统开发,但选用的开发技术与工具不一定符合主流的发展,快速建立的系统结构加上连续的修改可能导致产品质量低下。
测试模型
V 模型
单元测试 -> 集成测试 -> 系统测试 -> 验收测试,分别对应如下阶段:
编码 -> 详细设计 -> 概要设计 -> 需求分析
缺点:测试介入较晚,对于前期的一些缺陷无法发现和修改。
W 模型
需求分析 -> 概要设计 -> 详细设计 -> 编码 -> 集成 -> 实施 -> 交付,分别对应:
验收测试设计 -> 集成测试设计 -> 单元测试设计 -> 单元测试 -> 集成测试 -> 系统测试 -> 验收测试
优点:测试伴随软件的整个生命周期
软件测试分类
测试阶段
-
单元测试
编码完成前或后测试,主要测试类、方法(函数)、模块
-
集成测试
单元测试完成以后、模块已经写完编码时测试,主要测试模块与模块之间的调用
-
系统测试
集成测试完成后,主要测试整个程序、软件、app、网站项目
-
交付测试
系统测试之后,测试整个系统,内测、公测
是否覆盖源码
-
黑盒测试
看不见源码,只关注是否实现功能,不关注内部实现,运行程序得到的实际结果与预期结果比对。
用于功能测试、性能测试。
功能测试主要测试:
- UI 测试
- 业务测试
- 文档测试
- 易用性测试
- 安装、卸载
- 兼容性测试:多个浏览器都能正常运行?不同平台?(不同系统 windows、安卓、ios,不同品牌的手机等)软件升级后是否兼容以前的数据?是否打开其它有关联的软件?
性能测试
- 一般性能测试,包括响应速度、cpu 的使用率、gpu 的使用率、内存占用
- 稳定性测试:服务器、程序的稳定性
- 负载测试,能够承受高并发的访问
- 压力测试,在资源极少的情况下运行(如内存不足),观察程序的状况
-
白盒测试
可以看见源码内容,包括:
- 语句覆盖,确保代码中的每条语句都会被执行
- 条件覆盖,每个条件分支都会执行
-
灰盒测试
除了关心输入输出,也要关心程序运行的状态,但不需要关心所有代码
冒烟测试
检查最基本的模块是否能正常运行
测试用例
为了某个特殊目标准备一组输入、执行条件以及预期结果,测试程序是否符合特定需求。
测试用例的要素
测试用例编号 | 测试用例标题 | 测试项目 | 前提条件 | 测试输入 | 预期输出 | 操作步骤 | 级别 | 测试结果 |
---|---|---|---|---|---|---|---|---|
qq-login-01 | 有效测试qq登录 | 登录 | 网络正常 | 100000 | qq号正确 | 输入qq号,点击登录 | 重要 | 通过 |
qq-login-02 | 无效测试qq登录 | 登录 | 网络正常 | abcdef | qq号码输入有误 | 输入qq号,点击登录 | 重要 | 通过 |
等价类划分法
将所有可能的输入划分成若干部分,从每部分中抽取有代表性的数据作为测试用例。
有效等价类:合理、有意义的输入数据构成的集合
无效等价类:不合理、无意义的输入数据构成的集合,要给出错误原因,程序也不应崩溃
边界值法
边界值易出错,输入数据应取边界值、离边界值最近的点。
因果图
考虑输入条件的组合情况、制约关系。
条件:
- 输入 50 元
- 输入 100 元
- 充值 50 元
- 充值 100 元
结果:
a. 完成充值、退卡
b. 提示充值成功
c. 找零
d. 提示错误
出现记为 1,不出现记为 0
exclude:至多只有一个 1
include:至少有一个为 1
mandatory:若一个是 1,另一个必须是 0
only:有且只有一个为 1
required:若一个是 1,另一个必须是 1
判定表
输入 | 1.输入50 | 1 | 1 | 1 | |||||
---|---|---|---|---|---|---|---|---|---|
2.输入100 | 1 | 1 | 1 | ||||||
3.充值50 | 1 | 1 | 1 | ||||||
4.充值100 | 1 | 1 | 1 | ||||||
输出 | a.完成充值,退卡 | 1 | 1 | 1 | |||||
b.提示充值成功 | 1 | 1 | 1 | ||||||
c.找零 | 1 | 1 | 1 | 1 | |||||
d.提示错误 | 1 | 1 | 1 | 1 | 1 |
测试用例编号 | 测试用例标题 | 测试项目 | 前提条件 | 测试输入 | 预期输出 | 操作步骤 | 级别 | 测试结果 |
---|---|---|---|---|---|---|---|---|
bus-001 | 测试充值50元 | 充值模块 | 系统正常 | 50元选择充值50 | 充值完成、退卡,提示充值成功 | 1.投入50,2.选择充值50 | 重要 | 通过 |
正交表
https://cnblogs.com/gisen_6/p/3708201.html
https://blog.csdn.net/jiangjunsss/article/details/123684835
以最小的用例获得最大的测试覆盖率。
字体颜色 | 字体样式 | 字体风格 | 字体大小 |
---|---|---|---|
红色 | 粗体 | 宋体 | 30 |
黄色 | 斜体 | 正楷 | 40 |
蓝色 | 下划线 | 方正 | 50 |
红色、粗体、宋体、30
红色、斜体、正楷、40
红色、下划线、方正、50
黄色、粗体、正楷、50
黄色、斜体、方正、30
…
可通过 allpairs 生成。
场景法
从起点经过一系列步骤达成某一结果,到达终点的过程,用于冒烟测试。
基本流:a 拨打 b 的电话 -> b 电话响铃 -> b 接电话 -> 通话中 -> 挂断
备选流:a 拨打 b 的电话 -> b 电话未响铃 -> 提示对方关机或不在服务区,a 挂机结束
备选流2:b 电话响铃 -> b 主动挂断 -> 提示对方关机或不在服务区,a 挂机结束
备选流3:通话中 -> c 拨打 a 的电话 -> 对方忙,c 挂机结束
…
流程分析法
找出业务流程的各个页面与其它页面的跳转关系,分为广度优先和深度优先。
每个节点能够到达的地方:
a | b | c | d | e | f | g | h | i | j | |
---|---|---|---|---|---|---|---|---|---|---|
a | √ | √ | √ | |||||||
b | √ | √ | √ | |||||||
c | √ | √ | √ | √ | ||||||
d | √ | √ | √ | |||||||
e | √ | √ | ||||||||
f | √ | √ | √ | |||||||
g | √ | √ | ||||||||
h | √ | √ | ||||||||
i | √ | |||||||||
j | √ |
深度优先:选择一条路往前走,遇见多条分支,只选择一条分支走到黑;若选择的分支已重复走过,返回上一节点,选择另一条分支,直到覆盖到所有分支。
a -> b -> e -> f -> c -> h -> g 返回上一节点 h、c、f、e、b、a,选择 d 继续往下走。d -> i 返回上一节点 d -> j。
广度优先:走遍当前节点的所有相邻节点,再依次走遍相邻节点周围的相邻节点。
a -> b、c、d
b -> e、f
c -> h、g
d -> j、i
先考虑场景法,关注业务逻辑是否实现
需要输入数据的地方,考虑等价类划分法和边界值法
包含输入条件的组合情况,使用因果图与判定表法
对于配置类软件,需要考虑参数的组合情况,使用正交表
文章质量提示
此文章质量较低,不会获得较多流量扶持! 可能的原因为:篇幅太短,广告涉嫌违规,外链过多,缺少代码,图片涉嫌违规。 了解规则