一個面向應(yīng)用過程監(jiān)控系統(tǒng)的測試工具

(南京大學(xué) 計算機軟件新技術(shù)國家重點實驗室 南京 210093)

摘 要：為降低信息系統(tǒng)應(yīng)用過程中的各種風(fēng)險，開發(fā)并部署相應(yīng)的自動監(jiān)控和過程審計系統(tǒng)成為一種重要甚至必要的措施。不同于傳統(tǒng)應(yīng)用，此類系統(tǒng)以業(yè)務(wù)系統(tǒng)和操作人員的動態(tài)行為過程為目標(biāo)，其系統(tǒng)測試與確認(rèn)測試依賴于人工現(xiàn)場操作，施行不便，代價較高。為得到一套較為方便通用的過程監(jiān)控系統(tǒng)自動測試支持框架，分析了信息系統(tǒng)動態(tài)行為過程監(jiān)控系統(tǒng)的一般特點，建立了一個基于有限狀態(tài)自動機的監(jiān)控行為模型，基于此模型設(shè)計并實現(xiàn)了一個自動測試腳本語言。進(jìn)而使用該模型和語言，在Windows平臺上開發(fā)了一套分布式的自動監(jiān)控測試系統(tǒng)，并以一個真實的桌面應(yīng)用監(jiān)控系統(tǒng)產(chǎn)品為對象進(jìn)行了簡單的實驗，取得了較好的效果。由此可以認(rèn)為，該方法能夠有效降低監(jiān)控系統(tǒng)測試的成本，提高測試效率。

關(guān)鍵詞：應(yīng)用過程監(jiān)控; 自動化測試； 狀態(tài)機

中圖分類號：TP311文獻(xiàn)標(biāo)志碼：A

文章編號：1001-3695(2009)05-1639-06

Application process oriented testing tool to monitoring system

LI Yeqing MA Xiaoxing LV Jian

(State Key Laboratory for Novel Software Technology Nanjing University Nanjing 210093 China)

Abstract:To facilitate the automatic testing of these systems proposed a finite state machinebased approach for the behavior modeling of both the monitoring systems and the target business systems. Based on this modeling developed a prototypical distributed testing tool and corresponding script language. The tool is then used to perform the testing of a commercial monitoring software product and the result shows that the tool is effective. This can tell us that the method can greatly reduce the cost of testing and raise the efficiency.

Key words：application process monitoring; automatic testing; FSM

0 引言

隨著信息技術(shù)的迅猛發(fā)展和各種計算機設(shè)備的日益普及，公司和機構(gòu)內(nèi)部軟硬件設(shè)備構(gòu)成了一個復(fù)雜的信息系統(tǒng)，這些設(shè)備會通過LAN 連接成一個整體，并且還可能連接到更大的網(wǎng)絡(luò)環(huán)境，如Internet。這樣系統(tǒng)行為就變得更加復(fù)雜。當(dāng)這個系統(tǒng)能夠訪問一些關(guān)鍵或機密信息時，規(guī)范系統(tǒng)的行為就變得非常重要。一個典型例子就是銀行內(nèi)部的信息系統(tǒng)。銀行是重要的金融機構(gòu)，其內(nèi)部的信息流動背后就是資金流動，所以銀行對于其信息安全性要求特別高。提高信息安全性，一方面通過法律法規(guī)約束相關(guān)人員的行為；另一方面則通過引入監(jiān)控系統(tǒng)在系統(tǒng)行為層次降低風(fēng)險^[1]。為了保障企業(yè)的信息安全，除了完成日常業(yè)務(wù)的軟件，還會引入保障系統(tǒng)，如入侵檢測系統(tǒng)、監(jiān)控系統(tǒng)等。雖然監(jiān)控系統(tǒng)在目的和實現(xiàn)上與防火墻、入侵檢測系統(tǒng)有很多相似之處，但是它與這些系統(tǒng)有一個很重要的區(qū)別：這些系統(tǒng)關(guān)注點在防止入侵上，如黑客、病毒、木馬等；監(jiān)控系統(tǒng)雖然也會一定程度上考慮這些方面的問題，但是更多地集中在發(fā)現(xiàn)或制止內(nèi)部人員有意或無意威脅到信息安全的行為，也即監(jiān)控系統(tǒng)更多的是為了內(nèi)控。因為從現(xiàn)實的角度來看，無論從發(fā)生危害的可能性以及危害的后果來說，內(nèi)部非法行為都要高于外部入侵，一來這樣的行為更容易實施，二來內(nèi)部人員對于內(nèi)部信息的使用更加清楚。所以信息系統(tǒng)應(yīng)用過程監(jiān)控審計軟件就成為了企業(yè)必不可少的防御工具。

針對信息系統(tǒng)應(yīng)用過程設(shè)計的監(jiān)控系統(tǒng)，在實現(xiàn)上自然地以用戶操作集為中心進(jìn)行分析設(shè)計。這種觀點雖然直觀，但是卻給系統(tǒng)實現(xiàn)和測試造成了困難。根據(jù)用戶日常操作對要實現(xiàn)的部件進(jìn)行分類以后，各種部件之間沒有統(tǒng)一的參考模型。這樣就無法統(tǒng)一地對各個部件的需求進(jìn)行分析。每一類操作的分析都是從頭做起，并且設(shè)計的好壞很大程度上取決于設(shè)計人員對于用戶操作經(jīng)驗的豐富程度。另外，這種零散的設(shè)計方式也不利于評估和驗證系統(tǒng)設(shè)計。例如設(shè)計測試用例時對用戶操作的熟悉程度的依賴性很高。離散的功能設(shè)計也會導(dǎo)致系統(tǒng)被部署進(jìn)行確認(rèn)測試或系統(tǒng)測試時很難實現(xiàn)自動化，現(xiàn)實中常常需要雇傭大批操作人員進(jìn)行測試。

