用户测试脚本

❶ 自动化测试脚本的基本功能有哪些

自动化测试脚本的基本功能有脚本语言，对象识别，自动执行和结果判断。

1、测试需求分析阶段。测试需求分析阶段主要工作是获得测试项目的测试需求（测试规格）。输出产物：《可测试性需求说明书》和《测试规格》。

2、测试计划阶段。以测试需求为基础，分析产品的总体测试策略。输出产物：《产品总体测试策略》。

Test Partner：

它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，用户可以调用VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。

没有编程知识的测试人员也可以通过TestPartner的可视化导航器来快速创建测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。

❷ 什么是UAT测试

UAT，(UserAcceptanceTest),也就是用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。

它让系统用户决定是否接收系统，它是一项确定产品是否能够满足合同或用户所规定需求的测试，这是管理性和防御性控制。

(2)用户测试脚本扩展阅读

执行步骤

1、用户培训手册准备。

指针对要进行UAT测试的对象，及要进行培训的用户，准备一些培训资料。

一般是测试对象使用/功能手册及要培训的用户的个人资料等等，跟教师上课进行备课差不多。

2、测试脚本发放。

如果公司采用自动化测试，那么每一个功能或一个模块等都有对应的测试脚本，可以把这些测试脚本分发给特定的人员；如果采用手工测试，就要把详细描述一个功能或模块的文档分给相关人员（当然自动化测试也要分发）。

3、用户补充业务测试场景和测试数据。

请有代表性的一些最终用户根据实际应用环境及一些常用处理的数据，来给一些补充与建议，越贴近实际应用越好。

4、顾问补充测试步骤。

可以请项目专家，测试经理，或专门的测试，开发等顾问对测试步骤进行补充。

5、培训资料及测试脚本文档的确定与最终输出。

一般到此，各种资料都基本确定，这时可以将它们进行打印，或形成特别的电子文档。

6、测试策略的制定。

如嵌入测试策略等。

7、测试用户的确定。

大体上从培训人员中选取，因为不是每个接受培训的人员都能有资格去测试的，这里你可以通过一些考核来实现人员的筛选等等。

8、由专门的测试组织机构确定测试地点，并发出通知。

9、测试网络环境的搭建和保障。

包括网络，系统，硬软件，包括一些用例工具等。

10、组织进行测试。

11、评审分析提交的问题。

这就进入了一般bug处理过程，形成了一个循环。

UAT测试的重点体现

1、培训的资料表述要准确全面，易懂等（这是理论基础）

2、人员选择，要典型有代表性（用户基础）

3、测试流程步骤（要周密）

4、测试策略制定（确定一个适合测试对象及测试人员的测试策略）

