自 Zend Framework 1.6 之後就提供了 Zend_Test 這個套件，協助我們為 Zend Framework 的 MVC 做單元測試。然而當時也許是因為大家對 Zend Framework 的新架構還不熟悉，加上 Zend_Test 套件有許多小地方還不是很完善，因此就很少有人利用它來做測試。

而到了 Zend Framework 1.8 版之後， Zend_Test 便修正了許多缺點；而且也因為 Zend_Application 套件的引入，讓 Zend_Test 在 Controller 上的測試更加方便，也使得網路上許多高手開始為它編寫教學。

不過官方的文件並沒有特別告訴我們怎麼去建構 Zend Framework Testing 的環境，所以以下我以 Zend Framework 1.10 再加上 PHPUnit 3.4 為例，帶領大家進入 Zend Framework Testing 的世界。

準備 Zend Framework 專案

要進行測試前，我們得先要有個 Zend Framework 專案。假設這個專案名稱叫 unittest ，原始檔位於 D:\WEB\zf\unittest 上，我們用 Zend Framework 提供的 Zend_Tool工具來建立它：

zf create project unittest

然後我們切換到該專案目錄下：

cd unittest

註：雖然我是以 Win32 為主要環境，但 Linux 上的操作步驟也是雷同。

由於我個人偏好搬動整個目錄就可以移植專案的模式，因此我就不採用 Zend Framework 原本將 index.php 放在 public 目錄下的架構；以下動作的目的就是把 index.php 從 public 目錄移出來。

首先先把 D:\WEB\zf\unittest\public\index.php 和 D:\WEB\zf\unittest\public\.htaccess 複製到 D:\WEB\zf\unittest 下，然後修改 D:\WEB\zf\unittest\.zfproject.xml ，把上方紅框處的 index.php 和 .htaccess 的 XML tag 複製一份到下方的紅框處：

接下來要修改 D:\WEB\zf\unittest\index.php 中 application 目錄的相對位置；找到：

|| define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));

改為：

|| define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/application'));

然後我們要在 D:\WEB\zf\unittest\.htaccess 加入當前環境的常數，也就是在它的最上面一行加入：

SetEnv APPLICATION_ENV development

原來的 D:\WEB\zf\unittest\public\index.php 則用來阻擋使用者瀏覽 public 目錄，所以我們把它改成：

<?php
header('HTTP/1.1 403 Forbidden');

而原來的 D:\WEB\zf\unittest\public\.htaccess 則是將 Rewrite Engine 關閉，讓外界可以直接存取：

RewriteEngine Off

這樣就準備好我們的專案了。

在 NetBeans 中加入專案

NetBeans 近來對 PHP 的支援變得非常強大，讓我一用就愛上它。到 6.8 版為止， NetBeans 還沒有正式支援 Zend Framework ，不過這並不影響我們用它來開發以 Zend Framework 為架構的專案。

而這裡會提到 NetBeans ，主要是因為它支援了 PHPUnit ！而且還有圖形化介面；這使得我們在對 PHP 專案進行單元測試時更加便利！

回到剛剛我們建立的 Zend Framework 專案，我們可以在 NetBeans 裡加入一個現成的 PHP 專案。在工具列中，選擇 File > New Project... 後，會出現以下視窗：

然後要選擇現存專案的位置：

最後設定專案執行時的設置：

這樣一來我們就可以在 NetBeans 裡開發 Zend Framework 的專案了。

Zend_Test 基礎

Zend_Test 主要是基於 PHPUnit 這個 PHP 界公認最完善的自動化測試套件所開發的，所以不論是在設置環境或是在撰寫測試上，其實都是以 PHPUnit 的架構去完成。

為了避免本文內容過於冗長，這裡我已經先行設定好 PHPUnit 的執行環境；因此在繼續以下的步驟前，請大家先確認自己是否可以正確執行 PHPUnit 。

在 Zend Framework 為我們們準備好的專案目錄架構中，已經事先建立了 tests 這個供我們放置測試的目錄，所以現在我們可以先試試看用 PHPUnit 來執行我們的測試。假設我們目前的工作路徑是 D:\WEB\zf\unittest\ ，我們要先切換到 tests 目錄下：

cd tests

然後用 PHPUnit 提供的 Command Line Interface (CLI) 工具 phpunit 來執行測試：

phpunit .

我們會發現執行的結果出現了以下錯誤：

PHPUnit_Framework_Exception: Could not load "D:\WEB\zf\unittest\tests\phpunit.xml".

原來， phpunit 這個工具在我們對一個目錄進行測試時，會自動去剖析該目錄下的 phpunit.xml 內容；而 phpunit.xml 在 Zend_Tool 產生之後，並沒有任何內容，所以就使得 PHPUnit 丟出了一個異常。

所以這裡我們先簡單將它變成一個正確的 XML 檔案，在 D:\WEB\zf\unittest\tests\phpunit.xml 中我們加入：

<phpunit></phpunit>

然後在 Command Line 環境下再跑一次測試，結果如下：

這表示 PHPUnit 認得我們的測試環境啦！

建立測試

其實上面也只是讓 phpunit 能在我們的專案上啟用而已，但我們的測試主角根本還沒出現，所以接下來我們要開始來建立測試了。

Zend_Tool 建立出來的專案架構，其實有個預設的前置名稱，叫做 Application ；這個 Application 之後都做為專案中 Model 的前置名稱。一般來說，我都會將它改為像是 MyApp 或是 Shop 等等諸如此類符合目前專案性質的名稱。 Zend_Tool 也提供我們修改這個前置名稱的機制：

zf change application.class-name-prefix MyApp

執行結果如下：

Note: the name provided "MyApp" was altered to "MyApp_" for correctness.
Note: All existing models will need to be altered to this new namespace by hand
application.ini updated with new appnamespace MyApp_
Updating project profile 'D:\WEB\zf\unittest/.zfproject.xml'

要注意的是，如果在修改前就已經存在的 Model ，它們的前置名稱就要手動改成新的。

建立第一個 Model

接著我們建立第一個 Model Class ：

zf create model MyClass1

執行結果如下：

Creating a model at D:\WEB\zf\unittest/application/models/MyClass1.php
Updating project profile 'D:\WEB\zf\unittest/.zfproject.xml'

在 D:\WEB\zf\unittest/application/models/MyClass1.php 中就是 MyClass1 的內容：

<?php
 
class MyApp_Model_MyClass1
{
 
 
}

當然這個檔案目前只有簡單的類別定義而已，其他就是要靠我們自己手動完成。不過由於我們的重點是測試，所以這裡我們就不管 MyClass1 的內容。

用 NetBeans 產生 Test Case

前面提到 NetBeans 支援 PHPUnit ，因此這裡我們就直接試著用它來幫我們產生測試檔案。切換到專案目錄的「 Source Files/application/models 」下，在 MyClass1.php 上按下右鍵選擇「工具 / Create PHPUnit tests 」，我們就可以建立針對 MyClass1 類別的 Test Case ：

但因為 NetBeans 還不知道測試目錄的所在位置，因此它會提示我們輸入測試目錄；在這裡，我們當然就是選擇 D:\WEB\zf\unittest\tests ：

在按下確定之後， NetBeans 就會自動打開產生好的 Test Case 檔案。在本例中，它的位置就是在 D:\WEB\zf\unittest\tests\application\models\MyApp_Model_MyClass1Test.php 。

另外 NetBeans 也會把 tests 從原來的 Source Files 中獨立成 Test Files 目錄結構，但別忘了它實際的位置還是在 D:\WEB\zf\unittest\ 下。

目錄結構對應

繼續下個步驟之前，我們先來整個專案的目錄結構：

unittest
 |--application
 |   |--models
 |       |--MyClass1.php
 |--library
 |--docs
 |--public
 |--tests
 |   |--application
 |       |--models
 |           |--MyApp_Model_MyClass1Test.php
 |   |--library
 |   |--phpunit.xml
 |--.zfproject.xml
 |--.htaccess
 |--index.php