另外，監(jiān)控系統(tǒng)內(nèi)在的分布性加上行為模擬難以實現(xiàn)自動化造成了確認(rèn)測試和系統(tǒng)測試的困難。當(dāng)對系統(tǒng)進(jìn)行確認(rèn)測試和系統(tǒng)測試時，需要把系統(tǒng)部署在更大、更接近真實應(yīng)用場景的大計算系統(tǒng)中。這個是由監(jiān)控系統(tǒng)所面向環(huán)境的特點所決定的。如果行為模擬不能方便統(tǒng)一地實現(xiàn)自動化，那么就需要利用大量的測試人員進(jìn)行手工操作。這樣在實現(xiàn)上成本高，并且人員之間也難以協(xié)調(diào)，影響了測試質(zhì)量。

在這種情況下，本文提出了信息系統(tǒng)應(yīng)用過程的狀態(tài)機模型。該模型用更抽象的觀點看待所有信息系統(tǒng)應(yīng)用過程，將應(yīng)用過程分成從安裝到卸載的生命周期中的各個狀態(tài)，運行過程也細(xì)分了輸入/輸出等狀態(tài)。這樣，監(jiān)控系統(tǒng)的職能在于等待目標(biāo)系統(tǒng)的某個狀態(tài)變遷，并采取相應(yīng)的措施。應(yīng)用這個模型，能將各類目標(biāo)系統(tǒng)的行為統(tǒng)一到同一概念框架下討論，也能為系統(tǒng)設(shè)計提供清晰的參考。實現(xiàn)時可以針對目標(biāo)的狀態(tài)變遷進(jìn)行深入研究，各類行為之間的實現(xiàn)框架也能夠統(tǒng)一。

狀態(tài)機模型除了能夠使得系統(tǒng)設(shè)計有更清晰的參考以外，也使得自動化測試工具的設(shè)計有了更可行的模型。因為各種信息系統(tǒng)的行為已經(jīng)建立了一致的狀態(tài)機模型，則測試用例的實施本質(zhì)上即驅(qū)動目標(biāo)系統(tǒng)特定的狀態(tài)變遷。當(dāng)實現(xiàn)了一個統(tǒng)一的狀態(tài)機框架以后，只要將具體行為填入框架，就能成為對特定系統(tǒng)的測試驅(qū)動系統(tǒng)。

最后，筆者再為寫成的各個具體測試驅(qū)動系統(tǒng)建立一個分發(fā)部署運行的分布式測試框架，這樣就構(gòu)成了完整的測試工具。這個工具首先要支持分布式的對象分發(fā)和部署，能夠遠(yuǎn)程運行測試用例，還要支持自動化測試腳本，以方便測試用例的實施。本文后面就實現(xiàn)了這樣一個完整的原型工具，驗證了上面模型的有效性。

1 監(jiān)控系統(tǒng)

為了建立方便合理的測試工具，首先要對被測試的一類系統(tǒng)有一個清楚的認(rèn)識。本章首先介紹監(jiān)控系統(tǒng)的作用，進(jìn)而分析監(jiān)控系統(tǒng)的通用結(jié)構(gòu)和監(jiān)控的一般過程，以對應(yīng)用過程監(jiān)控系統(tǒng)的過程有個基本理解；然后分析當(dāng)前監(jiān)控系統(tǒng)發(fā)現(xiàn)信息系統(tǒng)行為視角的不足；最后提出信息系統(tǒng)的狀態(tài)機模型。

1.1 監(jiān)控系統(tǒng)的作用

在程序的設(shè)計過程中，人們通過各種方式來確保程序的正確性。這種正確性包括內(nèi)涵的和外延的。內(nèi)涵的正確性包括語法上和語義上的。語法上的正確性是指輸出的結(jié)果在形式上符合預(yù)期，而語義上的正確性則是指定的過程產(chǎn)生的確實是合理的結(jié)果。外延的正確性表示軟件系統(tǒng)不被用在不恰當(dāng)?shù)膱鼍爸小＠缫患夜緝?nèi)部的計算機軟硬件系統(tǒng)的作用可能是管理公司資源以及開展公司業(yè)務(wù)，那么公司的負(fù)責(zé)人（也就是這些設(shè)備資源的所有者）不會希望雇員用這些設(shè)備有意或無意地泄露公司機密，或在工作時間做私人的事情。這類事情就屬于不恰當(dāng)?shù)膱鼍啊榱舜_保這點，負(fù)責(zé)人可能會在這些設(shè)備中引入一個系統(tǒng)對這些場景進(jìn)行監(jiān)控，即信息系統(tǒng)應(yīng)用過程監(jiān)控系統(tǒng)（下面簡稱監(jiān)控系統(tǒng)）。這類系統(tǒng)針對特定的信息系統(tǒng)，檢查其輸入、輸出或狀態(tài)是否屬于指定的集合。

