目前通用的嵌入式自动化测试框架，四层结构：

解释几个术语：

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. IDName test scriptSchedule timeComments

Script_1Script_Address_112:01 2001-03-03Only adding address

Script_2Script_Address_212:03 2001-03-03Only deleting address

Table 1Layout 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()

return return_value

}

表2:系统具体功能元素，<>中的函数是必须的

7.初始化Initialization初始化测试包测试包启动时执行初始化测试包，它负责设置好所有的环境变量。如测试包和测试脚本的目录变量设置，日志和结果报告的目录设置。所有相关模块已经加载。系统启动并设置初始状态被测系统启动，这步可以是测试包自动实现也可以手动实现。系统的初始状态完成后，这样脚本可以正常执行的环境已经准备好。

初始状态恢复在整个自动测试期间，系统不会总是处于预期的状态。当系统处于非正常状态时，可以通过恢复操作使下一个脚本可以正常执行。有时系统可能需要系统重启。

8.