AutoRunner自动化测试入门：从脚本录制到数据驱动实战

1. 项目概述：软件测试实验五与AutoRunner

如果你是软件工程、计算机科学或相关专业的学生，最近正在为“软件测试实验五”发愁，或者你是一名刚入行的测试工程师，正想找一款上手快、功能全的国产自动化测试工具来练手，那么你很可能已经遇到了“AutoRunner”这个名字。这个实验标题，通常意味着你要从理论走向实践，开始接触功能测试自动化的核心环节——脚本录制与回放。AutoRunner正是泽众软件推出的一款面向C/S（客户端/服务器）和B/S（浏览器/服务器）架构的GUI自动化测试工具，它通过模拟用户操作，将重复、繁琐的手工测试转化为可自动执行的脚本，是很多高校软件测试课程和国内企业入门级自动化测试的常用选择。

简单来说，这次实验的核心目标，就是让你亲身体验如何利用AutoRunner这样的工具，对一个软件（可能是一个简单的Windows计算器、一个Web登录页面，或是课程设计的管理系统）进行自动化测试脚本的创建、执行和验证。这不仅仅是学会点几个按钮，更是理解自动化测试的基本思想、脚本的构成逻辑以及如何将测试用例转化为机器可读的指令。对于面临毕业求职的同学来说，掌握这样一款工具的操作和原理，无疑是简历上非常实在的一笔；对于测试新人，这也是构建自动化测试思维的第一步。接下来，我将以一个过来人的视角，结合常见的实验场景，为你拆解AutoRunner从安装、录制到脚本增强的全过程，并分享那些实验指导书上不会写的“坑”和技巧。

2. AutoRunner核心功能与实验目标解析

2.1 AutoRunner是什么？在实验中的角色定位

AutoRunner（简称AR）是一款国产的自动化功能测试工具。在软件测试的课程体系中，手工测试（黑盒、白盒）和自动化测试是两大支柱。前几个实验你可能还在学习设计测试用例、使用等价类划分、边界值分析等方法，而“实验五”通常是一个转折点，标志着从纯手工、静态的测试设计，转向动态、可重复执行的自动化测试实践。

AutoRunner在其中扮演了“执行者”和“记录者”的双重角色：

1. 执行者 ：它能代替你的双手，自动执行预先设定好的测试步骤，比如点击、输入、选择等。
2. 记录者 ：它可以通过“录制”功能，将你的手动操作过程捕捉下来，生成可复用的测试脚本。

在实验场景下，你可能会用它来完成以下典型任务：

• 对一个Windows桌面应用（如记事本、计算器）进行功能测试自动化 。
• 对一个Web应用（如学校内部的选课系统、图书管理系统）进行登录、查询等操作的自动化 。
• 理解并实践“对象识别”、“参数化”、“检查点”等核心自动化测试概念 。

它的优势在于对国内常见的开发框架（如Java Swing、.NET WinForms）以及主流浏览器（IE、Chrome、Firefox、Edge）有较好的支持，且脚本语言基于Java扩展（BeanShell），对于有Java基础的同学来说更友好。实验的目的不仅是让你“会用”，更是要理解自动化测试如何提升测试效率和一致性，以及它的局限性在哪里。

2.2 实验五通常涵盖的核心技能点

一次完整的AutoRunner实验，绝不仅仅是点开软件录个屏。它通常要求你掌握以下核心技能链，这也是评估你实验报告质量的关键：

