分类: LINUX
2008-07-04 10:02:59
2001 年 3 月 01 日
功能测试是软件开发的一个关键部分 -- 而已经装入 Linux 的 Bash 可以帮您轻而易举地完成功能测试。在本文中,Angel Rivera 将说明如何运用 Bash shell 脚本通过行命令来执行 Linux 应用程序的功能测试。由于此脚本依赖于命令行的返回码,因而您不能将这种方法运用于 GUI 应用程序
功能测试是开发周期的一个阶段,在这个阶段中将测试软件应用程序以确保软件的函数如预期的那样,同时能正确处理代码中错误。此项工作通常在单个模块的单元测试结束之后,在负载/重压条件下整个产品的系统测试之前进行的。
市场上有许多测试工具提供了有助于功能测试的功能。然而,首先要获取它们,然后再安装、配置,这将占用您宝贵的时间和精力。Bash 可以帮您免去这些烦琐的事从而可以加快测试的进程。
使用 Bash shell 脚本进行功能测试的优点在于:
如果已有现成的 Korn shell 脚本,而想要将它们移植到 Bash,就需要考虑下列情况:
#!/usr/bin/ksh
#!/bin/bash
|
这些基本的步骤和建议适用于许多在 Linux 上运行的客户机/服务器应用程序。
下面详细讲述了每一条建议以及用于说明问题的脚本。若要下载此脚本,请参阅本文后面的 参考资料部分。
1. 记录运行脚本的先决条件和主要步骤
记录,尤其是以有自述标题的单个文件(例如
"README-testing.txt")记录功能测试的主要想法是很重要的,包括,如先决条件、服务器和客户机的设置、脚本遵循的整个(或详细的)步骤、如何检查脚本的成功/失败、如何执行清除和重新启动测试。
2. 将操作分成若干个逻辑组
如果仅仅执行数量非常少的操作,可以将它们全部放在一个简单的 shell
脚本中。
但是,如果需要执行一些数量很多的操作,那最好是将它们分成若干个逻辑集合,例如将一些服务器操作放在一个文件而将客户机操作放在在另一个文件中。通过这种方法,划分适当的颗粒度来执行测试和维护测试。
3. 基于一般方案制定执行步骤
一旦决定对操作进行分组,需要根据一般方案考虑执行操作的步骤。此想法是模拟实际生活中最终用户的情形。作为一个总体原则,只需集中测试
80% 最常调用函数的 20% 用法即可。
例如,假设应用程序要求 3 个测试组以某个特定的顺序排列。每个测试组可以放在一个带有自我描述文件名(如果可能)的文件中,并用号码来帮助识别每个文件的顺序,例如:
1. fvt-setup-1: To perform initial setup. |
4. 在每个 shell 脚本中提供注释和说明
在每个 shell
脚本的头文件中提供相关的注释和说明是一个良好的编码习惯。这样的话,当另一个测试者运行该脚本时,测试者就能清楚地了解每个脚本中测试的范围、所有先决条件和警告。
下面是一个 Bash 脚本 "test-bucket-1" 的示例 。
#!/bin/bash |
5. 做一个初始备份以创建基准线
您可能需要多次执行功能测试。第一次运行它时,也许会找到脚本或进程中的一些错误。因而,为了避免因从头重新创建服务器环境而浪费大量时间
-- 特别是如果涉及到数据库 -- 您在测试之前或许想做个备份。
在运行完功能测试之后,就可以从备份中恢复服务器了,同时也为下一轮测试做好了准备。
6. 检查输入参数和环境变量
最好校验一下输入参数,并检查环境变量是否设置正确。如果有问题,显示问题的原因及其修复方法,然后终止脚本。
当测试者准备运行脚本,而此时如果没有正确设置脚本所调用的环境变量,但由于发现及时,终止了脚本,那测试者会相当感谢。没有人喜欢等待脚本执行了很久却发现没有正确设置变量。
# -------------------------------------------- |
关于此脚本的说明如下:
CALLER=`basename $0`
可以得到正在运行的脚本名称。这样的话,无须在脚本中硬编码脚本名称。因此当复制脚本时,采用新派生的脚本可以减少工作量。
TEMP=`getopt hs $*`
用于得到输入变量(例如 -h 代表帮助,-s 代表安静模式)。
[ -z "$X" ]
和
echo "The environment
variable X is not set."
以及
usage
都是用于检测字符串是否为空 (-z),如果为空,随后就执行 echo
语句以显示未设置字符串并调用下面要讨论的 "usage" 函数。
7. 尝试提供“usage”反馈
脚本中使用 "usage" 语句是个好主意,它用来说明如何使用脚本。
# ---------------------------- |
调用脚本时,使用“-h”标志可以调用 "usage"
语句,如下所示:
./test-bucket-1 -h
8. 尝试使用“安静”的运行模式
您或许想让脚本有两种运行模式:
下列摘录说明了在安静模式下运用所调用标志 "-s" 来运行脚本:
# ------------------------------------------------- |
9. 当出现错误时,提供一个函数终止脚本
遇到严重错误时,提供一个中心函数以终止运行的脚本不失为一个好主意。此函数还可提供附加的说明,用于指导在此情况下应做些什么:
# ---------------------------------- |
10. 如有可能,提供可以执行简单任务的函数
例如,不使用许多很长的行命令,如:
# -------------------------------------------------- |
……而是创建一个如下所示的函数,此函数也可以处理返回码,如果有必要,还可以增加错误计数器:
CreateAccess() |
……然后,以易读和易扩展的方式调用此函数:
# ------------------------------------------- |
11. 当显示正在生成的输出时,捕获每个脚本的输出
如果脚本不能自动地将输出发送到文件的话,可以利用 Bash shell
的一些函数来捕获所执行脚本的输出,如:
./test-bucket-1 -s 2>&1 | tee test-bucket-1.out |
让我们来分析上面的命令:
使用 "2>&1" 将标准错误重定向到标准输出。字符串 "2>&1" 表明任何错误都应送到标准输出,即 UNIX/Linux 下 2 的文件标识代表标准错误,而 1 的文件标识代表标准输出。如果不用此字符串,那么所捕捉到的仅仅是正确的信息,错误信息会被忽略。
UNIX/Linux 进程和简单的管道概念很相似。既然这样,可以做一个管道将期望脚本的输出作为管道的输入。下一个要决定的是如何处理管道所输出的内容。在这种情况下,我们会将它捕获到输出文件中,在此示例中将之称为 "test-bucket-1.out"。
但是,除了要捕获到输出结果外,我们还想监视脚本运行时产生的输出。为达到此目的,我们连接允许两件事同时进行的 "tee" (T- 形管道):将输出结果放在文件中同时将输出结果显示在屏幕上。 其管道类似于:
process --> T ---> output file |
如果
只 想捕获输出结果而不想在屏幕上看到输出结果,那可以忽略多余的管道:
./test-bucket-1 -s 2>&1 >
test-bucket-1.out
假若这样,相类似的管道如下:
process --> output file |
12. 在每个脚本内,捕获每个行命令所返回码
决定功能测试成功还是失败的一种方法是计算已失败行命令的数量,即返回码不是
0。变量 "$?"
提供最近所调用命令的返回码;在下面的示例中,它提供了执行 "ls"
命令的返回码。
# ------------------------------------------- |
13. 记录失败事务的次数
在功能测试中决定其成功或失败的一个方法是计算返回值不是 0
的行命令数量。但是,从我个人的经验而言,我习惯于在我的 Bash shell
脚本中仅使用字符串而不是整数。在我所参考的手册中没有清楚地说明如何使用整数,这就是我为什么想在此就关于如何使用整数和计算错误(行命令失败)数量的方面多展开讲的原因:
首先,需要按如下方式对计数器变量进行初始化:
let "errorCounter = 0" |
然后,发出行命令并使用 $? 变量捕获返回码。如果返回码不是 0,那么计数器增加 1(见蓝色粗体语句):
ListFile() |
顺便说一下,与其它变量一样,可以使用 "echo" 显示整数变量。
14. 在输出文件中,为了容易标识,突出显示错误消息
当遇到错误(或失败的事务)时,除了错误计数器的数量会增加外,最好标识出此处有错。较理想的做法是,字符串有一个如
ERROR
或与之相似的子串(见蓝色粗体的语句),这个子串允许测试者很快地在输出文件中查找到错误。此输出文件可能很大,而且它对于迅速找到错误非常重要。
ListFile() |
15. 如有可能,“实时”生成文件
在某些情况下,有必要处理应用程序使用的文件。可以使用现有文件,也可以在脚本中添加语句来创建文件。如果要使用的文件很长,那最好将其作为独立的实体。如果文件很小而且内容简单或不相关(重要的一点是文本文件而不考虑它的内容),那就可以决定“实时”创建这些临时文件。
下面几行代码显示如何“实时”创建临时文件:
cd $HOME/fvt |
第一个 echo 语句使用单个的 > 强行创建新文件。第二个 echo 语句使用两个 >> 将数据附加到现有文件的后面。顺便说一下,如果该文件不存在,那么会创建一个文件。
16. 在执行脚本的过程中提供反馈
最好在脚本中包含 echo
语句以表明它执行的逻辑进展状况。可以添加一些能迅速表明输出目的的语句。
如果脚本要花费一些时间执行,那或许应在执行脚本的开始和结束的地方打印时间。这样可以计算出所花费的时间。
在脚本样本中,一些提供进展说明的 echo 语句如下所示:
# -------------------------------------------- |
17. 提供脚本执行的摘要
如果正在计算错误或失败事务的次数,那最好表明是否有错误。此方法使得测试者在看到输出文件的最后能迅速地辨认出是否存在错误。
在下面的脚本示例中,代码语句提供了上述脚本的执行摘要:
# -------------- |
18. 提供一个容易解释的输出文件
在脚本生成的实际输出中提供一些关键信息是非常有用的。那样,测试者就可以很容易地确定正在查看的文件是否与自己所做的相关以及它是否是当前产生的。附加
的时间戳记对于是否是当前状态是很重要的。摘要报告对于确定是否有错误也是很有帮助的;如果有错误,那么测试者就必须搜索指定的关键字,例如
ERROR,并确认出个别失败的事务。
以下是一段输出文件样本的片段:
Subject: CMVC 2.3.1, FVT testing, Common, Part 1 |
当遇到错误时输出文件最后部分的示例如下所示:
ERROR found in Report -view DefectView |
19. 如有可能,提供清除脚本及返回基准线的方法
测试脚本可以生成临时文件;假若这样,最好能让脚本删除所有临时文件。这就会避免由于测试者也许没有删除所有临时文件而引起的错误,更糟糕的是将所需要的文件当作临时文件而删除了。
|
本节描述如何运用 Bash shell 脚本进行功能测试。假设您已经执行了在前面部分中所述步骤。
设置必要的环境变量
根据需要在 .profile
中或手工指定下列环境变量。该变量用于说明在脚本中如何处理,所需环境变量的验证必须在脚本执行前定义。
export TEST_VAR=1 |
将 Bash shell 脚本复制到正确的目录下
Bash shell
脚本和相关文件需要复制到要进行功能测试的用户标识的目录结构下。
mkdir fvt
unzip trfvtbash.zip
chmod u+x
*
mv test-bucket-1.bash
test-bucket-1
运行脚本
执行下列步骤以运行脚本:
cd $HOME/fvt
./test-bucket-1 -s 2>&1 |
tee test-bucket-1.out
如何解压该文件:
为了查看压缩文件中的内容(实际上并没有解包和解压缩该文件),用:
unzip -l trfvtbash.zip 命令。
为了解包和解压缩这个压缩文件,用:
unzip trfvtbash.zip 命令。
Angel Rivera 是一位 VisualAge TeamConnection 技术支持小组的顾问软件工程师,他目前是该小组的负责人。他拥有 Austin 德克萨斯大学电子工程专业的硕士学位和墨西哥 Instituto Tecnologico y de Estudios Superiores de Monterrey 电子系统工程的学士学位。他于 1989 年进入 IBM。可以通过 与他联系。 在写本文的过程中,Angel 感谢 Lee Perlov 在 WebSphere 方面的技术支持。 |