C#語言GUI程序自動評測關鍵技術研究

亓雪冬

(中國石油大學(華東),信息化建設處，山東,青島 266580)

0 引言

程序設計類課程是大學通識類教育課程中的重要組成部分，課程特點是理論與實踐緊密結合，上機編程練習對理解和消化課程內容非常關鍵，同時為了更好地檢驗學生的實際編程能力，程序設計類課程的考試環節中采用上機考試形式已成為趨勢[1]。上機練習或考試均需要以程序自動評測系統作為支撐，目前常見的系統有Moodle和OJ。Moodle是一個課程管理系統，最初由澳大利亞教師Martin Dougiamas開發，初期不具有程序評測功能，后作為一個插件加入[2-3]。OJ是Online Judge系統的統稱，主要用于程序競賽時對程序進行評測，國內比較有影響力的主要有北京大學和哈爾濱工業大學的OJ系統[4]。

Moodle和OJ的程序評測原理基本類似，通過操作系統的輸入輸出重定向捕獲控制臺程序(也被稱為命令行程序)的輸入輸出，適合于對C、C++和數據結構等程序算法類課程進行自動評測[5-7]。然而在C#程序設計課程中，程序的表現形式主要以GUI(Graphic User Interface，圖形用戶界面)程序為主，Moodle和OJ均不能對該類程序進行評測。此外Moodle和OJ均采用服務器集中評測架構，易導致服務器負載過重，無法支撐大規模(1 000人以上)用戶同時使用。本研究以C#程序的自動評測為背景，研究了可支持大規模用戶的分散式程序評測架構，分析GUI程序與控制臺程序的區別，提出針對GUI程序的管控模式評測方案，并討論評測過程中的關鍵技術細節。

1 分散式程序評測架構

在程序評測系統的架構設計上，Moodle和OJ都采用服務器集中評測架構，如圖1(a)所示。這種架構中，服務器通常由Web服務器、數據庫服務器和程序評測服務器等部件組成，客戶端(學生機端)僅需安裝瀏覽器。這種架構的優點是客戶端部署簡便，無須安裝專用的軟件,缺點是學生端僅充當程序的編寫工具，而所有學生程序的編譯和評測均需在服務器端完成，服務器端負載壓力聚集易出現資源瓶頸。

(a)服務器端集中式評測架構

為了分散負載壓力，支持大規模用戶量下的程序評測，調整了學生機和服務器的負載分配，提出了學生端分散式評測架構，如圖1(b)所示。新的架構中，服務器端程序評測服務器被移除，程序的編寫、編譯和評測等工作均在學生機中完成，僅需將評測結果發布到服務器保存，這使得所有學生機均分了原服務器中的程序評測工作量，分散了負載壓力，解除了資源瓶頸，提高了系統用戶承載規模。

2 GUI程序管控運行評測方案

控制臺程序的特點是使用標準輸入輸出流與操作系統進行數據交互。借助這個特點，使用操作系統輸入輸出重定向功能，將輸入輸出流對接到外部文件，在不干擾程序正常運行的情況下，對比程序實際輸出和預設輸出，即可完成程序評測。

GUI程序具有圖形用戶界面，不使用標準輸入輸出流而是通過界面元素(如文本框、按鈕等)與外界進行數據交互，采用事件機制驅動程序執行，與控制臺程序有本質區別，因此原控制臺程序的評測方案對GUI程序并不適用。

在深入分析GUI程序運行特點基礎上，提出基于管控模式的程序評測方案，如圖2所示。這種方案中，管控模塊和待評測的GUI窗體模塊組合為單一程序，管控模塊是自動評測的核心，管理和控制整個評測過程。評測過程由5個步驟組成：①程序啟動后首先執行管控模塊，再由管控模塊引導啟動待評測的GUI窗體；②管控模塊根據評測用例將輸入數據填充到控件中；③管控模塊執行控件的事件委托，實際效果相當于觸發控件相關事件；④管控模塊讀取控件輸出數據并與預設的觸發事件后的結果數據進行比較，輸出評測結果；⑤管控模塊關閉GUI窗體并結束自身程序，評測完成。

圖2 基于管控模式的程序評測方案

3 C#語言GUI程序自動評測關鍵技術

3.1 組合管控模塊與窗體模塊

C#程序設計課程中，一個基本的GUI程序包含Form1.cs、Form1.Designer.cs和Program.cs等3個文件，其中,Form1.cs和Form1.Designer.cs為窗體模塊，Form1.cs包含窗體的功能邏輯代碼，Form1.Designer.cs包含窗體的布局代碼，Program.cs主要包含Main函數用于啟動Form1窗體。與學生相關的代碼全部集中在Form1.cs和Form1.Designer.cs中，與Program.cs無關。因此將管控模塊置入Program.cs中。編譯時，管控模塊與窗體模塊組合在一個程序中；運行時，管控模塊管理和控制窗體模塊的評測過程。

3.2 管控模塊內部邏輯

根據評測方案，管控模塊應包含啟動和關閉窗體模塊、執行評測處理以及窗體模塊運行超時時強制關閉程序等功能。管控模塊內部邏輯核心代碼如下。

01 System.Threading.Timer timer;//定義定時器變量

02 TestRule[]testRules;//定義存儲測試規則的數組