5、问题的表达与处理(因为测试者不是专业开发测试人员，对于问题的表达可能不能到位，或根本就不是那种问题，这就存在如何复现与转化问题等）

❸ 怎么用python对qq登录界面写测试脚本

1. 用Python封装被测试接口,对于HTTP接口我们通常会采用 GET和POST 2种调用方式去访问,所以必须把这2种方式都封装进去
# -*- coding:gb2312 -*-
import urllib2,urllib
'''
函数说明：url 特殊字符编码转换
作者：xiaonan
输入参数：待转换的字符串数据
输出参数：转换完成后的字符串数据
'''
def urlcode(data):
return urllib2.quote(str(data))

'''
函数说明：获取用户信息的API接口
作者：xiaonan
输入参数：用户名(uname),HTTP接口调用方式(GET或者POST)
输出参数：HTTP接口调用返回数据
'''
def GetUserInfo(uname,method):
if method == 'GET':
url = 'http://ip:port/interface/GetUserInfo.php?uname='+urlcode(uname)
result = urllib2.urlopen(url).read()
return result

if method == 'POST':
url = 'http://ip:port/interface/GetUserInfo.php'
values = {'uname' : uname}
data = urllib.urlencode(values)
req = urllib2.Request(url, data)
response = urllib2.urlopen(req)
result = response.read()
return result
2. 编写、组织测试脚本, 准备测试数据
根据Testcase的具体业务逻辑用事先准备好的测试数据去调用封装好的API接口,验证实际返回结果是否与预期返回结果一致.
测试数据可以以各种形式存放,如Excel数据表:
TestCaseName uname method Expected Result
TestCase1 aaaa GET ....
TestCase2 aaaa POST ....
TestCase3 bbbb GET ....
... ... ... ....
# -*- coding:gb2312 -*-
import xlrd
'''
函数说明： Testcase 脚本
作者：xiaonan
输入参数：测试数据,API接口
输出参数：测试日志,测试报告
'''
def GetUser():
bk = xlrd.open_workbook(excel文件名称) # 打开excel文件
sh = bk.sheet_by_name(excel表名)# 打开excel表
nrows = sh.nrows # 获取总行数
for i in range(1,nrows):
TestCase = sh.cell_value(i,0)
uname = sh.cell_value(i,1)
method = sh.cell_value(i,2)
EX_Result=sh.cell_value(i,3)
WriterLog('Testcase Name:'+TestCase+'TestData: uname = '+uname+' ,method = '+method+' ,EX_Result = ' + ,EX_Result) # 写测试日志
AC_result = GetUserInfo(uname,method) # 调用API接口
WriterLog('AC_result = ' + AC_result) # 写测试日志
if EX_Result == AC_result: #实际结果与预期结果对比
WriterLog(...) #写测试日志
WriterReport(...)#写测试报告
else
WriterLog(...)#写测试日志
WriterReport(...)#写测试报告

3. 组织测试套,用驱动文件去调用执行所有测试套件,完成相关测试,并生成测试日志及测试报告.
# -*- coding:gb2312 -*-
'''
函数说明： Testsuit Driver驱动脚本
作者：xiaonan
输入参数：TestCase 脚本
输出参数：测试日志,测试报告

'''
if __name__ == '__main__':
...
WriterLog() #写测试日志
GetUser() # TestCase 脚本
...
...
Report(....) # 统计汇总所有测试报告数据,以文件或页面形式呈现.
4. 执行测试脚本,分析测试结果. 根据测试报告,如果有Bug则提交.

❹ APP怎么检测脚本

APP检测主要从以下几个方面展开：
APP性能测试和监控：极限测试：在各种边界压力情况下（如：电池、存储、网速等），验证App是否能正确响应。响应能力测试：测试App中的各类操作是否满足用户响应时间要求压力测试：反复/长期操作下，系统资源是否占用异常；性能评估：评估典型用户应用场景下，系统资源的使用情况。Benchmark测试（基线测试）：与竞争产品的Benchmarking，产品演变对比测试等。
至于如何写检测脚本，1.可以再Saas平台选择上百款真实机型,根据需要可进行调用哪一个云真机2.在SaaS平台的云端上传APP,方便统一管理;无需编写代码,开始录制脚本,并自动生成脚本步骤3.APP测试的脚本写的对不对,还是要回放看一看的

❺ APP兼容性测试脚本怎么写

兼容性测试，你需要根据测试用例，编写测试脚本，根据用户给出的测试用例，编写可以自动化执行的测试脚本。测试用例的样式，可以是word或者excel格式的。
兼容性测试:就是让APP、小程序、H5程序，在所有的设备上进行适配，兼容性测试，发现潜在的问题。
app兼容性测试使用方法:
1) 登陆您的TestBird账户，进入APP测试系统，如果没有账号可以直接注册一个。
2)点击右上角的“新建测试任务”
3)填写测试需求
4）选择测试机型后创建应用的版本
5)上传APK包，开始测试
6)任务上传成功，可以随时查看测试进展

❻ 软件功能测试流程

1、测试计划：测试计划一般由测试经理编写，根据需求估算测试所需资源（人力，设备等）、所需时间、功能点划分、如何合理分配安排资源。

2、用例设计：根据测试计划，修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档和详细设计文档。测试人员根据这两份文档补充测试用例。

3、测试环境：测试人员搭建测试环境。

4、执行测试：开发人员提交第一个版本，如果存在未完成的功能，开发需跟测试人员说明，然后测试人员根据测试用例的详细步骤，执行测试用例，发现BUG提交缺陷库。

5、BUG跟踪：开发人员提交第二个版本，包括修改的BUG以及增加的部分功能，测试人员进行第二轮测试和回归测试，跟踪BUG直到关闭。

