为什么需要写测试用例:测试用例是测试过程中用来对照产品功能是否实现的一类工作文档,用来确保测试覆盖全面没有遗漏。是测试工作的核心。
功能测试也叫黑盒测试,只需考虑功能,不需要考虑整个软件的内部结构及代码,一般从软件产品的界面、架构出发,按照需求编写出来的测试用例,输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。
接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,来进行数据之间的交互。
兼容性测试目前包含web端和移动端的兼容。
1) web端:
- 新增或改动的页面、弹窗、组件。
- 新增或改动的涉及浏览器或系统调用的功能(比如下载文件到本地等)。
- 操作系统、浏览器、分辨率。
2) 移动端
1.设备兼容:
- 新增或改动的页面、弹窗、组件。
- 新增或改动的涉及系统级调用的功能时(比如调用相机、读取本地文件等)。
- Android:品牌、系统版本、屏幕分辨率。
- iOS:系统版本、屏幕分辨率。
2.版本兼容:
- 改动了已有的移动端接口时,需要对已上线的app版本进行相关功能的兼容测试。
- 版本升级测试。
- Android和iOS。
- 统计数据表明有用户正在使用的app版本。
性能测试是指通过特定方式,对被测系统按照一定策略施加压力,获取系统响应时间、TPS(Transaction Per Second)、吞吐量、资源利用率等性能指标,以期保证生产系统的性能能够满足用户需求的过程。
安全测试是在软件产品的生命周期过程中,对产品检验是否符合安全需求定义。
易错点应包含以下内容:
- 容易被错误地理解、或者实现起来比较复杂容易出错的需求。
- 以往迭代中某个开发或多个开发经常出现的问题,对应到本次迭代应特别注意的点,比如某某场景需要考虑性能、某某功能需要严格校验某某字段、某某新增页面的标题需要修改等。
功能分解是将需求规格说明中每个功能加以分解,确保各个功能被全面的测试。功能分解法主要步骤如下:
a) 使用功能抽象方法把程序分解为功能单元;
b) 使用数据抽象方法产生测试每个功能单元的数据。
等价类划分法是将需求中功能输入要求进行分解,将输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例,每一类的代表性数据在测试中的作用等价于这一类中的其它值。等价类划分法必须在分解输入要求的基础上列出等价类分解表,划分出有效等价类及无效等价类。
a) 有效等价类:对于功能需求来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验软件是否实现了软件需求规格说明中所规定的功能。
b) 无效等价类:与有效等价类相反。对于功能需求来说是非法的,但有意义的数据集合。利用无效等价类可检验软件在功能实现的基础上是否对异常输入进行了保护。
边界值分析法是针对软件边界情况进行验证。通常需要选择边界内、边界上及边界外的值对程序进行验证。对于边界值分析法主要步骤如下:
a) 分析软件文档,找出功能需求中所有可能存在的边界条件。
b) 对于边界条件,找出边界内、边界上及边界外的输入数据。
c) 根据输入数据设计测试用例。
猜错法是基于经验和直觉推测程序中所有可能存在的各种错误。通过列举出程序可能有的错误表和易错情况表,有针对性的设计测试用例。
因果图法是从软件需求规格说明描述的自然语言中找出功能的因(输入)和果(输出或状态改变),通过因果图转换为判定表,根据判定表设计测试用例。该方法主要步骤如下:
a) 分析软件需求规格说明,找出功能的因和果。
b) 分析软件需求规格说明中描述语义的内容,并将其表示成连接各个原因与各个结果的“因果图”。
c) 标明约束条件。由于环境等限制,有些因果的组合情况是不可能发生的。为表明特殊情况,需要在因果图中标明约束条件。
d) 将因果图转换为判定表。
e) 将判定表中每一列表示的情况设计测试用例。
判定表是分析和表达多逻辑条件下执行不同操作情况的工具。通常由四部分组成:条件桩,条件项,动作桩,动作项。任何一个条件组合的特定取值及相应要执行的操作构成规则,判定表中贯穿条件项和动作项的一列就是一条规则。该方法主要步骤如下:
a) 确定规则的个数。假设有 n 个条件,每个条件有 2 个取值,则有 2n 种规则。
b) 列出所有的条件桩和动作桩。
c) 填入条件项。
d) 填入动作项,并制定初始的判定表。
e) 合并相似规则或相同动作,简化判定表。
正交试验法是从大量的试验点中挑出适量的、有挖根生的点,应用正交表,合理地安排试验的方法。该方法主要步骤如下:
a) 提取功能说明,构造因此状态表。把影响实验指标的条件称为因子,影响实验因子的条件叫做因子的状态。在设计测试用例时,首先要根据软件需求规格说明找出影响功能实现的操作对象或外部因素,把它们当作因子,把各个因子的取值当作状态。
b) 加权筛选,生成因素分析表。对因子与状态的选择可按重要程度分别加权。根据因子及状态作用的大小、出现频率等因素,确定权值大小。
c) 利用正交表进行各因子的状态组合,构造有效的测试输入数据集,形成测试用例。
场景法是根据软件文档划分软件运行场景,根据软件运行场景设计测试场景。用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。基本流是经过用例最简单的路径,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入到基本流中,也可能起源于另一个备选流,或终止用例而不再重新加入某个流。
控制流测试依据控制流程图产生测试用例,通过对不同控制结构成份的测试验证程序的控制结构。
所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行,也称这一过程为覆盖。控制流测试
一般步骤如下:
a) 将程序流程图转换成控制流图;
b) 经过语法分析求得路径表达示;
c) 生成路径树;
d) 进行路径编码;
e) 经过译码得到执行的路径;
f) 通过路径枚举产生特定路径的测试用例。
数据流测试是用控制流图对变量的定义和引用进行分析,查找出未定义的变量或定义了而未使用的变量,这些变量可能是拼错的变量、变量混淆或丟失了语句。数据流测试一般步骤如下:
a) 将程序流程图转换成控制流图;
b) 在每个链路上标注对有关变量的数据操作的操作符号或符号序列;
c) 选定数据流测试策略;
d) 根据测试策略得到测试路径;
e) 根据路径可以获得测试输入数据和测试用例。
用例的构成要素为:测试用例编号、所属模块、用例类型、测试用例标题、关键词、优先级、前置条件、步骤、预期结果。
1、UI界面测试用例
2、搜索查询测试用例
3、上传图片测试用例
4、输入框相关测试用例