1. 环境搭建与工具熟悉 ：正确安装AutoRunner，理解其工作界面（对象库、脚本编辑器、日志窗口等）。
2. 测试对象识别 ：这是自动化测试的基石。你需要理解工具是如何“看到”并记住一个按钮、一个输入框的（通过属性如name、id、class）。实验常会考察你对“标准控件”和“非标准控件”识别差异的理解。
3. 脚本录制与生成 ：学习启动录制、执行操作、停止录制并生成初始脚本。这是最直观的入门步骤。
4. 脚本编辑与增强 ：录制的脚本往往是脆弱且不灵活的。实验会让你学习如何编辑脚本，例如：
   • 插入检查点（Checkpoint） ：验证操作结果是否正确，比如检查登录后是否跳转到正确页面，或某个文本框的值是否符合预期。
   • 参数化（Parameterization） ：将脚本中的固定值（如用户名、密码）替换为变量，实现用多组数据驱动测试。这是自动化测试价值倍增的关键。
   • 添加同步点（Synchronization Point） ：让脚本在某个条件满足（如页面加载完成、某个元素出现）后再继续执行，提高脚本的稳定性。
   • 使用条件判断和循环 ：实现更复杂的测试逻辑。
5. 脚本调试与回放 ：运行脚本，查看执行结果，并根据日志和错误信息进行调试。
6. 测试结果分析 ：理解测试执行报告，能判断测试是通过还是失败，并定位失败原因。

3. AutoRunner实验环境准备与初体验

3.1 实验环境搭建详解

在开始实验前，稳定的环境是成功的一半。根据我多年的经验，环境问题能卡住一半以上的初学者。

1. 获取与安装AutoRunner： 通常，学校实验室或老师会提供AutoRunner的安装包。如果没有，可以访问泽众软件的官网下载试用版。安装过程本身是标准的Windows安装向导，但有几个关键点需要注意：

注意 ：安装路径建议选择全英文目录，避免中文路径可能带来的潜在问题。同时，确保你有足够的磁盘权限（如果是在学校机房，可能需要管理员权限）。

2. 浏览器与Java环境配置：

• 浏览器 ：AutoRunner对IE的支持通常最稳定。如果你实验的对象是Web应用， 强烈建议使用IE浏览器进行首次录制和回放 。对于Chrome、Firefox或Edge，可能需要安装对应的浏览器插件或进行特定配置，这些步骤在实验指导书中应有说明，务必仔细阅读。
• Java环境 ：由于AutoRunner的脚本基于Java扩展，确保系统已安装合适版本的JRE（Java Runtime Environment）。可以在命令行输入 java -version 来检查。如果没有，需要去Oracle官网下载安装。

3. 被测应用程序准备： 明确你的测试对象。如果是Windows应用，确保它已安装并可正常运行。如果是Web应用，确保你能在本地或局域网内稳定访问。 在开始录制前，最好先手动完整走一遍你要自动化的测试流程 ，确保所有步骤都是通畅的。

3.2 第一个脚本：从录制一个登录操作开始

理论讲再多，不如动手做一遍。我们以最常见的“Web系统登录”作为第一个实验脚本。

步骤1：启动AutoRunner并创建项目 打开AutoRunner，通常会有一个欢迎界面引导你创建新项目。给项目起个有意义的名字，比如“WebLoginTest”。项目是管理所有相关脚本、对象库和资源的基本单位。

步骤2：开启录制，执行操作

1. 在AutoRunner中找到“录制”或类似按钮。在录制开始前，工具通常会让你选择录制类型（Windows应用、Web浏览器等）。
2. 选择“Web”类型，并指定浏览器（如IE）。点击开始。
3. AutoRunner会启动你指定的浏览器。此时，你在浏览器中的所有操作都会被记录。
4. 在地址栏输入被测系统的登录页地址（例如 http://localhost:8080/login ）。
5. 在用户名输入框输入“testuser”，在密码框输入“password123”，点击“登录”按钮。
6. 登录成功后，可能跳转到主页。此时，点击AutoRunner录制工具栏的“停止”按钮。

步骤3：查看生成的脚本 停止录制后，AutoRunner会自动生成脚本并显示在脚本编辑器中。你看到的可能是一系列类似下面的命令（以下为示意代码，非真实语法）：

// 这是一个示意性的BeanShell脚本结构
startBrowser("ie", "http://localhost:8080/login");
edit_set("username_input", "testuser"); // 在名为‘username_input’的对象中输入值
edit_set("password_input", "password123"); // 输入密码
button_click("login_button"); // 点击登录按钮
// 后续可能还有对登录成功页面的验证

