自动化测试的另外一个想法

传统的自动化测试工具，都是先编写测试用例、编写测试脚本，然后做参数化、检查点，通过批量执行来发现问题。

传统方式的问题在于：

1，对测试工程师要求比较高。大多数的测试工程师并不会编写测试脚本，从而导致自动化测试开展比较困难；

2，测试的投入很大。我们需要搭建自动化测试平台，一次执行海量的自动化测试用例，才会比较有效果。但是这样做会导致投入很大。

3，测试用例的覆盖率不足。由于编写测试用例的代价比较高，因此导致自动化测试的用例相对比较少，造成覆盖率不足。从实践的情况来看，往往只能够覆盖到主要的、正确的流程，对于比较少的分支，比较难以覆盖。

有没有其他的方法，来提升自动化测试的范围？

我们知道，自动化测试的优势在于：1）执行的代价小，执行速度快；2）适合海量执行用例，比较能够覆盖到各个分支。但是，由于测试用例设计的问题，以及执行方式的问题，从而导致自动化测试使用的效果不佳。

因此，我们是否可以参照appscan等测试工具的做法，来解决以上的问题？大概的想法是：

1，测试脚本仍然需要，因为没有测试脚本，就无法进行自动化执行；

2，参数化，以及在参数化之后，对各个输入字段的输入范围进行描述和约束；

3，允许用户定义各种规则，用来生成海量的测试用例；

4，海量执行。生成的测试用例，可能达到几万到几十万条。如果使用接口测试，可能需要执行几个小时，甚至十几个小时，执行所有的自动生成的测试用例；

5，能够自动判定是否执行失败。这就需要预先定义规则，对执行的结果，使用规则进行判定，来决定测试用例是否执行失败。

6，人工复核。人工来筛选和查看测试用例，看是否存在漏测、误报的情况。

我们希望通过这样的方法，来单个的执行，生成海量的自动化测试用例，并且同步进行执行。当执行完成，我们也可以从中筛选出有效的、典型的测试用例，加入到常用的测试用例库中，用来执行回归测试。

推荐阅读：

自动化测试的基本流程

接口自动化用例设计的原则

目前主要的自动化测试框架有哪几种？

自动化测试真实项目工作流程，5个重要阶段和产出物

自动化测试基本流程七个步骤