從上面的架構圖可以看到，在這個 tests 目錄下的 application 及 library ，就是對應著我們的專案目錄下的 application 及 library 。換句話說，我們在專案目錄下的 application/models 所建立的 Model Class ，它們的測試程式就可以放在 tests/application/models 下，其他以此類推。

執行測試類別

在我們建立好 MyApp_Model_MyClass1Test 這個測試類別後，就可以在上面撰寫測試案例了。這裡我們先簡單加入一個空的測試案例，即 testMethod1 方法：

// ... 略 ...
class MyApp_Model_MyClass1Test extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function testMethod1()
    {
 
    }
}

接著就可以執行測試了。

這裡雖然我們可以用 phpunit 來執行測試，不過 NetBeans 也可以幫我們代勞。我們可以在 NetBeans 的 Project 視窗中，對 unittest 專案名稱按下滑鼠右鍵，執行 Test 指令 (或直接按下 Alt + F6 ) ，這樣就會開始執行測試了。

完成測試後，就會出現下圖中的 Test Results 視窗。

這看起來是不是比先前的 Command Line 輸出結果好多了呢？

測試環境的自動載入

在測試時，其實我希望要測試用的類別能被自動載入，而不需要加入一堆的 require_once 。以往我在舊專案的做法是在每個測試案例之前，引用一個 bootstrap.php 檔，內容如下：

<?php
define('APP_PATH', realpath(dirname(__FILE__) . '/../app/'));
 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APP_PATH . '/lib'),
    realpath(APP_PATH . '/base'),
    realpath(APP_PATH . '/mod/common/models'),
    get_include_path(),
)));
 
function autoload($className)
{
    $className = str_replace('_', '/', $className);
    require_once "$className.php";
}
 
spl_autoload_register('autoload');

而在新架構中， Zend_Tool 很貼心地為我們產生好了這個檔案，也就是 D:\WEB\zf\unittest\tests\application\bootstrap.php 。

註：不過 D:\WEB\zf\unittest\tests\application\bootstrap.php 裡面的內容是空的，我們得自己把它加入。

但是每次都要在測試類別檔載入這個 bootstraop.php 也是相當麻煩，還好 PHPUnit 讓我們可以在 phpunit.xml 中去加入對 bootstraop.php 的自動引用。接下來請將 D:\WEB\zf\unittest\tests\phpunit.xml 的內容改為：

<phpunit bootstrap="./application/bootstrap.php" />

這麼一來，當我們執行 phpunit 時，就會自動引入 bootstraop.php 了。而這裡要注意的是， ./application/bootstrap.php 這個路徑是相對於 phpunit.xml 的，其他非絕對路徑的設定也是。

不過上面的 bootstraop.php 寫法在新的 Zend Framework 架構中就不適用了，因為它的自動載入只能應付類別名稱為 Xxx_Yyy_Zzz 並對應到檔名為 Xxx/Yyy/Zzz.php 的模式；而新架構中的 Model 則是位於 application/models 之下，也就是說我們的 MyApp_Model_MyClass1 這個類別的實際位置是 D:\WEB\zf\unittest\application\models\MyApp_Model_MyClass1.php ，因此我們得想辦法讓 bootstrap.php 能自動載入新架構的 Model Class 。

還好 Zend_Loader 提供了 Zend_Loader_Autoloader_Resource 這個套件，來幫我們載入 Zend Framework MVC 架構下的 Model Class 。所以我們的 bootstrap.php 就可以改成：

<?php
error_reporting(E_ALL | E_STRICT);
 
date_default_timezone_set('Asia/Taipei');
 
define('APPLICATION_ENV', 'testing');
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../../application'));
define('APPLICATION_CONFIG', APPLICATION_PATH . '/configs/application.ini');
 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    realpath(APPLICATION_PATH . '/../tests'),
    get_include_path(),
)));
 
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();
$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
    'basePath'      => APPLICATION_PATH,
    'namespace'     => 'MyApp',
    'resourceTypes' => array(
        'model' => array(
            'path' => 'models/',
            'namespace' => 'Model',
        ),
    ),
));
$autoloader->pushAutoloader($resourceLoader);

註： Zend_Loader_Autoloader_Resource 的詳細用法請參考官方手冊 Resource Autoloaders 一節的說明。

現在我們可以試著把 MyApp_Model_MyClass1Test.php 中的 require_once 敘述移除，試試看 phpunit 會不會自動載入。

不過特別要注意的是， bootstrap.php 只會在 phpunit.xml 被載入時自動被引用，因此我們就一定要透過 phpunit . 這樣的方式來執行測試，不然就會發生找不到 Model Class 檔案的狀況。如果我們只想單獨執行某個測試類別時 (例如 MyApp_Model_MyClass1Test ) ，就必須改用以下的方式執行： (假設當前工作目錄是在 D:\WEB\zf\unittest\tests )

phpunit application\models\MyApp_Model_MyClass1Test.php --configuration ./phpunit.xml

而在 NetBeans 中，我們可以在 Project 視窗的 Test Files 上按下滑鼠右鍵選擇 Properties ，就會出現以下視窗：

然後我們再指定 phpunit.xml 的位置，這樣就算只對單一的 Model 進行測試， NetBeans 也會自動幫我們載入 phpunit.xml 了。

加入更多測試

一個專案裡要測試的 Model 當然不可能只有一個，接著我們再加入新的 Model 。在 D:\WEB\zf\unittest 之下，我們執行：

zf create model MyClass2

然後再透過 NetBeans 的 Create PHPUnit tests ，幫它建立一個測試類別 MyApp_Model_MyClass2Test 。當然也別忘了幫這個測試類別加入測試案例，以免執行測試時會出現沒有測試案例的警告。

不是只有 Model 可以被測試，在 Zend_Test 裡也提供了測試 Controller 的方法；方法很簡單，以預設的 IndexController 為例，我們一樣也是在 NetBeans 的 Project 視窗中，對 unittest/application/controllers/IndexController.php 執行 Create PHPUnit tests 就可以了。

但是這樣卻有可能出現以下的錯誤訊息，而無法成功建立 IndexController 的測試類別。

而查看輸出視窗 (Ctrl + 4) ，實際的錯誤訊息是：

Fatal error: Class 'Zend_Controller_Action' not found in D:\WEB\zf\unittest\application\controllers\IndexController.php on line 3

這是因為 NetBeans 其實是透過 phpunit --skeleton-test 這個指令來幫助我們建立測試類別，而 --skeleton-test 會利用 PHP 5 的 Reflection 機制幫我們找出類別裡的方法；但 Reflection 也會需要相關引用到的類別的定義 (這裡就是 Zend_Controller_Action ) ，因此在沒有事先定義好的狀況下， phpunit 就會回報錯誤了。

解決的方法很簡單，我們只要在 IndexController 類別的上方加入：

require_once 'Zend/Controller/Action.php';

就可以再執行 Create PHPUnit tests 指令了。

完成後， NetBeans 就會產生 D:\WEB\zf\unittest\tests\application\controllers\IndexControllerTest.php 這個檔案了。

測試 Controller

雖然前面我們產生了 IndexControllerTest 這個測試類別，但是它卻不能用來測試 IndexController 的流程。這是因為我們沒有去啟動 Zend_Application 及相關的 Resource ，所以這裡我們要借重 Zend_Test 提供的 Zend_Test_PHPUnit_ControllerTestCase 類別來幫我們進行測試。請將 D:\WEB\zf\unittest\tests\application\controllers\IndexControllerTest.php 的內容改為：

