自动化测试的前期准备工作[精选].doc

自动化测试前期准备工作 在项目启动阶段，我们就可以开始一些自动化测试准备工作了，主要包括一下几点： 编写自动化测试用例 封装第三方控件、自定义控件的测试方法 制定测试脚本规范 系统平台 测试范围 项目的开发语言 项目的需求 选择合适的项目实施自动化测试 在实施自动化的时候，往往会进入一个误区：进度紧、测试资源不够的情况下，可 以通过自动化测试来减轻测试人员手工测试的负担，以便更快的完成测试任务。 然而，自动化测试与开发一样，都需要投入足够的资源和时间进行自动化的计划、设计、脚本调试开发等。 因此，在使用自动化测试的项目选择上，需要选择一个进度不紧，测试人员相对充裕的测试项目来实施自动化测试。尤其是初次尝试自动化测试的项目组而言，自动化测试的成功率会有相应的提高。 自动化测试需要多次运行后，才会体现出自动化的优势。脚本需要不断更新，才能有效的预防问题的产生、减少测试人员手工回归测试的工作量。若是一个短期项目或为一次性的项目，不建议使用自动化测试。因为这种项目得不到自动化测试应有的效果和价值体现。（按阶段划分，按照项目类型划分等多方面） 在某个项目资源相对充裕的情况下，做自动化测试的同时，我们也应选择对的时间去实施自动化测试：如项目前期，需求变更较频繁亦或需求不是很稳定的时候就展开自动化测试，这么在维护的时候会浪费更多的时间，同时也无法体现出自动化测试的优势也得不到自动化测试应有的效果和价值体现。若我们把自动化测试放在项目的中后期来做的话，这个时候项目的需求变更不是很大，系统功能相对稳定，这个时间主要是针对项目初期发现的缺陷进行修正，测试人员的任务也相对轻松，这个时期我们有足够的时间和经历来实施自动化测试以及对脚本进行维护。 选择恰当的测试用例实现自动化 在实现自动化测试的前期有一点需要特别关注：选择恰当的用例来实现自动化测试。 大部分自动化项目的失败的原因主要归根于被测试应用程序的快速变化、选择不恰当的测试用例、不完善的测试框架以及脚本的编写问题等。 在做自动化测试时，需要分阶段逐步进行，不能局限在某一个阶段完成自动化测试，所以自动化测试应从选择重要的、恰当的测试用例开始，慢慢向其他方面扩展，这样会带来较低的维护成本，能实现更重要的业务价值。 那么，我们选择什么样的测试用例才能叫做恰当呢？ 通常需要结合手工测试用例复杂度的评估以及功能重要性来设计自动化测试用例以及确定测试用例的个数。首先，我们可以参考手工测试用例优先级的划分把自动化测试用例分为：简单、中等、复杂三大类。然后，从这三大类的测试用例中选取一定的比例来选取需要的自动化测试用例。 自动化测试用例的复杂度分组可通过综合分析测试用例包含的操作步骤，以及该测试用例包含的检查点个数来划分。分类方式可参考图2.1。 图2.1 测试用例复杂度分类 从表中可以看出： 若用例中包含的操作步骤少于5，检查点个数也少于5，则判定为简单测试用例，对于此类用例，脚本的录制及调试相对于比较简单，可适当的多选择一些实现自动化。（如登录、注册、菜单的点击等功能的测试） 若用例中包含的操作步骤在5~15间，检查点格式也5~15个，则判定为中等测试用例，对于此类用例，脚本的录制及调试过程稍复杂，可少选择一些实现自动化。（如提交数据，或者傻瓜式的Next操作等） 若用例中包含的操作步骤大于15，检查点的个数大于15，则判定为复杂测试用例。对于此类用例，脚本的录制级调试过程相对比较复杂，可更少的选择一些实现自动化。（在这里，自动化测试只要求做一下回归的功能，以便来确定系统流程是否可以顺利走通，主要的功能建议大家手工去测试，毕竟自动化测试不可完全替代手工测试） 对于用例个数选择，可根据一定的项目经验以及项目的实际情况进行一个调整。这种通过测试用例复杂度分组来筛选出自动化测试用例的方法比较简单易行，又不失科学性。自动化测试脚本的复杂度，在很大程度上取决于测试用例的复杂度，而测试用例的复杂度又在很大程度上取决于测试步骤和检查点的复杂度。 对控件的熟悉程度与自动化成功实施之间的关系 我们拿界面上面的GUI为例，基于GUI层面的测试需要与各种界面元素打交道。对于自动化测试工程师而言，如果能够充分了解不同控件的属性和方法的话，对用户自动化测试的脚本开发会有很大的帮助。如图3.1,这是一个JavaScript的Edit控件 图3.1, JavaScript的Edit控件 对于这个控件，使用普通的测试工具（QTP）录制将得到以下脚本： 我们分析一下录制下来的这个脚本可以发现，它是以控件的Text属性来对控件进行一个Click事件。当我们对控件的Text进行Edit后，界面的Text值就会发生变化，这样的话，QTP在回放的时候就会报错。提示找不到对象。这样的话，脚本的