大型机测试 – 完整教程

作者： Thomas Hamilton Thomas Hamilton
时间 - 权威教程 更新于

在学习大型机测试概念之前，让我们先了解一下

什么是大型机？

大型机是一种高性能、高速的计算机系统。它用于需要高可用性和安全性的更大规模的计算目的。它主要用于金融、保险、零售和其他需要多次处理大量数据的关键领域。

大型机测试

大型机测试是测试基于大型机系统的软件应用程序和服务的流程。大型机测试的目的是通过验证和确认方法来确保软件应用程序或服务的性能、可靠性和质量，并检查其是否已准备好部署。

在执行大型机测试时，测试人员只需了解 CICS 屏幕的导航。它们是为特定应用程序定制的。无论 COBOL、JCL 等代码中做了什么更改，测试人员都不必担心机器上的模拟器设置。在一个终端模拟器上能正常工作的更改在其他模拟器上也能正常工作。

  • 大型机应用程序（也称为批处理作业）根据使用需求开发的测试用例进行测试
  • 大型机测试通常在已部署的代码上进行，使用输入文件中设置的各种数据组合。
  • 在大型机上运行的应用程序可以通过终端模拟器访问。模拟器是唯一需要在客户端机器上安装的软件。

大型机属性

  1. 虚拟存储
    1. 它是一种技术，允许处理器模拟比实际真实存储量更大的主存储。
    2. 它是一种有效利用内存来存储和执行各种大小任务的技术。
    3. 它将磁盘存储用作实际存储的扩展。
  2. 多道程序设计
    1. 计算机同时执行多个程序。但在任何给定时刻，只有一个程序可以控制 CPU。
    2. 它是一种旨在有效利用 CPU 的设施。
  3. 批处理
    1. 它是一种通过以称为“作业”的单元完成任何任务的技术。
    2. 一个作业可能导致一个或多个程序按顺序执行。
    3. 作业调度程序根据作业的优先级和类别决定作业的执行顺序，以最大化平均吞吐量。
    4. 批处理所需的信息通过 JCL (JOB CONTROL LANGUAGE) 提供。JCL 描述了批处理作业——所需的程序、数据和资源。
  4. 分时
    1. 在分时系统中，每个用户都可以通过终端设备访问系统。用户不是提交计划稍后执行的作业，而是输入立即处理的命令。
    2. 因此这被称为“交互式处理”。它使用户能够直接与计算机交互。
    3. 分时处理被称为“前台处理”，批处理作业处理被称为“后台处理”。
  5. 假脱机
    1. SPOOLing 代表 Simultaneous Peripheral Operations Online（同步外围操作在线）。
    2. SPOOL 设备用于存储程序/应用程序的输出。假脱机输出将（如果需要）定向到打印机等输出设备。
    3. 它是一种利用缓冲优势来有效利用输出设备的设施。

大型机手动测试的分类

大型机手动测试可分为两种类型

1. 批处理作业测试 –

  • 测试过程涉及执行当前版本中实现的功能的批处理作业。
  • 从输出文件和数据库中提取的测试结果经过验证和记录。

2. 在线测试 –

  • 在线测试是指对 CICS 屏幕的测试，类似于对网页的测试。
  • 现有屏幕的功能可能会改变，或者可能会添加新屏幕。
  • 各种应用程序可以有查询屏幕和更新屏幕。这些屏幕的功能需要作为在线测试的一部分进行检查。

如何进行大型机测试

  1. 业务团队准备需求文档。这决定了特定项目或流程将在发布周期中如何修改。
  2. 测试团队和开发团队收到需求文档。他们将确定有多少流程会受到更改的影响。通常，在一个发布中，只有 20-25% 的应用程序直接受到定制需求的影响。其余 75% 的发布将用于开箱即用功能，如测试应用程序和流程。
  3. 因此，大型机应用程序必须分两部分进行测试
    1. 测试需求 – 根据需求文档中提及的功能或更改测试应用程序。
    2. 测试集成 – 测试整个流程或向受影响应用程序发送或接收数据的其他应用程序。回归测试是此测试活动的主要重点。

相关文章

大型机自动化测试工具

以下是可用于大型机自动化测试的工具列表。

  • REXX
  • Excel
  • QTP

大型机测试中的方法论

