最近又编写了一个项目的测试用例，我编写用例习惯写的十分简单，给执行的人留下了很多思考的空间。举例说明如下：
前提条件：
输入店员编号和密码可以正确登录客户端，其中店员编号为数字，位数没有限制，密码必须为六位数字，输入店员编号和密码后需要联网，后台判断编号和密码正确后，能够正确登录!
我编写测试用例如下：
1、输入正确的店员编号和密码，可以正确登录
2、 输入错误的店员编号或密码，不能登录，有正确的提示。
但是在实际测试过程中我会测试如下：
1、输入正确的店员编号和密码，可以正确登录!
2、输入正确的店员编号，输入密码少于六位，这时候不应该联网，应该在客户端做出提示!这样可以节省用户的流量费，因为目前国内的流量费用还是很高的!
3、输入正确的店员编号，输入密码多于六位，也应该客户端做出提示!
4、输入错误的店员编号，输入正确的密码，这时需要联网，然后后台给出判断，客户端显示错误提示!其中错误的店员编号分为两种情况，一个是不存在的店员编号，一个是存在的店员编号，但是店员不是属于这个商家的，我们的客户端支持不同的商家，客户端只支持本商家的店员登录，不是同一个商家的店员不能登录其他商家的终端!
5、在后台把这个店员停用，然后使用正确的店员编号和密码登录，联网后应该给出正确的提示!
6、输入店员编号和密码后，联网失败，需要给出提示：
备注：因为我们的客户端只能输入数字，所以不用验证输入字符，英文等情况!
测试数据如下：
序号店员编号密码目标结果提示信息
1222111111登录成功无提示，直接进入
222211111登录失败密码位对不对
32221111111登录失败密码位数不对
4111111111登录失败店员编号不对
5333111111登录失败不是这个商家的店员
6222111111登录失败店员已经被停用
7222111111登录失败联网失败
我在实际测试过程中，每条测试用例都有对应的测试数据，这样的优点：
* 测试用例逻辑清晰、数据与逻辑分离
* 测试步骤浅析，逻辑明了，新员工也容易使用
* 可以专心于测试用例覆盖(数据覆盖)的设计，即测试数据设计
* 很容易转化为自动化测试脚本。
但是如果我编写测试用例的时候把这个数据也都对应上的话，个人觉得限制了测试执行人员自己的发挥空间，不利于养成自己思考的习惯，所以我写测试用例都比较简单，执行编写简单的测试用例，要求执行人员有比较丰富的经验，能够自己扩展测试用例!
可能每种写法都有优缺点吧，但是貌似我写的测试用例，总是被人批评写的太少。
免责声明：
本站系本网编辑转载，会尽可能注明出处，但不排除无法注明来源的情况，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与本网联系， 来信: liujun@soft6.com 我们将在收到邮件后第一时间删除内容！
[声明]本站文章版权归原作者所有，内容为作者个人观点，不代表本网站的观点和对其真实性负责，本站拥有对此声明的最终解释权。
