通用的嵌入式自動化測試框架

　　目前通用的嵌入式自動化測試框架，四層結構：

　　解釋幾個術語：

　　1. 測試包(test suite)：只要點一個按鈕就可以完成一次測試必須用到的東西。

　　2. 數據驅動(Data driven)：測試數據與測試執行分離，測試數據起到驅動測試執行的作用。

　　3. 框架(Framework)：可重用模塊和設計的一個庫。

　　框圖如下，

　　測試用例：

　　測試用例存放在一個數據庫或者是表格中，當要增加一個用例時，只需要在數據庫或表格中添加，測試包不需要做任何修改。

　　測試動作：

　　可以理解為測試動作關鍵字，關鍵字的技術實現比較復雜。對于普通的測試包使用者，關鍵字的具體技術實現是不可見的，他們只需要知道哪些測試關鍵字可用。他們通過選擇正確的關鍵字和正確的腳本來實現測試。如圖1所示，如果被測系統的功能沒變化，但是技術實現發生變化了，例如接口變了。對于測試包的使用者來說，他們依然可以使用以前的測試數據，這個變化不會影響到他們。除非是系統功能變化了，他們才需要使用其他的關鍵字和腳本來測試這個新功能。

　　The technical implementation of the test actions is stored in a framework hidden from the user of the test suite

　　圖1:測試動作的技術在框架中實現，測試包的用戶不可見

　　如下圖2畫出了整個測試架構藍圖：測試包中包含三個部分，輸入部分，輸入測試場景和測試腳本。輸出部分，輸出測試結果報告和日志。中間的部分是測試包的核心部隊，是由這部分實現點擊一個按鈕測試就自動進行，整個測試場景的測試從開始到完成不需要有人交互。

　　下面分步驟來描述下面的藍圖，

　　圖2:Blueprint of a test suite測試包藍圖

　　1. 準備測試數據

　　測試數據存放在數據庫或一個文件中。包括測試場景描述和測試腳本，測試場景指示哪些測試腳本需要執行，有些還指定了什么時候開始執行哪段腳本。如Table 1所示的測試場景信息：

 

Test scenario 1: testing address book of electronic organizer
Test script. ID	Name test script	Schedule time	Comments
Script_1	Script_Address_1	12:01 2001-03-03	Only adding address
Script_2	Script_Address_2	12:03 2001-03-03	Only deleting address

　　Table 1 Layout of the test scenario

　　有好幾種方法可以檢查某個特定動作的結果。

　　執行動作中包含了檢查。測試腳本中定義了動作開始時的輸入，同時也定義了預期的輸出。最后的動作是比較實際結果是否與預期結果一致。

　　動作本身就是檢查。例如View_address可以用作查找一個地址，也可以作為檢查這個地址是否在地址薄中存在。

　　檢查被定義成了一個獨立的動作。動作用作檢查被測系統的一個特定狀態或特定輸出。

　　2. 啟動模塊

　　在測試包啟動測試時，測試環境已經初始化。所有的參數已經初始化了，模塊已經加載了，如果必要，與被測系統之間的連接已經建立起來了。下一步是初始化系統。啟動模塊包含打開和關閉日志報告，也可以正常關閉測試。

　　3. Planner模塊

　　該模塊讀取測試場景信息。測試場景中指定了哪些測試腳本需要執行或者有些指定了在某個時間段執行。如果沒有指定時間段，則按腳本列出的順序執行。

　　Planner模塊和測試場景結合起來就是整個測試包的驅動。當所有列出的測試腳本執行完成后，測試包會產生它的日志報告和結果報告然后停止。

　　Planner(test_scenario){

　　open_file (test_scenario);

　　while NOT_END_OF_FILE

　　{

　　read_line (test_scenario, line);

　　split (line, scr, ",");

　　if scr[1] !=""

　　Reader (scr[2]);

　　}

　　close_file (test_scenario);

　　return;

　　}

　　4. Reader模塊

　　Reader模塊讀取測試腳本，由Planner模塊傳遞測試腳本的名字給Reader模塊。Reader模塊執行完所有的腳本之后交回控制權給Planner模塊。

　　當腳本執行時有非預期的結果Reader會觸發”error recovery”。

　　Reader(test_script)

　　{

　　last_testcase = "";

　　error = NULL;

　　open_file (test_script);

　　while NOT_END_OF_FILE

　　{

　　if error == 1

　　{

　　while read_line (test_script, line) !=NOT_END_OF_FILE

　　{

　　split (line, case, ",");

　　if case[1] != last_testcase{

　　last_testcase = case[1]);

　　error = NULL;

　　break;

　　}

　　}

　　}

　　else {

　　read_line (test_script, line);

　　split (line, case, ",");

　　last_testcase = case[1]);

　　}

　　if case != ""{

　　if Translator(case) == ERROR

　　Write_to_status_report ();

　　Error_recovery ();

　　error = 1;

　　}

　　}

　　close_file (test_script);

　　return;

　　}

　　5. Translator

　　Translator把測試腳本中的動作與測試包中相應動作實現函數的庫連接起來。當執行完動作函數后，Translator交回控制權并返回執行結果。

　　Translator (action)

　　{

　　switch (tolower((action[2])

　　{

　　case "action1":

　　return (Action1(action));

　　break;

　　case "action2":

　　return (Action2(action));

　　break;

　　default: Write_to_status_report ("Test action does

　　not exist!");

　　return -1;

　　break;

　　}

　　}

　　6. 測試動作(Test actions)

　　測試動作實現了系統的具體功能，它包含了一套標準元素(見表2)，系統的具體功能，可以發展成為涵蓋基本功能，以及完整的過程或總體功能。一個”高層次”的動作覆蓋了完整的過程，它可以由實現基本功能的”低層次”動作構成。”低層次”動作使得測試包靈活，”高層次”動作讓測試包容易實現。

 

system_specific_function() { synchr_func() <synchr_func> <check_func> <common_func> <tool_func> return return_value }

　　表2:系統具體功能元素，<>中的函數是必須的

　　7. 初始化Initialization

　　初始化測試包

　　測試包啟動時執行初始化測試包，它負責設置好所有的環境變量。如測試包和測試腳本的目錄變量設置，日志和結果報告的目錄設置。所有相關模塊已經加載。

　　系統啟動并設置初始狀態

　　被測系統啟動，這步可以是測試包自動實現也可以手動實現。系統的初始狀態完成后，這樣腳本可以正常執行的環境已經準備好。

　　初始狀態恢復

　　在整個自動測試期間，系統不會總是處于預期的狀態。當系統處于非正常狀態時，可以通過恢復操作使下一個腳本可以正常執行。有時系統可能需要系統重啟。

　　8.

 

　　f3

　　f4

 

原文轉自：http://www.kjueaiud.com