Xwindow 是非常巧妙的设计，很多时候它在概念上比其它窗口系统先进，以至于经过很多年它仍然是工作站上的工业标准。许多其它窗口系统的概念都是从 Xwindow 学来的。

Xwindow 可以说的东西太多了。下面只分辨一些容易混淆的概念，提出一些正确使用它的建议。

分辨 X server 和 X client

这是我被别人问了好多次的问题，我实在不想再对人说一遍了，所以写在这里偷个懒，嘿嘿。

很多熟悉 Internet 原理的人首次遇到 Xwindow 的这两个概念都会搞错。如果他从一台 Windows 机器上使用 Exceed 通过 XDMCP 登录到一台 Sun 服务器，他就说 Exceed 是客户端(client)，而 Sun 机器是服务器(server)。这就完全搞错了。

理解了 Xwindow 的工作原理，这个区别就会很明显。X server 不是指你登录的那台机器，而是指一个程序，它负责在某台机器上接受客户的要求，在屏幕上显示客户请求的图形，并且把消息(键盘，鼠标，窗口消息)通知客户程序。

比如上面例子里的 Exceed 就是一个 X server，它负责控制那台 Windows 机器上的显示(display)，Sun 机器上的程序，xterm, xxgdb, dtwm(CDE的窗口管理器)，……是客户程序。它们通常会使用 TCP 6000 号端口连接 Windows 机器，而Windows机器的 6000 号端口是由 Exceed bind 和 listen 的，怎么样，我们的 Internet 专家，Exceed 看起来是一个 server 吧 :)

比如，当你通过 telnet 启动 Sun 机器上的 xterm，就会在 Exceed 的屏幕上显示一个窗口。实际发生的事情是： xterm 请求连接 Windows 机器的 6000 号端口，与Exceed 跟 Exceed 连接，然后xterm请求得到资源，然后 xterm 请求在屏幕上显示一个窗口。

你在 xterm 的窗口里按下"A"键时，Exceed 会把这个事件通知 xterm 进程，然后 xterm 会发送数据报，请求 Exceed, “请在坐标(100,30)处显示一个字母A，然后在后面显示一个矩形作为光标。”，这样你的 xterm 窗口里就会多显示一个字母。

这下你理解了吗？不？那还是自己多用用，体会体会吧。

Xwindow 的网络透明性

刚才那个 Exceed 用户，他的客户程序不仅可以运行在那台 Sun 机器上，而且可以运行在网络里其它的机器上，或者在本机上。比如他有可能同时通过 telnet 登录到几台 Sun 工作站，几台 Linux PC，他可以在那些机器上都起动 xterm，在这台 Windows 机器上的 Exceed 上显示。如果它安装了 cygwin，他还可以启动本机上的 cygwin里 的 xterm，用同样的方式显示。

如果他使用 xrdb 在本机的 Exceed 设置了 xterm 的样式，比如背景 midnightblue, 前景 白色，字体 -*-adobe-courier-*，……，那么，Sun, Linux, cygwin 里的 xterm，虽然没有经过配置，但是它们知道：“这个 X server 要求我用这个背景色，这个前景色，这个字体……”，它们会在你的屏幕上显示同样风格的窗口。

使用鼠标选择一段字符，然后就可以在另外的程序里按鼠标中间，把字符粘贴过去。不论这个程序运行在哪里。

看看更大的一个图景：你的屏幕上有三台机器上的 xterm, 两台机器上的 gvim，两台机器上的 mozilla 在显示，而它们都受本机的 FVWM 操纵，它们之间可以随意进行拷贝粘贴…… 从这里你可以初步体会到 Xwindow 的网络透明性，它使你方便的操作很多机器。

什么是窗口管理器？

很多人不知道窗口管理器是怎么回事。他们认为 Gnome 和 KDE 是窗口管理器，认为窗口管理器就是能够提供一个工具条，能够配置桌面背景，能够设置很多菜单的东西。而其实，窗口管理器只是 Gnome 和 KDE 的一部分，它的主要功能是你平时根本没有注意，但是却非常重要的操作。窗口管理器的主要功能是：移动窗口，改变窗口大小，图标化（最小化）窗口，改变窗口层叠顺序……

通常的X客户程序不需要知道有人想移动它，它只知道乖乖听窗口管理器的话。如果没有窗口管理器运行，你的程序会一个堆一个，你没有办法操纵被盖在下面的程序，你只能使用最上面一个程序，而且你不能移动它，你不能改变它的大小。这样的系统根本不能用！