让我们考虑一个例子：一家 XYZ 保险公司有一个会员注册模块。它既从会员注册屏幕获取数据，也从线下注册获取数据。如前所述，大型机测试有两种方法：在线测试和批处理测试。

  • 在线测试在会员注册屏幕上完成。就像网页一样，数据库通过屏幕输入的数据进行验证。
  • 线下注册可以是纸质注册或在第三方网站上的注册。线下数据（也称为批处理）将通过批处理作业输入到公司数据库中。根据预定数据格式准备一个输入平面文件，并将其馈送到一系列批处理作业中。因此，对于大型机应用程序测试，我们可以使用以下方法。
  • 批处理作业链中的第一个作业验证输入的数据。例如，特殊字符，仅限数字字段中的字母等。
  • 第二个作业根据业务条件验证数据的一致性。例如，儿童注册不应包含受抚养人数据，会员邮政编码（已注册计划无法提供服务）等。
  • 第三个作业修改数据，使其格式可以输入到数据库中。例如，删除计划名称（数据库将仅存储计划 ID 和保险计划名称），附加输入日期等。
  • 第四个作业将数据加载到数据库中。
  • 批处理作业测试在此过程中分两个阶段完成——
  • 每个作业分别验证，并且
  • 通过向第一个作业提供输入平面文件并验证数据库来验证作业之间的集成。（中间结果必须经过验证以格外小心）

以下是大型机测试所遵循的方法

步骤 1) 抖动/冒烟测试

此阶段的主要重点是验证部署的代码是否在正确的测试环境中。它还确保代码没有关键问题。

步骤 2) 系统测试

以下是作为系统测试一部分完成的测试类型。

  1. 批处理测试 – 此测试将通过验证输出文件中的测试结果以及测试范围内的批处理作业所做的数据更改并记录它们来完成。
  2. 在线测试 – 此测试将在大型机应用程序的前端进行。在此，应用程序将针对正确的输入字段进行测试，例如保险计划、计划利息等。
  3. 在线-批处理集成测试 – 此测试将在具有批处理流程和在线应用程序的系统上进行。将验证在线屏幕和批处理作业之间的数据流和交互。

    （此类测试示例 – 考虑对计划详细信息（例如利率增加）进行更新。利率更改在更新屏幕上完成，受影响账户的余额详细信息将仅由夜间批处理作业修改。在这种情况下，测试将通过验证计划详细信息屏幕和用于更新所有账户的批处理作业运行来完成）。

  4. 数据库测试 – 将验证大型机应用程序数据（IMS、IDMS、DB2、VSAM/ISAM、顺序数据集、GDG）所在的数据库的布局和数据存储。

步骤 3) 系统集成测试

此测试的主要目的是验证与被测系统交互的系统的功能。

这些系统不受需求直接影响。但是，它们使用来自被测系统的数据。测试接口和系统之间可能流动的不同类型的消息（如作业成功、作业失败、数据库更新等）以及各个系统采取的相应操作非常重要。

在此阶段完成的测试类型有

  1. 批处理测试
  2. 在线测试
  3. 在线 – 批处理集成测试

步骤 4) 回归测试

回归测试是任何类型测试项目中的一个常见阶段。大型机中的此测试可确保不直接与被测系统交互（或不属于需求范围）的批处理作业和在线屏幕不受当前项目发布的影响。

为了进行有效的回归测试，应根据其复杂性筛选出一组特定的测试用例，并创建一个回归测试床（测试用例存储库）。每当发布新功能时，都应更新此集合。

步骤 5) 性能测试

此测试旨在识别高命中区域（如前端数据、升级在线数据库）的瓶颈，并预测应用程序的可伸缩性。

步骤 6) 安全测试

此测试旨在评估应用程序在应对反安全攻击方面的设计和开发情况。

应在系统上进行双重安全测试——大型机安全和网络安全。

需要测试的功能有

  1. 完整性
  2. 保密性
  3. 授权
  4. 认证
  5. 可用性

批处理测试中涉及的步骤

  1. QA 团队收到批准的包（包包含过程、JCL、控制卡、模块等）后，测试人员应根据需要预览并检索内容到 PDS 中。
  2. 将生产 JCL 或开发 JCL 转换为 QA JCL，也称为作业设置。
  3. 复制生产文件并准备测试文件。
  4. 对于每个功能，都将定义一个作业序列。（如大型机方法论示例中所述）。应使用 SUB 命令和测试数据文件提交作业。
  5. 检查中间文件，以识别数据缺失或出错的原因。
  6. 检查最终输出文件、数据库和假脱机以验证测试结果。
  7. 如果作业失败，假脱机将包含作业失败的原因。解决错误并重新提交作业。

