<>1、软件测试的基本知识

<>1.1、软件测试目的

* 测试是程序的执行过程,目的在于发现错误
* 一个成功的测试用例在于发现至今未发现的错误
* 一个成功的测试是发现了至今未发现的错误的测试
* 确保产品完成了它所承诺或公布的功能,并且用户可以访问到的功能都有明确的书面说明。
* 确保产品满足性能和效率的要求
* 确保产品是健壮的和适应用户环境的
<>1.2软件测试原则

* 尽早介入测试
* 测试用例由输入数据和与之对应的预期输出结果两部分组成
* 程序员应避免检查自己的程序
* 设计测试用例的时候,要包括合理的输入条件和不合理的输入条件
* 注意缺陷具有集群性
* 严格执行测试计划,排除测试的随意性
* 杀虫剂悖论
* 应当对每一个测试结果做全面检查。
* 妥善保管测试计划、测试用例、出错统计和最终分析
<>1.3软件测试的分类

<>1.3.1 静态测试和动态测试

* 静态测试:不实际运行被测软件,只检查程序代码、界面或文档中的错误
* 动态测试:实际运行被测软件,输入相应的测试数据,检查输出结果和预期结果是否相符
* 静态测试和动态测试的唯一判断标准:被测软件是否运行
<>1.3.2 黑盒测试和白盒测试

* 黑盒测试:把被测软件当成黑盒子,只关心输入数据和输出结果 常用于软件的功能和性能
* 白盒测试:把“盒子”打开研究软件里的源代码和程序结构 常用于软件的源代码
<>1.4 软件测试模型

<>1.4.1 V模型

<>1.4.2 W模型

<>1.4.3 H模型

<>1.4.4 X模型

<>1.4.5 各个模型的优缺点

模型名称 优点 缺点
V模型 1. 既有底层测试,又有高层测试
2. 便于控制开发过程,当所有阶段都结束时,软件开发就结束了 1. 测试介入太晚,需求变更时,工作量大
2. 编码完成后才进行测试,bug不容易被发现
3. 无法支持迭代、自发性以及变更调整
W模型 1. 将测试贯穿整个软件开发的生命周期中,需求、设计、代码等都要测试
2.更早介入软件开发中,能够更早的发现缺陷
3. 测试与开发独立起来,与开发并行 1. 对于需求和测试技术要求很高,实践困难
2. 无法支持迭代、自发性以及变更调整
H模型 1.将测试从开发中独立出来,将测试分为测试准备和测试执行,只要触发点一触发即开始测试
2.H模型兼顾效率和灵活性,可以被应用到各种规模类型的软件项目上 不知道,考到就凉凉
X模型 不知道,考到就凉凉 不知道,考到就凉凉
<>1.5测试用例和测试环境

* 测试用例=输入+输出+测试环境
* 测试环境=软件+硬件+网络
* 4W :why when who what
*
<>2、软件测试过程

<>2.1 软件测试流程概述

<>2.1.1 软件测试流程

* 测试计划
* 测试设计
* 测试开发
* 测试执行
* 测试评估
<>2.1.2 按阶段划分测试

* 单元测试 :对软件中的最小可测试单元进行检查和验证。
* 集成测试:将已通过 测试的单元模块组装成系统或子系统,再进行测试, 重点测试不同模块的接口部分。
* 确认测试:检查已实现的软件是否满足了需求规格说明书中确定了的各种需求,以及软件配置是否完全,正确。
* 系统测试:是指将整个软件系统看做1个整体进行测试,包括对功能,性能,以及软件所运行的软硬件环境进行测试。
* 验收测试:让用户对软件进行测试,保证没有引入新的错误
<>2.2 单元测试

<>2.2.1单元测试的时间

* 程序员编码之后,代码通过编译之后进行单元测试
<>2.2.2 单元测试的人员

* 白盒测试工程师、开发人员,开发人员测试时,应做到交叉测试
<>2.2.3单元测试依据

