b）选择合适的测试用例

　　大部分自动化测试项目失败的原因主要归咎于被测试应用程序的快速变化、不恰当的测试用例、不可靠的框架、脚本编程等问题。并非所有的测试用例都可以用自动化来完成，因此需要对用例进行挑选，选择合适的用例作为自动化测试用例。自动化测试的成本是巨大的，一般来说，一个脚本运行6—7次才算收回成本，因此不可寄予自动化测试过高期望。通常需要结合测试用例的复杂度的评估来考虑选择的测试用例以及个数。这样会带来较低的维护成本，实现更重要的业务价值。

　　首先把测试用例按一定的原则分为简单、中等、复杂3大类。然后从这3大类的测试用例中按一定的比例来抽取需要实现自动化的用例。测试用例的复杂度分组可以通过综合分析测试用例包含的操作步骤，以及测试用例所包含的检查点个数来判定。

　　c）基于Selenium的分层测试框架

　　在Selenium环境中组织多个测试模块的测试，每个模块实现特有的功能，有多条测试路径需要覆盖，同时，各个模块功能之间又有共通之处，可以抽取某些部分进行复用。对此，我们假设这样的场景：分别对提交的多个待测组件返回的结果页面中设置相应的检查点，为它们撰写Test Cases用于执行测试。事实上，这些组件的测试由于同质性，还能够合并为一种测试，用不同的输入参数来指定所要测试的那个待测组件。

　　表中针对上述各待测组件做自动化测试，以一个经验丰富的测试人员做3次回归做一个成本对比。

　　通过上面表格的对比，可以很明显看出很多模块功能都包含一些公共检查点，例如：文本框、DBGrid列表信息、showModalDialog自定义控件、修改信息保存成功、树形节点、各种级别菜单选择等等。把这些公共检查点封装在公共函数库中，任何新功能模块的验证都只需要调用公共函数、配置测试数据，组合调试好测试脚本就可以进行测试了，这样大大提高了测试效率和测试覆盖率。

　　d）集成运行框架

　　构造一个适当的集成环境，会极大地提高自动化的效率。例如，通过数据库服务器来存储和管理测试用例和测试结果，以提高过程管理的质量。同时生成统计所需要的数据，供Web服务器使用，显示测试结果、生成统计报表、结果曲线。运行一个自动化测试项目时，客户端先通过Web服务器查询所用的测试用例和资源；然后提交任务，Web服务器负责向控制机发出指令，开始执行测试任务。测试结果经控制器存储到数据库中测试自动化运行环境，如图1所示。

图1 测试自动化的集成运行框架

　　e）脚本维护

　　测试脚本的开发和维护直接关系到软件测试自动化的成败，至少对自动化测试的投入产出存在巨大的影响。同时对不同的测试库的权限应该有很明确的定义。一个好的方案会将测试库的组织划分为三个级别：

　　级别1：全局的，这个一个通常的级别，被存储在这个级别的测试功能能够被所有的项目访问。通用的功能如，登陆、创建一个用户都是这个级别很好的候选者。

　　级别2：项目的，在这个级别的测试功能是与特定的测试项目相关的，但是通常在项目中有用的。通用的功能如，项目中自定义控件等。通常级别2是级别1的功能的提供者。

　　级别3：脚本的，功能被直接关联到特定的测试脚本。在这个级别中，通常一个测试功能的第一个版本是被开发的。在新的测试脚本的创建期间已有测试功能的重用性被发现，并被移到了级别2中。在这个级别上尽量最小化功能的数量，因为它将增加维护工作量。

　　4、结语

　　从软件测试的优化来看，如何实现软件的自动化测试是一个很吸引人的技术问题，由于不同企业在组织架构、人员能力以及管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性，具体如何选择，需要仔细权衡。