社区编辑申请
注册/登录
必填项验证、枚举测试,这些测试点你都知道吗?
开发 测试
对于有经验的测试人来说,有一些测试点,是我们在以往的测试经验中总结出来的,而对于初学者往往会忽略一些没有在需求中列明的点。

​在测试的过程中,有些测试点是在需求说明文档里明确提到的,比如果输入框的输入要求是什么、是否必填等等。

对于有经验的测试人来说,有一些测试点,是我们在以往的测试经验中总结出来的,而对于初学者往往会忽略一些没有在需求中列明的点。

对于不同模块的测试,我们需要着重注意的点也不一样,下面我们来总结一下注意点或者易错点。

必填项验证

  • 必填项不填,如果是前台做的验证,保存时给出了提示信息,这个时候要F12看一下是否调用保存接口,或者去数据库查看一下数据有没有新增上,有可能是前台只给了提示,但还是给后台发送请求了。
  • 提示了必填之后,将必填项填上,提示信息有无消失。

新增编辑成功验证

  • 不能只看页面提示成功,新增的信息要显示在列表或者数据库能查到。
  • 编辑数据,带出的信息跟我们填写的一致。
  • 编辑修改数据,什么都不修改,信息能保存成功(有时候编辑时会当成新增处理,校验重复)。
  • 编辑信息,将非必填项都清空,可保存成功。
  • 编辑保存,是在原记录上修改,而不是新生成一条。
  • 编辑保存数据,修改的信息不影响其他记录的信息。

用户信息修改

  • 后台修改前台登录用户信息,修改完成后,前台使用修改的账号能正常登录系统(因为编辑前台账号,密码是非必填的,如果不填,就是使用原密码)。
  • 通过后台修改密码,前台能用新密码正常登录(涉及明文转密文)。

枚举测试

(1) 通过代码实现的逻辑,需要枚举测试。

例如:相同分类总价满多少,可以使用满减券,也可以使用折扣圈,也可以同时使用。

每个优惠券的使用条件也不同,有必须相同品类的订单才能使用的优惠券,有不同品类可以使用的优惠券等等逻辑,这种的逻辑是通过代码实现的,所以不同的组合我们都要枚举出来,一一验证。

先列举一下我们的输入条件:

  • 输入条件1:相同产品分类、不同产品分类;
  • 输入条件2:总价不满1000、满1000;
  • 输入条件3:维护了满减优惠、维护了打折优惠、同时维护了满减和打折优惠。

我们要把这三个条件的所有组合都列举出来:

  • 相同产品分类,总价不满1000,只维护了满减优惠,不使用优惠券;
  • 相同产品分类,总价满1000只维护了满减优惠,使用满减优惠。
  • 不同产品分类,总价不满1000,只维护了满减优惠,不使用优惠券;
  • 不同产品分类,总价满1000不满2000(其中相同分类的总价不满1000),只维护了满减优惠,不使用优惠券;
  • 不同产品分类,总价满1000不满2000(其中相同分类的总价满1000),只维护了满减优惠,使用满减优惠券。

这里我们只列举了只维护满减优惠的情况,其他两种情况(只维护折扣优惠,满减优惠和折扣优惠同时维护)在这里就不细说了。

这里要说的是,这种不同的组合关系,使用什么样的优惠券,是通过代码实现的,所以每种条件组合都要测试一遍,不能只测试一种。

(2) 通过后台配置的功能,不需要枚举。

还是接着上面的场景来说,满多少减多少,满多少打几折,都是通过后台配置的,我们可以设置满1000,也可以设置满500;可以设置减200,也可以设置减100;可以设置打7折,也可设置打6折。

这种都是后台功能进行配置的,只要确保每个类型(满减类型、折扣类型、组合类型)的一条数据与其他条件的组合能正常工作即可,并不需要每个类型进行枚举,也不可能进行枚举。

例如:后台设置满1000减20,我们只需确保总价满1000可以减20即可。并不需要再设置一个满2000,减50的券,试试好不好用。

以上是我在以往的工作中总结出来的一些易错点和容易迷惑的点,希望能对大家有所帮助。​

责任编辑:赵宁宁 来源: 今日头条

同话题下的热门内容

功能测试vs.非功能测试:能否非此即彼地进行选择?浅谈Python+requests+pytest接口自动化测试框架的搭建测试员进阶技能:如何有效地利用单元测试报告?测试自动化的六大原则高级测试:如何使用Flink对Strom任务的逻辑功能进行复现测试?

编辑推荐

黑盒、白盒与灰盒测试的区别保证DevOps与持续交付质量的九大测试工具九大高效的前端测试工具与框架Python测试工具 | 8 个很棒的pytest插件技术栈!10种主流移动端性能测试工具概况及横向对比分析!
我收藏的内容
点赞
收藏

51CTO技术栈公众号