<?php
class IndexControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    protected function setUp()
    {
        $this->bootstrap = array($this, 'appBootstrap');
        parent::setUp();
    }
 
	public function appBootstrap()
	{
	  	$this->application = new Zend_Application(APPLICATION_ENV, APPLICATION_CONFIG);
	  	$this->application->bootstrap();
	}
 
    public function testHome()
    {
        $this->dispatch('/');
        $this->assertAction("index");
        $this->assertController("index");
        $this->assertResponseCode(200);
    }
}

在這裡我們要借重 Zend_Test_PHPUnit_ControllerTestCase 提供的 bootstrap 機制，幫我們處理有關應用程式設定與 Front Controller 等相關資源的啟動；然後我們就可以簡單地透過 Zend_Test_PHPUnit_ControllerTestCase 提供的方法 (例如 dispatch ) ，來幫我們測試 Controller 的流程。

上面的例子裡我們只很簡單地測試首頁，至於更進階的 Controller 測試，有機會我會再分享給大家。

進階的 phpunit.xml 設定

在 phpunit.xml 中可以設定的項目很多，可以參考官方手冊的說明，這邊我們簡單地探討幾個常用的項目。

testsuite

testsuite 標籤主要是幫我們透過 PHPUnit_Framework_TestSuite 去組織多個測試類別，例如以下範例：

<phpunit bootstrap="./application/bootstrap.php">
    <testsuite name="My App">
        <directory>./</directory>
    </testsuite>
</phpunit>

首先 testsuite 的 name 屬性是讓我們設定 Suite 的名稱，而 directory 標籤則是告訴 phpunit ，這個 Suite 包含了 D:\WEB\zf\unittest\tests 下所有檔名結尾為 Test.php 的測試檔案。

另外還要注意一點，在還沒加入 testsuite 之前，我們要在 D:\WEB\zf\unittest\tests 用 "phpunit ." 來指定目錄執行測試；而加入 testsuite 標籤後，我們就可以直接在 D:\WEB\zf\unittest\tests 執行 phpunit ，而不用再指定測試的路徑了。

filter

filter 標籤主要是幫我們過濾程式碼涵蓋範圍報告的項目，避免出現過多不相干類別的報告內容。 filter 分為白名單與黑名單兩種，以下我們以白名單為主：

<phpunit bootstrap="./application/bootstrap.php">
    <!-- 略 -->
    <filter>
        <whitelist>
            <directory suffix=".php">../application/</directory>
            <exclude>
            	<file>../application/Bootstrap.php</file>
            	<file>../application/controllers/ErrorController.php</file>
               <directory suffix=".phtml">../application/</directory>
            </exclude>
        </whitelist>
    </filter>
</phpunit>

這裡主要是告訴 phpunit 只處理 D:\WEB\zf\unittest\application 下的類別 (注意！不是 tests\application ！) ，但排除掉 D:\WEB\zf\unittest\application\Bootstrap.php 、 D:\WEB\zf\unittest\application\controllers\ErrorController.php 以及 D:\WEB\zf\unittest\application\ 下所有的 .phtml 樣板檔。

不過 filter 通常會搭配稍後要說明的 logging 標籤一起使用。

logging

logging 標籤主要用來產生測試報告，它支援相當多的格式，以下我們以 HTML 格式為主：

<phpunit bootstrap="./application/bootstrap.php">
    <!-- 略 -->
    <logging>
        <log type="coverage-html" target="./log/report" charset="UTF-8"
            yui="true" highlight="true" lowUpperBound="50" highLowerBound="80"/>
        <log type="testdox-html" target="./log/testdox.html" />
    </logging>
</phpunit>

在執行測試前，別忘了在 D:\WEB\zf\unittest\tests 下建立一個 log 目錄，避免 phpunit 回報錯誤。執行完測試後，就會在 D:\WEB\zf\unittest\tests\log 產生一個 testdox.html 檔案及一個 report 資料夾。

textdox.html 會以我們在測試類別裡寫的測試案例為名稱來做為驗證項目名稱，例如 testDoSomething 就會變成 Do something 。而用瀏覽器開啟 report/index.html 後，我們就能看到完整的程式碼覆蓋率報告。

小結

最後我們再整理一下重點：

• 我們可以在專案中建立一個 tests 目錄，供我們放置測試類別。

• PHPUnit 可以透過 phpunit.xml 及 bootstrap.php 來做自動化的測試環境。

• phpunit.xml 主要是用來設定 phpunit 執行時的選項。

• bootstrap.php 主要的工作是設定測試時會用到的環境常數、引入路徑以及類別自動載入機制等。

• NetBeans 對 PHPUnit 有強大的支援，不論在建立測試及執行測試上，都非常直覺。

• 即便不使用 NetBeans ，我們還是可以透過 phpunit 這個 CLI 工具來完成自動化測試。

雖然這裡我是以 Zend Framework 專案為主，但大家還是可以仿照這樣的機制，在自己的專案裡去建構自動化測試。

還猶豫什麼？快去試試吧！

為什麼要測試？

因為我們沒辦法保證程式碼是萬無一失的，所以通常我們都會需要驗證我們的程式，而測試就是其中一種方法。很多工程師都在寫完程式之後，自己手動去做測試；如果執行結果是按照自己的想法出現後，那麼他們通常就認為程式沒錯了。

可是，其實這樣的程式碼通常就會躲進很多很多的 Bug 。所以我們要讓程式碼自己告訴我們它沒問題，而不是我們自己去想像它沒問題。

當然測試並不是萬靈丹，它只是去驗證我們所考慮到的狀況；但如果抱持著「既然我都有考慮到，而且也寫在程式碼裡，那這樣就不用測試了呀！」的態度，那其實也是災難的根源。因為如果我們沒有寫測試來驗證程式碼的話，那我們的防範措施根本就不值得信賴！

所以不是手動測試過沒問題，下次就不會再發生了；而是要拿出保證來才值得相信，而測試就是我們的保證。

如何確保系統照著規格實作？

符合客戶所要求的規格，就是我們實作系統的最終目標。有些規格是流程的控制，有些規格是資料的處理；但這些如果沒有一套好的檢驗機制來協助我們確認這些規格的話，我們就沒辦法有百分之百的信心告訴客戶說，我們的程式完成了你們的需求。

自動化測試就是一個方便的檢驗機制，而測試案例就是客戶的規格。當我們的程式按通過測試後，我們也就可以放心把這些程式碼用在實際的開發中；如果這時還發現執行的結果有問題的話，通常就就可以判斷是實際開發的程式碼中出現了錯誤。

當然有些工程師會認為：為什麼我要把同樣的程式碼在測試案例和實作運作的系統中各寫一遍？其實這是錯誤的觀念。

測試案例分成兩種：一種是在程式正常運作下的案例，它們能明確告訴我們程式的使用方式，也就是客戶要求的規格；一種是設想到可能會讓程式出現問題的案例，它們考驗著身為工程師應該去設想到的錯誤處理機制。

當客戶新增或修改了規格時，那麼我們的測試案例就要跟著調整。而沒有調整的部份，我們就能透過現有的測試案例來確保舊有程式按照舊的規格執行，確保我們的程式沒有因為新增或修改的功能而出現預料之外的錯誤。

怎麼寫出好測試？

好的測試案例依賴著工程師的經驗，經驗越豐富的工程師，就能預想到各種可能發生的狀況，並寫出因應的測試案例。不過有經驗的工程師畢竟是少數，所以大多數時候我們還是要按步就班，從我們能做得到的部份做起。

一開始我們可以先對正常的流程編寫測試；而在程式通過正常測試之後，我們再針對有可能造成我們程式誤動作的狀況去加入異常的測試。有時候 Bug 可能是因為操作流程錯誤而產生，那麼就要在流程中的每個關卡做好程序的把關。

例如某些關卡要有防呆機制，某些關卡不能重覆執行，我們就必須去防止等等。測試之所以要強調自動化，就是讓我們不用把時間花在手動去模擬使用者操作的過程；而且我們可以透過對調測試案例裡的每個觸發條件的執行順序來產生不同的測試方式，以找出可能潛藏的流程問題。