1.2 監(jiān)控系統(tǒng)結(jié)構(gòu)

當(dāng)監(jiān)控的目標(biāo)對象確定后，通常實現(xiàn)會有兩種途徑獲得目標(biāo)對象的輸入/輸出和狀態(tài)（圖1）。

a)檢查目標(biāo)對象與環(huán)境的交互。這里把目標(biāo)對象邊界之外凡可能與目標(biāo)對象交互的對象集統(tǒng)稱為環(huán)境。這時，目標(biāo)對象被看做一個黑盒子。

b)使用目標(biāo)對象提供的接口。如果對象本身提供這樣的接口，那么直接使用目標(biāo)對象提供的接口也許是更方便的做法。這時，目標(biāo)對象被看做一個灰盒子。

無論是用底層環(huán)境提供的接口，還是使用目標(biāo)對象提供的接口，都面臨著為每個目標(biāo)對象單獨開發(fā)一套監(jiān)控機制的問題，并且這樣開發(fā)出來的系統(tǒng)很難復(fù)用。對于桌面系統(tǒng)來說，不斷涌現(xiàn)的軟件資源反而造成監(jiān)控系統(tǒng)開發(fā)人員工作的困難。后面將會再討論這個問題。

接下來是如何處理這些得到的監(jiān)控信息。通常的做法是使用規(guī)則標(biāo)志違規(guī)操作，然后應(yīng)用規(guī)則來對監(jiān)控信息進(jìn)行匹配，確定要采取怎樣的善后措施。由于目標(biāo)對象的多樣性，監(jiān)控信息獲取的隨意性造成了這些規(guī)則的形式很難統(tǒng)一。這樣，就不得不為每個或者每一類目標(biāo)對象設(shè)計一套檢查機制。而且檢查機制設(shè)計的測試和驗證也耗時費力，無疑增加了開發(fā)的成本。

一個監(jiān)控場景可能包括以下部分：

a)決策者。使用監(jiān)控進(jìn)行決策的人或程序。

b)監(jiān)控對象。也即上面所說的目標(biāo)對象。

c)環(huán)境。監(jiān)控對象邊界之外的對象集合。

d)監(jiān)控系統(tǒng)。具體執(zhí)行監(jiān)控動作產(chǎn)生報告的軟硬件。這部分包括:

(a)嗅探器。運行在與目標(biāo)對象相同的環(huán)境下，收集關(guān)于監(jiān)控對象的決策者感興趣的信息。

(b)收集器。訂閱嗅探器得到的信息局部匯總。一般收集器可能還要負(fù)責(zé)啟動相關(guān)的嗅探器。

(c)控制器。從各個收集器得到監(jiān)控信息進(jìn)行全局匯總，并進(jìn)行相關(guān)的處理。

(d)執(zhí)行器。在必要的時候能夠?qū)崿F(xiàn)對監(jiān)控對象及其環(huán)境的干涉。

在這個框架下，監(jiān)控信息處理過程是：首先監(jiān)控對象產(chǎn)生了該事件；然后嗅探器感知到這個事件的發(fā)生，打包監(jiān)控結(jié)果信息發(fā)送給收集器；收集器得到消息后隨之向控制器發(fā)送消息；控制器中有配置好的事件處理機制，通過匹配事件的類型決定是否記錄日志、發(fā)出警報、產(chǎn)生處理動作由執(zhí)行器執(zhí)行或進(jìn)行其他處理。

1.3 信息系統(tǒng)應(yīng)用過程的狀態(tài)機模型

分析了監(jiān)控系統(tǒng)通用結(jié)構(gòu)和監(jiān)控的一般過程以后，下面深入到當(dāng)前監(jiān)控查看信息系統(tǒng)的視角，通過分析現(xiàn)有觀點的一些不足，引入信息系統(tǒng)應(yīng)用過程的狀態(tài)機模型。

監(jiān)控系統(tǒng)是基于用戶日常操作行為來看目標(biāo)對象的，本文稱之為基于用戶操作的行為模型。這種模型的優(yōu)點是直觀：系統(tǒng)的規(guī)則直接反映了使用信息系統(tǒng)的人平時可能進(jìn)行的操作集合。但是這個模型也會造成一些困難：首先，在測試時使得開發(fā)測試用例沒有統(tǒng)一的詞匯，表面上各個功能之間沒有聯(lián)系，也就造成了要實現(xiàn)測試自動化很困難，要為每個特定分類獨立設(shè)計用例，測試用例的執(zhí)行也要各自從頭開始；另外，在監(jiān)控系統(tǒng)實現(xiàn)時也是各自為政，如實現(xiàn)文件類監(jiān)控的就不用關(guān)心網(wǎng)絡(luò)管理類監(jiān)控，這樣造成各個部分無法統(tǒng)一討論，也就沒辦法在一個維度上保障軟件質(zhì)量，軟件質(zhì)量很大程度上依賴組內(nèi)開發(fā)人員的經(jīng)驗。監(jiān)控系統(tǒng)體系結(jié)構(gòu)如圖2所示。