测试报告 – 如果实际结果与预期结果不符，则应记录缺陷。

在线测试中涉及的步骤

  1. 在测试环境中选择在线屏幕。
  2. 测试每个字段是否接受数据。
  3. 测试屏幕上的测试场景。
  4. 验证数据库中在线屏幕的数据更新。

测试报告 – 如果实际结果与预期结果不符，则应记录缺陷。

在线-批处理集成测试中涉及的步骤

  1. 在测试环境中运行作业，并验证在线屏幕上的数据。
  2. 更新在线屏幕上的数据，并验证批处理作业是否已使用更新后的数据正确运行。

大型机测试中使用的命令

  1. SUBMIT – 提交后台作业。
  2. CANCEL – 取消后台作业。
  3. ALLOCATE – 分配数据集
  4. COPY – 复制数据集
  5. RENAME – 重命名数据集
  6. DELETE – 删除数据集
  7. JOB SCAN – 将 JCL 与程序、库、文件等绑定，而不执行它。

需要时还会使用许多其他命令，但它们并不常用。

开始大型机测试的先决条件

大型机测试所需的基本详细信息包括

  • 用于登录应用程序的登录 ID 和密码。
  • ISPF 命令的简要知识。
  • 文件的名称、文件限定符及其类型。

在开始大型机测试之前，应验证以下方面。

  1. 作业
    1. 在执行作业之前，先进行作业扫描（命令 – JOBSCAN）以检查错误。
    2. CLASS 参数应指向测试类。
    3. 使用 MSGCLASS 参数将作业输出定向到假脱机或 JHS 或根据需要。
    4. 将作业中的电子邮件重新路由到假脱机或测试邮件 ID。
    5. 在初始测试中注释 FTP 步骤，然后将作业指向测试服务器。
    6. 如果作业中生成了 IMR（事件管理记录），只需在作业或参数卡中添加注释“测试目的”。
    7. 作业中的所有生产库都应更改并指向测试库。
    8. 作业不应无人看管。
    9. 为防止作业在发生任何错误时进入无限循环，应添加 TIME 参数并指定时间。
    10. 保存作业的输出，包括假脱机。假脱机可以使用 XDC 保存。
  1. 文件
    1. 仅创建所需大小的测试文件。必要时使用 GDG（生成数据组 – 具有相同名称但具有顺序版本号的文件 – MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 等）将数据存储到具有相同名称的连续文件中。
    2. 应正确编码文件的 DISP（处置 – 描述系统在步骤或作业正常或异常终止后执行保留或删除数据集）参数。
    3. 确保所有用于作业执行的文件都已正确保存和关闭，以防止作业进入 HOLD 状态。
    4. 使用 GDG 进行测试时，请确保指向正确的版本。
  2. 数据库
    1. 执行作业或在线程序时，确保不会插入、更新或删除意外数据。
    2. 此外，请确保使用正确的 DB2 区域进行测试。
  3. 测试用例
    1. 始终测试边界条件，例如 – 空文件、第一个记录处理、最后一个记录处理等。
    2. 始终包括正面和负面测试条件。
    3. 如果程序中使用标准过程，如检查点重启、异常终止模块、控制文件等，请包含测试用例以验证模块是否已正确使用。
  4. 测试数据
    1. 测试数据设置应在测试开始之前完成。
    2. 未经通知，切勿修改测试区域上的数据。可能还有其他团队使用相同的数据，他们的测试会失败。
    3. 如果在执行期间需要生产文件，应在复制或使用它们之前获得适当的授权。

最佳实践

  1. 在批处理作业运行的情况下，MAX CC 0 表示作业已成功运行。但这并不意味着功能运行良好。即使输出为空或不符合预期，作业也会成功运行。因此，始终期望在宣布作业成功之前检查所有输出。
  2. 对被测作业进行空运行始终是一个好习惯。空运行是使用空输入文件完成的。对于受测试周期更改影响的作业，应遵循此过程。
  3. 在测试周期开始之前，应提前完成测试作业设置。这将有助于提前发现任何 JCL 错误，从而节省执行时间。
  4. 通过 SPUFI（模拟器上访问 DB2 表的选项）访问 DB2 表时，始终将自动提交设置为“NO”，以避免意外更新。
  5. 测试数据可用性是批处理测试中的主要挑战。所需数据应在测试周期开始前充分创建，并检查其完整性。
  6. 某些在线事务和批处理作业可能会将数据写入 MQ（消息队列）以将数据传输到其他应用程序。如果数据无效，可能会禁用/停止 MQ，这将影响整个测试过程。测试后检查 MQ 是否正常工作是一个好习惯。