6、测试报告：通过不断测试，BUG跟踪，直到用例全部测试，覆盖率、缺陷率以及其他各项指标达到质量标准，即达到上线要求。

(6)用户测试脚本扩展阅读：

功能测试根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好。

功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码。

❼ 如何使用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)

❽ 【超详细】可用性测试方法总结

之前总结过一版 交互设计流程图 ，主要是想给自己以后做设计梳理一下过程，但是那份流程里面只有枝干，并没有枝叶，所以针对每个方法我都会撰写一份方法总结，或者说指导，目的就是为以后实践做准备。我期望的效果是，假如一个没有接触过该方法的人看到这份总结，可以按照这个总结一步步完成实验。这就是我最大的目的。下面就是第一份总结《可用性测试方法总结》。

（预警：长文慎入！不过耐心看完肯定会有所收获）

============分割线==================

可用性测试的过程主要有七个步骤：测试前思考、制作测试原型、撰写测试脚本、招募测试者、设置测试环境、预测师、正式测试以及测试结果统计分析。这七个步骤有些事可以并行的，有些是需要严格按照前后顺序执行的。七个步骤组成的流程图如下：

下面我就针对这七个步骤，谈谈具体要怎么做。

不论是做哪个平台的可用性测试，比如PC端、移动端或者是WEB端的可用性测试，最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题：

·为什么要进行这个测试（why）？测试可以验证一些设计中的疑惑，或者找出现有的界面、流程设计上的问题，具体问题要具体分析。

·什么时候在哪里做测试（when？where？）？时间一般是需要和测试者协调的；地点一般选择在安静的会议室即可，如果公司有专门的实验室那就最好不过了。

·谁要作为测试者（who）？这里可以在招募测试者会详细讨论，不过测试者一般是跟我们的persona接近的人，或者换个说法，测试者一般是我们的目标用户。

·我们要测试什么（what）？测试一些功能点，测试界面设计，测试流程设计，测试设计中有争议、有疑问的地方。

当然这些问题其实都不太难，但是这些都是至关重要的问题。如果没有经过这个步骤的思考，整个可用性测试做下来就会像无头苍蝇，没有一个总的指导。

在想清楚以上的问题之后，需要为可用性测试做一些准备工作。主要工作有：①招募测试者；  ②撰写测试脚本；  ③制作测试原型。

这三个过程不分先后，条件允许的情况下（人力物力充足时）也可以同时进行。

招募测试者算是可用性测试最重要的一个环节之一的，测试者是否合适直接关系到测试结果的好坏，测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户，所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下：

a)最简便的，假如同事（非同部门）或者好友也是目标用户，可以选用同事或者好友作为测试人员。

b)其次，大型公司都会有自己的用户资料库，可以从这个库里面寻找到测试人员。

c)又或者说，委托第三方机构帮忙寻找测试人员也是允许的，不过效果可能不如自己寻找的。

d)当然，现在的应用一般都会有自己的微博、微信、官网或者论坛，这些是非常好的寻找测试者的渠道。我们可以推送招募测试者的公告，让用户填写一份调查之后，我们再筛选得到我们想要的测死者。公告中要注明奖励，一般为小礼品的奖励，保证对测试者有一定的吸引力，同时又不至于让他们会为了这个礼物对个人信息造假。其次，对于测试者，我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息：比如姓名、电话（邮箱）、空闲时间；然后根据调查选择其他一些个人信息：性别、年龄、职业之后，最后留几道问卷题目进行筛选。

筛选的维度主要有：

·平台。如果测试的产品与平台有关，比如是Android或者iOS，需要在这里进行一个筛选。

·对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户，可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。

测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前，我们需要先确定一些结果分析的维度。一般的维度有：a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。

由于分析的维度会关系到脚本的问题，所以在确定分析维度之后，我们可以对功能点进行任务分析。把所有需要测试的功能点列出来，对每个功能点进行任务设计。对于任务而言，用户最主观的感受就是两个：界面和流程。所以测试脚本又可以从这两个维度去细分。

需要注意的是，可用性测试中，问只是其中的一部分，观察是另外一个重要的内容，所以测试脚本不仅仅要有问的问题，还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时，把总结大纲也写出来，方便后期总结的时候统一结果展示。