為了能夠更好地理解信息系統(tǒng)行為，使得監(jiān)控系統(tǒng)的測試和開發(fā)都能擺脫單純依靠經(jīng)驗的問題，本文將每個被監(jiān)控信息子系統(tǒng)（軟件、硬件和數(shù)據(jù)）看做一個對象。這樣信息系統(tǒng)行為就可以看做是對象狀態(tài)的變遷。于是測試監(jiān)控系統(tǒng)的過程不過是驅(qū)動特定對象的狀態(tài)變遷。將狀態(tài)機A定義為一個五元組A=(Q，Σ，Δ，q0，F(xiàn))^[2]。形式地，目標(biāo)對象的狀態(tài)機At為

Qt≡{qit｜qit  is target object state}

Σt≡{σjt｜σjt is input symbol of target object}

ΔtQt×Σt→Qt is transition function

q0t≡start state

Ft≡{qft｜qft is final state}

目標(biāo)對象的狀態(tài)機如圖3所示。

它包括以下三大狀態(tài)變遷過程：

a)安裝。一個對象要經(jīng)過安裝才能被使用。如果安裝成功，則對象就緒可以進(jìn)一步運行；如果安裝失敗，則對象生命周期結(jié)束。

b)運行。如果安裝成功，則對象只是靜態(tài)成為系統(tǒng)一部分，這時可以使得對象進(jìn)入運行狀態(tài)，如將軟件裝載進(jìn)內(nèi)存運行。通常對象處于空閑狀態(tài)，如果有請求到達(dá)，則進(jìn)入交互狀態(tài)。交互過程也包含自己的子自動機。

c)交互。主要是獲得輸入，更新自身狀態(tài)。如果這個過程失敗，則會產(chǎn)生交互錯誤，并最終返回空閑狀態(tài)。

類似地，定義監(jiān)控系統(tǒng)在不對目標(biāo)對象進(jìn)行監(jiān)控時，狀態(tài)機為Am=(Qm，Σm，Δm，q0m，F(xiàn)m)，各個成分意義類似At所述。

當(dāng)監(jiān)控系統(tǒng)開始對目標(biāo)系統(tǒng)監(jiān)控時，假設(shè)需要監(jiān)控的變遷是qitσktqjt。

假設(shè)qidlem為監(jiān)控系統(tǒng)的空閑狀態(tài)，qcheckm為監(jiān)控系統(tǒng)對信息進(jìn)行匹配的狀態(tài)，則開始對目標(biāo)狀態(tài)進(jìn)行監(jiān)控后，監(jiān)控系統(tǒng)的狀態(tài)機為

Q′m=Qm，′m=m∪{σ′=\"qitσktqjt\"}

Δ′m=Δm∪{qidlemσ′qcheckm}，

q′0m=q0m，F(xiàn)′m=Fm

直觀地說，對于一個目標(biāo)對象，在設(shè)計時需要回答的問題是在哪個狀態(tài)變遷上監(jiān)聽消息。用狀態(tài)機來表達(dá)如圖4所示。目標(biāo)對象開始被監(jiān)控時，其狀態(tài)變遷會同時觸發(fā)監(jiān)控系統(tǒng)的狀態(tài)變化。所以監(jiān)控系統(tǒng)的輸入集合需要加入它所感興趣的事件，這個事件也就是目標(biāo)對象的一次狀態(tài)變遷。然后，監(jiān)控系統(tǒng)會處于匹配規(guī)則的狀態(tài)，此時監(jiān)控系統(tǒng)試圖確認(rèn)所得到的信息是否意味著違規(guī)操作。若匹配失敗，則監(jiān)控系統(tǒng)再次回到等待狀態(tài)；若匹配成功，則監(jiān)控系統(tǒng)將會進(jìn)行進(jìn)一步處理。

2 測試工具設(shè)計

2.1 系統(tǒng)測試和確認(rèn)測試

軟件的確認(rèn)測試始于集成測試的結(jié)束，這時已測試完單個構(gòu)件，軟件已組裝成完整的軟件包。測試主要關(guān)注于用戶可見的動作和用戶可識別的輸出。確認(rèn)測試主要是為了確保軟件滿足所有的需求。系統(tǒng)測試則是將軟件部署到真實的計算機大系統(tǒng)中，對其進(jìn)行一系列不同側(cè)重點的測試。系統(tǒng)測試包括恢復(fù)、安全、壓力、性能等。這兩種測試的實施依次位于軟件開發(fā)的后期。

從監(jiān)控系統(tǒng)本身的分布性以及對象的多樣性，將系統(tǒng)部署到接近真實應(yīng)用環(huán)境中進(jìn)行測試的過程本身就要耗費相當(dāng)大的成本。顯然，這種測試往往只能在小環(huán)境中使用大量的人力進(jìn)行測試，這樣的做法效率很低，而且人員之間也不易協(xié)調(diào)，測試的質(zhì)量很難提高。

通過分析測試中存在的困難可以發(fā)現(xiàn)，要實現(xiàn)一個自動測試工具中的幾個基本需求：

a)測試工具應(yīng)是分布式的，能夠方便地部署；

b)要能夠靈活地配置功能，支持自動化的腳本；

c)腳本還要能支持高層的語義，測試實現(xiàn)上還要具有一定的自主能力。

下面將介紹基于這些需求設(shè)計的一個測試工具。

2.2 測試系統(tǒng)模型

基于上面對監(jiān)控系統(tǒng)以及被監(jiān)控系統(tǒng)的模型，可以相應(yīng)地建立測試系統(tǒng)行為模擬部分的模型，如圖5所示。

