传统方式的问题在于：
1，对测试工程师要求比较高。大多数的测试工程师并不会编写测试脚本，从而导致自动化测试开展比较困难；
3，测试用例的覆盖率不足。由于编写测试用例的代价比较高，因此导致自动化测试的用例相对比较少，造成覆盖率不足。从实践的情况来看，往往只能够覆盖到主要的、正确的流程，对于比较少的分支，比较难以覆盖。
有没有其他的方法，来提升自动化测试的范围？
我们知道，自动化测试的优势在于：1）执行的代价小，执行速度快；2）适合海量执行用例，比较能够覆盖到各个分支。但是，由于测试用例设计的问题，以及执行方式的问题，从而导致自动化测试使用的效果不佳。
因此，我们是否可以参照appscan等测试用具的做法，来解决以上的问题？大概的想法是：
1，测试脚本仍然需要，因为没有测试脚本，就无法进行自动化执行；
2，参数化，以及在参数化之后，对各个输入字段的输入范围进行描述和约束；
3，允许用户定义各种规则，用来生成海量的测试用例；
4，海量执行。生成的测试用例，可能达到几万到几十万条。如果使用接口测试，可能需要执行几个小时，甚至十几个小时，执行所有的自动生成的测试用例；
5，能够自动判定是否执行失败。这就需要预先定义规则，对执行的结果，使用规则进行判定，来决定测试用例是否执行失败。
6，人工复核。人工来筛选和查看测试用例，看是否存在漏测、误报的情况。
我们希望通过这样的方法，来单个的执行，生成海量的自动化测试用例，并且同步进行执行。当执行完成，我们也可以从中筛选出有效的、典型的测试用例，加入到常用的测试用例库中，用来执行回归测试。
推荐阅读：
sales@spasvo.com