其实你的窗口上的标题，按钮，漂亮的边框，全都是窗口管理器提供的，而不是程序自己的，这样你用窗口管理器就能改变任何窗口的样式了。当你点击关闭窗口的那个按钮，你其实点击的是窗口管理器放在你的程序窗口上面的一个小窗口，发现它受到点击后，窗口管理器就会通知那个程序：“喂！有人想关掉你，你自己准备准备后事，然后退出吧。”

不同的机器在本机显示的窗口，由窗口管理器统一装饰和指挥。比如，窗口管理器决定： xterm 窗口上面都应该有四个按钮，一个在左边，点击它会显示窗口操作菜单，另外三个在右边，分别是最大化，最小化和关闭。窗口都使用 7pixel 厚的边框，窗口首次出现的时候首先在桌面上找一个空位置，如果找不到，就找一个能够最少的遮盖其它窗口的位置……

这些都是窗口管理器的职责。

Gnome 和 KDE 是什么？

有人把 Gnome 和 KDE 叫做窗口管理器，甚至还有人把它们叫做 Xwindow。经常看到有人问：“装哪种 Xwindow 好啊？Gnome 还是 KDE？” 其实你不安装 Gnome 和 KDE 也可以使用 Xwindow.

Gnome 和 KDE 是“桌面系统”，一种很多程序和函数库的集合。它们的设计目的是提供一致的方便的操作方式来满足普通用户的需要。它们不但包含窗口管理器，还有很多实用程序和应用程序，比如配置程序，工具条，编辑器，绘图工具…… 其实 Gnome 可以和很多窗口管理器合作，在历史上，Gnome 使用过的窗口管理器包括 englightenment, sawmill, sawfish, metacity。KDE 的窗口管理器叫做 kwin。

你也知道，设计整整一套应用程序：编辑器，绘图程序，浏览器，…… 是非常不容易的。所以它们肯定是不如专用的编辑器，绘图程序，浏览器的。不过要求不太高的用户也可以用它们。

用 Xwindow 做一个有趣的试验

现在我们来做一个试验来引起你对 Xwindow 的兴趣。

很多人离开了 xdm 就不知道怎样启动 "Xwindow" 了。其实 Xwindow 的启动方式很简单。

首先，启动你的 X server。在 Linux 下，你可以直接输入 "X&"，让一个 X server 在后台运行。这样，一个占据整个屏幕的布满斜纹的窗口（根窗口）就出现了。如果是 Exceed 或者 X-win32，你需要把屏幕设置为 "single window" 才能看到这个窗口。

接着，Linux 用户需要用 xauth 给你的 X server 设置一个密码，这样别人就不能非法连接你的 X server。你需要Ctrl-Alt-F1切换到tty1才能输入这个命令。Exceed 和 X-win32 的用户不需要这步。以下的例子只用 Linux 作为实例，其它系统的用户可以依葫芦画瓢。

xauth add :0 . `mcookie`

好了，现在你可以试试启动一个 xterm 到这个 X server 上：

xterm -display :0

按 Alt-F7 切换到 X，你看到了一个不受窗口管理器管理的 xterm。试试移动它呢？再切换到 tty1 启动另一个 xterm，两个 xterm 重合了吗？你怎样在第一个 xterm 里输入呢？这样用起来很痛苦吧？那么你可以在 xterm 里启动一个窗口管理器，比如 twm，直接运行 "twm&" 就行了。

你发现xterm的窗口都被加上了标题栏，按钮和边框，你现在可以移动它们了。试试把 twm 杀死，看看那些标题栏，按钮，边框是不是都消失了？你知道了窗口管理器的作用了吧。

现在告诉你怎样不用 XDMCP broadcast，绕过 CDE 的登陆界面，而使用 Sun 机器上的 CDE。其实你只需要把刚才那个例子里的 "twm" 换成 CDE 的窗口管理器 dtwm 就行了，或者启动 dtsession。它们一般在 /usr/dt/bin 下。Sun 还有另外一个窗口管理器叫做 OpenLook, 它在系统里的名字叫做 olwm，你自己找找吧。

现在如果你自己在 Sun 机器上装一个 FVWM，你知道怎么绕过 CDE 登录而启动 FVWM 了吧？你不需要成为 root 就可以使用你喜欢的FVWM了。