模擬部分建立了目標(biāo)系統(tǒng)相應(yīng)的自動機，并實現(xiàn)了相關(guān)行為驅(qū)動部分，則執(zhí)行相關(guān)的模擬命令時它需要兩個輸入：模擬的變遷；目標(biāo)系統(tǒng)當(dāng)前狀態(tài)。在目標(biāo)系統(tǒng)狀態(tài)集Qt上定義以下的序關(guān)系：

ab，if there exist a path from x to y in At

且x∈Qt∶x≡x，然后再定義兩個函數(shù)before和next：

beforeQt×Qt→{true，1}

before(a，b)=trueif a≡b of ab1 otherwise

nextQt×Qt→Qt

next(x，y)=the immediate successor if there exist

of x in the path to ya path from x to y

nilotherwise

模擬部分的狀態(tài)機為As=(Qs，Σs，Δs，q0s，F(xiàn)s)。

設(shè)src，dst，cur∈Qt。其中：src表示需要模擬的狀態(tài)變遷之源狀態(tài)；dst表示需要模擬的狀態(tài)變遷之目標(biāo)狀態(tài)；cur表示目標(biāo)系統(tǒng)當(dāng)前狀態(tài)。(src，dst，cur)構(gòu)成模擬部分的一個輸入。可以定義模擬部分的狀態(tài)轉(zhuǎn)換函數(shù)，非形式地寫為

Δs(src，dst，cur)=next(cur，dst) if before(cur，src)

next(src，dst)if before(src，cur)

back to the

\"listen\" stateif cur≡dst

這樣，就可以通過這種關(guān)系實現(xiàn)模擬部分的一個簡單框架，然后再將對應(yīng)具體目標(biāo)系統(tǒng)的動作加進(jìn)去，就能夠?qū)崿F(xiàn)一個完整的模擬程序。測試系統(tǒng)架構(gòu)如圖6所示。 

2.3 測試系統(tǒng)體系結(jié)構(gòu)設(shè)計

當(dāng)對應(yīng)各個具體目標(biāo)系統(tǒng)模擬程序構(gòu)造完成以后，就可以通過一個分布式測試框架將它們組織成一個完整的測試工具，這些模擬程序就作為測試框架在本地的代理。測試過程就是通過在對象活動的機器上部署代理用來與對象進(jìn)行交互，并產(chǎn)生需要監(jiān)控的狀態(tài)變遷。

按照職能劃分，測試系統(tǒng)包括四個部分:

a)總控制器。作為整個系統(tǒng)的用戶界面，可以集中式控制系統(tǒng)運行。

b）代理。控制局部機器上的對象，使得對象產(chǎn)生需要被監(jiān)控的狀態(tài)變遷。

c）局部控制器。運行在特定的物理機器上，負(fù)責(zé)管理部署在這個機器上的agent，如啟動、停止、發(fā)送消息給agent等。另外，它還負(fù)責(zé)與總控制器通信。

d）分發(fā)器。主要用于向局部控制器部署agent。

這樣，運行測試用例的主機可以根據(jù)需要，部署一個到多個對監(jiān)控對象進(jìn)行控制的代理，然后通過總控制器上運行測試腳本來控制各個代理的行為。

實現(xiàn)一個代理所要做的工作就是實現(xiàn)一個目標(biāo)對象的狀態(tài)機。運行測試用例其實就是觸發(fā)某個狀態(tài)變遷。這樣只要代理所表示的狀態(tài)機已能覆蓋測試用例所需的變遷，就能通過一個簡單的推理引擎最終激發(fā)所需的行為。例如要產(chǎn)生IE訪問“www.nju.edu.cn”的事件，而已經(jīng)有一個實現(xiàn)了完整IE 狀態(tài)機的代理，那么代理可以簡單地搜索得到下面的路徑：

就緒=>運行【初始化=>空閑=>交互（輸入=>更新）】

然后代理再將“www.nju.edu.cn”作為輸入發(fā)送給IE，就能產(chǎn)生出瀏覽事件。

2.4 腳本語言設(shè)計

測試通過在總控制器上執(zhí)行命令腳本來觸發(fā)。腳本命令是順序結(jié)構(gòu)的命令式語言。每行是一個語句。一個語句包含下面四個元素：

a)執(zhí)行動作的代理。成為動作的主體：performer。

b)動作。在具體代理類中定義的動作名字：act。

c)參數(shù)。表示動作的參數(shù)：object。

d)身份標(biāo)志。成為系統(tǒng)用戶：user。因為一般監(jiān)控審計系統(tǒng)都會將行為與具體的人聯(lián)系起來，而這個聯(lián)系是通過用戶ID來建立的，類似于操作系統(tǒng)中的用戶。

這里控制器與代理之間通信是異步的，也就是一個命令成功發(fā)送給特定代理，只是表示這個命令已經(jīng)放入了代理的命令隊列，并不表示命令已經(jīng)執(zhí)行完成。

腳本語言的語法如下面的BNF所示：

〈command〉::=〈defagent〉｜〈do〉｜〈load〉｜〈wait〉｜〈kill〉｜〈ca〉｜〈lsa〉

〈defagent〉::=defagent〈agentname〉〈agenttype〉

〈do〉::=do〈agentname〉〈action〉〈object〉by〈user〉

〈load〉::=load〈filename〉

〈wait〉::=wait〈number〉

