大型机测试 – 完整教程

在学习大型机测试概念之前，让我们先来看看测试运行的平台。

什么是大型机？

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

大型机测试

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

在进行大型机测试时，测试人员主要需要了解 CICS 屏幕的导航。这些屏幕是为特定应用程序定制的。当 COBOL、JCL 和类似语言的代码发生更改时，测试人员无需担心机器上模拟器的设置，因为在一个终端模拟器上有效的更改在其他模拟器上也有效。

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

由于该平台与 Web 技术栈的运行方式不同，因此了解哪些大型机特性驱动测试设计至关重要。因此，大型机测试与其他测试并行进行。 软件测试类型 而不是替换其中任何一个。

大型机属性

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

大型机手动测试的分类

这些特性将主机上的手动测试工作分成了两个明显分离的流程。

主机 手动测试 可以分为两类：

1. 批量作业测试 —

• 测试过程包括对当前版本中实现的功能执行批量作业。
• 测试结果trac从输出文件和数据库中提取的信息将被验证并记录。

2. 在线测试 —

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

如何进行大型机测试

1. 业务团队准备需求文档，以确定在发布周期中如何修改特定项目或流程。
2. 测试团队和开发团队会收到需求文档。他们会确定有多少流程会受到变更的影响。通常，在一个版本中，只有 20-25% 的应用程序会直接受到定制需求的影响。剩余的 75-80% 的发布工作量则用于开发开箱即用的功能，例如测试相关的应用程序和流程。
3. 因此，大型机应用程序必须分两部分进行测试：
   • 测试要求 — 测试应用程序的功能或变更是否符合需求文档中的规定。
   • 测试集成 — 测试整个流程或与受影响应用程序接收或发送数据的其他应用程序。 迭代测试 是本次测试活动的重点。

大型机自动化测试工具

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

• REXX — z/OS 附带的脚本语言，广泛用于驱动重复的作业提交和输出检查。
• Excel — 与宏一起使用，用于构建、比较和报告测试数据和输出文件。
• OpenText UFT 一个 ——这是业内人士仍然称之为该工具的当前名称。 QTP 或者 QuickTest Professional；它可以自动处理 3270 个终端屏幕。
• 加拉萨 — 一个开源的， 开放大型机项目深度集成测试框架 它通过 CI/CD 管道驱动 3270 个屏幕、JCL 批处理作业和 Db2。
• 厂商 z/OS 测试套件 - IBM Test Accelerator for Z 和 BMC AMI DevX Total Test 涵盖 COBOL 单元测试和虚拟化测试环境。

无论选择哪种工具，只有当它处于维护良好的环境中时才能发挥作用。 测试自动化框架 而不是一堆散乱的剧本。

大型机测试方法

我们来看一个例子：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，也称为作业设置。
3. 复制生产文件并准备测试文件。
4. 每个功能都对应一个已定义的作业序列（如“大型机测试方法”部分的示例所述）。这些作业应使用 SUB 命令并附带测试数据文件提交。
5. 检查中间文件，以确定数据缺失或出错的原因。
6. 检查最终输出文件、数据库和 Spool 文件，以验证测试结果。
7. 如果作业失败，后台处理程序将记录作业失败的原因。解决错误并重新提交作业。

测试报告 - A. 缺陷 如果实际结果与预期结果存在偏差，则应记录在案。

在线测试的步骤

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

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

在线批量集成测试的步骤

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

大型机测试中使用的命令

这些步骤都是通过终端驱动的，因此测试人员一天的大部分时间只需要使用少量命令即可。

1. 提交 — 提交一份背景调查工作。
2. 取消 — 取消背景调查。
3. 分配 — 分配数据集。
4. COPY — 复制数据集。
5. 改名 — 重命名数据集。
6. 删除 — 删除数据集。
7. 作业扫描 — 将 JCL 与程序、库、文件和其他资源绑定，而不执行它。

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

开始大型机测试的前提条件

大型机测试所需的基本信息如下：

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

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

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

最佳实践