同时，所有你操作过的界面元素（输入框、按钮）都会被捕获并存入“对象库”中。对象库是AutoRunner的核心，它存储了每个控件的识别属性（如ID、Name、XPath等）。

步骤4：首次回放与验证 在脚本编辑器中，点击“运行”或“回放”按钮。AutoRunner会重新打开浏览器，并自动执行刚才录制的步骤。如果一切顺利，你会看到浏览器自动完成了登录操作。

实操心得 ：第一次回放失败的概率不低。常见原因有：浏览器启动慢导致脚本执行过快；页面元素加载未完成；对象属性动态变化（如ID带随机数）。如果失败，不要慌，仔细查看工具输出的“执行日志”，里面通常会告诉你哪一行脚本失败了，原因是什么。这是学习调试脚本的第一步。

4. 脚本增强：让录制脚本变得可靠和强大

直接录制的脚本我们称之为“线性脚本”或“脆弱的脚本”。它只能原封不动地重复你的操作，任何细微的变化（如页面加载慢了半秒、用户名输入框的ID变了）都可能导致脚本失败。实验的高阶部分，就是学习如何加固和增强这个脚本。

4.1 对象库管理与对象识别原理

为什么脚本能找到那个按钮？ 这依赖于对象库。在对象库中，每个控件都有一组用于识别的属性，比如：

• 类型（Class） ： WebEdit , WebButton
• 名称（Name） ： username
• ID ： txtUser
• XPath ： //input[@id='txtUser']

当回放脚本执行 edit_set(“username_input”, “testuser”) 时，AutoRunner会拿着“username_input”这个名字去对象库查找对应的属性定义，然后根据这些属性在当前页面上定位到那个真实的输入框。

实验中的常见问题与处理：

• 对象识别失败 ：这是头号杀手。可能因为页面结构变了，或者控件属性是动态生成的。 解决方案 ：
  1. 使用更稳定的属性 ：优先选择 id 、 name 这类通常比较固定的属性，避免使用自动生成的 class 或 index 。
  2. 使用XPath或CSS选择器 ：如果标准属性不稳定，可以手动在对象库中为该对象添加一个更精确的XPath。这需要你了解一点HTML和XPath知识。
  3. 使用“图像识别”作为备选 ：AutoRunner支持将无法识别的控件截图，作为图像对象来操作。这在处理一些自定义绘制或非常规控件时是最后的救命稻草，但执行效率较低，且对界面变化极其敏感。
• 对象库维护 ：随着被测应用迭代，对象属性可能改变。定期使用工具的“重新识别”或“更新对象”功能来维护对象库是必要的。在实验中，你可能需要手动编辑对象属性来适应变化。

4.2 插入检查点：让测试拥有“判断力”

录制的脚本只会操作，不会判断对错。插入检查点，就是告诉脚本：“执行到这里，检查一下某个东西是不是符合预期”。

常见的检查点类型：

1. 属性检查 ：检查某个控件的属性值，例如检查登录后的欢迎信息文本是否包含用户名“testuser”。
2. 文本检查 ：检查页面上特定区域的文本内容。
3. 数据库检查 （高级）：在操作后，通过SQL查询验证数据库中的数据是否被正确更新（这通常需要额外的配置和脚本编写）。

在AutoRunner中插入检查点： 通常在脚本编辑界面，有“插入检查点”的选项。你需要先选中要检查的页面对象（比如一个显示“登录成功”的标签），然后选择检查的类型和预期值。工具会自动在脚本中生成类似 checkProperty(“welcome_label”, “innerText”, “欢迎，testuser”) 的语句。

实验技巧 ：不要滥用检查点。只在关键的业务断言点插入。过多的检查点会降低脚本执行速度，并增加维护成本。通常，一个主要的业务流程（如登录-查询-登出）设置2-3个核心检查点即可。

