|
我看了一些资料都说,测试用例的设计最好也要按照如:功能测试、用户界面测试、性能测试、安全性测试这样的分类分开去写。
我同意这种观点,但请大家来讨论讨论如下的登录用例的设计,到底是属于用户界面的测试呢,还是属于功能测试啊?
我的想法是下面这些测试用例的设计主要只从界面设计文档中得出“文本框”(用户名、密码)的一些要求,因此,这些用例是
属于用户界面的测试,而真正的登录功能的测试要另外再写测试用例:形如用户名和密码都正确时登录正确,用户名或密码错误时登录
失败(与数据库中的存储来比较的角度),登录正确和失败的各自的流程应该怎么样,还有比如连续登录3次错误会怎么样这样的测试,我认为是单独地归入功能测试?不知道我的理解对不对?大家是这样分开的吗,还是弄在一起,都归入功能测试呢?
例如:用户登录的UI详细设计说明书中是这样描述的:用户名的长度在4-20,密码的长度在6-16,并且用户名和密码的字符都必须是数字、
有效字符和下划线所组成字符,倘若不符合上述描述,系统将给出相应的错误提示信息。
第1步:提取测试需求
序号 测试需求
1 用户名的长度在4-20(假定为Ulength)
2 用户名必须是数字、有效字符和下划线所组成字符
3 密码的长度在6-16(假定为PLength)
4 密码必须是数字、有效字符和下划线所组成字符
第2步:划分等价类
测试对象 有效等价类 无效等价类
用户名 数字、有效字符、下划线(1) 空白(5)
空值(6)
零值(7)
默认值(8)
非法(9)
4<=Ulength<=20(2) Ulength<4(10)
Ulength>20(11)
密码 数字、有效字符、下划线(3) 空白(12)
空值(13)
零值(14)
默认值(15)
非法(16)
6<=密码<=16(4) Plength<6(17)
Plength>16(18)
第3步:确定覆盖等价类的测试用例
提示:测试用例只描述其思想,不包括具体数据。另外测试用例应该尽可能多的覆盖有效等价类,
而应为每个无效等价类设计单独的测试用例
序号 测试用例 覆盖等价类 预期结果
1 用户名由数字、有效字符和下划线所组成字符,并且长度在4-20之间 1,2 无错误提示信息
2 密码由数字、有效字符和下划线所组成字符,并且长度在6-16之间 3,4 无错误提示信息
3 。。。。。。。。。。 5-18无效等价类每个单独设计一个测试用例 5-18 系统给出相应的错误提示信息 |
|