〈kill〉::=kill〈agentname〉

〈ca〉::=ca〈agentname〉｜ca..｜ca/

〈lsa〉::=lsa

〈agentname〉::=〈string〉

〈agenttype〉::=〈string〉

〈action〉::=〈string〉

〈object〉::=〈string〉

〈user〉::=〈string〉

〈filename〉::=〈string〉.〈string〉

〈string〉::=〈letter〉｜〈agentname〉〈letter〉｜〈agentname〉〈digit〉

〈number〉::=〈digit〉｜〈number〉〈digit〉

〈letter〉::=-｜〈upper〉｜〈lower〉

〈lower〉::=a｜b｜c｜d｜e｜f｜g｜h｜i｜j｜k｜l｜m｜n｜o｜p｜q｜r｜s｜t｜u｜v｜w｜x｜y｜z

〈upper〉::=A｜B｜C｜D｜E｜F｜G｜H｜I｜J｜K｜L｜M｜N｜O｜P｜Q｜R｜S｜T｜U｜V｜W｜X｜Y｜Z

〈digit〉::=0｜1｜2｜3｜4｜5｜6｜7｜8｜9

腳本語言的直觀解釋如下：

a）Defagent。當(dāng)分發(fā)器把一個代理的相關(guān)程序部署到特定主機以后，通過這個命令運行一個代理實例，并命名這個實例。

b）Do。命令特定的代理執(zhí)行指定的動作。一個動作一般就是表示一個狀態(tài)變遷。

c)Load。用于在主控制器端執(zhí)行腳本文件。

d)Wait。為了實現(xiàn)一些簡單的同步，這個命令可以讓特定代理等待一段時間。

e)Kill。終結(jié)特定代理實例，這是一個清理命令。由于代理是組織成樹狀結(jié)構(gòu)，終結(jié)一個有孩子的代理，會使得以這個代理為根的整個子樹的所有代理被終結(jié)。

f)其他輔助命令如ca、lsa等，用于直接訪問特定代理、列表代理的孩子節(jié)點。

命令中的參數(shù)可以使用通配符，這樣就可以指定同一父親的所有子代理執(zhí)行同一個命令（上面已經(jīng)提到，代理是組織成一個樹狀結(jié)構(gòu)）。

3 系統(tǒng)實現(xiàn)及實驗

基于上面系統(tǒng)設(shè)計，本文基于一款桌面監(jiān)控系統(tǒng)產(chǎn)品開發(fā)了一個分布式測試工具原型系統(tǒng)，以對模型的有效性進(jìn)行初步驗證。

3.1 桌面監(jiān)控系統(tǒng)

本文基于南京道及天的APA EosEyeTM易視^[3]桌面監(jiān)控審計系統(tǒng)進(jìn)行模擬測試。易視系統(tǒng)是基于應(yīng)用過程審計的思想和技術(shù)，面向Windows 個人桌面系統(tǒng)的內(nèi)部信息安全防御體系，可通過對個人桌面的各種操作的監(jiān)控，實現(xiàn)對異常、可疑、違規(guī)行為的發(fā)現(xiàn)、報警、錄像、阻斷和審計，以達(dá)到防止內(nèi)部敏感信息或涉密信息泄露的目的。

易視系統(tǒng)主要針對規(guī)則來設(shè)定其監(jiān)控范圍。規(guī)則主要包括五大類：

a)文件類。保護(hù)指定的文件集合不被執(zhí)行未授權(quán)的查看、拷貝、移動、刪除、修改等。

b)存儲介質(zhì)類。針對移動存儲設(shè)備的使用，阻止某些機器使用未注冊的移動存儲設(shè)備，如U盤、光盤刻錄機等。

c)網(wǎng)絡(luò)管理類。針對特定的網(wǎng)絡(luò)地址進(jìn)行的連接或通信。

d)軟件程序類。針對目標(biāo)機器上安裝和運行的程序及服務(wù)。

e)系統(tǒng)管理類。包括七大類：CPU 使用情況、注冊表狀態(tài)審計、內(nèi)存狀態(tài)、硬盤狀態(tài)、系統(tǒng)設(shè)備變動、Windows 系統(tǒng)配置和實時錄像。

易視系統(tǒng)由桌面終端代理、控制服務(wù)器、特殊報警服務(wù)器、用戶控制臺、監(jiān)控器和采樣器等幾部分組成，其中使用時用戶控制臺如圖7所示。

測試工具的實現(xiàn)上，本文使用Ruby^[4]語言，并使用了開源框架DRb作為進(jìn)程間通信的設(shè)施。這個框架在Ruby上實現(xiàn)RMI協(xié)議。

總控制器負(fù)責(zé)全局的協(xié)調(diào)和控制。這里實現(xiàn)了測試腳本的最初解析，產(chǎn)生測試命令信息。這個命令信息會被發(fā)送到局部控制器，然后轉(zhuǎn)發(fā)給相應(yīng)的代理。

運行在一個機器上的多個代理一般會組織成一個層次樹狀結(jié)構(gòu)，這也是為了管理上方便以及概念上清晰。根是局部控制器。局部控制器代表它控制的整個主機。一個測試命令的消息首先是通過總控制器發(fā)送到局部控制器，然后局部控制器再按照代理的層次把消息傳遞下去，直到消息到達(dá)最終要處理它的代理。這里最終處理的代理并不一定是位于最底層，而可能位于任何層次。