4.3 参数化：实现数据驱动测试

这是自动化测试从“自动化操作”升维到“自动化测试”的关键。参数化意味着将脚本中的固定测试数据（如用户名、密码）提取出来，用变量代替，然后从外部数据源（如Excel、CSV文件或数据库）读取多组数据来循环执行同一脚本。

在AutoRunner中实现参数化的基本步骤：

1. 创建数据源 ：最常见的是使用Excel文件。创建一个Excel，第一行是列名（如 Username , Password , ExpectedResult ），下面每一行是一组测试数据。
2. 在脚本中定义参数 ：将脚本中的硬编码值 “testuser” 替换为一个参数变量，例如 @{Username} 。
3. 绑定数据源 ：在AutoRunner中配置，将脚本参数 @{Username} 与Excel文件的 Username 列关联起来。
4. 设置循环 ：配置脚本循环执行，每次循环读取下一行数据。

这样，你只需要维护一个Excel文件，就能用几十组甚至上百组数据（包括有效数据和无效数据）来测试登录功能，极大地提高了测试覆盖率和效率。

注意事项 ：参数化时，要特别注意数据之间的关联性和测试场景的独立性。例如，如果测试用例依赖于上一条用例创建的数据，就需要在脚本中处理这种依赖，或者确保每条用例都是独立的。

4.4 添加同步与等待：解决“脚本跑得比页面快”的问题

这是新手最常踩的坑。你的脚本执行速度是毫秒级的，但页面加载、网络请求可能需要几秒。如果脚本在页面元素还没出现时就尝试去点击，肯定会失败。

AutoRunner提供的解决方案：

1. 隐式等待（全局等待） ：在工具设置或脚本开头，设置一个默认的等待超时时间（如10秒）。在查找元素时，如果没立刻找到，工具会持续等待直到超时。
2. 显式等待（同步点） ：在关键操作前，插入一个“等待”命令，明确等待某个特定条件满足。例如，等待“登录成功”的提示框出现，或者等待某个按钮变为可点击状态。这比隐式等待更精确、更高效。
3. 固定等待（Sleep） ：使用 sleep(3000) 让脚本强制暂停3秒。这是最不推荐但有时最简单粗暴的方法，因为它会浪费不必要的等待时间，且无法适应不同运行环境的速度差异。

实验建议 ：优先使用“等待对象出现”这类显式同步点。在录制脚本后，回顾并在每个可能导致页面跳转或刷新的操作后，手动添加合适的等待命令。

5. 实验项目实战：构建一个完整的自动化测试用例

假设你的实验任务是“对XX学生信息管理系统的‘学生信息查询’功能进行自动化测试”。我们来拆解一个完整的实现流程。

5.1 测试用例分析与设计

首先，不要急着打开AutoRunner。拿出一张纸或打开思维导图工具，分析手动测试“学生信息查询”的步骤：

1. 打开系统登录页。
2. 输入管理员账号密码登录。
3. 导航到“学生管理”->“信息查询”菜单。
4. 在查询页面，输入不同的查询条件（如学号、姓名、学院）。
5. 点击“查询”按钮。
6. 验证结果列表是否正确显示预期记录。
7. 点击“退出”或关闭浏览器。

然后，设计自动化脚本的结构：

• 脚本模块化 ：将“登录”作为一个公共函数或单独脚本，供其他业务流程调用。
• 参数化设计 ：查询条件（学号、姓名）需要参数化。
• 检查点设计 ：在登录后检查用户名；在查询后，检查结果表格的第一条记录的学号或姓名是否与查询条件匹配（这里可能涉及动态数据的验证，是难点）。
• 异常流考虑 ：是否测试无效查询条件（如不存在的学号）？预期结果应该是“未找到相关记录”的提示。这需要额外的检查点。

5.2 分步实现与脚本编写

步骤1：录制基础操作流 按照设计好的正常流，录制从登录到查询的完整操作。录制时动作可以慢一点、清晰一点。录制完成后，保存脚本，命名为 StudentQuery_Main 。