大型机测试的挑战和故障排除

挑战 方法
不完整/不明确的需求

可能存在用户手册/培训指南，但这些与文档化的需求不同。		 测试人员应从需求阶段开始参与 SDLC。这将有助于验证需求是否可测试。
数据设置/识别

可能存在需要根据需求重用现有数据的情况。有时很难从现有数据中识别所需数据。		 对于数据设置，可以根据需要使用自制工具。对于获取现有数据，应提前构建查询。如果遇到任何困难，可以向数据管理团队提出请求以创建或克隆所需数据。
作业设置

一旦作业被检索到 PDS 中，就需要将其设置在 QA 区域中。这样，作业就不会使用生产限定符或路径详细信息提交。		应使用作业设置工具，以克服设置过程中人为造成的错误。
临时请求

可能存在由于上游或下游应用程序问题而需要支持端到端测试的情况。这些请求增加了执行周期的时间和精力。		使用自动化脚本、回归脚本和骨架脚本有助于减少时间和精力开销。
范围变更的按时发布

可能存在代码影响可能完全改变系统外观的情况。这可能需要更改测试用例、脚本和数据。		 应制定范围变更管理流程和影响分析。

遇到的常见异常终止

  1. S001 – 发生 I/O 错误。

    原因 – 读取到文件末尾、文件长度错误、尝试写入只读文件。

  2. S002 – 无效的 I/O 记录。

    原因 – 尝试写入比记录长度更长的记录。

  3. S004 – OPEN 期间发生错误。

    原因 – 无效的 DCB

  4. S013 – 打开数据集时出错。

    原因 – PDS 成员不存在，程序中的记录长度与实际记录长度不匹配。

  5. S0C1 – 操作异常

    原因 – 无法打开文件，缺少 DD 卡

  6. S0C4 – 保护异常/存储冲突
  7. 原因 – 尝试访问程序不可用的存储。
  8. S0C7 – 程序检查异常 – 数据
  9. 原因 – 记录布局或文件布局发生更改。
  10. Sx22 – 作业已取消
  11. S222 – 用户取消作业，没有转储。
  12. S322 – 作业或步骤时间超过指定限制，或者程序处于循环中，或者时间参数不足。
  13. S522 – TSO 会话超时。
  14. S806 – 无法链接或加载。

    原因 – 作业 ID 无法找到指定的加载模块。

  15. S80A – 没有足够的虚拟存储来满足 GETMAIN 或 FREEMAIN 请求。
  16. S913 – 尝试访问用户未经授权的数据集。
  17. Sx37 – 无法为数据集分配足够的存储空间。

Error Assist – 一个非常流行的工具，用于获取各种异常终止的详细信息。

大型机测试中遇到的常见问题

  • 作业异常终止 – 为了成功完成作业，应检查数据、输入文件以及指定位置是否存在模块。异常终止可能由于多种原因而发生，最常见的原因是 – 无效数据、不正确的输入字段、日期不匹配、环境问题等。
  • 输出文件为空 – 尽管作业可能成功运行 (MaxCC 0)，但输出可能不符合预期。因此，在通过任何测试用例之前，测试人员必须确保输出经过交叉验证。只有这样才能继续进行。
  • 输入文件为空 – 在某些应用程序中，文件将从上游进程接收。在将接收到的文件用于测试当前应用程序之前，应交叉验证数据，以避免重新执行和返工。

摘要

  • 大型机测试与任何其他测试过程一样，从需求收集、测试设计、测试执行到结果报告。
  • 为了有效测试应用程序，测试人员应参与开发和业务团队安排的设计会议。
  • 在测试周期开始之前，测试人员必须熟悉各种大型机测试功能。例如屏幕导航、文件和 PDS 创建、保存测试结果等。
  • 大型机应用程序测试是一个耗时的过程。应遵循明确的测试计划进行测试设计、数据设置和执行。
  • 批处理测试和在线测试应有效完成，不得遗漏需求文档中提及的任何功能，并且不应放过任何测试用例。