大部分测试自动化项目失败的原因主要归咎于被测试应用程序的快速变化、不恰当的测试用例、不可靠的框架、脚本编程的问题。分析这些问题的根源，我们可以看到，自动化测试必须分阶段逐步开展，而不能局限在某个阶段完成自动化测试。因此，建议自动化测试从选择那些重要的、合适的测试用例开始，然后慢慢地扩展到其他方面。这样会带来较低的维护成本，但是实现更重要的业务价值。
那么如何选择合适的测试用例呢？
通常需要结合测试用例的复杂度的评估来考虑选择的测试用例以及个数。首先把测试用例按一定的原则分为简单、中等、复杂3大类。然后从这3大类的测试用例中按一定的比例来抽取需要实现自动化的用例。 WWW.SYUE.COM
测试用例的复杂度分组可以通过综合分析测试用例包含的测试步骤（操作步骤），以及测试用例所包含的检查点个数来判定，例如可参考下表来分类： SYUE.COM
表中规定： ["岁月联盟"]
1、如果测试用例中包含的测试步骤个数小于5，检查点个数也小于5，则判定为简单类型的测试用例，对于这类测试用例，可多选择一些用于实现自动化。
2、如果测试用例中包含的测试步骤在5到15个之间，检查点个数在5到10个之间，则判定为中等复杂类型的测试用例，对于这类测试用例，可略选择少一些用于实现自动化。 [来源"岁月联盟"]
3、如果测试用例中包含的测试步骤在15到25个之间，检查点个数在10到15个之间，则判定为复杂类型的测试用例，对于这类测试用例，可再略为选择少一些用于实现自动化。
至于选择的比例，则可参考一些项目的经验数值，或者根据项目实际情况自己调整。这种通过测试用例复杂度分组选择的方式来筛选出自动化测试用例比较简单易行，而又不失科学性。因为众所周知，自动化测试脚本的实现难度，在很大程度上取决于测试用例的复杂度，而测试用例的复杂度又在很大程度上取决于测试步骤和检查点的复杂度。
在自动化测试的测试用例范围内，找出每个测试用例的操作数量和验证点的数量，然后画出一个图表来找出平均值，并且定出控制点，这样可以基于被测试应用程序的实际情况而不是仅仅根据行业来判断复杂度。 [信息来自"岁月联盟"]
例如下表显示了25个测试用例中每个用例所包含的测试步骤： (Syue.com)
根据这个表，可以画出图1所示的复杂度与测试步骤个数的关系图： [Syue.com]
[内容来自"岁月联盟"]
图1 复杂度与测试步骤个数的关系图 "岁月联盟"
文章来源于领测软件测试网 https://www.ltesting.net/