具體執(zhí)行測試用例的是運行在目標(biāo)機器上的代理，任何代理都派生自基類agent。Agent 類定義了與代理生命周期相關(guān)的方法，并使用反射機制建立了添加動作的框架。所有名字為a XXX 能夠作為代理可執(zhí)行的動作被自動調(diào)用，調(diào)用的消息就是XXX。而代理執(zhí)行哪個動作最初是通過在總控制臺執(zhí)行腳本控制的。這些動作后面都是在狀態(tài)機上的一個簡單搜索以及基本相同的執(zhí)行過程，然后在輸入上有所區(qū)別。

總控制器和局部控制器、局部控制器和代理、代理和代理之間的進(jìn)程間通信都是通過DRb 框架提供RMI 機制來實現(xiàn)。

3.2 運行過程及行為模擬

實驗一共包括四個測試場景：a)測試文件類的規(guī)則，對一個預(yù)先指定的被保護(hù)文件模擬刪改操作；b)測試網(wǎng)絡(luò)管理類的規(guī)則，通過控制IE訪問http://bbs.nju.edu.cn來激發(fā)禁止訪問的規(guī)則;c)測試軟件程序類規(guī)則，通過代理在一個主機上運行被禁止運行的記事本;d)測試系統(tǒng)管理類，使用代理修改注冊表中關(guān)于IE主頁的設(shè)置。四個場景都能有效地完成，并成功地觸發(fā)了監(jiān)控系統(tǒng)報警，而且用例設(shè)計好以后均能很方便地實現(xiàn)和運行。

圖8展示了實驗的四個場景中模擬程序的狀態(tài)機。其中：（a)為模擬程序的狀態(tài)機，agent刪除一個受保護(hù)的文件，F(xiàn)S表示文件系統(tǒng)，這里只是在交互環(huán)節(jié)上進(jìn)行控制，安裝等環(huán)節(jié)均沒有動作；(b)是agent的狀態(tài)機，控制IE訪問 http://bbs.nju.edu.cn以觸發(fā)禁止訪問網(wǎng)頁的規(guī)則；(c)為模擬程序的狀態(tài)機，運行記事本，以觸發(fā)禁止程序運行類的規(guī)則；(d)為模擬程序的狀態(tài)機，修改注冊表中的主頁設(shè)定，以觸發(fā)系統(tǒng)管理類的規(guī)則。實驗證明，只要一次編寫模擬的基礎(chǔ)設(shè)施，最終的測試人員只需用很少的代價就能產(chǎn)生各種測試場景。

4 相關(guān)工作

隨著信息系統(tǒng)與人們工作、生活的關(guān)系日益密切，信息技術(shù)成為經(jīng)濟(jì)發(fā)展的重要支柱。所以，信息系統(tǒng)安全問題所產(chǎn)生的損失和影響不斷加大。人們需要通過各種手段來降低信息系統(tǒng)應(yīng)用過程中的各種風(fēng)險。一種是引入桌面監(jiān)控審計系統(tǒng)；另一種就是入侵檢測系統(tǒng)。這兩種系統(tǒng)之間無論從架構(gòu)實施方式和目的上都有很多共通之處，但是也存在著明顯的差別：入侵檢測系統(tǒng)主要是為了防止外來入侵，而監(jiān)控系統(tǒng)則主要為了防止內(nèi)部人員破壞，屬于內(nèi)控范疇。典型的入侵檢測系統(tǒng)（intrusion dectetion system，IDS），如美國普渡大學(xué)開發(fā)的基于自治agent 的分布式入侵檢測框架AAFID^[5]。該系統(tǒng)由agent、filter、transceiver和monitor 四類部件組成。其中agent負(fù)責(zé)數(shù)據(jù)收集和分析。另外，還有日本的IPA （informationtechnology promotion agency）開發(fā)的IDA^[6]（intrusion detection agent）。IDA 具有兩個不同于傳統(tǒng)IDS的特征：通過移動agent跟蹤入侵行為；它一旦發(fā)現(xiàn)入侵，agent 將收集所有與入侵有關(guān)的數(shù)據(jù)。上面兩個系統(tǒng)數(shù)據(jù)收集雖然是分布式的，但數(shù)據(jù)處理卻是集中式的。清華大學(xué)設(shè)計了一種基于分布式協(xié)作數(shù)據(jù)處理的IDS 分布式協(xié)同入侵檢測系統(tǒng)^[7]（distributed cooperative intrusion detection system，DCIDS）。本文在分析桌面監(jiān)控系統(tǒng)時借用了入侵檢測系統(tǒng)理論和實現(xiàn)上的共通之處。