步骤2：封装登录模块 将登录部分的脚本代码抽取出来，保存为一个独立的脚本文件 Login_Admin ，或者封装成一个可调用的函数。在AutoRunner中，可以通过“脚本调用”功能来实现。

步骤3：参数化查询条件 在 StudentQuery_Main 脚本中，找到输入查询条件的语句（如 edit_set(“studentId_input”, “2023001”) ）。将其中的固定值 “2023001” 替换为参数，例如 @{QueryStudentId} 。然后创建一个Excel数据文件 QueryData.xlsx ，里面包含多组测试数据。

步骤4：插入关键检查点

• 在登录后，插入属性检查，验证页面标题或某个欢迎语。
• 在点击查询后，插入一个“等待”命令，等待结果表格加载完成。
• 在结果表格出现后，插入文本检查。这里有个技巧：如果结果行是动态的，你可以检查结果表格不为空，或者检查表格中是否包含查询关键字。更精确的做法是，通过脚本获取第一行第一列单元格的文本，与预期值进行比较。这可能需要编写一些简单的BeanShell脚本来提取页面元素文本。

步骤5：处理查询无结果的情况 增加一组测试数据，其学号在系统中不存在。在脚本中，需要添加一个判断：如果出现了“未找到记录”的提示信息，则视为测试通过；如果错误地显示了结果表格，则测试失败。这需要用到条件判断语句（if-else）。

5.3 脚本调试与执行

编写完成后，不要一次性运行所有数据。 采用“单步调试”或“逐行执行”模式 ，先用第一组数据跑一遍，观察每一步的执行情况，查看对象库中的对象是否被正确识别，检查点是否生效。

调试常见问题清单：

• 对象找不到 ：回放日志会报错“无法定位对象”。回到对象库，检查该对象的属性在当前页面上是否还匹配。可能需要重新识别或修改识别属性。
• 检查点失败 ：预期值与实际值不符。检查是应用逻辑错误，还是你的检查点设置得太严格（比如包含了多余的空格或换行）。
• 脚本执行顺序错误 ：有时因为页面加载问题，脚本可能先执行了下一步操作。在关键步骤前后增加同步点。
• 数据驱动循环出错 ：检查Excel文件格式是否正确，参数绑定是否准确，确保文件路径没有空格或中文。

调试通过后，再以“批量执行”模式运行所有测试数据。最后，查看AutoRunner生成的测试报告，报告会清晰列出每条用例的执行结果（通过/失败）、执行时间以及失败时的截图和日志，这对于编写实验报告至关重要。

6. 进阶技巧与实验报告撰写要点

6.1 超越录制：编写更健壮的脚本

当你能熟练使用录制、参数化和检查点后，可以尝试一些“编码”工作，让脚本更智能、更健壮。

1. 使用条件逻辑（If-Else） ：BeanShell脚本支持Java语法。你可以用if语句来处理不同的测试场景。例如：

   // 伪代码示意
   String resultText = getText(“result_label”);
   if (resultText.contains(“成功”)) {
       log.info(“查询成功！”);
       // 执行成功后的验证
   } else {
       log.error(“查询失败：” + resultText);
       // 执行失败后的处理或截图
   }
   

2. 使用循环（For/While） ：除了工具自带的数据驱动循环，你可以在脚本内写循环来处理重复性操作，比如遍历一个表格的所有行进行检查。
3. 错误处理与恢复 ：尝试使用 try-catch 块来捕获预期中的异常（如元素未找到），并执行恢复操作（如刷新页面、重新登录），而不是让整个脚本崩溃。
4. 调用外部函数或命令 ：通过BeanShell，你可以调用系统命令、读写文件，甚至调用其他Java类库，极大地扩展了自动化测试的能力边界。

6.2 撰写一份出色的实验报告

实验报告不仅是记录过程，更是展示你思考和分析能力的窗口。一份好的AutoRunner实验报告应包含以下部分：