特别的，在设计的时候有疑惑的点，或者有争议的点，在可用性测试也可以得到较好的验证。

写完测试脚本之后，可以和利益相关者（项目经理、产品经理、开发等）讨论一下，请他们校验一下测试脚本。

界面：

a)当前界面有什么？

b)每个东西用户觉得是什么？

c)可以操作吗？

d)用什么手势操作方式？

e)操作之后会怎么样？

f)界面显示的内容足够吗，有没有缺少什么东西？

流程： 流程的测试就是根据任务来进行的。把产品的需求文档罗列出来，然后给每个需求配上一个合适的场景，当然也会出现一个场景覆盖多个需求的情况，这也是允许的。然后让用户在场景下去进行任务，观察用户，然后随时提问用户，随时准备回答用户的问题。

以上两点适合所有的可用性测试，但是对于版本更新类的可用性测试，我们还需要了解这个更新对于用户来说的接受度如何，所以需要增加一些对比性的问题：比如说：新旧版的操作流畅度、界面表达对比感受。

最后需要注意的是，一次可用性测试能涵盖的范围有限，所以要限制脚本问题的数量，以及对脚本的问题进行优先级的排序。

举个例子，之前做过一个微信端的众筹平台。我就可以设定以下任务：

可用性测试的原型一般是高保真的Demo，可以用Prott，Flinto，proto，墨刀等来制作，制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作，所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考，所以辛苦也是值得的。甚至于，可以请求开发人员制作原生的程序Demo（针对安卓平台），程序Demo体验会更加好。

当然，纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来，然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作，然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用，同时，测试的时间也会大大增长。同时，动效作为设计的一环在这里无法表现出来，所以结果可能会不如高保真Demo来的好。总之各有利弊，根据实际情况来考虑。

测试环境是指测试的时候需要使用的记录设备，通过把测试过程记录下来可以更好地分析用户的行为，特别是用户自己都没有觉察出来的一些东西。

首先，最最重要的一点是录音，录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景，然后填补一些缺失的笔记。另一方面，录音也可以作为一种存档的材料。同时，录音也存在简单、易操作、隐蔽等特点，使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。

录音之外就是录像，如果有录像的话，录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。

除此之外，用户的屏幕记录也是一种方式，通过用户的屏幕、加上用户操作的动作，表情，可以真实还原用户的使用场景，方便后期的分析。

录像和录屏的操作比较难进行，主要的设备可以参考如下【5】，具体可以查看相关的链接：

·摄像机：记录动作和部分表情

·眼动仪：可以追踪眼球的焦点轨迹，不适合移动端

·鼠标轨迹记录：记录鼠标轨迹，只适用于PC端

·QuickTime (iOS)：仅记录屏幕

·Mobizen (Android)：记录屏幕、手势

·Display Recorder (iOS)：手势、声音

·SCR (Android)：记录屏幕、手势、表情、声音

·Magitest (iOS)：记录屏幕、手势、表情、声音

·Mobizen +AirDroid (Android)：现场观察并记录手势、表情、声音

预测试是正式实施可用性测试前的一次模拟， 模拟有助于发现问题，这时候邀请同事即可。把正式测试的流程走一遍，包括设配的调试、访谈切入、问题的提问、记录者的记录等，然后把记录的录音、视频等放出来看看效果如何，效果不如意的时候再进行调整。

总之，预测试可以帮助发现问题，包括以下几个方面的问题：

·设备的问题。举个例子，录音设备放置的位置会影响录音的效果。

·测试脚本的问题。测试问题是否足够清晰。

·访谈的切入以及问题的提问。

·记录者的记录。

发现问题之后去解决问题，才能使正式测试的时候达到更好的效果。

测试前的接待工作是测试人员对公司的第一印象，给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。

首先，可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。

其次，遇上用户迟到的情况下，也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况，如果用户因故取消测试，也要保持友好的态度。

在接到用户之后，送上一杯温水或者温热的饮料，然后让用户等待一下。最后可以有专门的人员先和用户聊聊天，可以打听一些事情。

