技术开发 频道

测试用例编写小结

  【IT168 技术文档】

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

  前提条件:

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

  我编写测试用例如下:

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

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

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

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

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

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

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

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

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

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

  测试数据如下:

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

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

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

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

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

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

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

0
相关文章