03 void Main(){

04 timer = new System.Threading.Timer(OnTimeOut,null,5 000,-1);

05 Form1 testForm = new Form1();//創建窗體對象

06 testRules = ReadTestRules();//讀取測試規則

07 foreach(TestRule rule in testRules)//循環處理每一個測試規則

08 TestForm(testForm, rule);

09 OutputResult(testRules);//輸出測試結果

10 Form1.Close();//關閉窗體對象

11 }

12 void OnTimeOut(object state){//定時器處理程序

13 Environment.Exit(1);//強制結束程序

14 }

①第5行和第10行中，管控模塊在評測前和評測后分別啟動和關閉窗體模塊。②第4行設置了定時器timer，用于對窗體模塊進行超時檢測，避免學生程序進入死循環干擾評測過程。此處設置時間閾值為5 s(5 000 ms)，超時后管控模塊調用第12行的OnTimeOut函數，強制結束程序。③第6行讀取測試用例集，每個測試用例包含輸入數據、觸發的事件、輸出數據、評測結果等數據項；第7、8行循環使用每一個測試用例對窗體進行評測；第9行將捕獲的測試結果輸出。

3.3 管控模塊讀寫窗體模塊的數據

C#語言GUI程序通過界面控件(如文本框、按鈕等)與外界進行數據交互。為了使評測過程自動化，管控模塊需要能夠按照評測規則讀取和寫入控件數據。然而管控模塊在窗體模塊外部，不能直接讀寫窗體模塊內部的控件數據，需要借助C#反射功能實現。

以文本框控件textBox1為例，讀寫該控件數據主要包括以下2個步驟。

(1)管控模塊通過反射取得窗體模塊textBox1的引用。這里，Form1為窗體模塊名，textBox1為控件名。因為窗體內的控件均為窗體的私有變量，因此需要NonPublic和Instance樣式的綁定說明。

TextBox textBox1 =(TextBox)Form1.GetType()

.GetField("textBox1", BindingFlags.NonPublic|BindingFlags.Instance)

.GetValue(Form1);

(2)通過賦值語句讀寫控件數據

textBox1.Text = 寫入的數據

讀取的數據 = textBox1.Text

3.4 管控模塊模擬觸發事件

GUI程序依賴事件機制驅動程序執行，C#語言中觸發事件時會自動調用該事件對應的委托函數。為了模擬觸發事件的行為，管控模塊通過C#反射功能直接提取事件對應的委托函數并執行。

以按鈕控件button1的鼠標單擊事件為例，事件委托函數原型為

void button1_Click(object sender, EventArgs e)

模擬觸發該事件的過程主要包括以下3個步驟。

(1)獲取button1所有事件委托函數列表，這其中包含了鼠標單擊事件的委托函數。

EventHandlerList events =(EventHandlerList)(typeof(Button)

.GetProperty("Events", BindingFlags.NonPublic|BindingFlags.Instance)

.GetValue(button1, null));

(2)在上述委托函數列表中，以鼠標單擊事件名“EventClick”作為鍵值，得到鼠標單擊事件的委托函數。處理后，handler變量即表示button1_Click委托函數。

object key = typeof(Control)

.GetField("EventClick", BindingFlags.NonPublic|BindingFlags.Static)

.GetValue(null);

Delegate handler = events[key];

(3)調用委托函數，模擬觸發鼠標單擊事件。

handler.DynamicInvoke(button1, EventArgs.Empty);

4 應用中出現的問題及改進思路

評測系統在應用過程中出現的問題及后續改進思路總結如下。

(1)可評測控件種類不夠豐富。目前可評測的控件包括標簽Label、文本框TextBox、單選按鈕RadioButton、復選框CheckBox、組合框ComboBox、列表框ListBox和進度條ProgressBar等常用控件。下一步需要加入菜單MenuStrip、列表視圖ListView和樹形視圖TreeView等功能更復雜的控件，進一步豐富題目類型。

(2)學生編寫的程序與測評的程序不一致。部分學生在評測前未對最新修改的程序進行保存，導致評測結果與學生程序不匹配。下一步對評測系統進行改進，在評測前顯示提示信息，提醒學生對修改后的程序進行保存。

(3)編寫評測規則較繁瑣、效率低。評測規則采用Json格式，每一道題目的評測規則由多個子規則構成，每個子規則包含輸入數據、觸發的事件和輸出數據。目前評測規則由教師手工建立，繁瑣且效率低。下一步擬增加評測規則自動生成模塊，教師對題目進行測試時自動捕獲測試數據用以生成評測規則，提高題目維護效率。

5 總結

評測系統采用學生端分散式評測架構，充分利用機房中每一臺學生機的計算能力，分散了負載壓力，提高了系統可承載用戶規模，滿足了大規模上機考試的需要。在2018—2019學年第1學期，該系統僅使用一臺虛擬服務器(4個2.2GHz CPU、4G內存)承擔全校程序設計上機考試，共3場考試，第1場共800人，第2場和第3場每場均為1 500人，總計3 800人?？荚囘^程中，系統運行穩定，發題、評測和回收答案未出現任何異常，考試順利完成。系統運行至今，累計超過10 000名學生使用該系統進行程序設計的自測和考試，累計評測題目數百萬個。共承擔程序設計相關課程階段性測試和期末上機考試任務數十場次，系統效果好，利用率高，具有示范性和輻射性。