有時候我們的系統可能會有多個使用者同時在操作，如何讓獨立性的資料不互相干擾，或是避免資料更新的先後順序問題 (例如商品庫存) ，這都是好的測試應該注意的重點。

重要的是，每個測試案例是要有意義的，我們在撰寫測試之前就要先分析它們的前因後果，才能擬定出正確的測試方向。如果覺得自己寫的流程測試可能有盲點時，那麼也可以請伙伴幫我們一起思考可能的狀況。

測試太花時間？

在很多 Web 系統開發的過程中，其實很少有人會去考慮測試這件事情；主要是因為 Web 系統中大部份只是簡單的 CRUD 而已，加上時程的壓力，就會讓很多開發人員放棄撰寫自動化測試。

不過在一個較具規模的系統的規劃與設計過程中，就應該將自動化測試考慮進來；而且即便有時程壓力，也應該對核心功能撰寫測試案例。尤其當核心功能牽扯到有關金流等不容有錯的部份時，更是應該用測試來嚴格把關。

更好的方式是將撰寫測試的時間在一開始就放到時程規劃裡，其他的就讓專案經理去傷腦筋，即便是在維護階段時也是如此。因為如果多花半個小時寫自動化測試的話，那麼未來找 Bug 的時間就至少可以減掉半天。

既有的程式該如何測試？

如果大部份已經在運作的程式沒有對應的自動化測試，而在它們發生問題就要花很多時間來除錯時，就應該考慮安排時間進行重構與撰寫測試。

首先在第一次重構時，可以先考慮把核心邏輯獨立出來；如果這個動作在執行上相當困難的話，那麼就先將資料或網路存取的部份獨立出來。這些外在因素我們可以透過 Dependency Injection 的方式來重構，然後在自動化測試時用 Stub 物件來代替它們。

當程式重構至無關外在變因，且手動測試通過後，就可以開始考慮撰寫自動化測試；這時還是要按照先測正常流程，再測異常流程的步驟來進行。而其中測試用的假資料可以從現有的資料中產生，這些資料因為已經透過客戶的驗證，更能確保測試的可靠性。

另外有些既有的錯誤是必須在長時間才能發現，這時候我們可能就要用推測的方式來撰寫測試案例。這樣一來有兩個好處，其一是我們就可以讓測試自動化去代替手動測試的部份，其二是如果未來還是發生同樣問題時，我們也能透過這些測試來排除掉先前推測出來的因素。

結論

其實我們也很難百分之百地保證通過測試的程式碼一定完全沒問題，但很重要的一點就是我們至少能保證通過測試的部份是會按照我們的想法來執行。

一個好的系統在交到客戶手上時，就應該要有一定的品質；而品質的保證來自我們的信心。至於我們的信心並不是建構在想像之上，而是應該用實際的測試數據來做為它的基礎。

這次臨時去亞太資安論壇，主要是因為 Darkhero 的介紹，且主題剛好是我有興趣的網頁安全；所以就拜託了 Neo 老大讓我去聽課囉。

聽了一整天下來，很多都是廠商在介紹產品，觀念部份反而都是老調重彈 (但實作技術上都比以前進步很多) 。

不過阿碼科技的場次倒是讓我非常驚豔！主要是他們本身在這個業界就非常有名，而且這次分享的內容偏向技術面，讓我非常有認同感。

這次阿碼科技的分享主要內容是「網頁掛馬」，以下我就簡單分享這次的筆記與心得。

Malware 是什麼？

其實就是用來控制被攻擊電腦的惡意軟體，像是不必經過使用者允許就能遠端連線的桌面控制工具。

而常看到的透過 Script 或 Iframe 標籤所連結的 JavaScript ，其實只是用來下載 Malware 的工具程式。

網頁掛馬的途徑

網頁掛馬的方式分成三種途徑：

Web

一般常見的就是透過後端技術 (例如 ASP 、 PHP 、 JSP 等等) ，然後使用 SQL Injection 等常見的 Web 攻擊手法，把木馬掛到 Web 應用程式當中。

LAN

利用使用者操作上的疏忽，感染他們的電腦，再透過區域網路的 ARP 封包來對主機做掛馬的動作。常見的工具有 zxarps.exe ，它可以對區網內的使用者所訪問的所有網站插入惡意的 HTML 碼，例如 iframe 。

WAN

部份非知名品牌的網路設備 (例如 Layer 4 / Layer 7 switch) 存在著漏洞，駭客就利用它來讓連線的用戶被導向惡意的網站。

Malzilla 解掛碼工具

阿碼科技提供了以下測試用的掛碼網址：

• http://zcrack.org/a
• http://zcrack.org/cookie

然後透過 Malzilla 來就可以攔截到 http://zcrack.org/a 的原始 HTML 碼：

<html>
<head>
  <META NAME = "ROBOTS" CONTENT = "NOARCHIVE" >
  <META NAME = "ROBOTS" CONTENT = "NOINDEX" >
  <META NAME = "ROBOTS" CONTENT = "NONE" >
</head>
<body>
<div id="imgs"> <script src='go.jpg'></script><script src='2.jpg'></script><script src='3.jpg'></script><script src='4.jpg'></script><script src='5.jpg'></script><script src='5.1.jpg'></script><script src='6.jpg'></script><script src='7.jpg'></script><script src='8.jpg'></script>
</body>
</html>

主要可以看到木馬透過多個 <script> 標籤去組合，這會讓 Sever 端的防毒很難偵測出它的存在。

而這些 JavaScript 就會動態組合出所謂的 Exploits (或稱為 Dropper 及 Downloader )，讓特定的瀏覽器執行後去下載真正的惡意程式 (Malware) 。

因為這些 Exploits 是動態組合，所以不容易被偵測出來，因此要借重一些工具來找出真正的 JavaScript 。

Burp Suite 可以幫我們攔截網頁 HTML ，然後進行適當的修改 (例如把 JavaScript 的 eval 改為 alert ) ，讓我們能看到真正會被執行的 JavaScript 長什麼樣子。

圖解掛馬流程

一般掛碼分為三個步驟：

1. Cracker 想辦法攻擊某些網站的漏洞 (就是上面提到的三種途徑) ，並把 Url Generator 放到它們上面；通常流量較大的知名網站越容易成為被攻擊目標。

2. 使用者去瀏覽這些被攻擊的網站的頁面時，就會被導向置有惡意 JavaScript Exploits 的網站。

3. 當下載回來的 JavaScript Exploits 被特定瀏覽器執行時 (例如 IE6 ) ，就會再次連到另一個真正存放惡意軟體的網站將該惡意軟體下載回來執行。

偵測的難度如下圖所示：

因為 JavaScript 可以透過 JavaScript 來產生新的 JavaScript ，使得 Url Generator 及 Exploits 很容易變形，增加了偵測的難度。

Exploits 難以偵測的原因

• 目前的 Exploites 都做了模組化，不同的瀏覽器有不同的掛馬方式。

• 如果 Exploites 透過 Browser Agent 的方式識別瀏覽器的話，很容易被資安廠商透過更改 Agent 的方式偵測到。所以目前的 Exploits 大多都是透過瀏覽器支援的特性來識別瀏覽器，這樣就更能精準確認使用者的瀏覽器，避免被資安廠商的自動檢測掛馬程式給偵測出來。

• Exploites 也會先行利用偵測到的瀏覽器特性為 Key 來對自己的程式碼進行編碼，這樣就更能增加自動檢測掛馬程式的偵測難度。

Cracker 掛馬的難度

• 要讓被攻擊網站的安全檢測工具都檢查不出來。

• 在網路上的任何節點也不能被偵測到。

• 要隨時注意瀏覽器的漏洞。

• 必須知道資安廠商的 IP ，避免自己的網站被列入黑名單。

資安廠商因應的對策

• Web Application Firewall