在測試工具設(shè)計方面，本文工作則更多的是在GUI 測試，以及測試用例自動生成等研究的基礎(chǔ)上進(jìn)行擴(kuò)展。與命令行（command line interface，CLI）用戶界面的系統(tǒng)相比，基于GUI 的軟件要實現(xiàn)測試用例生成存在兩個難點：要測試的操作太多；操作的順序相關(guān)。為了能夠生成測試用例，相關(guān)的文章也提出了相應(yīng)的模型，但是其中大部分是延續(xù)了用在CLI上的技術(shù)。這些技術(shù)實施在GUI程序上都會遇到規(guī)模的問題。例如，最常見的就是基于有限狀態(tài)機的模型^{[8 9]}。不過這些模型需要手工建立復(fù)雜的狀態(tài)機，比較耗費人力。自動生成測試用例的工作則是在這些模型上基于搜索的方法完成^[9]。此外還有借鑒在CLI上使用過的人工智能規(guī)劃的用例生成技術(shù)^[10]，在GUI也有相應(yīng)的實現(xiàn)^[11]。使用規(guī)劃產(chǎn)生測試用例可以使得測試路徑不惟一，有更大的靈活性，并且能發(fā)現(xiàn)很多新的路徑。遺傳算法在測試用例生成上也有應(yīng)用^[12]。在測試用例的執(zhí)行上，CLI常用的方法是捕捉/回放，但是在GUI上遇到了困難^[13]。其中一個問題是GUI本身可變性較大，不易實現(xiàn)回放。解決這個問題的一個辦法就是深入到GUI與窗口系統(tǒng)的交互上，捕捉/回放那些交互事件^[14]。更進(jìn)一步，人們逐漸開始采用建立一個代理程序與GUI進(jìn)行交互的方法^[12]來實現(xiàn)測試用例。本文測試工具的實現(xiàn)也是通過建立代理程序來控制被監(jiān)控目標(biāo)的方法，而模型上參考了GUI測試的自動機模型的應(yīng)用。

5 結(jié)束語

本文分析了監(jiān)控系統(tǒng)的特點，建立了目標(biāo)對象的自動機模型，然后使用Ruby語言的反射（reflection）機制和方便的RMI，在Windows平臺下實現(xiàn)了一個軟件行為模擬系統(tǒng)，用于簡化監(jiān)控系統(tǒng)設(shè)計及測試。雖然框架本身還存在很多不足，但隨著工作的進(jìn)一步加深，系統(tǒng)能夠模擬越來越多的行為，而且這個行為框架是從一個監(jiān)控系統(tǒng)而來，但并不會局限于測試這個系統(tǒng)，能夠用于測試任意的軟件行為監(jiān)控系統(tǒng)。

當(dāng)然，這個工作還有許多可以改進(jìn)的地方：首先，對于硬件設(shè)備使用的監(jiān)控，如移動設(shè)備使用的監(jiān)控，使用這種代理控制軟件的模式可能很難實現(xiàn)行為模擬。這個問題，可以使用虛擬化技術(shù)來解決：將代理運行在虛擬機當(dāng)中，通過虛擬機管理系統(tǒng)來實現(xiàn)硬件設(shè)備接入的模擬；另外，對于協(xié)作的違規(guī)行為，也可以通過進(jìn)一步引進(jìn)代理之間的通信機制以及更復(fù)雜的狀態(tài)機模型來進(jìn)行模擬。這些都將留待進(jìn)一步研究。

參考文獻(xiàn)：

［1］STONEBUMER G GROGEN A FERING A. Risk management guide for information technology systems[S]. 2001.

[2]HOPCROFT J E MOTWANI R ULLMAN J D. Introduction to automata theory languages and computation[M]. 2nd ed. 北京：清華大學(xué)出版社 2002:60-65.

[3]APA eoseye[EB/OL]. http://www.gesoft.com.cn/Files/99/116/109/20080820313.asp.

[4]CARLSON L RICHARDSON L. Ruby cookbook[M]. Sebastopol: O’Reilly 2006.

[5]SPAFFORD E H ZAMBONI D. Intrusion detection using autonoumous agents[J]. Computer Networks 2000，8(3):547-570.

[6]ASAKA M TAGUCHI A GOTO S. The implementation of IDA: an intrusion detection agent system[C]//Proc of the 11th Annual FIRST Conference on Computer Security Incident Handling and Response. Brisbane: University of Queensland 1999.

[7]段海新.吳建平. 一種分布式協(xié)同入侵檢測系統(tǒng)的設(shè)計與實現(xiàn)[J]. 軟件學(xué)報 2001 12(9):1375-1379.

[8]SHEHAD R K SIEWIOREK D P. A method to automate user interface testing using variable finite state machines[C]//Proc of the 27th International Symposium on FaultTolerant Computing. Washington DC: IEEE Computer Society 1997.

[9]WHITE L ALMEZEN H. Generating test cases for GUI responsibilities using complete interaction sequences[C]//Proc of the 11th International Symposium on Software Reliability Engineering. Washington DC: IEEE Press 2000.

[10]Von MAYRHAUSER A HOWR A MRAZ R T. Test case generation as an AI planning problem[J]. Automated Software Engineering 1997，4(1):77-106.

[11]KOEHLER J NEBEL B HOFFMANN J et al. Extending planning graphs to an ADL subset[C]//Proc of European Conference on Planning. Toulouse: SpringerVerlag 1997:273-285.

[12]KASIK D J GEORGE H G. Toward automatic generation of novice user test scripts[C]//Proc ofSIGCHI Conference on Human Factors in Computing Systems : Common Ground. New York: ACM Press 1996.

[13]KEPPLE L R. The black art of GUI testing[J]. Dr Dobb’s Journal of Software Tools 1994，19(2):40-46.

[14]HENDRICKSON J J HAMMONTREE M L HENSLEY B W. Integrated data capture and analysis tools for research and testing on graphical user interfaces[C]//Proc of the SIGCHI Conference on Human Factors in Computing System. New York: ACM Press 1992:431-432.