* 源程序,代码,注释
* 《详细设计》文档
<>2.2.4 单元测试通过标准

* 程序通过所有的单元测试的用例
* 语句的覆盖率达到100%
* 分支的覆盖率达到85%
<>2.2.5 如何进行单元测试

* 单元测试主要采用白盒测试,先静态检查代码是否符合规划,再动态运行代码,检查运行结果(非法数据、边界处理等)**
<>2.3 集成测试

<>2.3.1集成测试的时间

* 理论:单元测试之后(效率低)
* 实际:单元测试和集成测试同步进行,单元测试中先测试几个函数的功能,然后再集成测试一下这几个函数的接口(即参数传递)
<>2.3.2 集成测试的人员

* 白盒测试工程师、开发人员,开发人员测试时,应做到交叉测试
<>2.3.3集成测试依据

* 单元测试模块
* 《详细设计》文档
<>2.4 系统测试

<>2.4.1 系统测试的特点

* 需要花费大量的时间和精力(交付给用户进行验收测试的最后一道关口)
* 测试工作前松后紧,后期的测试工作量大
<>2.4.2 系统测试的依据

* 《系统需求规格说明书》文档。
<>2.5 验收测试

<>2.5.1 验收测试的重要性

* 涉及到用户能否最终验收签字并付款。
<>2.5.2 α测试

* 由用户、测试人员、开 发人员共同参与的内部测试。
<>2.5.3 β测试

* 内侧后的公测,即完全交给最终用户测试。
<>2.6 各种测试的对比

测试名称 测试对象 测试依据 测试人员 测试方法 时间比例
单元测试 软件的最下模块 详细设计 白盒测试工程师
或开发人员 主要采用白盒 1
集成测试 软件各个模块之间的接口 概要设计 白盒测试工程师
或开发人员 黑盒白盒结合 2
系统测试 整个系统 需求规格说明书 黑盒测试工程师 黑盒测试 4
验收测试 整个系统 需求规格说明书 主要为用户,还
可能有测试工程师 黑盒测试 2
<>3、 黑盒测试

<>3.1 等价类划分法

​ 所谓等价类是指某个输入域(输出域)的子集合。再这个子集合中,每个数据对于程序来讲都是等效的,即每个数据都可以代表这一类的其他数据

<>3.1.1 等价类划分原则

* 完备性:整个集合划分成若干个互不相交的子集合
* 无冗余性:子集互不相交
<>3.1.2 有效等价类和无效等价类

* 有效等价类:对于软件规格说明书来讲,是有意义、合理的输入数据组成的集合,用于验证预先规定的功能和性能
* 无效等价类:对于软件规格说明书来讲,是无意义、不合理的输入数据组成的集合,可以鉴别程序异常处理的情况
<>3.1.3 等价类划分设计测试用例的步骤

* 划分有效等价类和无效等价类
* 建立等价类表
* 设计测试用例,尽可能多的覆盖有效等价类
<>3.1.4 等价类设计测试用例的例子

<>3.2 边界值分析法

​ 对输入或输出的边界值进行测试的一种黑盒测试方法,测试用例来自等价类的边界

<>3.2.1 边界值法设计思路

*
确定边界情况,着重测试边界情况

*
取值应取等于、刚刚大于或刚刚小于作为测试数据,不选取等价类中的典型值或任意值

一部分数据的取值:

<>3.2.2 边界值法例子

其中,每个方框便是对一个边界的测试

<>3.3 决策表法

在所有的黑盒测试方法中,基于决策表(判定表)的测试是最为严格、最具有逻辑性的测试方法

<>3.3.1 决策表的优点

* 将复杂的问题简化,并避免遗漏
* 十分适合处理多个逻辑条件的问题
<>3.3.2 决策表的组成

* 条件桩:列出问题的所有条件
* 条件项:针对条件桩给出的条件列出所有可能的取值
* 动作桩:列出所有问题规定的可能的取值
* 动作项:列出了在条件项下应采取的动作

