一、模版
测试配置 | 测试数据 | 测试 结果 | ||||||
场景 | 测试用例名称 | 是否执行 | 执行次数 | 测试步骤 | 字段一 | 字段二 | 字段三 | |
|
| N/A |
| 1、… 2、… 3、… |
|
|
| Pass |
| N/A |
|
|
|
| Fail | ||
| N/A |
|
|
|
| N/A |
二、说明:
1、场景
场景用于描述此次所在的功能模块点,把一些测试操作相同的功能点抽象成一个场景,以便后面的脚本编写采用数据驱动的方式。
2、测试用例名称
测试用例名称用于描述在同样的场景下用例的测试重点。
3、是否执行
该项配置是为了适应在不同的测试执行阶段中脚本执行要求,也是测试脚本执行的开关。
4、执行次数
对于一些不稳定的脚本,需要设置多次运行才能获得最佳效果,那么就需要设置执行次数
5、测试步骤
测试步骤是为了方便执行测试用例者更好理解,一般叙述清楚即可。
6、测试数据
测试数据一般需要列举出场景中需要的各项参数,包括输入和输出2类。可以采用描述性的语言表达,如“***用户名”和“***密码登陆”,期望得到的结果值是“***”等。
7、测试结果
测试结果项用来表达测试的结果,主要用于记录各次执行的结果。
三、测试用例开发原则
1、场景选择方法
选择场景相同的一些测试需求来组成用例场景;
使用测试用例结构化指导测试脚本结构化;
2、场景包含用例的复杂度
场景包含的用例不能太多,超过15个时就要考虑对场景进行拆分;
3、其他
相互独立的测试用例,是测试用例之间在逻辑上没有线性关系,不能因一个测试用例错误导致连锁错误;
基于拥有前置数据的测试用例,每个用例需要有前置的数据,避免必须通过其他脚本的执行来生成,在数据上消除脚本依赖。
基于同一起点的测试用例,每个用例都要从一个已知条件出发,当程序执行时,已经生成了一个测试结果,这样已经对前置数据进行了修改,需要提供数据恢复机制,保证每次测试执行的出发点是相同的。
不要设计相同的测试用例,测试用例不是随意组合,需要采用等价类划分、边界值分析、决策逻辑等方法来开发,通过组合来达到使用最少用例覆盖最大测试面的目的。
四、测试内容分类
每个选举的重点模块可以作为各个测试对象,从测试角度又分为UI、功能、性能及产品的安装与卸载。
<1>UI测试分类
风格统一方面
确认正确性
易用性
数据完整性
通用性
特殊性
<2>功能测试分类
1、 是否符合客户需求
对产品完成的功能,测试是否符合需求文档的描述;
时刻保持对客户真正需求的敏感;
2、 正确性测试
输入用户实际数据以验证系统是否满足需求规格说明书的要求;
测试用例中的测试点要保证至少覆盖需求说明书中的各项功能,并且正确;
3、 容错性测试
系统应接收正确数据的输入并产生正确或预期的输出;
系统应对非法数据的输入应给出提示并做相应的处理;
4、 兼容性测试
系统能够在不同的软件、硬件、网络环境下运行且对特定客户的网络、业务不造成影响。
常规软件:不同版本的操作系统、常用工具、常用杀毒软件和防火墙;
常规硬件:主流计算机,网络及网络交换设备;
业务系统:常规的业务系统;
五、测试的方法
1、等价类划分
2、边界值
3、因果图
4、错误推测