大型机测试 – 完整教程

由： 托马斯·汉密尔顿 托马斯·汉密尔顿
Hours 更新

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

什么是大型机？

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

大型机测试

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

在执行大型机测试时，测试人员只需要了解 CICS 屏幕的导航。它们是为特定应用程序定制的。对 COBOL、JCL 等代码所做的任何更改，测试人员都不必担心机器上设置的模拟器。在一个终端模拟器上有效的更改将在其他终端模拟器上有效。

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

大型机属性

  1. 虚拟存储
    1. 它是一种让处理器模拟比实际存储量更大的主存储的技术。
    2. 它是一种有效利用内存来存储和执行各种规模任务的技术。
    3. 它使用磁盘存储作为真实存储的扩展。
  2. 多道程序设计
    1. 计算机可以同时执行多个程序。但是，在任何特定时刻，只有一个程序可以控制 CPU。
    2. 它是为了有效利用 CPU 而提供的一种设施。
  3. 批量处理
    1. 它是一种以作业为单位来完成任何任务的技术。
    2. 一个作业可能导致一个或多个程序按顺序执行。
    3. 作业调度程序决定作业的执行顺序。为了最大化平均吞吐量，作业将根据其优先级和类别进行调度。
    4. 批处理所需的必要信息通过 JCL（作业控制语言）提供。JCL 描述批处理作业 - 所需的程序、数据和资源。
  4. 分时
    1. 在分时系统中，每个用户都可以通过终端设备访问系统。用户无需提交计划稍后执行的作业，而是输入可立即处理的命令。
    2. 因此这被称为“交互式处理”。它使用户能够直接与计算机交互。
    3. 分时处理称为“前台处理”，批处理作业处理称为“后台处理”。
  5. 假脱机
    1. SPOOLing 代表 同步外设 Opera在线.
    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. Integrity
  2. 保密协议
  3. 授权
  4. 认证
  5. 可用性

批量测试涉及的步骤

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

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

在线测试涉及的步骤

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

测试报告——如果实际结果与预期有偏差，则应记录缺陷。

在线批量集成测试涉及的步骤

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

大型机测试中使用的命令

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

还有许多其他命令在需要时使用，但并不那么频繁。

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

大型机测试所需的基本细节包括：

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

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

  1. 工作
    1. 执行作业扫描（命令 - JOBSCAN）以在执行之前检查错误。
    2. CLASS 参数应该指向测试类。
    3. 将作业输出直接放入假脱机或 JHS 中，或根据需要使用 MSGCLASS 参数。
    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—打开期间发生错误。

    原因 – DCB 无效

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

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

  5. S0C1 – Opera异常

    原因 – 无法打开文件，缺少 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 – 无法为数据集分配足够的存储空间。

错误助手——一种非常流行的工具，可以获取有关各种类型异常终止的详细信息。

大型机测试期间面临的常见问题

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

总结

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

你可能会喜欢：