正式开始之前有个暖场介绍。首先主持人做一下自我介绍，然后介绍一下测试的目的和时间，需要向用户强调测试的对象是系统，希望用户可以畅所欲言。如果有录音或者录像，需要向用户告知会有此类行为，但是结果完全保密。最后还需要签署保密协议。

正式提问分两个部分：个人信息的小问题和可用性测试任务问题。

小问题主要是为了让用户有个适应的过程，可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等，之后的测试问题就是主要的可用性测试的问题。这里需要把问题放入到场景中，让用户在场景中去完成任务。或者可以询问用户的使用习惯，然后引导到脚本中的问题。需要注意的是，不一定要按照脚本的顺序提问，可以随机应变，所以主持人要非常熟悉脚本的内容。除了询问，聆听之外，主持人还要观察用户的神情以及动作，遇上用户有疑问的表情的时候可以适当穿插新的问题，但是尽量不要提供帮助，也不要指出用户的错误或指责动作太慢，但是可以询问用户“为什么这么操作”，必要的时候可以选择停止任务。

测试过程中还需要有一个记录人员，记录人员需要记录：用户做了什么动作和步骤（重点）、用户说了什么、写下自己的疑问（适当时候可以进行提问或者让主持人提问）。

测试结束之后，主持人可以问一下用户的想法，同时让记录人员补充提问，所有问题结束之后，需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。最后要把用户送到公司门口。

测试结束之后，如果有时间可以立马进行整理，因为时间越短，整理出来的内容就越丰富。必要的时候，可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲，根据大纲来整理内容。大纲要具备灵活性，可以记录一下测试现场发现的新问题。

记得只是整理而已，每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结，最终出具一份可用性测试结果，根据这份结果进行相应的改进工作。

我们可以从如下几个维度去分析我们的可用性测试【8】（维度之间可能有交叉）：

a)任务完成度。每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户最终没能完成任务？多少用户需要在主持人提示下完成任务？多少人可以自行完成任务？这些都是很重要的指标

b)致命错误。严重错误指那些阻碍用户完成任务的错误，这些错误非常重要，每一个都要得到足够的重视。

c)非致命错误。非致命错误是指用户能完成任务，但是某些地方会有一些阻滞，会停顿或者思考的错误。这些错误相对来说没那么重要，不过如果发生的次数较多，该类错误也需要得到重视。

d)完成任务的时间。每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。

e)主观情绪。用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。

f)偏好和建议。可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。

【1】Adaptingyour usability testing practise for mobile http://www.userfocus.co.uk/articles/testing-for-mobile.html

【2】移动可用性测试(一):概述 – 腾讯ISUX–社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-one.html

【3】网易公司用户访谈活动招募问卷 http://survey.askform.cn/51194-79597.aspx

【4】用户访谈心得总结– 腾讯CDC http://cdc.tencent.com/?p=5690

【5】移动可用性测试（三）：现场测试– 腾讯ISUX– 社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-three.html

【6】用户研究经验谈-采铜学心录-博客大巴 http://xuexinlu.blogbus.com/c4061443/

【7】简单快速的可用性测试|网易用户体验设计中心 http://uedc.163.com/4151.html

【8】Planninga Usability Test Usability.gov  http://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html

❾ 可用性测试脚本应包含哪些内容

可用性测试脚本应包含：

（1）连接速度测试。用户连接到电子商务网的速度与上网方式有关，他们或许是电话拨号，或是宽带上网。

（2）负载测试。负载测试是在某一负载级别下，检测电子商务系统的实际性能。也就是能允许多少个用户同时在线！可以通过相应的软件在一台客户机上模拟多个用户来测试负载。

（3）压力测试。压力测试是测试系统的限制和故障恢复能力，也就是测试电子商务系统会不会崩溃。

概述

更改目标软件时，需要对测试过程进行局部的可控制的变更。这将使得测试过程和测试脚本对目标软件的变化有更大的应变能力。例如，假设软件的登录部分已经改变。在遍历该登录部分的所有测试用例中，只有关于登录的测试过程和测试脚本需要进行改变。

测试脚本是针对一个测试过程的。一个测试过程往往需要众多的数据来测试。通过自动录制得到的脚本，所有的输入数据都是常数，是固定的。