最近又编写了一个项目的测试用例，我编写用例习惯写的十分简单，给执行的人留下了很多思考的空间。举例说明如下：
前提条件：
输入店员编号和密码可以正确登录客户端，其中店员编号为数字，位数没有限制，密码必须为六位数字，输入店员编号和密码后需要联网，后台判断编号和密码正确后，能够正确登录！
我编写测试用例如下：
1、输入正确的店员编号和密码，可以正确登录
2、 输入错误的店员编号或密码，不能登录，有正确的提示。
但是在实际测试过程中我会测试如下：
1、输入正确的店员编号和密码，可以正确登录！
2、输入正确的店员编号，输入密码少于六位，这时候不应该联网，应该在客户端做出提示！这样可以节省用户的流量费，因为目前国内的流量费用还是很高的！
3、输入正确的店员编号，输入密码多于六位，也应该客户端做出提示！
4、输入错误的店员编号，输入正确的密码，这时需要联网，然后后台给出判断，客户端显示错误提示！其中错误的店员编号分为两种情况，一个是不存在的店员编号，一个是存在的店员编号，但是店员不是属于这个商家的，我们的客户端支持不同的商家，客户端只支持本商家的店员登录，不是同一个商家的店员不能登录其他商家的终端！
5、在后台把这个店员停用，然后使用正确的店员编号和密码登录，联网后应该给出正确的提示！
6、输入店员编号和密码后，联网失败，需要给出提示：
备注：因为我们的客户端只能输入数字，所以不用验证输入字符，英文等情况！
测试数据如下：
| 序号 | 店员编号 | 密码 | 目标结果 | 提示信息 |
| 1 | 222 | 111111 | 登录成功 | 无提示，直接进入 |
| 2 | 222 | 11111 | 登录失败 | 密码位对不对 |
| 3 | 222 | 1111111 | 登录失败 | 密码位数不对 |
| 4 | 111 | 111111 | 登录失败 | 店员编号不对 |
| 5 | 333 | 111111 | 登录失败 | 不是这个商家的店员 |
| 6 | 222 | 111111 | 登录失败 | 店员已经被停用 |
| 7 | 222 | 111111 | 登录失败 | 联网失败 |
我在实际测试过程中，每条测试用例都有对应的测试数据，这样的优点：
* 测试用例逻辑清晰、数据与逻辑分离
* 测试步骤浅析，逻辑明了，新员工也容易使用
* 可以专心于测试用例覆盖（数据覆盖）的设计，即测试数据设计
* 很容易转化为自动化测试脚本。
但是如果我编写测试用例的时候把这个数据也都对应上的话，个人觉得限制了测试执行人员自己的发挥空间，不利于养成自己思考的习惯，所以我写测试用例都比较简单，执行编写简单的测试用例，要求执行人员有比较丰富的经验，能够自己扩展测试用例！
可能每种写法都有优缺点吧，但是貌似我写的测试用例，总是被人批评写的太少，呵呵！
版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。本文出自xingzunxi的51Testing软件测试博客：http://www.51testing.com/?27352
