PHP接口自动化测试框架实现

在上一份工作中，我有一部分工作是在维护一套接口自动化测试，这一篇文章，我来介绍这套接口自动化框架的设计思路。

我们来看一个简单的PHP实现的超简单的接口。

...

//报名验证
private function apply_verify() {
    $raid = $this->input->get_post('raid');
    $mid = $this->input->get_post('mid');

    if (!$raid || !$mid) {
        $this->ret_json(10021, '参数错误');
    }

    $this->load->model('enlist_model');
    $result = $this->enlist_model->get_enlist_by_raid_mid($raid, $mid, true);
    if (!empty($result)) {
        $this->ret_json(10101, '你已经报过名');
    }
}

说明：

• 首先，它是一个POST接口。它需要两个参数：raid 和 mid。
• 然后，判断raid 和 mid 是否为空，为空返回：参数错误。
• 最后，调用 enlist_model 模型，通过 get_enlist_by_raid_mid方法查询是否为空，如果不为空返回：你已经报过名了。

接下来要做的事情不是写用例，而是构造一条已经报名的数据。

创建 xx_enlist_test_data.php 文件

array(
    'table_name'=>'xx_enlist',
    'data'=>array(
        array('eid'=>1,'raid'=>99,'mid'=>150,'phone'=>'01234567890'),
    )
)

当自动化在执行之前，会先到数据库的 xx_enlist 表插入这条数据，为什么要初始化数据？当然是为了保证接口测试用例的稳定性。比如，我在调用接口时，传入 raid=99, mid=150。如果数据库是表空的？那么，用例肯定失败了！如何保证这条用每次运行 100% 成功呢？当然是每次执行之前再对应的表中初始化这么一条数据了！

定义的数据怎么插入到数据库中，当然是有一层解析的，将上面的数据库转成一条SQL语句执行。上面的数据当然比原生的一条插入SQL语句好写。

最后，才是开始写用例。创建interface_enlist_test.php测试文件。

class Interface_enlist_test extends InterfaceTestCase
{
    //初始化数据
    public function db_fixtures()
    {
        return array(
            array(
                'data_file' => 'xx_enlist_test_data.php',
                'truncate'  => true
            ),
        );
    }


    /*
    * 报名验证
    * raid不传
    */
    public function test_post_enlist_raid_null()
    {
        $result = $this -> request('enlist/apply_verify',array(),array('mid'=>150));
        $this->assertEquals($result['status'],'10021');
        $this->assertEquals($result['message'],"参数错误");
    }

    /*
    * 报名验证
    * mid不传
    */
    public function test_post_enlist_mid_null()
    {
        $result = $this -> request('enlist/apply_verify',array(),array('raid'=>99));
        $this->assertEquals($result['status'],'10021');
        $this->assertEquals($result['message'],"参数错误");
    }

    /*
    * 报名验证
    * 用户已报名
    */
    public function test_post_enlist_verify_success()
    {
        $result = $this -> request('enlist/apply_verify',array(),array('raid'=>99, 'mid'=>150));
        $this->assertEquals($result['status'],'10101');
        $this->assertEquals($result['message'],"你已经报过名");
    }
}

这里的用例我就做过多解释了。调用接口写断言。

答疑环节

我知道你们大概会有哪些疑问，接下来，我将试着解答这些疑问。

1、我怎么知道接口调用了哪些表？

首先你要懂PHP编程，然后熟悉Web开发框架，申请代码查看权限，阅读接口处理逻辑，自然就知道接口调用哪些表。

2、看不懂开发代码怎么办？

学呗！我当年也不是一下子就看懂PHP代码的，前后也学了两三个月。

3、往数据库里面插入测试数据，有重复的怎么办？

我们当时的设计是，框架在运行时会自动化的修改被测试的接口项目将数据库指到我本地，也就是说我本地有一个跟测试环境一模一样的数据库，每次在插入数据之前先清空表。
要保证本地数据库的表结构和测试环境是一样的。这其实也不难，开发如果改到表会上传SQL脚本，我只需要在本地数据库执行一下就行了。

4、这样做接口测试有什么好处？

• 首先，接口用例超级稳定，稳定是自动化测试的 大敌 ，做过自动化的同学知道我在说什么。在保证数据的基础上，如果用例失败了， 100% 是接口逻辑被改动到了。
• 不依赖接口文档，有几个公司的接口文档是非常详细，且及时维护的？我这种方式不需要接口文档。
• 不 盲测，盲测就是把接口的参数，每个类型试一遍，然后再排列组合，如果你不知道接口要调用哪个表的哪个字段来判断条件，那么这种盲测依然覆盖不到接口的所有处理逻辑。
• 当然更装X（玩笑~！），实际情况是你测试接口的水平即全面又深入，比只会用 postman 盲测的同学厉害多了。
• 反向促进接口代码质量，因为的接口用例编写是基于阅读接口代码的，有一个新来的PHP开发被我叫到面前几次，并直接指出对方的代码逻辑错误之后（分分钟教他怎么做开发，哈哈！），它的接口提测质量一下子提高了许多。

5、这样做接口测试的缺点是什么？

• 不适合所有团队，不是每个测试都懂开发代码的，比如，我们现在的接口用GO，如果我现在想达到无障碍阅读GO接口代码，也需要较高的学习成本。
• 不适合大型项目，我之前之所以可在这么玩，主要也是因为PHP项目不大，如果是一个大型项目的话就不适合了，在微服务的架构下，你甚至很难理清一个接口的调用关系。

不过，我仍然认为这是一个优秀的接口测试工程师应该努力的方法。接口测试平台解决的只是测试效率问题，如何把一个接口测好？当然是理解好需求，并有能力阅读接口处理逻辑，设计出有效和全面的接口用例。

其实，这篇文章所传达的思想，我在《Web接口开发与自动化测试--基于Python语言》一书都有介绍，只是换了个语言和框架而已。