PHP服務介面測試

標籤：des   style   blog   color   java   使用   os   io   

最近百度Hi項目擬針對內部員工版本增加裝置綁定功能，也許是公司出於對員工聊天資訊安全性的考慮，同時也考慮到後期會有相應的員工名片等功能的推出，裝置綁定的過程也是為了員工名片功能做個準備吧！裝置綁定的服務是用php語言實現的，我的主要工作就是在現有的平台上搭建好這個新的服務，然後測試各個介面，保證功能的可用性和效能等。我比較擅長的語言是C++和Python，Java和php基本處於聽過、看過，沒有寫過的這種程度。我在搭建好測試環境之後，開始思考到底怎麼去完成這件事？對於這種web請求，或許Java是最好的選擇，C++太費事，Python也還是可以，但這個服務都是php提供的，用php去做這件事情也是個不錯的選擇。就是上個周末，周末閑來無聊，我就想公司最近內推的郵件中對php開發的需求蠻多的，我是不是該學學php呢，然後我就著手在linux下搭建了一個php開發環境，花了1天的時間看php cookbook的大概1/3左右。然後這周就遇到php的需求，所以當時就很愉快的做了一個決定，就用php了，正好驗收下我上周末的學習情況。phpunit是php語言中的單測架構，就用它了，bingo！

使用phpunit編寫測試案例要遵守如下規則：

1. 在測試案例中，可以擴充PHPUnit_Framework_TestCase類，單測中的setUP、tearDown等方法就是在這個類中定義的；
2. 測試案例的名字最好是使用約定俗成的格式，即在被測試類別的後面加上Test，比如要測試的類為DeviceBind,則測試案例的命名為DeviceBindTest。
3. 在一個測試案例中的所有的測試方法，在命名時都應該以test+測試方法名去命名，如test_devicebind(),要注意的是該方法必須是聲明為public類型的。當然可以在你的測試案例中包含private的方法，但它們不能被phpunit所調用。
4. 測試方法中是不能接收參數的。

開始動手吧，考慮到一些頻繁需求，比如在裝置綁定前登入Hi帳號，對get和post請求過程的封裝這

Data Providers

些過程。我首先自訂了一個測試類別，即對PHPUnit_Framework_TestCase類的擴充，我給它命名為HiTest。

class HiTest extends PHPUnit_Framework_TestCase

Hi在成功登入之後，會產生cookies檔案，我們的post方法定義如下：

public function Post_Data($url, $fields, $cookie_file)

這個類定義結束之後，裝置綁定的單測才剛剛開始。針對裝置綁定的幾個連接埠，分別實現一個測試類別去完成測試工作，我們一綁定介面為例：

class DeviceBindTest extends HiTest

針對綁定介面，我們設計了幾種測試案例，笨笨的辦法就是寫幾個測試方法一個一個的去做這件事情，可是那樣顯得多麼的不高大上啊！還好，有phpunit提供了高大上的方法，即Data Provides.

這是phpunit官方給出的使用協助：

A test method can accept arbitrary arguments. These arguments are to be provided by a data provider method (provider()). The data provider method to be used is specified using the @dataProvider annotation.

好了，開始動手吧，先定義資料提供函數：

public function provider_bind()

然後使用標記告訴測試案例使用我們定義的資料提供函數中的資料：

1 /** 2 * @dataProvider provider_bind 3 */ 4 public function test_devicebind($userName, $random, $device_id, $device_id_fixed, $device_name)

在測試方法中使用assertEquails等諸多斷言去完成我們的測試工作吧！

最後，單測怎麼跑起來？很簡單：

phpunit devicebind.php

好了，就這些了，算是工作的一個小記錄吧！這個是3周前的工作，花了半天的時間學了下php的單測架構，對裝置繫結項目介面做了測試。目前我主要的工作是使用gtest做協議的測試，當然對gtest的使用不是什麼痛點，主要的痛點在於協議的類比，目前使用的協議類比是從源碼拿協議的定義過來，然後封裝一些函數去完成協議中請求包的發送，A包的接收和N包的發送等系列工作。在以後的2周時間裡，我會主要關注ProtocolBuffer去做協議的一些最佳化，這個工作會合并到Hi項目中去，主要的原因為：目前Hi的訊息報文對流量的消耗較大！

Published with Windows Livewriter.