A. 浅学Jmeter性能测试：使用代理服务器录制脚本
右上角设置->高级->系统->打开您计算机的代理设置->连接->局域网设置->勾选“为LAN使用代理服务器”->地址输入：127.0.0.1->端口输入：8888->勾选‘’对于本地地址不使用代理服务器->确定。
PS：设置代理时要关掉抓包工具，因为它也是一个代理服务器。
注：jmeter自带代理服务器
1、设置代理
启动Jmeter->测试计划->右键添加“非测试元件”->选择HTTP代理服务器->设置端口：8888->Test Plan Creation-> 目标控制器选择“后面创建的自定义线程组”。
2、创建线程组存放脚本
测试计划->右键添加“Threads”->选择“线程组”-> 自定义线程组名称 ->保存。
3、提前设置过滤
通常会碰到录制完脚本后查看Jmeter有多余的请求，我们可提前设置过滤去掉不需要的请求。
在HTTP代理服务器页面，点击"Requests Filtering"，找到“排除模式”后添加并输入多个正则表达式 ，每行一个（.*\.php.* 或 .*\.js.* 或 .*\.png.* 或 .*\.gif.* 或 .*\.txt.* ）。设置完成后，再重新启动代理录制脚本即可。
PS：话说之前学到的正则表达式终于用上了~
4、录制脚本
在jmeter代理服务器里“启动”服务器->弹出窗口点击ok->操作浏览器里目标网页->结束录制需要的模块后，点击jmeter“停止”，在Jmeter里查看脚本。
5、优化脚本
录制完成后，可能还存在一些漏网之鱼，可根据实际需要增删请求或配置。
PS:删除了多余的请求；配置了监听器-查看结果树后，有些请求失败了，添加了cookie管理器后全都请求成功。
注：B/S录制完脚本一定要添加cookie管理器
6、浏览器增加证书（如果有需求访问Https，无可省略）
右上角设置->高级->隐私设置与安全性->证书->受信任的证书颁发机构->导入->在jmeter文件夹 bin 目录下 选择证书（只要开启过代理服务器，都会生成证书）。
录制完成后，一定要记得关闭代理服务器，否则上不了网。问题来了，如何取消代理服务器的设置呢？
右上角设置->高级->系统->打开您计算机的代理设置->连接->局域网设置->取消勾选“为LAN使用代理服务器”->确定。
B. APP怎么检测脚本
APP检测主要从以下几个方面展开：
APP性能测试和监控：极限测试：在各种边界压力情况下（如：电池、存储、网速等），验证App是否能正确响应。响应能力测试：测试App中的各类操作是否满足用户响应时间要求压力测试：反复/长期操作下，系统资源是否占用异常；性能评估：评估典型用户应用场景下，系统资源的使用情况。Benchmark测试（基线测试）：与竞争产品的Benchmarking，产品演变对比测试等。
至于如何写检测脚本，1.可以再Saas平台选择上百款真实机型,根据需要可进行调用哪一个云真机2.在SaaS平台的云端上传APP,方便统一管理;无需编写代码,开始录制脚本,并自动生成脚本步骤3.APP测试的脚本写的对不对,还是要回放看一看的
C. 自动化测试脚本开发的主要步骤
1、通过某些方式定位到我们要执行的对象、目标( Target)
2、对这个对象进行什么操作(command)
3、通过操作对定位到的元素赋值(value)
4、添加断言操作
D. 如何进行shell脚本正确性测试
最近刚刚接触到RobotFramework，发现这个工具倒是可以满足我的要求，而且可以结合seleniumLibrary，用来做web的自动化测试相当不错。之前我也接触过selenium，不过感觉那个工具更贴近开发人员使用，有了robotFramework之后，感觉这个工具相当强大，而且是贴近测试人员的。之所以说强大，主要是这些测试脚本都可以用文本格式保存（如txt/html等）
==安装篇==
如果有想学的朋友可以自己下载以下文件安装（Google-code里可以找到大部分的安装文件）：
这篇文章的内容比较旧了，最新的安装指南请查看 更新篇
python-2.7.1.msi（首先要有python，请选择将Python加入Path）
wxPython2.8-win32-unicode-2.8.11.0-py27.exe（wxPython，必须要的）
robotframework-2.6.0.win32.exe（然后装robot的Framework）
robotframework-ride-0.38.1.win32.exe（robotFramework的IDE，很不错）
robotframework-seleniumlibrary-2.8.win32.exe（seleniumLibrary）
安装成功后
执行[PythonDir]\Scripts\ride.py
看到界面就是安装成功了。
如果需要AutoIt支持就下载下面2个东东。
AutoItLibrary-1.1
pywin32-216.win32-py2.7.exe
==入门篇==
安装完成了，这个框架可以说是基于keyword的操作，按F5可以看到所有加载的keyword。
首先新增一个project
然后新增suite
然后新增test case，接着在suite层级add library，把selenium library加进来，添加后按F5检验是否添加成功，如图
OK，继续在suite的setting里设置suite启动和结束的keyword，即Start Selenium Server和Stop Selenium Server，他会在运行时帮助我们自动启动seleniumserver。
接下来在test case里添加一个步骤，open browser（一般用selenium做web测试都要用这个方法来打开浏览器），添加后关键字变成蓝色表示找到关键字了，否则可能是拼写错误或者没有加载相应的library。红色表示有一个必选参数要给定输入值，具体参数可以看F5里的keyword说明。
E. 测试脚本的介绍
Testing script（测试脚本），一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。 为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。或许会发现这样的情况，即有的操作将出现在几个测试过程中。因此，应有目的地确定这些操作的目标，这样就可以复用它们的实施。 测试脚本是自动执行测试过程（或部分测试过程）的计算机可读指令。测试脚本可以被创建（记录）或使用测试自动化工具自动生成，或用编程语言编程来完成，也可综合前三种方法来完成。
F. 自动化测试实例二：脚本开发(上)
完成测试用例后就可以开发测试脚本，一般包括自动化测试框架的开发和功能脚本的开发。在本节中不介绍如何开发自动化测试框架，有兴趣的读者可以参考《 QTP 自动化测试与框架模型设计 》一书中第 19 章和第 20 章的自动化测试框架的内容。本章介绍该实例中需要调用到的函数。
(1)公用函数封装。
在本实例中需要封装的函数主要包括： 读取测试用例、输入每个测试用例的测试结果。
通过获取单元格中数据的行数，可以确定测试用例文档中有多少条测试用例， 代码如下：
读取单元格中的数据，即获得测试用例值， 代码如下：
在该实例中还需要记录每个测试用例执行的结果， 封装的代码如下：
由于在本实例中需要连接数据库，检查数据库中的数据是否正确，所以将连接数据库的代码进行封装， 代码如下：
(2)单一模式脚本开发。
自动化测试脚本开发完成后，开始录制脚本，这个阶段主要是将自动化测试的需求转换为一个简单的脚本。
1)录制登录过程的脚本如下：
2)录制订票流程的脚本如下：
3)录制航班信息的脚本如下：
4)录制查询订票信息的脚本如下：
(3)脚本增强。
录制好的单一模式脚本的功能很弱，只完成了一个简单的功能，不具备可扩展性，无法兼容不同的测试数据，所以需要对上面的脚本进行增强。在录制单一模式的脚本时，其实有一个功能是通用的，就是登录功能，每个操作的功能都需要先登录系统，所以可将一个正确登录的脚本封装成一个过程，这样可以节约脚本量，也便于维护脚本。在封装登录过程时，需要使用到描述性编程， 封装的代码如下：
接着对登录的脚本进行增强操作，增强的原因是脚本需要能正确处理当输入用户名或密码出错的情况。 主要需要处理的情况有： 输入的用户名为空、输入的用户名少于 4 个字符、输入的密码为空、输入的密码少于 4 个字符。 登录功能增强后的脚本如下：
订票流程脚本的增强主要需要处理订票日期未输入和输入错误的情况， 订票流程功能增强后的脚本如下：
航班信息查询脚本的增强主要是需要检查当选择出发城市和到达城市后，显示出来的航班信息是否正确，脚本增强时需要获取所有航班信息。 增强后的脚本如下：
查询订票信息脚本增强主要是需要检查该航班号是否存在，如果航班号不存在，会弹出相应的对应信息;如果查询的订单号存在，就会显示出该订单的相关信息。 增强后的脚本如下：
G. 自动化测试实例三：脚本开发(下)
仅仅通过上面对脚本增强还不够，不能做到真正的自动化测试，还必须让脚本正确地执行所有用例，并且同时判断每个测试用例执行的结果。
对于登录功能调用测试用例后的脚本如下：
订票流程功能脚本不但需要调用测试用例，并且在选择出发城市和到达城市时需要随机选择，选择好出发城市和到达城市后，在选择航班时也需要做到随机选择，这样能更好地模拟真实的情况。
订票完成后需要检查订票信息是否已经写入数据库，即需要检查 Orders 表中是否添加了相关的订单信息，增强后的脚本如下：
航班信息功能不需要读取数据，但需要随机选择出发城市和到达城市，当输入出发城市和到达城市后，应该检查弹出的航班信息对话框中的所有航班信息是否成功，即是否与 Flights 表中的记录对应， 增强后的脚本如下：
查询订票信息功能增强，即随机输入一个订单号，当该订单号存在时，需要进一步判断相关的信息是否正确，如果正确，说明该测试通过，否则测试失败。 增强后的脚本如下：
脚本开发完成后，即可开始执行脚本，这些脚本主要是功能方面的验证测试。功能验证测试也可以理解为每日构建测试，主要是对系统每日新增或修改的代码进行测试，以保证新增或修改的代码不会对关键功能产生影响。
在执行脚本过程中，需要记录每一轮测试用例执行的情况，即测试用例记录，当整个项目的自动化测试完成后，需要提交相关的测试报告。
【自动化测试小结】
本章主要介绍了自动化测试相关的知识， 自动化测试的目的、范围，测试的程度和测试对象;自动化测试的优缺点和当前自动化测试普遍存在的问题;当前主流的自动化测试工具、自动化测试框架和自动化测试的过程。 通过本章的学习，重点了解什么是自动化测试、自动化测试框架和自动化测试过程。最后通过介绍一个自动化测试实例，使读者更好地学习自动化测试的相关知识，但要进一步了解自动化测试，还必须阅读相关的自动化测试资料。
H. Shell基础脚本-文件测试操作
下列每一个运算符在满足其下条件时，返回的结果为真
检测文件是否存在
检测文件是否存在
等价于 -e。不推荐使用，已被弃用。
文件是常规文件(regular file)，而非目录或 设备文件
文件大小不为0
文件是一个目录
文件是一个 块设备
文件是一个 字符设备
文件是一个 管道设备
文件是一个 符号链接
文件是一个符号链接
文件是一个 套接字
文件（文件描述符）与终端设备关联
该选项通常被用于 测试脚本中的 stdin [ -t 0 ] 或 stdout [ -t 1 ] 是否为终端设备
该文件对执行测试的用户可读
该文件对执行测试的用户可写
该文件可被执行测试的用户所执行
文件或目录设置了 set-group-id sgid 标志
如果一个目录设置了 sgid 标志，那么在该目录中所有的新建文件的权限组都归属于该目录的权限组，而非文件创建者的权限组。该标志对共享文件夹很有用
文件设置了 set-user-id suid 标志。
一个属于 root 的可执行文件设置了 suid 标志后，即使是一个普通用户执行也拥有 root 权限。
对需要访问硬件设备的可执行文件（例如 pppd 和 cdrecord）很有用。
如果没有 suid 标志，这些可执行文件就不能被非 root 用户所调用了
设置了 suid 标志后，在权限中会显示 s
设置了粘滞位(sticky bit)
标志粘滞位是一种特殊的文件权限。如果文件设置了粘滞位，那么该文件将会被存储在高速缓存中以便快速访问。如果目录设置了该标记，那么它将会对目录的写权限进行限制，目录中只有文件的拥有者可以修改或删除文件。设置标记后你可以在权限中看到 t
如果一个用户不是设置了粘滞位目录的拥有者，但对该目录有写权限，那么他仅仅可以删除目录中他所拥有的文件。这可以防止用户不经意间删除或修改其他人的文件，例如 /tmp 文件夹。（当然目录的所有者可以删除或修改该目录下的所有文件）
执行用户是文件的拥有者
文件的组与执行用户的组相同
文件在在上次访问后被修改过了
文件 f1 比文件 f2 新
文件 f1 比文件 f2 旧
文件 f1 和文件 f2 硬链接到同一个文件
取反——对测试结果取反(如果条件缺失则返回真)
样例-1. 检测链接是否损坏
二元比较操作比较变量或者数量。注意整数和字符串比较使用的是两套运算符
整数比较
等于
不等于
-gt )
大于
大于等于
小于
小于等于
小于（使用 双圆括号）
小于等于（使用双圆括号）
大于（使用双圆括号）
大于等于（使用双圆括号）
等于
等于
和 = 同义 == 运算符在 双方括号和单方括号里表现不同
不等于
在 [[ ... ]] 结构中会进行模式匹配。
小于，按照 ASCII码 排序
注意在 [] 结构里 < 需要被 转义
大于，按照 ASCII 码排序
注意在 [] 结构里 > 需要被转义
字符串为空，即字符串长度为0
字符串非空（null）
使用 -n 时字符串必须是在括号中且被引用的
使用 ! -z 判断未引用的字符串或者直接判断 通常可行，但是非常危险
判断字符串时一定要引用
样例-2. 算术比较和字符串比较
样例-3. 测试字符串是否为空（null）
样例-4. zmore
逻辑与
exp1 -a exp2 返回真当且仅当 exp1 和 exp2 均为真
逻辑或
如果 exp1 或 exp2 为真，则 exp1 -o exp2 返回真。
以上两个操作和 双方括号结构中的 Bash 比较运算符号 && 和 || 类似
测试操作 -o 和 -a 可以在 test 命令或在测试括号中进行
rihad 指出：
I. 测试中如何使用自动化脚本
从毕业到现在，经历了软件开发，
软件测试，
1）QTP工具。QTP是一个快速测试专业工具。它的优点是可以快速建立企业自动化框架，但不是一个全能的工具，因为利用QTP并不能帮助用户找出更多的 BUG，只能提高执行测试用例的效率。 QTP的价格也较贵。 QTP主要应用于较稳定的测试项目的回归测试，UI的变化不明显，功能较稳定的项目。它可以节省回归测试的成本，但相对手工测试来说，QTP对测试人员的要求较高，比如要掌握VB脚本，掌握函数调用等技术；另外，建立QTP框架前期需要投入较大的人力写测试用例，加上调试的时间，是一笔不小的开销，所以企业在选用QTP测试工具时一定要三思而后行。
2）Loadrunner是一个企业级性能测试工具，应用十分广泛。对于WEB应用，Loadrunner的优势十分明显。但与QTP一样，lr的 License十分昂贵，所以很多企业都使用破解版。并且真正掌握LR精髓的人员并不多，很多人都会使用这个工具，但能用这个工具找出系统瓶颈的人并不多，所以，会使用Loadrunner和会性能测试是两码事。懂脚本语言的性能测试人员当然最好。
3）Python和Tcl/tk脚本语言。在我之前的经验中，我用到过PYTHON和TCL。他们都是脚本语言，不需要编译。两种语言的特点如下：Python开发JAVA方面的http接口比较方便；tcl/tk开发C++方面的接口更容易一些。PYTHON写的程序可读性强，TCL写的程序的可读性不好。
4）在需要产生一些大批量数据时，如一个表需要插入100万条数据，然后这100万条数据属于100个不同的类别，如果是手工输入的话，估计10个人一个月都输不完，但如果利用脚本，如PB，VB或者Tcl/tk，可以通过产生批量SQL脚本的方式，来产生SQL脚本，这样不到半小时就可以搞定全部的数据。看来脚本的威力不小！
5）另外，就是Linuxshell脚本了，我们通常说“事半功倍”，shell脚本的确可以帮助你实现这个目的。我们平时在LINUX部署一个应用会用到很多的命令如 Checkout，ps，vi，kill等等，如果能把这个操作流程写成一个SHELL脚本让机器自动执行，那该是省了多少事？另外，作为 UNIX/LINUX管理员，平时可以要监控较多的PC终端，他完全可以在UNIX/LINUX上定制各种任务（如备份，删除临时文件，检查磁盘空间等等），所以，掌握Shell脚本（如Sed，awk，grep等）对一个测试人员来讲是十分必要的！
6）另外一个就SQL脚本了，要能写存储过程（SP）和触发器（Trigger），还有游标（Cursor）的使用，掌握这些的话对于测试数据库方面的用例是相当有帮助的。SQL脚本对系统性能和功能都起着十分重要的作用。
作为一名有6年测试经验的工程师，我坚定地认为脚本测试技术是以后的发展方向，包括白盒测试，也是将来的一个发展方向，对于测试人员来讲，核心竞争力是能完整的测试开发人员的程序，尽可能找出更多的BUG。黑盒测试只能从系统的角度去完成功能测试，但作为软件本身，应该作更深层次的测试。
J. 如何使用Bash Shell脚本进行功能测试
在本文中，Angel Rivera 将说明如何运用 Bash shell 脚本通过行命令来执行 Linux 应用程序的功能测试。由于此脚本依赖于命令行的返回码，因而您不能将这种方法运用于 GUI 应用程序 功能测试是开发周期的一个阶段，在这个阶段中将测试软件应用程序以确保软件的函数如预期的那样，同时能正确处理代码中错误。此项工作通常在单个模块的单元测试结束之后，在负载／重压条件下整个产品的系统测试之前进行的。 市场上有许多测试工具提供了有助于功能测试的功能。然而，首先要获取它们，然后再安装、配置，这将占用您宝贵的时间和精力。Bash 可以帮您免去这些烦琐的事从而可以加快测试的进程。 使用Bash shell 脚本进行功能测试的优点在于： Bash shell 脚本已经在 Linux 系统中安装和配置好了。不必再花时间准备它。 可以使用由 Linux 提供的文本编辑器如 vi 创建和修改 Bash shell 脚本。不需要再为创建测试程序而获取专门的工具。 如果已经知道了如何开发 Bourne 或 Korn shell 脚本，那对于如何运用 Bash shell 脚本已经足够了。对您来说，学习曲线已不存在了。 Bash shell 提供了大量的编程构造用于开发从非常简单到中等复杂的脚本。 将脚本从 Korn 移植到 Bash 时的建议 如果已有现成的 Korn shell 脚本，而想要将它们移植到 Bash，就需要考虑下列情况： Korn 的 "print" 命令在 Bash 中不能使用；而是改为使用 "echo" 命令。 需要将脚本的第一行： #!/usr/bin/ksh 修改成： #!/bin/bash 创建Bash shell 脚本进行功能测试 这些基本的步骤和建议适用于许多在 Linux 上运行的客户机／服务器应用程序。 记录运行脚本的先决条件和主要步骤 将操作分成若干个逻辑组 基于一般方案制定执行步骤 在每个 shell 脚本中提供注释和说明 做一个初始备份以创建基准线 检查输入参数和环境变量 尝试提供 "usuage" 反馈 尝试提供一个“安静”的运行模式 当出现错误时，提供一个函数终止脚本 如可能，提供可以执行单个任务的函数 当显示正在生成的输出时，捕获每个脚本的输出 在每个脚本内，捕获每个行命令的返回码 计算失败事务的次数 在输出文件中，突出显示错误消息，以便于标识 如有可能，“实时”生成文件 在执行脚本的过程中提供反馈 提供脚本执行的摘要 提供一个容易解释的输出文件 如有可能，提供清除脚本及返回基准线的方法 下面详细讲述了每一条建议以及用于说明问题的脚本。若要下载此脚本，请参阅本文后面的 参考资料部分。 1. 记录运行脚本的先决条件和主要步骤 记录，尤其是以有自述标题的单个文件（例如 "README-testing.txt"）记录功能测试的主要想法是很重要的，包括，如先决条件、服务器和客户机的设置、脚本遵循的整个（或详细的）步骤、如何检查脚本的成功／失败、如何执行清除和重新启动测试。 2. 将操作分成若干个逻辑组 如果仅仅执行数量非常少的操作，可以将它们全部放在一个简单的 shell 脚本中。 但是，如果需要执行一些数量很多的操作，那最好是将它们分成若干个逻辑集合，例如将一些服务器操作放在一个文件而将客户机操作放在在另一个文件中。通过这种方法，划分适当的颗粒度来执行测试和维护测试。 3. 基于一般方案制定执行步骤 一旦决定对操作进行分组，需要根据一般方案考虑执行操作的步骤。此想法是模拟实际生活中最终用户的情形。作为一个总体原则，只需集中测试 80% 最常调用函数的 20% 用法即可。 例如，假设应用程序要求 3 个测试组以某个特定的顺序排列。每个测试组可以放在一个带有自我描述文件名（如果可能）的文件中，并用号码来帮助识别每个文件的顺序，例如： 1. fvt-setup-1: To perform initial setup. 2. fvt-server-2: To perform server commands. 3. fvt-client-3: To perform client commands. 4. fvt-cleanup: To cleanup the temporary files, in order to prepare for the repetition of the above test cases. 4. 在每个 shell 脚本中提供注释和说明 在每个 shell 脚本的头文件中提供相关的注释和说明是一个良好的编码习惯。这样的话，当另一个测试者运行该脚本时，测试者就能清楚地了解每个脚本中测试的范围、所有先决条件和警告。 下面是一个 Bash 脚本 "test-bucket-1" 的示例 。 #!/bin/bash # # Name: test-bucket-1 # # Purpose: # Performs the test-bucket number 1 for Proct X. # (Actually, this is a sample shell script, # which invokes some system commands # to illustrate how to construct a Bash script) # # Notes: # 1) The environment variable TEST_VAR must be set # (as an example). # 2) To invoke this shell script and redirect standard # output and standard error to a file (such as # test-bucket-1.out) do the following (the -s flag # is "silent mode" to avoid prompts to the user): # # ./test-bucket-1 -s 2>&1 | tee test-bucket-1.out # # Return codes: # 0 = All commands were successful # 1 = At least one command failed, see the output file # and search for the keyword "ERROR". # ######################################################## 5. 做一个初始备份以创建基准线 您可能需要多次执行功能测试。第一次运行它时，也许会找到脚本或进程中的一些错误。因而，为了避免因从头重新创建服务器环境而浪费大量时间 -- 特别是如果涉及到数据库 -- 您在测试之前或许想做个备份。 在运行完功能测试之后，就可以从备份中恢复服务器了，同时也为下一轮测试做好了准备。 6. 检查输入参数和环境变量 最好校验一下输入参数，并检查环境变量是否设置正确。如果有问题，显示问题的原因及其修复方法，然后终止脚本。 当测试者准备运行脚本，而此时如果没有正确设置脚本所调用的环境变量，但由于发现及时，终止了脚本，那测试者会相当感谢。没有人喜欢等待脚本执行了很久却发现没有正确设置变量。 # -------------------------------------------- # Main routine for performing the test bucket # -------------------------------------------- CALLER=`basename $0` # The Caller name SILENT="no" # User wants prompts let "errorCounter = 0" # ---------------------------------- # Handle keyword parameters (flags). # ---------------------------------- # For more sophisticated usage of getopt in Linux, # see the samples file: /usr/lib/getopt/parse.bash TEMP=`getopt hs $*` if [ $? != 0 ] then echo "$CALLER: Unknown flag(s)" usage fi # Note quotes around `$TEMP': they are essential! eval set -- "$TEMP" while true do case "$1" in -h) usage "HELP"; shift;; # Help requested -s) SILENT="yes"; shift;; # Prompt not needed --) shift ; break ;; *) echo "Internal error!" ; exit 1 ;; esac done # ------------------------------------------------ # The following environment variables must be set # ------------------------------------------------ if [ -z "$TEST_VAR" ] then echo "Environment variable TEST_VAR is not set." usage fi 关于此脚本的说明如下： 使用语句 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" 语句是个好主意，它用来说明如何使用脚本。 # ---------------------------- # Subroutine to echo the usage # ---------------------------- usage() { echo "USAGE: $CALLER [-h] [-s]" echo "WHERE: -h = help " echo " -s = silent (no prompts)" echo "PREREQUISITES:" echo "* The environment variable TEST_VAR must be set," echo "* such as: " echo " export TEST_VAR=1" echo "$CALLER: exiting now with rc=1." exit 1 } 调用脚本时，使用“-h”标志可以调用 "usage" 语句，如下所示： ./test-bucket-1 -h 8. 尝试使用“安静”的运行模式 您或许想让脚本有两种运行模式： 在"verbose" 模式（您也许想将此作为缺省值）中提示用户输入值，或者只需按下 Enter 继续运行。 在"silent" 模式中将不提示用户输入数据。 下列摘录说明了在安静模式下运用所调用标志 "-s" 来运行脚本： # ------------------------------------------------- # Everything seems OK, prompt for confirmation # ------------------------------------------------- if [ "$SILENT" = "yes" ] then RESPONSE="y" else echo "The $CALLER will be performed." echo "Do you wish to proceed [y or n]? " read RESPONSE # Wait for response [ -z "$RESPONSE" ] && RESPONSE="n" fi case "$RESPONSE" in [yY]|[yY][eE]|[yY][eE][sS]) ;; *) echo "$CALLER terminated with rc=1." exit 1 ;; esac 9. 当出现错误时，提供一个函数终止脚本 遇到严重错误时，提供一个中心函数以终止运行的脚本不失为一个好主意。此函数还可提供附加的说明，用于指导在此情况下应做些什么： # ---------------------------------- # Subroutine to terminate abnormally # ---------------------------------- terminate() { echo "The execution of $CALLER was not successful." echo "$CALLER terminated, exiting now with rc=1." dateTest=`date` echo "End of testing at: $dateTest" echo "" exit 1 } 10. 如有可能，提供可以执行简单任务的函数 例如，不使用许多很长的行命令，如： # -------------------------------------------------- echo "" echo "Creating Access lists..." # -------------------------------------------------- Access -create -component Development -login ted -authority plead -verbose if [ $? -ne 0 ] then echo "ERROR found in Access -create -component Development -login ted -authority plead" let "errorCounter = errorCounter + 1" fi Access -create -component Development -login pat -authority general -verbose if [ $? -ne 0 ] then echo "ERROR found in Access -create -component Development -login pat -authority general" let "errorCounter = errorCounter + 1" fi Access -create -component Development -login jim -authority general -verbose if [ $? -ne 0 ] then echo "ERROR found in Access -create -component Development -login jim -authority general" let "errorCounter = errorCounter + 1" fi ……而是创建一个如下所示的函数，此函数也可以处理返回码，如果有必要，还可以增加错误计数器： CreateAccess() { Access -create -component $1 -login $2 -authority $3 -verbose if [ $? -ne 0 ] then echo "ERROR found in Access -create -component $1 -login $2 -authority $3" let "errorCounter = errorCounter + 1" fi } ……然后，以易读和易扩展的方式调用此函数： # ------------------------------------------- echo "" echo "Creating Access lists..." # ------------------------------------------- CreateAccess Development ted projectlead CreateAccess Development pat general CreateAccess Development jim general 11. 当显示正在生成的输出时，捕获每个脚本的输出 如果脚本不能自动地将输出发送到文件的话，可以利用 Bash shell 的一些函数来捕获所执行脚本的输出，如： ./test-bucket-1 -s 2>&1 | tee test-bucket-1.out 让我们来分析上面的命令： "2>&1" 命令： 使用"2>&1" 将标准错误重定向到标准输出。字符串 "2>&1" 表明任何错误都应送到标准输出，即 UNIX/Linux 下 2 的文件标识代表标准错误，而 1 的文件标识代表标准输出。如果不用此字符串，那么所捕捉到的仅仅是正确的信息，错误信息会被忽略。 管道"|" 和 "tee" 命令： UNIX/Linux 进程和简单的管道概念很相似。既然这样，可以做一个管道将期望脚本的输出作为管道的输入。下一个要决定的是如何处理管道所输出的内容。在这种情况下，我们会将它捕获到输出文件中，在此示例中将之称为 "test-bucket-1.out"。 但是，除了要捕获到输出结果外，我们还想监视脚本运行时产生的输出。为达到此目的，我们连接允许两件事同时进行的 "tee" （T- 形管道）：将输出结果放在文件中同时将输出结果显示在屏幕上。其管道类似于： process --> T ---> output file | V screen 如果 只 想捕获输出结果而不想在屏幕上看到输出结果，那可以忽略多余的管道： ./test-bucket-1 -s 2>&1 > test-bucket-1.out 假若这样，相类似的管道如下： process --> output file 12. 在每个脚本内，捕获每个行命令所返回码 决定功能测试成功还是失败的一种方法是计算已失败行命令的数量，即返回码不是 0。变量 "$?" 提供最近所调用命令的返回码；在下面的示例中，它提供了执行 "ls" 命令的返回码。 # ------------------------------------------- # The commands are called in a subroutine # so that return code can be # checked for possible errors. # ------------------------------------------- ListFile() { echo "ls -al $1" ls -al $1 if [ $? -ne 0 ] then echo "ERROR found in: ls -al $1" let "errorCounter = errorCounter + 1" fi } 13. 记录失败事务的次数 在功能测试中决定其成功或失败的一个方法是计算返回值不是 0 的行命令数量。但是，从我个人的经验而言，我习惯于在我的 Bash shell 脚本中仅使用字符串而不是整数。在我所参考的手册中没有清楚地说明如何使用整数，这就是我为什么想在此就关于如何使用整数和计算错误（行命令失败）数量的方面多展开讲的原因： 首先，需要按如下方式对计数器变量进行初始化： let "errorCounter = 0" 然后，发出行命令并使用 $? 变量捕获返回码。如果返回码不是 0，那么计数器增加 1（见蓝色粗体语句）： ListFile() { echo "ls -al $1" ls -al $1 if [ $? -ne 0 ] then echo "ERROR found in: ls -al $1" let "errorCounter = errorCounter + 1" fi } 顺便说一下，与其它变量一样，可以使用 "echo" 显示整数变量。 14. 在输出文件中，为了容易标识，突出显示错误消息 当遇到错误（或失败的事务）时，除了错误计数器的数量会增加外，最好标识出此处有错。较理想的做法是，字符串有一个如 ERROR 或与之相似的子串（见蓝色粗体的语句），这个子串允许测试者很快地在输出文件中查找到错误。此输出文件可能很大，而且它对于迅速找到错误非常重要。 ListFile() { echo "ls -al $1" ls -al $1 if [ $? -ne 0 ] then echo "ERROR found in: ls -al $1" let "errorCounter = errorCounter + 1" fi } 15. 如有可能，“实时”生成文件 在某些情况下，有必要处理应用程序使用的文件。可以使用现有文件，也可以在脚本中添加语句来创建文件。如果要使用的文件很长，那最好将其作为独立的实体。如果文件很小而且内容简单或不相关（重要的一点是文本文件而不考虑它的内容），那就可以决定“实时”创建这些临时文件。 下面几行代码显示如何“实时”创建临时文件： cd $HOME/fvt echo "Creating file softtar.c" echo "Subject: This is softtar.c" > softtar.c echo "This is line 2 of the file" >> softtar.c 第一个 echo 语句使用单个的 > 强行创建新文件。第二个 echo 语句使用两个 >> 将数据附加到现有文件的后面。顺便说一下，如果该文件不存在，那么会创建一个文件。 16. 在执行脚本的过程中提供反馈 最好在脚本中包含 echo 语句以表明它执行的逻辑进展状况。可以添加一些能迅速表明输出目的的语句。 如果脚本要花费一些时间执行，那或许应在执行脚本的开始和结束的地方打印时间。这样可以计算出所花费的时间。 在脚本样本中，一些提供进展说明的 echo 语句如下所示： # -------------------------------------------- echo "Subject: Proct X, FVT testing" dateTest=`date` echo "Begin testing at: $dateTest" echo "" echo "Testcase: $CALLER" echo "" # -------------------------------------------- # -------------------------------------------- echo "" echo "Listing files..." # -------------------------------------------- # The following file should be listed: ListFile $HOME/.profile ... # -------------------------------------------- echo "" echo "Creating file 1" # -------------------------------------------- 17. 提供脚本执行的摘要 如果正在计算错误或失败事务的次数，那最好表明是否有错误。此方法使得测试者在看到输出文件的最后能迅速地辨认出是否存在错误。 在下面的脚本示例中，代码语句提供了上述脚本的执行摘要： # -------------- # Exit # -------------- if [ $errorCounter -ne 0 ] then echo "" echo "*** $errorCounter ERRORS found ring ***" echo "*** the execution of this test case. ***" terminate else echo "" echo "*** Yeah! No errors were found ring ***" echo "*** the execution of this test case. Yeah! ***" fi echo "" echo "$CALLER complete." echo "" dateTest=`date` echo "End of testing at: $dateTest" echo "" exit 0 # end of file 18. 提供一个容易解释的输出文件 在脚本生成的实际输出中提供一些关键信息是非常有用的。那样，测试者就可以很容易地确定正在查看的文件是否与自己所做的相关以及它是否是当前产生的。附加的时间戳记对于是否是当前状态是很重要的。摘要报告对于确定是否有错误也是很有帮助的；如果有错误，那么测试者就必须搜索指定的关键字，例如 ERROR，并确认出个别失败的事务。 以下是一段输出文件样本的片段： Subject: CMVC 2.3.1, FVT testing, Common, Part 1 Begin testing at: Tue Apr 18 12:50:55 EDT 2000 Database: DB2 Family: cmpc3db2 Testcase: fvt-common-1 Creating Users... User pat was created successfully. ... Well done! No errors were found ring the execution of this test case :) fvt-common-1 complete. End of testing at: Tue Apr 18 12:56:33 EDT 2000 当遇到错误时输出文件最后部分的示例如下所示： ERROR found in Report -view DefectView *** 1 ERRORS found ring the execution of this test case. *** The populate action for the CMVC family was not successful. Recreating the family may be necessary before running fvt-client-3 again, that is, you must use 'rmdb', 'rmfamily', 'mkfamily' and 'mkdb -d', then issue: fvt-common-1 and optionally, fvt-server-2. fvt-client-3 terminated, exiting now with rc=1. End of testing at: Wed Jan 24 17:06:06 EST 2001 19. 如有可能，提供清除脚本及返回基准线的方法 测试脚本可以生成临时文件；假若这样，最好能让脚本删除所有临时文件。这就会避免由于测试者也许没有删除所有临时文件而引起的错误，更糟糕的是将所需要的文件当作临时文件而删除了。 运行功能测试的 Bash shell 脚本 本节描述如何运用 Bash shell 脚本进行功能测试。假设您已经执行了在前面部分中所述步骤。 设置必要的环境变量 根据需要在 .profile 中或手工指定下列环境变量。该变量用于说明在脚本中如何处理，所需环境变量的验证必须在脚本执行前定义。 export TEST_VAR=1 将Bash shell 脚本复制到正确的目录下 Bash shell 脚本和相关文件需要复制到要进行功能测试的用户标识的目录结构下。 登录进某个帐户。您应该在主目录下。假设它是 /home/tester。 为测试案例创建目录： mkdir fvt 复制Bash shell 脚本和相关文件。获取压缩文件（请参阅 参考资料 ）并将其放在 $HOME 下。然后将其按下列方式解压： unzip trfvtbash.zip 为了执行这个文件，更改文件的许可权： chmod u+x * 更改名称以除去文件的后缀： mv test-bucket-1.bash test-bucket-1 运行脚本 执行下列步骤以运行脚本： 以测试者的用户标识登录 更改目录至所复制脚本的位置： cd $HOME/fvt 从$HOME/fvt 运行脚本： ./test-bucket-1 -s 2>&1 | tee test-bucket-1.out 看一下输出文件 "test-bucket-1.out" 的尾部并查看摘要报告的结论。 参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文. 下载trfvtbash.zip，它包含本文所引用的样本代码和工具。该工具在以后有可能会更新。 尝试用 Info-ZIP 软件 解开该文件。由于该工具很常用，推荐您最好将解压和压缩工具的目录放至 PATH 中，这样该机器上的所有用户都可以使用这个工具。 如何解压该文件： 为了查看压缩文件中的内容（实际上并没有解包和解压缩该文件），用： unzip -l trfvtbash.zip 命令。(T002)