<>3.3.3 决策表的合并


在决策表中,如果有两个或多条的动作项相同,条件项只有一项不同(该条件桩可以去多个值时,所有可能的取值都需要有)可以将该项合并,合并不同取值的条件项用“-”表示,得到最终的决策表

​ 例:

<>3.3 因故图法

<>3.3.1 因果图法产生的原因

​ 等价类法、边界值法都是着重考虑输入条件,没有考虑输入条件的各种组合、输入条件之间的相互制约关系
,多个条件组合后可能出错的情况被忽略,便产生了因果图(逻辑模型)

<>3.3.2 因果图法的优点

* 考虑到了输入条件之间的各种组合以及制约关系
* 帮助测试人员按照一定的步骤,高效率的开发测试用例
* 将自然语言规格说明严格的转换为形式语言规格说明,指出说明规格存在的不完整和二义性
<>3.3.3 因果关系的基本符号

<>3.3.4 因果关系中的约束符号

PS:

* E约束(异)(Exclusive排外的):a和b中最多有一个可能为1,即a和b不能同时为1
* I 约束(或)(In):a、b、c中至少有一个必须为1,即 a、b、c不能同时为0
* O约束(唯一)(Only):a和b必须有一个且仅有一个为1
* R约束(要求)(Request):a是1时,b必须是1,即a为1时,b不能为0。
* M约束(强制)(mandatory):若结果a为1,则结果b强制为0
<>3.3.5 因果图法测试举例

*
分析程序规格说明书,列出原因和结构

*
画出因果图

*
将因果图转换为决策表

*
设计测试用例

<>4、白盒测试

<>4.1 逻辑覆盖法

<>4.1.1语句覆盖(SC)

每条语句至少执行一次

例:

<>4.1.2 判定(分支)覆盖(DC)

不仅每个语句执行一次,每个判定的每种可能(真和假)都要执行一次

例:

<>4.1.3 条件覆盖(CC)

每个判定的每个条件应取到各种可能的值

并不是说满足条件覆盖的就一定满足判定覆盖,或者满足判定覆盖的就一定能够满足条件覆盖

例:可以看到,其中路径没有完全被覆盖,判定也没有被覆盖

<>4.1.4 条件判定覆盖(CDC)

同时满足判定覆盖条件覆盖

<>4.1.5 条件组合覆盖(MCC)

设计足够多的测试用例,使被测程序中每个判定的所有可能的条件取值组合至少执行一次。

例:

<>4.1.6 各种覆盖法的对比

<>4.2 基本路径测试

<>4.2.1 基本路径测试方法

* 画出程序的控制流图
* 就算程序的圈复杂度(确定测试用例数目的最大值)
* 确定程序的独立路径
* 设计测试用例的输入数据和预期输出
<>4.2.2 控制流图

* 节点:节点由带标号的圈表示,代表一个或多个语句、一个处理框和一个条件判定框
* 控制流线:由带箭头的弧或线表示,称为边

<>4.2.3 圈复杂度

用于计算程序的基本独立路径数目

计算圈复杂度的方法

* V(G)=E-N+2,E是图中边的数量,N是图中结点的数量。
* 将圈复杂度定义为控制流图中的区域数
* V(G)=P+1,P是控制流图G中判定(谓词) 结点的数量。
<>5、性能测试

不知道怎么复习,看书吧

技术
©2019-2020 Toolsou All rights reserved,
@Repository注解的作用最优化方法总结:公式解、数值优化、求解思想C#/.NET 系统优化专题(redis第六篇 数据结构【List】)非父子组件之间的三种传值办法vue使用THREE.js创建一个可以控制的立方体elementui select 获取 valuepython读取、写入txt文本内容在vue+element-ui中,select选项值动态从后台获取,同时将选中值的id传给后台的方法keras数据生成器--数据增强TypeScript中的数据类型这一篇就够了