1. 对于批处理作业，MAX CC 0 表示作业已成功运行。但这并不意味着所有功能都运行正常。即使输出为空或与预期不符，作业也会成功运行。因此，在宣布作业成功之前，务必检查所有输出。
2. 对被测作业进行预运行测试始终是一个好习惯。预运行测试使用空的输入文件。对于受测试周期更改影响的作业，都应遵循此流程。
3. 在测试周期开始之前，测试作业的设置应该提前完成。这有助于提前发现任何 JCL 错误，从而节省执行时间。
4. 通过 SPUFI（模拟器上访问 Db2 表的一个选项）访问 Db2 表时，务必将自动提交设置为“否”，以避免意外更新。
5. 批量测试中，测试数据的可用性是主要挑战。所需数据应在测试周期开始前提前创建，并检查其完整性。 Tracking 共同准备 测试管理 存储库保持回归床和数据设置的一致性。
6. 某些在线交易和批处理作业可能会将数据写入消息队列 (MQ)。 transmit将数据发送到其他应用程序。如果数据无效，可能会导致消息队列 (MQ) 被禁用或停止，这将影响整个测试过程。因此，测试后检查消息队列是否正常工作是一种良好的实践。

大型机测试挑战与故障排除

即使采取了这些措施，几乎每次大型机版本发布时仍然会遇到一些重复出现的问题。下表列出了每个问题及其解决方法。

挑战	途径
要求不完整/不明确	用户手册或培训指南可能可以查阅，但这与文档化的需求并不相同。测试人员应该参与其中。 软件测试生命周期 从需求阶段开始，这有助于验证需求是否可测试。
数据设置/识别	在某些情况下，可能需要根据需求重用现有数据。但有时很难从现有数据中识别出所需数据。对于数据设置，可以根据需要使用自研工具。为了获取现有数据，应预先构建查询语句。如果遇到任何困难，可以向数据管理团队提出请求，要求创建或克隆所需数据。
作业设置	作业导入PDS后，需要在QA区域进行设置，以避免作业提交时带有生产环境限定符或路径详细信息。应使用作业设置工具来避免设置过程中人为错误。
临时请求	可能会出现这种情况 端到端测试 由于上游或下游应用程序出现问题，需要进行支持。这些请求会增加执行周期的时间和精力。使用自动化脚本、回归脚本和框架脚本可以帮助减少时间和精力开销。
按时发布范围变更	代码变更可能会彻底改变系统的外观和运行方式，这种情况可能需要修改测试用例、脚本和数据。因此，必须制定变更范围管理流程并进行影响分析。

常见的侧弯

当作业失败时，后台打印程序会报告异常终止代码。以下列表涵盖了大型机测试人员最常遇到的代码及其常见原因。

1. （S001） — 发生 I/O 错误。

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

2. （S002） — 无效的 I/O 记录。

   原因——试图录制比唱片长度更长的唱片。

3. （S004） — 打开过程中发生错误。

   原因——无效的DCB。

4. （S013） — 打开数据集时出错。

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

5. S0C1 - Opera异常。

   原因——无法打开文件，或缺少DD卡。

6. S0C4 — 保护异常/存储违规。

   原因——尝试访问程序无法访问的存储空间。

7. S0C7 — 程序检查异常，数据。

   原因——记录布局或文件布局发生变化。

8. Sx22 — 工作已被取消。

   原因——该工作在完成前被终止；中间的数字表示是谁或什么取消了它。

9. （S222） — 用户取消作业但未生成转储文件。
10. （S322） — 作业或步骤时间超过了指定的限制，或者程序处于循环中，或者 TIME 参数不足。
11. （S522） — TSO 会话超时。
12. （S806） — 无法链接或加载。

    原因——作业找不到指定的加载模块。

13. S80A — 虚拟存储空间不足，无法满足 GETMAIN 或 FREEMAIN 请求。
14. （S913） — 尝试访问用户无权使用的数据集。
15. Sx37 — 无法为数据集分配足够的存储空间。

错误协助 — 一款非常受欢迎的工具，可用于获取各种类型异常终止的详细信息。

大型机测试中常见的难题

• 工作结束 — 为确保作业顺利完成，您应检查数据、输入文件以及模块是否位于指定位置。异常终止可能由多种原因引起，最常见的原因是数据无效、输入字段错误、日期不匹配或环境问题。
• 输出文件为空 — 即使作业成功运行（MaxCC 为 0），输出结果也可能与预期不符。因此，在通过任何测试用例之前，测试人员必须确保输出结果经过交叉验证。只有这样，测试才能继续进行。
• 输入文件为空 — 在某些应用程序中，文件是从上游进程接收的。在使用接收到的文件测试当前应用程序之前，应交叉验证数据，以避免重复执行和返工。

常见问题