注册、登陆、修改密码、添加、删除、查询的测试用例设计

客户要求用户名的长度是4-20个字符， 密码长度6-16个字符

一、注册

　　以等价类划分和边界值法来分析

　　1、用户名字和密码都为最大长度 （边界值分析，取上点）

　　2、用户名字和密码都为最小长度 （边界值分析，取上点）

　　3、用户名字和密码长度在最大和最小长度之间（边界值分析，取内点）

　 4、必填项分别为空注册

　　5、用户名最大长度+1（边界值分析，取离点）

　　6、用户名最小长度-1 （边界值分析，取离点）

　　7、密码最大长度+1（边界值分析，取离点）

　　8、密码最小长度-1（边界值 分析，取离点）

　　9、用户名含有非法字符注册（这个可以划分几个无效的等价类，如空格，#等，看需求是否允许）

　　10、密码含有非法字符注册（这个可以划分几个无效的等价类）

　　11、两次输入密码不一致（如果注册时候要输入两次密码，那么这个是必须的）

　　12、重新注册存在的用户

　　13、以已经注册的用户名（改变大小写）来注册。（有的需求是区分大小写，有的不区分）

　　14、看是否支持Tab和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示

15、邮箱地址格式不正确，正确格式 ---@---.com

16、验证码错误（大小写、空值、错误输入等）

二、登陆

1、 用户名和密码都正确

2、用户名和密码都错误

3、 用户名正确和密码错误

4、 用户名错误和密码正确

5、用户名或密码为空

6、删除的用户名和错误密码

7、删除的用户名和正确密码

8、未注册用户名和错误密码

　 9、用户名或密码中插入空格

10、使用Tab,Enter键是否能登陆

11、改变用户名或密码的大小写登陆

12、用户名和密码中含有全角字符登陆

13、Web系统是否有超时的限制

14、登陆错误次数是否限制

15、密码的安全性是否有强中弱鉴定

备注补充说明：

1.在登录WEB页面也可以进行压力性的测试，比如不停的点击登录按扭，或多个人同时登录（可用loadrunner进行压力模拟）
2．登录的安全性测试：
a) 是否可以不登陆而直接浏览某个页面等。
b) Web应用系统是否有超时的限制，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
c) 为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪，以防止被黑客截取。
d) 当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
e) 服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
f) 有的在线登录系统会有“找回密码”，这样我们在测试是就一定要注意找回密码的条件（找回密码条件安全级应等同于或高于密码安全级）和此时的网络安全性。
3． 登录在易用性上要求也是较高的，以次我们也可以参照用户的观点以及安全性上考虑给出一个标准：
a) 界面的美观程度
b) 按扭的设置和排列
c) 输入提示的人性化考虑
d) 错误提示的准确性
e) 验证码的清晰度和复杂程度
关于自动化测试工具在登录性能测试上的缺陷及解决办法
现在越来越多的网站为了安全性或是防止Spam的侵害，采用了验证码的校验技术。简单地说，验证码就是在进行登录或是内容提交的时候，页面上会随机出现一个人工可识别，但机器不可识别的验证字符串（一般是采用背景、扭曲等方式产生的图片），要求登录或是提交内容时同时输入这个验证码。
验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或是Intranet应用接受为标准的实现方式。但对性能测试来说，这种验证码又带来了很大的问题。
最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是“防止自动化工具尝试”的方法，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题：
1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输入的是什么验证码，都认为是正确的。这种方法最容易实现，对测试结果也不会有太大的影响（当然，这种方式去掉了“验证验证码”这个环节，不过这个环节本来就很难成为系统性能瓶颈）。但这种方法有一个致命的问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不合适了；
2、第二种方法，在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题，那么我们可以考虑，不取消验证，但在其中留一个后门，我们设定一个所谓的“万能验证码”，只要用户输入这个“万能验证码”，我们就验证通过，否则，还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题，但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在性能测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面已经有较大的改进了；
3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处理这个问题。一般的性能测试工具（loadrunner等）都能够调用外部的组件接口，因此，可以考虑获得“验证码验证”部分的实现，写一个验证码获取的代码，在测试脚本中进行调用即可。
一般，第二种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的是已上线系统，无论用哪种方法，测试完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样的接口，以及获取验证码开发的难度。

三、修改密码

　　1、不输入旧密码，直接改密码

　 2、输入错误旧密码

　　3、不输入确认新密码

　　4、不输入新密码

　　5、新密码和确认新密码不一致

　 6、新密码中有空格

　　7、新密码为空

　　8、新密码长度为最大长度

　 9、新密码为最大长度与最小长度之间

　　10、新密码长度为最小长度

　　11、新密码为最大长度+1

　　12、新密码为最大长度-1

　　13、新密码为最小长度+1

　　14、新密码为最小长度-1

　　15、新密码为非法字符（如有的密码要求必须是英文和数字组成，如中文汉字）

　　16、检查是否支持Tab和Enter键等；密码是否可以复制粘贴；密码是否以* 之类的加密符号

　　17、检查密码是否区分大小写，新密码中英文小写，确认密码中英文大写．

　　18、新密码与旧密码一样能否修改成功．

四、添加

　 1、要添加的数据项均合理，检查数据库中是否添加了相应的数据

　 2、留出一个必填数据为空

　　3、按照边界值等价类设计测试用例的原则设计其他输入项的测试用例

4、不符合要求的地方要有错误提示

　 5、是否支持table键

6、按enter是否能保存

7、若提示不能保存，也要察看数据库里是否多了一条数据

五、 删除

　1、删除一个数据库中存在的数据，然后查看数据库中是否删除

　 2、删除一个数据库中并不存在的数据，看否有错误提示，并且数据库中没有数据被删除

3、输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。

4、输入的正确数据前加空格，看是否能正确删除数据

5、什么也不输入

6、是否指出table键

7、是否支持enter键

六、查询

　 　精确查询：

　　1、输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据

2、输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据

　 3、输入格式或范围不符合要求的数据，看是否有错误提示

4、输入数据库中不存在的数据

　 5、不输入任何数据

6、是否支持table键

7、是否支持enter键

　　模糊查询：

　　在精确查询的基础上加上以下一点：

　　1、输入一些字符，看是否能查出数据库中所有的相关信息