• 使用白名單網址，判斷 Script 的來源是否合法。

心得

其實以前也研究過有關 IIS 與 ASP 的資安議題，也在實際上線的網站上被 Cracker 攻擊過，那時就覺得網站安全是一門很深的學問。

今天又在阿碼科技的 CTO 口中，瞭解了這些相當紮實且淺顯易懂的觀念，真是此行最大的收穫！

資安的世界真是複雜又有趣呀~

MADE IN LUKA 手創館自去年度就陸續協助本土設計師發展自己的創意品牌商品，這次超人氣職場部落客 i'm mark 也進駐賣起衣服跟馬克杯了。

現在買衣服還有送 i'm mark 紙喇叭喔。

雖然現在商品還不多，有興趣的話快到 MADE IN LUKA 的 i'm mark 專區看看吧:
http://www.madeinluka.com.tw/category/313

想跟豆花妹穿的一樣甜美可愛嗎? 到天母嚴選 Gotobuy 來看看吧: ^^
http://www.gotobuy.com.tw/templates/gotobuy/edm/100301-EDM/100301-EDM.html

雖然這樣的規劃聽起來不錯，但單元測試這件事說到底我的實務經驗還是太少，在這次的專案項目裡，才讓我真正有了較為深入的體會。

先對要測試的事情有一個概觀

其實測試一開始真的很難下手，主要是因為我們不知道我們要測些什麼東西。因此，我們需要對需要測試的東西有個概觀。

就以這次的例子來說吧，我要測試的東西就是「折價券攤提的演算法邏輯」，那它裡面重要的東西是什麼？

在跟客戶討論，我們得知折價券面額要分攤到的商品上時有一定的規則；這時我們就要先在紙上作業，用簡單的例子跟客戶確認清楚規則。

確認了方向之後，因為我之前已經測試架構準備好了，所以接下來就只要針對要測試的部份撰寫程式碼即可。但如果一開始還沒有準備好測試架構的話，這裡給大家幾個建置環境的簡易流程：

1. 在專案裡開個 tests 資料夾，這裡就是放置測試案例的地方。

2. 準備一個 init.php ，目的是用來設置 include_path 及 autoload 機制。

3. 按照 PHPUnit 官方的建議，建立一個 AllTests.php 的 Test Suite 。

註：這裡我就不列出程式碼了，讓大家自己試試看。

然後每次測試就用以下指令即可：

> phpunit AllTests.php

之後我會以「跑測試」來表示執行這個指令。

描繪程式的輪廓

接下來我們就要把整個系統的測試架構定義出來，不過這時候其實我們還沒開始寫程式，只是把流程和相關的方法先定義出來。

這裡的方法很簡單，就是先透過註解和方法介面來描述整個流程，而不是先寫細部的程式碼。

class Shop_Cart_Plugin_Coupon extends Shop_Cart_Plugin
{
    // ... 略 ...
 
    // 演算法計算後的結果
    protected $_sharedCouponData = array();
 
    // 取得演算法計算後的結果，也可供測試來驗證
    public functino getSharedCouponData() 
    {
        return $this->_sharedCouponData;
    }
 
    // 主要的執行方法
    public function doCheckout()
    {
        $this->_getCouponData(); // 取得
        $this->_getProductData(); // 取得商品資料
        $this->_initData(); // 初始化要攤提的資料
        $this->_shareCouponToProduct(); // 開始攤提
    }
 
    // ... 略 ...
}

當然這些都是大概的輪廓，因為可能在我們寫好測試執行時，會再額外加入新的方法及介面。

還有一個要先定義好的是測試用的比對數據格式，它對我們稍後要測試的程式寫法會有影響。

寫第一個測試

到這裡，我們就可以開始寫第一個測試，而接下來的程式碼，都是先以這個測試可以成功為目的。而這個測試要怎麼寫呢？就是把一開始我們在紙上作業的數字拿進來套用。

當然這裡我的 setUp 和 tearDown 也已經在之前準備測試架構時寫好了，它們會讓我們每次的測試數據都能夠獨立。我們關心的就是第一個測試案例：

<?php
class Shop_Cart_Plugin_CouponTest extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function setUp()
    {
        // ... 略 ...
    }
 
    public function tearDown()
    {
        // ... 略 ...
    }
 
    public function testDoCheckout()
    {
        $this->_plugin->setValue(array(
           1 => 1, // C1, ProductCoupon for P1, $100
           2 => 2, // C2, ProductCoupon for P1, P2, $100
        ));
        $this->_cart->addItems(array(
            'P1' => 1, // $200
            'P2' => 1, // $300
        ))->refresh();
        $this->assertEquals(300, $this->_cart->getTotal());
        $this->_plugin->doCheckout();
        $resultDataList = $this->_plugin->getSelectedOrderCouponDataList();
 
        $this->assertEquals(-100, $resultDataList['P1-C1']['discountPrice']);
        $this->assertEquals(-25,  $resultDataList['P1-C2']['discountPrice']);
        $this->assertEquals(-75,  $resultDataList['P2-C2']['discountPrice']);
    }
}

這裡因為我們在上一步就定義好比對用的數據，所以測試時就是用這個輸出的數據來與我們預期的數字相比較。

接下來就先跑跑測試，看看這個 TestCase 有沒有執行錯誤的地方 (例如物件沒有正確初始化或是變數名稱誤寫等等) ；當然如果沒有出現預期值是正常的，因為我們根本還沒有寫計算公式。

繼續完成演算法

現在回到 Shop_Cart_Plugin_Coupon ，我們就要把剛剛那些只有骨頭的方法開始添血添肉，這裡就請大家自行發擇。

接著只要你覺得程式差不多了，就先跑一下測試，看看是不是符合測試的預期結果。

當你完成第一個測試時，程式的就差不多完成百分之五十啦，到這裡別忘了先把程式 commit 到版本控制系統裡。

加入新測試並修改程式

完成第一個測試時，當然不是沒事了，我們要針對不同的狀況再加入其他的測試數據。

這裡我們就可以開始考慮把第一個測試以 PHPUnit 提供的 Data Provider 改寫，讓我們不必重複過多的程式碼。

<?php
class Shop_Cart_Plugin_CouponTest extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function setUp()
    {
        // ... 略 ...
    }
 
    public function tearDown()
    {
        // ... 略 ...
    }
 
    /**
     * @dataProvider provider
     */
    public function testDoCheckout($selectedCouponIdList, $productSkuNumberList, $total, $discountDataList)
    {
        $this->_plugin->setValue($selectedCouponIdList);
        $this->_cart->addItems($productSkuNumberList)->refresh();
        $this->assertEquals($total, $this->_cart->getTotal());
        $this->_plugin->doCheckout();
        $resultDataList = $this->_plugin->getSharedCouponData();
 
        foreach ($discountDataList as $key => $value) {
        	$this->assertEquals($value, $resultDataList[$key]['discountPrice']);
        }
    }
 
 
    public function provider()
    {
        return array( // 第一個測試
            array(array(
                1 => 1, // C1, ProductCoupon for P1, $100
                2 => 2, // C2, ProductCoupon for P1, P2, $100
            ), array(
                'P1' => 1, // $200
                'P2' => 1, // $300
            ), 300, array(
                'P1-C1' => -100,
                'P1-C2' => -25,
                'P2-C2' => -75,
            )),
            array( // 第二個測試
                // ... 略 ...
            ),
            // ... 略 ...
        );
    }
}

而加入新測試之後，就可以跑跑測試，看看我們剛寫好的演算法是否正確動作？通常這時候才真正是考驗的開始。因為這時候前面寫好的程式碼可能只對第一個測試正常，接下來的測試也許就會出錯了。

所以我們就會需要修改或重構程式碼，讓後面的測試也能正常執行。當然改過的程式也要讓第一個測試正常運作，才是正確的修改。

