是分布式测试框架还是统一的测试框架好？

　　这是自动化测试框架设计中面临了又一个测试抉择。

　　分布式的测试框架，有点像早期的软件开发，微软的方式，就是每个人一套软件。每个人一个测试框架。这个测试框架是由测试人员独享的。他在这个测试框架上执行测试用例，收获测试结果。

　　统一的测试框架，有点类似于当今Web2.0 的概念，是以提供服务，而不是软件为主的。整个公司的测试人员都同意到一个服务器上去提交测试任务，这个统一的测试框架会有自己的任务调度功能，优先级处理功能等来统一执行提交的测试任务，并把测试结果返回给提交相应测试任务的测试人员。 通常，是有一个Web界面的人机接口。

　　那么，是一人一套框架好呢？还是大家共用一个框架好呢？在设计原则上，并没有优劣之分。虽然有人说，Web2.0的方式是大势所趋，云计算已经成为了趋势。一个统一的基于客户端服务器架构的自动化测试框架会便于管理，便于跟踪，但是，统一的框架需要复杂的进度调度和测试环境的协调(共用使用物理测试环境所造成的冲突)。 相对来说，一个人一套自动化测试框架的设计方法直接，实现简单，部署容易，管理花费少。可以让大家很快的用起来，能够早的看到测试结果。而对自动化测试框架来说，越快看到结果（测试结果）越能得到管理层的支持和投资。

　　所以，在项目初期的时候，建议可以使用一个测试工程师一套框架的方法，在大家等候使用起来以后，在把这套框架移植到统一的服务器上去。做一个渐进式的，逐步演化的测试框架，而不是在项目一开始就设计一个一个高，大，全的自动化测试框架，让大家等的望眼欲穿。

　　自动化测试框架中ＡＰＩ设计原则有哪些？

　　API的封装的好坏涉及到脚本的开发效率和可维护性。有经验显示，相对于设计水平一般的API，一套好的自动化测试API可以提高自动化脚本的开发效率2-3倍，一般来讲，需要进行三层封装：

　　总的来说，自动化框架中设计的好的API有两个原则要把握：

　　隐藏测试设备的复杂性，针对测试逻辑提供统一的接口。 熟悉软件测试的工程师都知道，测试当中，是需要使用很多辅助测试设备的，这些设备，有可能是PC上的运行的测试软件，有可能是专用的测试设备。而很多时候，不同的测试设备往往都是做同样的测试活动。如简单的Web页面自动化就可以使用QTP，Winrunner，Selenium等。封装的好的API，应该能够隐藏底层使用的测试工具。而对测试人员提供统一的编程接口。测试人员只需要下达操作动作，而具体这个动作使用了那些测试工具来实现，是API内部的事情，不需要测试人员分心。

　　关键字驱动：关键字驱动的意思是API的封装的程度要和测试用例描述的程度相同。如测试用例中描述：“注册是一个新用户，并验证生效”，那么相应的ＡＰＩ的设计的关键字就需要有“Register $user_name”这个关键字，并能够根据返回值来验证动作是否成功。测试人员不需要去担心在那个页面，如何输入等具体的细节。

　　本文属测试家园和成都杰华科技共有,若需转载请注明出处或直接复制本行内容。