自动化用例设计原则

Posted 2021-03-04 123blog

　　用例设计部分，无论是手工测试还是自动化测试，都必须的环节，也是非常重要的环节。在做自动化测试的时候，用例需要考虑前置，步骤和比对。每一个部分都要有提供非常明确的测试数据，要考虑数据的重复使用是否会影响脚本的执行结果。

　　

手工测试用例是针对手工测试人员，自动化测试用例是针对自动化测试框架，前者是手工测试用例人员应用手工方式进行用例解析，后者是应用脚本技术进行用例解析，两者最大的各自特点在于，前者具有较好的异常处理能力，而且能够基于测试用例，制造各种不同的逻辑判断，而且人工测试步步跟踪，能够细致的定位问题。而后者是完全按照测试用例的方式测试，而且异常处理能力不强，往往一个自动化测试用例运行完毕后，报一堆错误，对于测试人员来定位错误是一个难点，这样往往发现的问题很少。

手工测试用例与自动化测试用例对比：

手工测试用例
? 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。
? 人工执行用例具有一定的步骤跳跃性。
? 人工测试步步跟踪，能够细致的定位问题。
? 主要用来发现功能缺陷

自动化测试用例
? 执行对象是脚本，任何一个判断都需要编码定义。
? 用例步骤之间关联性强。
? 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
? 目前自动化测试阶段定位在冒烟测试和回归测试。

通过对比我们可以看到，手工测试用例与自动化测试用例之间是存在差异的。所以，直接不能拿手工测试用例来直接转化成自动化测试脚本。

在此笔者需要强调：自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。目前自动化测试更多的时候是定位在冒烟测试和回归测试；冒烟测试执行的是主体功能点的用例。回归测试执行全部或部分的测试用例。

 

用例选型注意事项：

1、不是所有的手工用例都要转为自动化测试用例。

2、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。

3、选择的用例最好可以构建成场景。例如一个功能模块，分n 个用例，这n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。

4、选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。

5、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。

6、选取的用例可以是主体流程，这部分适用冒烟测试。

7、自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。

8、如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。

 

在编写自动化测试用例过程中应该遵守以下几点原则：

1.一个用例为一个完整的场景，从用户登录系统到最终退出关闭浏览器。

2.一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。

3.尽量少的编写逆向逻辑用例。一方面因为逆向逻辑的用例很多（例如，手机号输错就有几十种情况）；另一方面自动化脚本本身比较崔阿若，对于复杂的逆向逻辑用例实现麻烦且容易出错。

4.用例与用例之间避免产生依赖。

5.一条用例完成测试之后需要对测试场景进行还原，以免影响其他用例的执行。

 

参考文章：https://blog.csdn.net/loner_fang/article/details/80540651