我在理解测试harness和自动化测试中的测试用例、测试脚本等相关常用术语方面遇到了一些困难。
所以这就是我到目前为止得到的：
自动化测试是使用特殊的软件（被测试的软件除外）来控制测试的执行并将实际结果与预期结果进行比较。它还涉及设置测试先决条件。这种测试最适合经常进行的测试。
现在，我在测试工具方面遇到了一些问题。我读到它由测试用例、输入文件、输出文件和测试脚本组成的测试套件组成。现在我的问题是测试用例和测试脚本有什么区别？
您如何使用该软件来测试验收单元测试 (AUT) 的不同功能？我还遇到了一些术语，例如套件大师和案例代理。
那里有几个广泛的问题，将根据我的经验尝试回答。
将测试工具想象成一个“推动者”，它实际上完成了所有工作：(1)使用 (2)测试库执行测试和 (3)生成报告。这将要求您的测试脚本旨在处理不同的 (4)测试数据和 (5)测试场景。本质上，当测试工具到位并准备好先决条件数据（又名数据准备）时，应该能够单击一个按钮或运行一个命令来执行所有测试并生成报告。
测试工具很可能是使上述所有事情发生的不同事物的集合。如果您在开发应用程序时编写单元测试，那将是测试工具的一部分。您还将对应用程序的功能进行其他测试，例如：用户登录站点、查看收藏夹窗格、最近的消息和通知。然后你添加一个“运行器”，它会遍历你所有的“测试脚本”并运行它们（而不是你必须一次执行一个测试）。如果感觉测试工具更像是一个概念集合而不是单个软件，那么您就正确理解了这一点:-)
现在我的问题是测试用例和测试脚本有什么区别？
简单但不完全正确的答案：测试用例定义了测试目标、描述、前提条件、步骤（描述性或特定性）、预期结果。然后，测试脚本将是您执行该测试的实际自动化脚本。那是在自动化环境中。它会改变。很多。
像 ISTQB 这样的认证定义为测试场景在一些公司和国家通常被称为测试用例。在其他情况下，当提到手动测试时（当详细给出步骤但不是自动化工具的一部分时），测试用例会被测试脚本翻转。其他人说测试脚本完全意味着自动化测试。另一方面，人们也可以争辩说，多个测试用例可以组合在一个测试脚本中，反之亦然。那么这就引出了一个问题，测试程序如何适应？
一个测试开发阶段可以有：“测试程序、测试场景、测试用例、测试数据集、测试脚本在测试软件中使用。”
如果您假设>（大于/集合）关系，您将如何关联这些关系？修辞问题-根据您的工作地点，客户是谁等而有所不同。最好的办法是与您的同事/客户一起定义它，并就对术语的理解而不是定义达成一致。我目前使用测试脚本 = 自动化脚本，基于预先存在的手动测试用例或测试场景。
另外，您如何使用该软件来测试 AUT 的不同功能？
你编写不同的测试来测试不同的东西。每个测试都会执行某些操作并检查 AUT 的输出是否符合您的预期 - If displayed_value == expected_value。例如，输入文件可用于为测试用户名和密码的测试列表提供数据。或者使用不同的数据运行相同的测试 - 使用不同的消息以不同的用户身份登录，等等。
看看RobotFramework和Selenium。与 Selenium 库相结合的机器人框架测试（以文本或 html 文件编写）将允许您编写测试特定内容的自动化测试……例如主页验证。您将编写一个单独的测试以确保用户可以看到他/她的所有消息。另一个测试清除通知。等等。
测试工具：由执行测试所需的存根和驱动程序组成的测试环境。
测试工具和存根将用于复制缺失的项目（尚未包含在测试或外部系统中的组件）。通常，当执行多个模块或组件的小规模集成测试时，有必要设计或即兴创作方法和工具以将测试数据获取到被测组件。这通常称为测试工具。由于需要了解构建测试工具所需的技术细节，因此该测试几乎总是由开发团队完成。
测试工具可以通过模拟测试对象将在其中运行的环境来促进组件或系统部分的测试。这可能是因为该环境的其他组件尚不可用并被存根和/或驱动程序替换，或者只是为了提供可预测和可控的环境，在该环境中任何故障都可以定位到被测对象。这些通常是由开发人员生成的定制程序，以帮助测试过程。如果在成熟的组织中使用它们，这些工具很可能会被视为“测试资产”并受版本控制和配置管理的约束。
测试工具包含编译和运行测试所需的所有信息。这包括测试用例、被测源文件、存根和目标部署端口 (TDP) 配置设置。
测试工具是在单元、模块、应用程序或系统级别测试软件所需的所有项目的集合，并提供执行测试的机制。输入数据、测试参数、测试用例、测试脚本、预期输出数据、测试工具和测试结果报告等每一项都是测试工具的一部分。