1. 实验目的与要求 ：清晰复述实验任务。
2. 实验环境 ：列出AutoRunner版本、被测系统信息、浏览器版本、操作系统等。
3. 测试需求分析 ：用文字或流程图描述你要自动化的测试场景（如登录、查询）。
4. 自动化测试设计 ：
   • 测试用例设计 ：将手动测试用例转化为自动化测试用例表格，包含用例ID、步骤、输入数据、预期结果。
   • 框架设计 （如果涉及）：说明你是否采用了模块化（如公共登录模块）、数据驱动等设计。
   • 对象识别策略 ：简要说明你主要依靠哪些属性来识别对象，对特殊控件如何处理。
5. 实现过程与关键代码 ：
   • 截图 ：包括AutoRunner项目结构、对象库截图、关键脚本代码截图、参数化数据源截图。
   • 代码说明 ：对脚本中的关键片段（如参数化设置、检查点插入、同步点添加）进行解释。
6. 测试执行与结果分析 ：
   • 执行结果截图 ：展示最终的测试报告，突出显示通过和失败的用例。
   • 问题与解决 ：这是报告的精华部分。详细记录你在实验中遇到的所有问题（如对象识别不稳定、脚本执行超时、检查点误报等），以及你是如何分析并解决这些问题的。这能充分体现你的调试能力和解决问题的思路。
7. 实验总结与思考 ：
   • 收获 ：你学会了哪些AutoRunner的核心功能？对自动化测试的理解有何加深？
   • 局限性认识 ：通过实践，你认为AutoRunner或这类录制回放工具的局限性是什么？（例如，对动态Web应用支持不佳、维护成本随UI变化而增高等）。
   • 改进设想 ：如果时间更充裕，你会如何改进你的测试脚本或框架？是否想到了与持续集成（CI）工具结合？

7. 避坑指南与经验总结

结合我自己和学生们常踩的坑，这里有一份速查清单：

• 环境隔离 ：尽量在干净的测试环境中进行。避免在录制和回放时，有其他弹窗或软件干扰（如杀毒软件提示、系统更新）。
• 浏览器专注模式 ：录制Web脚本时，关闭浏览器的密码自动填充、表单自动完成等功能，这些可能会干扰脚本的输入操作。
• 使用相对稳定的定位方式 ：优先选择 id 和 name 。如果都没有，再考虑 XPath ，但尽量编写简洁、稳定的XPath，避免使用绝对路径和包含大量索引的表达式。
• “慢就是快” ：在关键操作后（如点击提交按钮、页面跳转），主动添加一个显式等待，这比事后调试脚本节省大量时间。
• 版本控制你的脚本 ：虽然实验项目小，但养成好习惯。将你的AutoRunner项目文件夹（包含脚本、对象库、数据文件）用Git管理起来。这样你可以回溯任何修改，也方便在不同电脑间同步。
• 理解“对象库”是核心资产 ：对象库维护得好，脚本就稳定。定期检查对象属性，对于频繁变化的元素，考虑使用更灵活的定位策略，或者与开发人员约定一些固定的测试属性（如 data-testid ）。
• 不要追求100%自动化 ：尤其是在实验和学习阶段。自动化测试最适合那些稳定、重复、冒烟级别的测试用例。将复杂、易变的探索性测试留给手工。认清自动化测试的定位，是提升效率的工具，而非取代测试工程师的银弹。

最后，软件测试实验五的核心价值，不在于你多么熟练地点击了AutoRunner的某个按钮，而在于你通过这个工具，切身理解了自动化测试的 价值 （效率、一致性、回归）、 成本 （脚本开发与维护）和 边界 （什么适合自动化，什么不适合）。当你下次听到“自动化测试框架”、“持续集成”、“脚本维护成本”这些词时，你脑子里浮现的不再是抽象的概念，而是你亲手录制、调试、最终成功运行的那个脚本，以及它背后一整套的实践逻辑。这才是这门实验课留给你的，比工具操作本身更重要的东西。