近又编写了一个项目的测试用例，我编写用例习惯写的十分简单，给执行的人留下了很多思考的空间。举例说明如下：

　　前提条件：

　　输入店员编号和密码可以正确登录客户端，其中店员编号为数字，位数没有限制，密码必须为六位数字，输入店员编号和密码后需要联网，后台判断编号和密码正确后，能够正确登录！

　　我编写测试用例如下：

　　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 登录失败 联网失败

　　我在实际测试过程中，每条测试用例都有对应的测试数据，这样的优点：

　　* 测试用例逻辑清晰、数据与逻辑分离

　　* 测试步骤浅析，逻辑明了，新员工也容易使用

　　* 可以专心于测试用例覆盖（数据覆盖）的设计，

即测试数据设计

　　* 很容易转化为自动化测试脚本。

　　但是如果我编写测试用例的时候把这个数据也都对应上的话，个人觉得限制了测试执行人员自己的发挥空间，不利于养成自己思考的习惯，所以我写测试用例都比较简单，执行编写简单的测试用例，要求执行人员有比较丰富的经验，能够自己扩展测试用例！

　　可能每种写法都有优缺点吧，但是貌似我写的测试用例，总是被人批评写的太少，呵呵！