1. Opentest的用途

Opentest是一个开放式的测试框架，目的是用于具备规范接口模块自动化回归测试（不太适用于网页展示上的测试）。测试框架遵从简单可依赖的原则，实现不同功能的子模块功能简单，扩展方便。框架使用依赖注入的方式，将实现不同功能的子模块组织起来，完成测试所需的工作。

opentest框架中，使用测试数据与逻辑相分离的方式进行组织。测试数据在不同的逻辑之间具有一定程度的通用性。

2. Opentest的使用

现阶段opentest部署了一个较简单的逻辑，用于支持支付组各server测试中的绝大多数用例，用例的逻辑比较简单，做下面几件事情：

对于测试来说，需要做的就是在配置中提供测试用例执行所需要的数据，不必在做其它的开发性工作。下面就以这个流程为例，说明一下做测试需要进行的工作。

2.1. 目录结构与建立个人配置

目录结构如上图所示。测试用例放置于cases目录中，其中sample文件夹下的是opentest测试用例的示例。在testmods目录中，部署各被测模块，以<程序名>.<版本号>形式部署。

用户配置位于confs文件夹中的用户目录(yanp)中，在这个目录中，存在一个framework_defaults.conf.php文件，这个文件是opentest框架中提供的各工具服务的配置信息，描述了mcpack接口的client与server，数据库与log的配置信息，作为用户自己的配置。在用户目录(yanp)中，还包含了被测模块的配置文件，opentest在执行用例时，将会以指定用户的配置文件启动被测模块。

即使是同一模块，不同用户的端口号与数据库配置也可以不同，例如用户可以配置opentest发送pack的client 向11003端口发送，同时使用固定的端口11003启动所有的server，可以免去每次回归测试环境配置的烦恼。

2.2. 编写并部署测试用例

在opentest中，测试用例只包含测试逻辑所需要的数据。测试用例以类的形式部署，支持继承。这样就可以在基类中部署初始化操作与通用的逻辑，避免在具体的用例数据中编写编写重复的内容。

用例文件sample_case_init.php

class sample_case_init{     static $TESTMOD_NAME = ‘fake_listener’;     static $TESTMOD_VER  = ’1.0.0.0′;     static $DB_INIT = array(         //写上数据库表中的具体内容，将会truncate对应的表         //如果不写上表中的具体内容，将会truncate所有的分表（根据数据将数据分到不同表中的情况）         ‘truncate’ => array(             ‘table’                 => ‘t_accounts’,             ‘F_user_id’             => ’100000′,             ‘F_sub_account_type’    => ’1′,             ‘F_currency’            => ’1′,         ),      );  }

用例文件sample_case1_case.php

require_once(dirname(__FILE__).’/sample_case_init.php’); class sample_case1_case extends sample_case_init{     static $CLIENT_PACK = array(         //发送到被测模块的pack         ‘send’  => array(             ‘cmd’       => ‘hello’,         ),          //期望从被测模块接收的pack         ‘recv’  => array(             ‘result’    => ’0′,         ),      );  //…还有另外一些内容，为节省空间，在此省略… }

sample_case1_case是opentest需要执行的测试用例，在类中使用静态数组的方式提供进行具体操作的数据。在sample_case类中的一部分数据，可以通过它的基类sample_case_init.php提供。opentest通过反射的方式解析各测试用例。如果测试用例中没有提供对应的数据，根据逻辑的定义，可能认为case失败或者跳过对应的流程。

Opentest支持提供文件名字或者目录的方式指定测试用例，提供目录后，将会执行目录中的所有用例（以_case.php结尾的文件被认为是需要执行的）。

执行用于演示的测试用例：

账户：testframe@jx-testing-eb18.jx.baidu.com

cd test_framework/framework/ ./bin/run_sample.sh

3. Opentest的模块结构与开发新功能

Opentest使用一种松散耦合的方式进行组织，case执行逻辑所使用的数据与工具都由组装模块进行依赖注入。比如checker就可以在使用时候注入松散检查或者严格检查不同类型的工作类。目前已经支持数据库操作与mcpack接口，如果需要不同的case执行逻辑，可以通过继承原有的类或者添加一个新的类。

目前opentest�
��模块结构如下图，各模块都比较简单，主要功能如下：

1. ctrl

a) 解析用户请求，将各功能组件进行组装

b) case执行逻辑，各种不同的case执行逻辑部署在这里，用于组装

c) caseloader，用于解析case配置文件，被组装模块调用，提供所需的数据

d) checker，用于检查测试结果数据域case中预定义的是否相符

2. client:各种发送请求的client，目前有mcpack的与http的

3. server:各种接收请求的server，目前只有mcpack的

4. dbop:用于操作数据库，case文件中指定表名即可，分库分表逻辑在dbop中内置

5. conf:管理用户的配置信息与被测模块的配置信息，附赠一个启动被测模块的能力

4. 附录：

得益于simpletest，目前支持html格式或者text格式的输出，其它功能正在扩展中，目前opentest支持的启动参数

Usage:

-c case_full_name like "/home/test/test.php" or "/home/test". if a dir is given, framework will try all the file in the dir as a case

-o html|text output result as html or text, default is text

-n conf name which you want to use

您可能会喜欢:

1. 分层次管理tag文件
2. svn安装备份完全解决方案
3. sql运行简单封装

理想自动化测试框架，应该满足下面的条件：

1.可文本描述：包括各子系统之间，子系统之中各模块之间的接口，以及个模块及子系统所需要的数据定义。

2.可检查：模块的产出能够进行精确检查，子系统内部各模块之间的通信（在一定程度上，属于产出的一部分）能够进行精确检查，模块产生的日志能够进行检查。

3.能够适应不同类型的被测模块：服务型，批处理型等

4.用户接口友好，测试可能涉及多种功能实体的配置，如一次测试可能需要模拟多个下游桩模块，配置数据等。所有的命令与数据都可以在同一个配置文档中进行配置说明

5.提供一定的附加能力用于模拟异常情况：如kill进程，切断数据库连接，构造磁盘不足等

按照目前的情况看来，1，2，3每一点都已经能够提供约50%的能力，4还需要等待1，2逐渐完善才能开始着手。5不是迫切需求。

永远不要一开始就尝试做一个大且完善的系统，着手在小的地方逐渐增强，有一天你会突然发现，原来各个部分组合协作起来，已经是一个不错的系统了

您可能会喜欢:

1. Opentest测试框架
2. 在搜索引擎上提交网站
3. wordpress插件之持久化链接