●在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性；

　　●尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持；

　　●应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。

　　过程

　　自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。

　　1）自动化测试需求分析。

　　当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

　　2）自动化测试框架的搭建。

　　所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。

　　而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：

　　（a）公用的对象。

　　不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。

　　（b）公用的环境。

　　各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。

　　（c）公用的方法。

　　当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。

　　（d）测试数据。

　　也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。

　　在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

　　探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但是却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。

　　对探索性测试最直白的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试（ad hoc testing）混淆。即兴测试通常是指临时准备的、即兴的Bug搜索测试过程。从定义可以看出，谁都可以做即兴测试。由Cem Kaner提出的探索性测试，相比即兴测试是一种精致的、有思想的过程。

　　在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。

　　探索性测试

　　探索性测试强调测试设计和测试执行的同时性，这是相对于传统软件测试过程中严格的“先设计，后执行”来说的。测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息通过综合的整理和分析，创造出更多的关于测试的主意。

　　探索性测试的基本过程

　　探索性测试识别软件系统的目的；

　　识别软件系统提供的功能；

　　识别软件系统潜在的不稳定的区域；

　　在探索软件系统的过程中记录关于软件的信息和问题；