.Xdefaults 文件的作用

弄明白 X 的工作原理后，你就可以使用 .Xdefaults 来配置你的程序了。有人不理解 .Xdefaults 是用来干什么的，喜欢用 shell alias 出一些带有很多参数的命令，或者写一些 shell script，里面只有一行带有很多参数的程序调用，然后他说：“.Xdefaults 没用。”

其实 .Xdefaults 比起这些办法有很多好处。首先，几乎所有的 X 客户程序都可以从 .Xdefaults 文件得到配置信息，比如前景色，背景色，字体…… 这样你可以在同一个文件里配置所有 X 程序的样式，而不用写那么多 shell script。

另外，如果你用 xrdb .Xdefaults 把这些配置信息写入到根窗口的数据结构里，不是本地机器上的 X 程序也会遵守同样的样式。比如如果你的 .Xdefaults 里面有这些内容：

XTerm.background: midnightblue
XTerm.foreground: white

然后你用 xrdb ~/.Xdefaults，那么所有的 xterm 都会使用 midnightblue 作为背景色，使用白色显示字符。这些配置，用X术语叫资源(resource)。

有时候你会开很多 xterm 窗口在机器上，它们来自不同的远程机器，这时候如果它们都用同样的样色和字体，你就不容易分辨它们了。比如有一天，我在实验室的PC机上打开了很多 xterm，它们来自本机，实验室的 Sun 服务器，我宿舍的机器和数据库实验室一台 HP 服务器。在我走之前，想关闭本地的机器，我输入 “shutdown -h now” 在一个我自认是本地的 xterm 上，结果，等了一会儿，我回头看到机器没关掉，只是那个 xterm 停止了响应。我一拍脑袋：糟了，我把宿舍的机器给关掉了！

为了避免这种情况，你可以在不同的机器上编辑不同的 .Xdefaults，而不使用 xrdb 在根窗口导入这些配置。这样不同的机器上的 xterm 使用不同的颜色，你就不容易搞错了。

怎样更加深入的了解 Xwindow？

哎哟！我本来想写很多东西，后来发现要需要写的实在太多了。我没那么多时间，没办法，给参考书目吧，你们自己去看。

学习使用 Xwindow 不是学习使用 Gnome，KDE，…… 很多书籍教用户怎样使用 Gnome, KDE 的菜单，配置程序…… 结果到了最后用户还是没能知道 Xwindow 是怎么回事。用那些菜单谁不会啊？真是浪费大家时间。

学习 Xwindow，其实最好的一个办法是看看 Xlib 编程的书籍，你可以在图书馆找到这样的书，我推荐 O'reily 的那本 Xlib 程序设计书（我忘了名字了），虽然它很老，但是那上面讲解的 Xwindow 的工作原理一直都没有变过。

如果你不会编程序，你可以不看编程的部分而得到很多深入的概念上的认识，比如窗口属性，字体，颜色，…… 这些东西在你使用 Xwindow 时会有很大帮助。如果你真的要编写 Xlib 程序，这本书就过时了一点，你最好到 www.x.org 去免费下载最新的 Xlib 手册来看。