當然演算法寫好後，就要真正上到 Web 畫面去測試。至此，你會發現你花在寫測試上的心力都有了回報，因為通常如果你已經定義好介面，而這次的修改只是改寫一個小類別的話，那麼就會發現程式會非常順利地運作了。

心得

每次寫購物車時，最麻煩的就是測試時要開啟購物車網頁，把一個一個的商品加進來，再加入不同的折價券條件...

而有單元測試之後，我就可以省去一大堆開啟網頁，點選連結的功夫，專心地撰寫計算邏輯...只能說...單元測試真的個超級便利的工具呀。

在和Neo討論之後，想試試看"內嵌前台"方式來製作這次的管理介面，一開始思索了一下，首先是"如何進入管理模式"，一般正常的方式，不外乎就是進到一個有帳號&密碼欄位的畫面，輸入帳密之後，導向進管理後台，而這次想挑戰的內嵌式，當然要嚐試看看新鮮的寫法，相信有玩過魂斗羅的骨灰級玩家都知道，只要在一開始遊戲畫面中輸入上、上、下、下、左、右、左、右、B、A、B、A，，就可以得到30隻，對於想破關的朋友，莫不是一大福音，根據這樣的"取得隻數"的方式，"取得權限"亦可如法炮制，於是就出現了，魂斗羅內嵌Trihome的想法，在網站的任意位置，只要管理者突然有想進入管理介面的衝動，只要輸入密碼按下Enter，就可以神不知鬼不覺的偷偷進入管理介面，以下即為進入管理介面之後的畫面：

眼尖的朋友應該注意到了，在畫面上有隱約透露出神秘綠光的區塊，這部份是提示管理者，目前頁面上"即將被編輯的區域"，而點擊右上的綠勾，就可以進入真正的編輯區塊了，如下圖：

在編輯區塊內全部採取ajax即時更新資訊方式，讓管理者更能直覺的輸入修改資料。

在一開始構思的時候，本來預定是要真的在網頁上，即時編輯所有內容，不過第一頁就遇到問題了，在首頁的Banner，一次需要上多張Banner，系統判斷上下檔期後，要自動替換，那要可以即時編輯的話，難道要把全部已經上傳的圖都秀出來，版面應該會破的亂七八糟吧，所以才借助了blockUI，把需要編輯的部份通通丟在裡面，以不破壞原始版面為主；在這次撰寫過程，遇到很多問題需要解決，也連帶吸收了不少EXP，整個管理的方式進步空間還很大，不過算是處女作就....勉強算ok，未來有機會的話，可以再嚐試看看不同的方式，朝更人性、更直覺的設計介面前進吧~

三燔本家在網路上許多吃過的人都極力推薦，甚至可以說是一生當中一定要吃一次的店。經過哇寶挑嘴團這次尾牙的實地品嚐，雖然價格較高，但的確非常值得親身前往一探究竟。

有多值得呢? 從第一道菜開始沒多久，身邊陸續傳來同事們此起彼落的聲音「好好吃喔~」「嗯~這個真好吃」「喔~太好吃了」...(每道新的菜上來，重覆的戲碼也不斷的上演 XD)

(不只沙拉做的美味，連裝沙拉的碗都又脆又香，吃的不亦樂乎)

(極度受好評的開胃菜)

(生魚片好吃到大家都在用搶的)

(這道牛肉的料理鮮嫩多汁，對牛肉最挑嘴的 Jace 都大力推薦)

(龍蝦海鮮的美妙滋味實在讓人難以忘懷)

(這隻魚一出現沒多久就只剩下骨頭了 XD)

(燒烤的味道也不是蓋的)

這次的主角"和牛"更是不可少，甚至加點了一份頂級和牛來吃。

(用鍋底的蒸氣來吃，這真的是人間美味呀~)

最後的甜點水果一搬進來，真的就是異口同聲的「哇噢~~~」

(照片看起沒什麼，但現場看這個真的非常大一鍋)

雖然有遇到牛小排吃到飽的優惠，但同事有的不吃牛、不吃肉...點吃到飽的並不划算 (註)，所以這次以尾牙以三燔本家的套餐為主。以上的照片也只列出部份餐點，由於現場吃的種類很多，加上平常難得有機會吃到高級料理，只顧著吃都來不及了，能保持理性的人記得每樣菜的人已經不多了。XD

註:使用吃到飽的優惠，包廂全場的每個人都要加一份牛小排吃到飽的價格。

(最後每個人幾乎飽到走不太動了，飽到不行的合照)

今年大家也要一起好好努力，明年繼續吃大餐。^^

會議開始後，從投影機之中映出了一網站，問我們能不能做到這樣的效果?

(這個網站是 Pixazza 。發音 Pix-a-zza 音似: "皮克斯阿殺")

Pixazza 在去年成立時就引發國外媒體關注，這個連 Google 也名列股東之一的公司，做的事看起來明白易懂:「即使是新聞圖片也可以購物」。

雖然很多人笑稱這只是 Flickr + EDM 的變形，國外早年已有類似的應用在型錄上，但實際應用於購物網站在台灣還沒見到。

特力的團隊同時也帶來了 IKEA 的網站做為參考:

看完之後，我請另一位同事先放下手邊的工作，從電腦拿出個東西給他們看，我們其實很早就開發出雛形來了。

(這個雛形不只有"點"，甚至可以延伸到"面"。上圖是 Email 給特力團隊時改為廚房情境照)

接著跟特力的團隊討論完技術層面，並且參考 HOLA 的實體型錄內容之後，特力團隊的負責人認為還有一件事要解決，以圖片為購物主軸來結合購物網站並不容易，在國內外都沒有這樣的案例可以參考，也希望我們能提供一些意見。

這次就輪到我來做展示了，其實在討論的過程中就已經想到我們的客戶 BlingCandy 的網站首頁非常適合呈現這樣的購物模式:

首頁上方遠大於一般購物網站的圖片尺寸，可以左右切換不同的圖片來進行購物。
這樣情境圖片便能成為網站購物的主體，網頁下方再規畫為展示及促銷訊息區塊。

就這樣，客戶帶著滿意的微笑離去， HOLA 的新版計畫也就從這裡開始了。

(第1名"天母嚴選"及第10名"御家族"正好都是我們的客戶)

我們非常了解網路市場的經營不易，因此對能入榜 Yahoo! TOP10 的商家都深感佩服。

在這邊也同時祝福台灣所有的電子商務網站在 2010 年能有更好的成績。TAIWAN UP!

相關網頁:
Yahoo! 奇摩2009之最

上線日期: 2009/11/30

沒吃過御海苔，等於這輩子沒吃過海苔。

御海苔有多好吃? Google 搜尋 "御海苔" 所出現的一大串團購、勸敗文:

小華兒愛瞎拼_【團購】御家族的御海苔~忍不住想吃咧

喵喵の簡單生活 ::【團購】御家族的味付海苔&手工達人之黃金蛋捲

[團購]板橋市。寬泓御海苔@ 佳莉。心情:: 痞客邦PIXNET ::

yumi的隨意札記: 【零食】味付御海苔- yam天空部落

御家族除了海苔很有名之外，陸續推出了許多不同種類的零食。

這次很高興能有機會跟御家族的團隊合作，他們真的很在乎每一位網友的反應，對於自家購物網站也要求一定要做到最好、最方便訂購。

御家族網站在2009 年尾很順利的上線了，但偷偷告訴大家，這個網站的重頭戲還沒來，2010 年初將提供一般購物網站難得一見的新功能，敬請期待。

御家族官方購物網站:
http://www.ace-88.com/

哇寶當然不能錯過這個新時代 3D 電影的響宴，阿凡達在台正式上映前便已預訂在台灣螢幕最大的美麗華 IMAX 影廳，讓全體同仁體驗身歷其境的 IMAX 3D 的潘朵拉星球之旅。

(哇寶夥伴們在阿凡達立牌前合影)

