测试用例编写小结

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

　　前提条件：

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

　　我编写测试用例如下：

　　1、输入正确的店员编号和密码，可以正确登录

　　2、 输入错误的店员编号或密码，不能登录，有正确的提示。

　　但是在实际测试过程中我会测试如下：

　　1、输入正确的店员编号和密码，可以正确登录!

　　2、输入正确的店员编号，输入密码少于六位，这时候不应该联网，应该在客户端做出提示!这样可以节省用户的流量费，因为目前国内的流量费用还是很高的!

　　3、输入正确的店员编号，输入密码多于六位，也应该客户端做出提示!

　　4、输入错误的店员编号，输入正确的密码，这时需要联网，然后后台给出判断，客户端显示错误提示!其中错误的店员编号分为两种情况，一个是不存在的店员编号，一个是存在的店员编号，但是店员不是属于这个商家的，我们的客户端支持不同的商家，客户端只支持本商家的店员登录，不是同一个商家的店员不能登录其他商家的终端!

　　5、在后台把这个店员停用，然后使用正确的店员编号和密码登录，联网后应该给出正确的提示!

　　6、输入店员编号和密码后，联网失败，需要给出提示：

　　备注：因为我们的客户端只能输入数字，所以不用验证输入字符，英文等情况!

　　测试数据如下：

　　序号店员编号密码目标结果提示信息

　　1222111111登录成功无提示，直接进入

　　222211111登录失败密码位对不对

　　32221111111登录失败密码位数不对

　　4111111111登录失败店员编号不对

　　5333111111登录失败不是这个商家的店员

　　6222111111登录失败店员已经被停用

　　7222111111登录失败联网失败

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

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

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

　　* 可以专心于测试用例覆盖(数据覆盖)的设计，即测试数据设计

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

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

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