每个人都能使用 UTF-8

  普遍性是选择 UTF-8 的第一个也是最有说服力的理由。它可以处理目前世界上使用的每一种文字。虽然还有少数空白，但是越来越不明显，被逐渐填平了。没有纳入的文字通常也没有其他任何字符集实现过，即使有也不能在 XML 中使用。最好的情况下，这些文字通过字体借用转嫁到 Latin-1 这样的单字节字符集。对这类稀有文字的真正支持可能最先来自 Unicode，而且可能只有 Unicode 支持它们。

  但这仅仅是使用 Unicode 的一个理由。为什么选择 UTF-8 而不是 UTF-16 或者其他 Unicode 编码呢？最直接的原因之一是广泛的工具支持。基本上所有可能用于 XML 的主要编辑器都能处理 UTF-8，包括 JEdit、BBEdit、Eclipse、emacs 甚至 Notepad。在 XML 和非 XML 工具中，没有其他 Unicode 编码拥有这样广泛的工具支持。

  对于其中一些编辑器，如 BBEdit 和 Eclipse，UTF-8 并不是默认的字符集。现在有必要改变默认设置了，所有工具出厂的时候都应该选择 UTF-8 作为默认编码。除非这样，否则当文件跨越国界、平台和语言传递的时候，我们就会陷入不能互操作的泥潭。不过在所有程序都把 UTF-8 作为默认编码之前，自己修改默认设置也很容易。比如在 Eclipse 中，图 1 所示的“General/Editors”首选项面板允许指定所有文件都使用 UTF-8。您可能注意到 Eclipse 希望默认值为 MacRoman，但是如果这样，当把文件传递给使用 Microsoft® Windows® 的程序员或者美国和西欧之外的计算机时将无法编译。

  当然，要让 UTF-8 其作用，开发人员交换的文件也都必须使用 UTF-8，但这不成问题。与 MacRoman 不同，UTF-8 不局限于少数文字或者个别平台。任何人都能用 UTF-8。而 MacRoman、Latin-1、SJIS 和其他各种遗留的国家字符集都不能做到。

  UTF-8 在不支持多字节数据的工具中也能正常工作。其他 Unicode 格式如 UTF-16 往往包含很多零字节。很多工具将这些字节解释为文件尾或者其他某种特殊的分界符，造成不希望的、未曾预料到的、常常是不愉快的结果。比方说，如果 UTF-16 数据原样加载到 C 字符串中，字符串可能从第一个 ASCII 字符的第二个字节截断。UTF-8 文件仅在确实表示 null 的地方包含 null。当然，不应该选择这么天真的工具来处理 XML 文档。但是，遗留系统中文档常常在奇怪的地方结束，没有人真正认识到或者理解那些字符序列仅仅是旧瓶装新酒。与 UTF-16 或其他 Unicode 编码相比，对于不支持 Unicode 和 XML 的系统，UTF-8 更不容易造成问题。

专家们的说法

  XML 是第一个全面支持 UTF-8 的重要标准，但这仅仅是开始。各标准组织都在逐渐推荐 UTF-8。比如，包含非 ASCII 字符的 URL 是长期困扰 Web 的一个问题。在 PC 机上工作的包含非 ASCII 字符的 URL 不能用于 Mac，反之亦然。万维网联盟（W3C）和 Internet 工程任务组（IETF）最近同意所有 URL 都必须采用 UTF-8 编码而不能是其他编码，从而解决了这一问题。

  W3C 和 IETF 对最先、最后还是偶尔使用 UTF-8 变得越来越强硬。The W3C Character Model for the World Wide Web 1.0: Fundamentals 指出，“如果必须选择一种字符编码，则必须是 UTF-8、UTF-16 或 UTF-32。US-ASCII 对 UTF-8 向上兼容（US-ASCII 字符串也是 UTF-8 字符串，参见 [RFC 3629]），因此如果需要与 US-ASCII 保持兼容，UTF-8 非常合适。”事实上，与 US-ASCII 兼容如此重要，几乎是必需的。W3C 明智地解释说，“其他情况下，如对于 API，UTF-16 或 UTF-32 可能更合适。选择一种编码的原因可能包括内部处理的效率以及与其他进程的互操作性。”

  我同意内部处理的效率这条理由。比如，Java™ 语言中字符串的内部表示采用 UTF-16，因此对字符串的索引更快。不过，Java 代码永远不会把这种内部表示向与它交换数据的程序公开。相反，对于外部数据交换，要使用 java.io.Writer，明确地指定字符集。选择的时候，强烈推荐 UTF-8。

  IETF 甚至更加明确。The IETF Charset Policy [RFC 2277] 指出，在没有不确定性的语言中：

    协议必须能够使用 UTF-8 字符集，它由 ISO 10646 编码集和 UTF-8 字符编码方法组成，全文参见 [10646] Annex R（修正版 2 中发布）。 此外，协议可以规定如何使用其他 ISO 10646 字符集和字符编码方案，如 UTF-16，但是不能使用 UTF-8 是对本策略的违反，这种违反在进入或者提升到标准跟踪过程时，需要经过变更程序（[BCP9] 第 9 节），并在协议规范文档中提出明确、可靠的理由。

  现有的协议或者从已有数据存储转移数据的协议，可能需要支持其他数据集，甚至使用 UTF-8 之外的默认编码。这是允许的，但是必须能够支持 UTF-8。

  要点：今后一段时间，对遗留协议和文件的支持可能要求接受 UTF-8 之外的字符集和编码，但是如果必须如此我会非常小心。每种新的协议、应用程序和文档都应该使用 UTF-8。


