共计 852 个字符，预计需要花费 3 分钟才能阅读完成。
传统的自动化测试工具，都是先编写测试用例、编写测试脚本，而后做参数化、检查点，通过批量执行来发现问题。
传统形式的问题在于：
1，对测试工程师要求比拟高。大多数的测试工程师并不会编写测试脚本，从而导致自动化测试发展比拟艰难；
2，测试的投入很大。咱们须要搭建自动化测试平台，一次执行海量的自动化测试用例，才会比拟有成果。然而这样做会导致投入很大。
3，测试用例的覆盖率有余。因为编写测试用例的代价比拟高，因而导致自动化测试的用例绝对比拟少，造成覆盖率有余。从实际的状况来看，往往只可能笼罩到次要的、正确的流程，对于比拟少的分支，比拟难以笼罩。
有没有其余的办法，来晋升自动化测试的范畴？
咱们晓得，自动化测试的劣势在于：1）执行的代价小，执行速度快；2）适宜海量执行用例，比拟可能笼罩到各个分支。然而，因为测试用例设计的问题，以及执行形式的问题，从而导致自动化测试应用的成果不佳。
因而，咱们是否能够参照 appscan 等测试工具的做法，来解决以上的问题？大略的想法是：
1，测试脚本依然须要，因为没有测试脚本，就无奈进行自动化执行；
2，参数化，以及在参数化之后，对各个输出字段的输出范畴进行形容和束缚；
3，容许用户定义各种规定，用来生成海量的测试用例；
4，海量执行。生成的测试用例，可能达到几万到几十万条。如果应用接口测试，可能须要执行几个小时，甚至十几个小时，执行所有的主动生成的测试用例；
5，可能主动断定是否执行失败。这就须要事后定义规定，对执行的后果，应用规定进行断定，来决定测试用例是否执行失败。
6，人工复核。人工来筛选和查看测试用例，看是否存在漏测、误报的状况。
咱们心愿通过这样的办法，来单个的执行，生成海量的自动化测试用例，并且同步进行执行。当执行实现，咱们也能够从中筛选出无效的、典型的测试用例，退出到罕用的测试用例库中，用来执行回归测试。
举荐浏览：
自动化测试的根本流程
接口自动化用例设计的准则
目前次要的自动化测试框架有哪几种？
自动化测试实在我的项目工作流程，5 个重要阶段和产出物
自动化测试根本流程七个步骤