阿凡達這部電影成功的寫下影史的新頁，相信台灣未來也能做出更多舉世刮目相看的革命性產品。

TAIWAN UP!

噗浪備份工具 BKPlurk Beta 測試上線網址:
http://www.wabow.com/bkplurk/

在噗浪官方 API 發布前，備份工具大多只能備份自己的噗，因此這次在做 BKPlurk 時就把備份"回噗"列為重點。

為了觀看方便，所以備份檔案採用 HMTL 格式，點一下就可以看到回噗了。
(至於 CSV 的格式目前還在規畫中)

使用上有任何問題或意見也歡迎大家提出來一起討論。^^

更新記錄:
12/15: 感謝 Jace 做的新畫面 (點此回顧初版的畫面)

不就是個服裝購物網站嘛?

如果這麼想可就大大的錯囉。

只要在 Yahoo! 購物中心 或 Gotobuy 網站消費，都可以累積紅利積點兌換好康商品喔。接下來即將登場的優惠折扣機制，讓網友即使在實體通路也能享受到天母嚴選異業合作的大優惠，真的是賺翻啦。

在建置的過程當中，最複雜的地方在於庫存的調撥機制，為了讓天母嚴選在不同的通路都能有正確的數量，花了很多時間跟天母嚴選的團隊一起討論、修正、討論、再修正，過程當中天母嚴選的倉管、物流、客服人員也很用心的提出作業的流程建議參考，在雙方不斷的努力下，最後終於讓網站順利的完成上線了。

上線後才驚覺天母嚴選的團隊更是臥虎藏龍，有人在家隨手就畫出了這張 Gotobuy 的 7-11 取貨圖。

別再等啦~ 想親身體驗各種不同風格的時尚穿搭，來 Gotobuy 就對了! ^^

天母嚴選 Gotobuy 網址:
http://www.gotobuy.com.tw/

同場加映，網站開發中畫面:

問題

目前我們公司是用 Subversion 做為版本控管系統，在 commit 時都會需要把版本更新訊息寄送給相關人員，當然這就會用到 post-commit 這個 hook 指令；而在 post-commit 中，我們可以利用 bash 語法去呼叫寄信程式。

不過預設建立好的 Repository 下的 hooks 目錄並沒有這個檔案，我們可以把預設的 post-commit.tmpl 複製成 post-commit ：

# cp /path-to-svn-repository/project_name/hooks/post-commit.tmpl /path-to-svn-repository/project_name/hooks/post-commit

至於寄信程式的部份，在 Subversion 的 Source code 裡就提供了一個很有用的 mailer.py ，它可以協助我們寄送 commit 後的訊息。

原來的 post-commit 內容如下：

#!/bin/sh
 
# POST-COMMIT HOOK
# (略)
 
REPOS="$1"
REV="$2"
 
commit-email.pl "$REPOS" "$REV" commit-watchers@example.org
log-commit.py --repository "$REPOS" --revision "$REV"

將它修改為：

#!/bin/sh    
 
# POST-COMMIT HOOK 
# (略) 
 
REPOS="$1"
REV="$2"
 
/path-to-subversion-source/tools/hook-scripts/mailer/mailer.py commit "$REPOS" "$REV"
# log-commit.py --repository "$REPOS" --revision "$REV"

不過用原始的 mailer.py 有個缺點，主要是它寄送的訊息主旨範例如下：

r3214 - branches/2.0

這樣在多個專案時，我們就不容易識別這次的更新是哪個專案。

所以我就想透過修改 mailer.py ，讓它產生如下的主旨：

[project_name] r3214 - branches/2.0

修改方式

改法很簡單，有兩個地方要改： (針對 Subversion 版本 1.4.4 原始檔)

if commondir:
  self.output.subject = 'r%d - in %s: %s' % (repos.rev, commondir, dirlist)
else:
  self.output.subject = 'r%d - %s' % (repos.rev, dirlist)

改成：

if commondir:
  self.output.subject = '[%s] r%d - in %s: %s' % (repos.project_name, repos.rev, commondir, dirlist)
else:
  self.output.subject = '[%s] r%d - %s' % (repos.project_name, repos.rev, dirlist)

也就是這裡我多加了一個 repos.project_name ，讓信件主旨可以多一個專案名稱。不過 projects_name 並不是 repos 的屬性，所以我們還要再修改一個地方。

往下找到：

self.author = self.get_rev_prop(svn.core.SVN_PROP_REVISION_AUTHOR)

然後在底下加入一行：

self.project_name = repos_dir[10:]

其中 10 這個數字是指 /path-to-svn-repository/ 的長度，因為 repos_dir 的內容會是 /path-to-svn-repository/project-name ，而字串是由 0 開始算起，那麼 project_name 的起始位置就會剛好是 /path-to-svn-repository/ 的長度。 (所以請自行計算並更改之)

至於為什麼我會知道 repos_dir 的內容，這是因為我在一開始就用了以下的程式去印出它：

f = open("mailer.log", 'w')
f.write(repos_dir)
f.close()

當然這邊要注意縮排。

結論

Python 對我來說，其實是一個不熟悉的語言。不過它的語法也不是那麼難以理解，以我這種三流能力，竟然還能看懂並修改它。

而 mailer.py 也大量使用了物件導向的寫法，所以未來有機會在開發 Python 程式時，在物件導向的基礎也是不可或缺的。

就這樣啦~謝謝收看~再會~

官方網站 http://filenice.com/
展示網頁 http://filenice.com/demo/

介紹

filenice是一套用php編寫的檔案瀏覽工具，作用在你本身如果有架設網站並有某個資料夾提供上傳檔案，當你想要查看這個資料夾中有哪些檔案時，filenice提供使用瀏覽器就可以查看的功能。

安裝