中文、日文和韩文
  一种常见的误解是认为 UTF-8 是一种压缩格式。其实并非如此。与其他 Unicode 编码特别是 UTF-16 相比，在 UTF-8 中 ASCII 字符占用的空间只有一半。不过一些字符的 UTF-8 编码占用的空间要多出 50%，特别是中文、日文和韩文（CJK）这样的象形文字。

  但即使用 UTF-8 编码 CJK XML，实际的大小可能也比 UTF-16 小。比如，中文的 XML 文档包含大量 ASCII 字符，如 <、>、&、=、"、' 和空格。这些字符的 UTF-8 编码要比 UTF-16 小。具体的压缩/膨胀因素因文档而异，但不论哪种情况，差别都不可能很明显。

  最后，值得一提的是中文和日文这类象形文字，与 Latin、Cyrillic 这类字母文字相比，用字往往更少。由于字符的绝对量很大，要求每个字符使用三个或更多字节才能完全地表达这些文字，就是说，与英文或俄文相比，同样的词语或句子，这些语言可以用更少的字表达。比如，“tree”在日文中用“木”表示（非常像一棵树）。 用 UTF-8 表示需要三个字节，而英文单词“tree”包含四个字母，需要四个字节。日文中的“grove（小树林）”是“林”（两棵树靠在一起）。用 UTF-8 编码需要三个字节，而英文单词“grove”有五个字母，需要五个字节。日文中的“森”（三棵树）仍然需要三个字节。而对应的英文字“forest”需要六个字节。 
 
  如果确实需要压缩，则使用 zip 或 gzip。压缩后，UTF-8 和 UTF-16 的大小差不多，不论原始大小相差多少。无论哪种编码，原始大小越大，压缩算法去掉的冗余就更多。

健壮性

  真正的优势在于设计，与以前和以后设计的其他任何文本编码相比，UTF-8 是一种更健壮、更容易解释的格式。首先，与 UTF-16 相比，UTF-8 没有 endianness 问题。UTF-8 用 Big-endian 和 little-endian 来表示都是一样的，因为 UTF-8 是按 8 位字节而不是 16 位字定义的。UTF-8 没有字节序的不确定性问题，后者必须通过字节序标志或其他试探手段来解决。

  UTF-8 更重要的一个特征是无状态性。UTF-8 流或序列中的每个字节都是明确的。在 UTF-8 中总是可以知道所处的位置，就是说给定一个字节，马上就能确定它是一个单字节字符、双字节字符的第一个字节、双字节字符的第二个字节，或者三字节/四字节字符的第二个、第三个或第四个字节（当然还有其他可能性，但明白这个意思就行）。在 UTF-16 中，就不能确定字节“0x41”是不是字母“A”。有时候是，有时候不是。必须记录足够的状态才能确定在流中的位置。如果损失了一个字节，此后的数据就全部无法用了。在 UTF-8 中，丢失或者破坏的字节很容易确定，也不会影响其他数据。

  UTF-8 并非是万能的。需要随机访问文档特定位置的应用程序使用 UCS2 或 UTF-32 这类固定宽度的编码可能操作起来更快。（如果考虑到替换对，UTF-16 是一种变长字符编码。）但是，XML 处理不属于这类应用程序。XML 规范特别要求解析器从 XML 文档的第一个字节开始解析直到最后一个字节，所有现有的解析器都是这样操作的。更快的随机访问对 XML 处理没有什么帮助，虽然对于数据库或其他系统使用不同的编码这可能是一个很好的理由，但不适用于 XML。


结束语

  在越来越国际化的世界中，语言和政治边界日渐模糊，依赖于地域的字符集不再适用了。Unicode 是惟一能够跨越很多地域互操作的字符集。UTF-8 是最好的 Unicode 编码：

• 广泛的工具支持，包括与遗留 ASCII 系统最佳的兼容性。
• 处理起来简单而高效。
• 抗讹误。
• 平台独立。

该停止关于字符集和编码的争论了，选择 UTF-8，结束纷争。

