测试用例（四）

2018-08-20  14:04:12

二、为什么要写测试用例

1、 理清思路，避免遗漏

理清思路是我们认为最重要的一点，有的系统本来就是一个大而复杂的项目，我们需要把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。

2、 跟踪测试进度进展

通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度，方便跟踪我们的测试进度。

3、 回归测试

首先我们的系统不是测一遍就完了的，我们需要在开发环境上测试，测试环境上还要进行回归，其次还有可能涉及到合并测试，而且也有可能会有不同的人在不同的阶段进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。

4、 历史参考

在我们所做项目的各个版本中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。

另外如果产品发布后出现了发布缺陷，测试用例也是分析发布后缺陷的依据之一。

具体需求： 有一个登陆页面， （假如上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的TestCase.）

功能测试(Function test)

　　0. 什么都不输入，点击提交按钮，看提示信息。（非空检查）

　　1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。（正常输入）

　　2.输入错误的用户名或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）

　　3.登录成功后能否能否跳转到正确的页面（低）

　　4.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）

　　5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）

　　6.记住用户名的功能

　　7.登陆失败后，不能记录密码的功能

　　8.用户名和密码前后有空格的处理

　　9.密码是否加密显示（星号圆点等）

　　10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

　　11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确

　　12.输入密码的时候，大写键盘开启的时候要有提示信息。

 

界面测试(UI Test)

　　1.布局是否合理，2个testbox 和一个按钮是否对齐

　　2.testbox和按钮的长度，高度是否复合要求

　　3. 界面的设计风格是否与UI的设计风格统一

　　4. 界面中的文字简洁易懂，没有错别字。

 

性能测试(performance test)

　　1.打开登录页面，需要几秒

　　2.输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒

 

安全性测试(Security test)

　　1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)

　　2.用户名和密码是否通过加密的方式，发送给Web服务器

　　3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证

　　4.用户名和密码的输入框，应该屏蔽SQL注入攻击

　　5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）

　　6.错误登陆的次数限制（防止暴力破解）

　　7. 考虑是否支持多用户在同一机器上登录；

　　8. 考虑一用户在多台机器上登录

 

可用性测试(Usability Test)

　　1. 是否可以全用键盘操作，是否有快捷键

　　2. 输入用户名，密码后按回车，是否可以登陆

　　3. 输入框能否可以以Tab键切换

 

兼容性测试（Compatibility Test）

　　1.主流的浏览器下能否显示正常已经功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）

　　2.不同的平台是否能正常工作，比如Windows, Mac

　　3.移动设备上是否正常工作，比如Iphone, Andriod

　　4.不同的分辨率

 

本地化测试（Localization test）

　　1. 不同语言环境下，页面的显示是否正确。

　　软件辅助性测试 （Accessibility test）

　　软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能

　　2. 高对比度下能否显示正常 （视力不好的人使用）

 

 

 

默认值测试：
1、固定值还是数据库or配置项给定的值输入验证。
2、在输入框里填写了值，点界面刷新时，是显示输入值还是默认值。

单选按钮控件的测试：
a. 一组单选按钮不能同时选中，只能选中一个。
b. 逐一执行每个单选按钮的功能, 存入数据库是不是选项值。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
c. 一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；
d. 选项是否有排列顺序
e. 有默认选项还是没有。
f. 选项名和选项值是否符合要求
g. 刷新页面后，选中的值／默认的值是否掉了。

上传控件的测试
测试方法：
a、通过Browse按钮选择文件；
b、如果文件限制类型（exe,rar,doc,pdf,xls,jpg,gif,bmp,png 等）和大小（100k,512k,1M,1.5M,2M,2.5M），要逐一测试限制条件是否正确，并且给出了明确的提示；
c、检查实际上传后是否能够正确下载，如果是图片是否能够正确显示；
d、如果没有特殊要求，应该保持上传文件的名字是否和保存后的文件名字一致。

文本框为时间型 
合法性检查：
1、时输入[24时] －－程序应提示错误；
2、时输入[00时] －－OK；
3、分输入[60分] －－程序应提示错误；
4、分输入[59分] －－OK；
5、分输入[00分] －－OK；
6、秒输入[60秒] －－程序应提示错误；
7、秒输入[59秒] －－OK；
8、秒输入[00秒] －－OK；

测试计划

1）作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目

2）在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数

3）计划写完之后不是装在兜里，要组织PM和Dev进行评审

4）要不断更新计划，记住：每个计划都是动态的，不是一成不变的

验证码

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