到官網下載檔案(http://filenice.com/demo/fileNice.zip)，下載完畢將解壓縮後的檔案放到網站伺服器上你想要瀏覽檔案的資料夾下即可。

優點

官方的說明是filenice是使用php+javascript也就是所謂的Ajax技術編寫的，因此速度比較快，而且當應用程式忙碌時可以返回而不會整個畫面當掉。此外使用filenice不需要安裝任何資料庫。

感想

filenice提供了無須安裝其他軟體，僅需使用瀏覽器就可觀看主機上提供upload的資料夾下的內容，也可自訂瀏覽檔案的一些排列等細節，另外也提供搜尋的功能。不過個人比較覺得可惜的是，因為無須登入帳密即可觀看，在安全性上稍顯不足，不過或是也因此除了觀看以外，並沒有額外提供刪除或是上傳的功能吧!?介紹給大家用看看!

可以接受回傳資料？

先調查一下，知道 include 或 require 可以取得回傳資料的請舉手... (眺望)

呃...不知道的朋友也不用煩惱，我來解釋一下。

如何回傳資料呢？假設現在有個 php 檔叫做 config.php ，內容如下：

<?php
return array('123', '456');

咦？那邊有人說 return 放錯地方了？不不不， PHP 能接受這樣的寫法。

好，現在我們來證明 include 或 require 能取得 config.php 所 return 回來的資料。請建立一支 test.php ，其內容是：

$config = require 'config.php';
var_dump($config);

執行看看，是不是可以跑呀？

所以我們可以在某支 PHP 程式中 return 一個資料 (任何型態) ，然後在另一支 PHP 程式中用 include 或 require 來取得這個資料。

把 require 放在參數裡

什麼？這不是密技？不不不，密技在底下：

function test($config) {
    var_dump($config);
}
test(require 'config.php');

對！你沒看錯！直接把 require 放在函式的參數裡！

還沒完呢，再看：

class Test
{
    public function __construct($config)
    {
        var_dump($config);
    }
}
$a = new Test(require 'config.php');

連 new 建構子的參數都可以接受 require ！

所以只要能放變數的地方，都可以放 include 或 require ，例如：

if (require 'config.php') {
    var_dump(require 'config.php');
}
 
if ($config = require 'config.php') {
    var_dump($config);
}

而且不僅是 include 及 require ，連 include_once 和 require_once 都可以這麼做。

我在某篇文章發現這個密技以後，分享給辦公室裡的同事們；沒想到玩了 PHP 這麼多年的他們也沒看過這個方法，看來大家對 PHP 的瞭解需要更深入一點囉！

Scope 的問題

接著我同事問了我一個問題：如果在參數使用 require 敘述，而且被 require 的 PHP 程式裡如果有定義全域變數的話，那麼這個變數在執行的 PHP 程式裡，它的 scope 在哪裡呢？

答案是：它還是全域。

怎麼說呢？現在我們在剛剛的 config.php 的 return 敘述前加上一行程式，如下：

<?php
$data = '789'; // 加上這行
return array('123', '456');

然後在 test.php 裡的 Global 部份 (也就是不在函式或類別定義裡) 的任意處加入：

var_dump($data);

是不是也可以正確顯示 config.php 中 $data 變數所指定的內容呢？這就表示在參數中使用 require 不會影響全域變數的 scope 。

還有其他 include 或 require 的密技嗎？歡迎大家一起討論囉~

For Example:
Google Apps 就是用這個方式去作驗證

CNAME 是 DOMAIN or SUB DOMAIN 指向另一個 DOMAIN 的方式. (跟 alias 一樣)

那麼如果要用 PHP 實作呢? 有兩種方式 :
1. PHP5 內建的 dns_get_record() (Windows & BSD & Mac 不適用)
2. PEAR NET_DNS

NET_DNS 原理是用 fsockopen("你的 DNS SERVER IP", 53),
但是要先自己組合出 "封包的header data" 再丟過去, DNS Server 才會理你唷.
這些複雜的部份 NET_DNS 已經都幫我們做好了.

我們只要:

require_once('Net/DNS.php');
$ndr = new Net_DNS_Resolver();
$answer = $ndr->search("www.OOO.com", "CNAME");
echo "<pre>";
print_r($answer);
 
// 獲得的結果
Array
(
    [0] => Net_DNS_RR_CNAME Object
        (
            [name] => www.OOO.co.nz
            [type] => CNAME
            [class] => IN
            [ttl] => 86400
            [rdlength] => 18
            [rdata] => store	XXX�3
            [cname] => store.XXX.com
        )
 
)

PS, 在 Windows 環境, 請修改 PEAR/NET/DNS/Resolver.php 裡的

var $resolv_conf = '/etc/resolv.conf';

改成

var $resolv_conf = 'D:\Appserv\resolv.conf';

resolv.conf 要加入你的 DNS Server (請用 ipconfig /all 查詢)

nameserver 168.95.192.1

平常使用的安裝在哇寶主機上的subversion，這次想嘗試看看將subversion架設在windows平台上，於是開始了尋找資料之旅。
基本上，這裡有很詳細的說明，只要按照個人系統，修改部份設定，以下就紀錄一下我自己的步驟：

(因為已經寫的超白話了，所以就不另外附圖)

• 安裝apache，我是用懶人包xampp直接裝好apache、php、mysql，apache版本2.2.9。  (  範例懶人包安裝的路徑是在c:\xampp\ )     點我下載xampp (版本 1.7.2 )
• 下載subversion windows版本，點我下載  (版本 1.6.5 ) ， 安裝很容易，狂點next就對了。
• 打開C:\xampp\apache\conf\httpd.conf ，隨便找個地方 加入

    <Location /svn/repository>
      DAV svn
      SVNPath D:\svn\repository
    </Location>
  

  其中 /svn/repository 是你想對應到的網址，像是 http://localhost/svn/repository， 而D:\svn\repository 則是實際svn專案檔案放置的位置。

• 最後，請到windows提供的"命令提示字元"模式下，輸入 svnadmin create d:/svn/repository ，完成建立專案，到這裡算是完成建立整個專案。
• 打開瀏覽器，輸入http://localhost:8080/svn/repository/ ，可以看到 『 repository - Revision 0: / 』，代表該專案目前版號為0 (還沒開始動工，當然是0)
• 測試一下，先隨便找個地方，例如 D:\wwwroot\ ，滑鼠右鍵選擇『 SVN 取出 』，檔案庫URL 請輸入 『 http://localhost:8080/svn/repository 』，取出目錄按照預設即可，按下確定。
• 到D:\wwwroot\repository，測試建立一個文字檔， aaa.txt ，同樣路徑下按滑鼠右鍵『 SVN 送交 』，將更新的檔案傳送至SVN檔案庫，完成測試SVN上傳。
• 同樣來到 http://localhost:8080/svn/repository/ ，會看到『 repository - Revision 1: / 』，版號以由0變成1，代表剛上傳的svn紀錄已完成。

以上就是依照個人設定，完成subversion安裝在windows的過程，看到專案是使用自己架設的subversion，檔案成功被建立、刪除修改後更新，感覺還不錯～

]]> http://blog.wabow.com/archives/2067/feed 1 http://blog.wabow.com/archives/2072 http://blog.wabow.com/archives/2072#comments Thu, 27 Aug 2009 06:32:14 +0000 daniel http://blog.wabow.com/?p=2072 感謝上一篇文章中前輩們的熱心回覆；垃圾留言果然是大家心中的痛啊（噗）～雖然 CAPTCHA 可以透過各式各樣的 OCR 破解（最新版的 JDownloader 也已經能忽略大部分免費空間所用的圖像辨識...扯遠了），不過它仍是目前阻擋機器人最直接也最簡單的解決方案；當然更複雜的 CAPTCHA 還是能夠達到阻擋的目的，但是使用 CAPTCHA 的方式對使用者來說就已經是不友善了。

後來在討論中 Jace 提到，其實 SESSION 是有可能被機器人知道的；所以我後來綜合了 fillano 提供的演算法概念，稍微改良了一下之前的 NoSpamNX class。利用隨機產生的隱藏欄位順序，用不同的演算法再對隱藏欄位的數值作編碼；讓 SESSION 內存的未編碼的值，與 POST 過來的已編碼的值不一樣。最後再將 SESSION 內存的值編碼，與 POST 的已編碼的值作比較，判斷留言的使用者是不是機器人。

SESSION 紀錄的值是未編碼的值，但在產生隱藏欄位時，input 的值是已經編碼過後的值

/**
 * 建立隱藏欄位 HTML；利用隱藏欄位先後順序不同，使用 md5 or sha1 編碼
 * 
 */
public function addHiddenFields()
{
    $nospamnx = $_SESSION[$this->_sessionName];

    if (1 === rand(1,2)) {
        return '<input type="text" name="nospamnx['.$nospamnx['nospamnx-1'].']" value="" class="locktross" /><input type="text" name="nospamnx['.$nospamnx['nospamnx-2'].']" value="'.md5($nospamnx['nospamnx-2-value']).'" class="locktross" />';
    } else {
        return '<input type="text" name="nospamnx['.$nospamnx['nospamnx-2'].']" value="'.sha1($nospamnx['nospamnx-2-value']).'" class="locktross" /><input type="text" name="nospamnx['.$nospamnx['nospamnx-1'].']" value="" class="locktross" />';
    }
}

驗證時根據 POST 過來的 nospamnx 順序不同，以不同的演算法編碼後再做比較

// 根據 POST 過來的值順序不同，以 md5 or sha1 判斷
if ($nospamnx['nospamnx-1'] == current(array_keys($postData))) {
    $encode_value = md5($nospamnx['nospamnx-2-value']);
} else {
    $encode_value = sha1($nospamnx['nospamnx-2-value']);
}
if ($postData[$nospamnx['nospamnx-2']] != $encode_value) {
    return false;
}

最後提供範例程式下載，分為一般 POST 與 AJAX 二種方式。

]]> http://blog.wabow.com/archives/2072/feed 0