1．1、测试脚本语言的定义

   测试脚本语言（test scripting language）是脚本语言的一种，准确地讲是脚本语言在测试领域地一个分支，是自动化软件测试设计的基础。要理解测试脚本语言就不能不对脚本语言进行一些了解。

   脚本语言（scripting language）就是在执行时以解释(interpreting) 为主的编程语言，比如常见的perl,python,php,tcl,guile,ruby以及UNIX系统的各种shell都是脚本语言，它的执行效率比不上编译后再执行的程序，如以C, C++, Java, Pascal等语言编写的程序。

   脚本语言应用到测试领域就可以称之为测试脚本语言，以上提到的脚本语言都可以作为测试脚本语言来使用，特别是tcl语言更是被业界称为事实上的测试脚本语言标准。随着软件测试的发展，各种测试工具也相继推出，为了保护知识产权或者说是保护商业秘密，这些商业化的软件大多使用自己的测试脚本语言，比如MI的TSL语言等。

   测试脚本技术大致可以分为以下几类：

l         线性脚本：是录制手工执行的测试实力得到的脚本。这种脚本包括所有的击键、功能键、箭头、控制测试软件的控制键及输入数据的数字键。

l         结构化脚本：类似于结构化程序设计，结构化脚本中含有控制脚本设计的指令。这些指令或为控制结构或为调用结构。

l         共享脚本：脚本可能被多个测试事例使用。

l         数据驱动脚本技术：将测试输入存储在独立的文件中，而不是存储在脚本中。

l         关键字驱动脚本：较复杂的数据驱动技术的逻辑扩展。

1．2、脚本语言的发展历史

 这里我们以tcl语言的发展来回顾一下脚本语言的发展历史，商业化的测试脚本语言一般就是随着商业测试软件的发展来发展的，在此不作详细介绍。

  Tcl/Tk 的发明人 John Ousterhout 教授在八十年代初是伯克利大学的教授。在其教学过程中，他发现在集成电路 CAD 设计中，很多时间是花在编程建立测试环境上。并且，环境一旦发生了变化，就要重新修改代码以适应新环境。这种费力而又低效的方法，迫使 Ousterhout 教授力图寻找一种新的编程语言，它即要有好的代码可重用性，又要简单易学，这样就促成了 Tcl (Tool Command Language) 语言的产生。

  Tcl 最初的构想是希望把编程按照基于组件的方法 (component approach)，即与其为单个的应用程序编写成百上千行的程序代码，不如寻找一种方法将程序分割成一个个小的, 具备一定“完整”功能的，可重复使用的组件。这些小的组件小到可以基本满足一些独立的应用程序的需求，其它部分可在这些小的组件功能基础上生成。不同的组件有不同的功能，用于不同的目的，并可为其它的应用程序所利用。当然, 这种语言还要有良好的扩展性, 以便用户为其增添新的功能模块。最后，需要用一种强的，灵活的“胶水”把这些组件“粘”合在一起, 使各个组件之间可互相“通信”，协同工作。程序设计有如拼图游戏一样，这种设计思想与后来的 Java 不谋而合。终于在 1988 年的春天, 这种强大灵活的胶水 - Tcl 语言被发明出来了。

  到了80年代图形用户界面逐渐流行的时候，Ousterhout 教授要想使基于组件的设计能够实现，需要有一个强大的有弹性的控件整合工具。这些想法在一开始考虑做Tcl的时候就产生了，Ousterhout 教授觉得像Tcl这样的嵌入式命令语言作为脚本语言对整合部件会很有用。Ousterhout 教授决定创建一些作为Tcl扩展的GUI部件并且使用Tcl来把这些部件整合到图形用户界面中，借此实践一下这个理论。这个扩展就成为了Tk。

  Tcl在创始初期都是以开放源码的方式发布的，到了90年代初，Tcl语言得到了广泛的发展，并得到了大型厂商的支持，如SUN公司，并逐步形成了tcl社区，这样就逐渐有了商业赢利产品的开发，同时Tcl将会继续开发开放源代码的产品，至此TCL语言进入了两种不同的发展轨道，同时也促进了tcl语言的发展和应用。

1.3、脚本语言的特点

脚本语言的特点，通过下面tcl/tk与C++和java的比较就可见一斑。

C++，Tcl/Tk 和 Java 的性能比较表

1．4、商业测试脚本语言简介

  商业测试软件

1．5、脚本语言的基本工作原理

脚本语言的基本工作原理可以用下面的图示来说明

脚本解释器是脚本语言工作的核心，所有具体指令或是函数的执行都由它来完成，扩展项实现了与其它语言的接口，使脚本语言运行C/C++,java等函数成为可能；同时在用户具体应用中可以定义命令和函数，应用更加灵活；作为解释器它也提供了基本的内建指令或是函数，不同厂商、版本的解释器提供的内建命令（函数）可能不同。