# 大型机测试-完整教程 > 原文： [https://www.guru99.com/mainframe-testing.html](https://www.guru99.com/mainframe-testing.html) 在学习大型机测试概念之前，请先学习 ## 什么是大型机？ 大型机是高性能和高速计算机系统。 它用于需要高可用性和安全性的大规模计算目的。 它主要用于金融，保险，零售和其他重要领域的部门，这些领域需要处理大量数据。 ## 什么是大型机测试？ **主机测试**是对基于大型机系统的软件应用程序和服务的验证和验证。 在执行大型机测试时，测试人员仅需要了解 CICS 屏幕的导航。 它们是针对特定应用定制的。 对 COBOL，JCL 等中的代码进行的任何更改。测试仪不必担心在计算机上设置的仿真器。 在一个终端模拟器上进行的更改将在其他终端模拟器上进行。 * 针对使用需求开发的测试用例，对大型机应用程序（也称为作业批处理）进行了测试 * 大型机测试通常是使用输入文件中设置的各种数据组合对部署的代码执行的。 * 可以通过终端仿真器访问大型机上运行的应用程序。 该仿真器是唯一需要在客户端计算机上安装的软件。 在此初学者教程中，您将学习- * [大型机属性](#2) * [大型机中手动测试的分类](#3) * [如何进行主机测试](#4) * [大型机自动化测试工具](#5) * [大型机测试中的方法](#6) * [批处理测试中涉及的步骤](#7) * [在线测试涉及的步骤](#8) * [在线–批次集成测试中涉及的步骤](#9) * [在大型机测试中使用的命令](#10) * [开始大型机测试的前提条件](#11) * [最佳做法](#12) * [大型机测试的挑战和故障排除](#13) * [遇到常见异常](#14) * [大型机测试期间面临的常见问题](#15) ## 主机属性 1. **虚拟存储** 1. 它是一种让处理器模拟比实际存储量大的主存储量的技术。 2. 这是一种有效使用内存来存储和执行各种大小的任务的技术。 3. 它使用磁盘存储作为实际存储的扩展。 2. **多重编程** 1. 计算机同时执行多个程序。 但是在任何给定时刻，只有一个程序可以控制 CPU。 2. 它是为了有效利用 CPU 而提供的工具。 3. **批处理** 1. 它是一项技术，通过该技术可以以称为作业的单位完成任何任务。 2. 一项作业可能导致一个或多个程序按顺序执行。 3. 作业调度程序决定执行作业的顺序。 为了使平均吞吐量最大化，将根据作业的优先级和类别来安排作业。 4. 通过 JCL（作业控制语言）提供批处理的必要信息。 JCL 描述了批处理作业-所需的程序，数据和资源。 4. **分时** 1. 在分时系统中，每个用户都可以通过终端设备访问系统。 用户无需输入计划稍后执行的作业，而是输入立即处理的命令。 2. 因此，这称为“交互处理”。 它使用户可以直接与计算机进行交互。 3. 分时处理称为“前台处理”，而批处理作业称为“后台处理”。 5. **假脱机** 1. SPOOLing 表示**同时进行外围操作**。 2. SPOOL 设备用于存储程序/应用程序的输出。 假脱机输出将定向到打印机等输出设备（如果需要）。 3. 这是一种利用缓冲优势来有效利用输出设备的工具。 ## 大型机中手动测试的分类 大型机[手动测试](/manual-testing.html)可以分为两种类型： 1. **批处理作业测试** – * 测试过程涉及为当前版本中实现的功能执行批处理作业。 * 从输出文件和数据库中提取的测试结果将得到验证和记录。 2. **在线测试** – * 在线测试是指对 CICS 屏幕的测试，类似于对网页的测试。 * 可以更改现有屏幕的功能，也可以添加新屏幕。 * 各种应用程序可以具有查询屏幕和更新屏幕。 这些屏幕的功能需要作为在线测试的一部分进行检查。 ## 如何进行大型机测试 1. 业务团队准备需求文档。 这决定了在发布周期中将如何修改特定项目或过程。 2. 测试团队和开发人员将收到需求文件。 他们将找出更改将影响多少个流程。 通常，在发行版中，只有 20-25％的应用程序直接受到定制需求的影响。 该版本的其他 75％将用于开箱即用功能，例如测试应用程序和流程。 3. 因此，大型机应用程序必须分两部分进行测试： 1. **测试需求** –测试应用程序的功能或需求文档中提到的更改。 2. **测试集成** –测试接收或发送数据到受影响应用程序的整个过程或其他应用程序。 [回归测试](/regression-testing.html)是此测试活动的主要重点。 ## 大型机自动化测试工具 以下是可用于大型机[自动化测试](/automation-testing.html)的工具列表。 * 雷克斯 * 电子表格 * QTP ## 大型机测试中的方法 让我们考虑一个示例：XYZ 保险公司具有会员注册模块。 它从成员注册屏幕和脱机注册中获取数据。 正如我们之前讨论的，它采用两种方法进行大型机测试，在线测试和批处理测试。 * **在会员注册屏幕上完成在线测试**。 就像网页一样，数据库也会通过屏幕输入的数据进行验证。 * **离线注册**可以是书面注册，也可以是第三方网站上的注册。 脱机数据（也称为批处理）将通过批处理作业输入到公司数据库中。 根据指定的数据格式准备输入平面文件，并将其输入批处理作业序列。 因此，对于大型机应用程序测试，我们可以使用以下方法。 * 批处理作业行中的第一个作业将验证输入的数据。 例如说特殊字符，仅数字字段中的字母等。 * 第二项工作是根据业务条件验证数据的一致性。 例如，子注册不应包含相关数据，会员邮政编码（已注册计划无法提供服务）等。 * 第三项作业以可以输入数据库的格式修改数据。 例如，删除计划名称（数据库将仅存储计划 ID 和保险计划名称），附加输入日期等。 * 第四个作业将数据加载到数据库中。 * **批处理作业测试**在此过程中分两个阶段进行- * 每个作业都经过单独验证，并且 * 通过向第一个作业提供输入平面文件并验证数据库来验证作业之间的集成。 （中间结果必须经过验证，以特别注意） 以下是大型机测试所遵循的方法： **步骤 1）**：减速/ [烟雾测试](/smoke-testing.html) 此阶段的主要重点是验证所部署的代码是否在正确的测试环境中。 它还可以确保代码没有关键问题。 **步骤 2）**：[系统测试](/system-testing.html) 以下是系统测试中完成的测试类型。 1. **批处理测试** –该测试将通过验证输出文件的测试结果以及在测试范围内由批处理作业完成的数据更改并记录下来来完成。 2. **在线测试** –该测试将在大型机应用程序的前端进行。 在这里，将针对正确的输入字段（例如保险计划，计划利息）对应用程序进行测试。 3. **Online-Batch Integration testing** – This testing will be done on the systems having batch processes and online application. The data flow and interaction between the online screens and the batch jobs is validated. （**此类测试的示例** –考虑对计划详细信息进行更新，例如提高利率。在更新屏幕上完成利息更改，并且仅通过以下方式修改受影响帐户上的余额详细信息： 夜间批处理作业。在这种情况下，将通过验证计划明细屏幕并运行批处理作业以更新所有帐户来进行测试）。 4. **数据库测试** –验证大型机应用程序（IMS，IDMS，DB2，VSAM / ISAM，顺序数据集，GDG）中的数据的布局和数据存储的数据库。 **步骤 3）**：系统[集成测试](/integration-testing.html) 该测试的主要目的是验证与被测系统交互的系统的功能。 这些系统不受要求的直接影响。 但是，他们使用来自被测系统的数据。 测试界面和不同类型的消息（如作业成功，作业失败，数据库已更新等）非常重要，这些消息可能会在系统之间流动以及各个系统所采取的措施。 在此阶段完成的测试类型为 1. 批量测试 2. 在线测试 3. 在线–批量集成测试 **步骤 4）**：回归测试 回归测试是任何类型的测试项目中的一个常见阶段。 在大型机中进行的此测试可确保不与被测系统直接交互（或不在要求范围内）的批处理作业和在线屏幕不受当前项目版本的影响。 为了进行有效的回归测试，应根据测试案例的复杂性来选择一组特定的测试案例，并应创建一个回归测试床（测试案例存储库）。 每当在发行版中推出新功能时，都应更新此集。 **步骤 5）**：[性能测试](/performance-testing.html) 进行此测试是为了确定热门数据区域（如前端数据），升级在线数据库并预测应用程序的可伸缩性方面的瓶颈。 **步骤 6）**：[安全测试](/what-is-security-testing.html) 进行此测试是为了评估设计和开发应用程序以抵抗反安全攻击的能力。 应在系统上进行两次安全测试-大型机安全性和网络安全性。 需要测试的功能是 1. 廉正 2. 保密 3. 授权书 4. 认证方式 5. 可用性 ## 批处理测试中涉及的步骤 1. 质量检查团队收到批准的程序包（程序包包含过程，JCL，控制卡，模块等）后，测试人员应预览并根据需要将其内容检索到 PDS 中。 2. 将生产 JCL 或开发 JCL 转换为质量检查 JCL，否则称为 JOB SETUP。 3. 复制生产文件并准备测试文件。 4. 对于每种功能，将定义一个作业序列。 （如大型机方法一节中示例中所述）。应使用 SUB 命令和测试数据文件提交作业。 5. 检查中间文件，以确定丢失或错误数据的原因。 6. 检查最终输出文件，数据库和假脱机以验证测试结果。 7. 如果作业失败，则后台打印程序将有作业失败的原因。 解决错误，然后重新提交作业。 测试报告– [如果实际结果偏离预期，则应记录缺陷](/defect-management-process.html)。 ## 在线测试中涉及的步骤 1. 在测试环境中选择“在线”屏幕。 2. 测试每个字段以获取可接受的数据。 3. 在屏幕上测试[测试方案](/test-scenario.html)。 4. 从联机屏幕验证数据库中的数据更新。 测试报告-如果实际结果偏离预期，则应记录缺陷。 ## 在线–批次集成测试中涉及的步骤 1. 在[测试环境](/test-environment-software-testing.html)中运行作业，并在联机屏幕上验证数据。 2. 在联机屏幕上更新数据，并验证批处理作业是否使用更新的数据正确运行。 ## 大型机测试中使用的命令 1. 提交–提交后台作业。 2. 取消–取消后台作业。 3. 分配-分配数据集 4. COPY –复制数据集 5. 重命名–重命名数据集 6. 删除–删除数据集 7. 作业扫描–将 JCL 与程序，库，文件等绑定而不执行它。 在需要时还有许多其他命令，但是它们并不那么频繁。 ## 开始大型机测试的先决条件 大型机测试所需的基本细节是： * 登录 ID 和用于登录应用程序的密码。 * 关于 ISPF 命令的简要知识。 * 文件名，文件限定符及其类型。 在开始大型机测试之前，应对以下方面进行验证。 1. 工作 1. 执行作业扫描（命令– JOBSCAN）以检查是否存在错误。 2. CLASS 参数应指向测试类。 3. 将作业输出定向到假脱机或 JHS 中，或根据需要使用 MSGCLASS 参数。 4. 将作业中的电子邮件重新路由到假脱机或测试邮件 ID。 5. 注释 FTP 步骤以进行初始测试，然后将作业指向测试服务器。 6. 如果在作业中生成 IMR（事件管理记录），只需在作业或参数卡中添加注释“ TESTING PURPOSE”。 7. 作业中的所有生产库都应更改并指向测试库。 8. 该作业不应无人看管。 9. 为了防止作业在出现任何错误的情况下在无限循环中运行，应在 TIME 参数中添加指定的时间。 10. 保存作业的输出，包括线轴。 线轴可以使用 XDC 保存。 2. 文件 1. 仅创建所需大小的测试文件。 必要时使用 GDG（发电数据组–具有相同名称但具有顺序版本号的文件– MYLIB.LIB.TEST.G0001V00，MYLIB.LIB.TEST.G0002V00 等）将数据存储到具有相同名称的连续文件中。 2. 应该正确编码文件的 DISP（处置-描述在正常或异常终止步骤或作业后执行保留或删除数据集的系统）参数。 3. 确保已正确保存并关闭了用于作业执行的所有文件，以防止作业进入保留状态。 4. 使用 GDG 进行测试时，请确保指向正确的版本。 3. 数据库 1. 在执行作业或在线程序时，请确保未插入，更新或删除意外数据。 2. 另外，请确保使用正确的 DB2 区域进行测试。 4. 测试用例 1. 始终测试边界条件，例如–空文件，第一个记录处理，最后一个记录处理等。 2. 始终同时包括阳性和阴性测试条件。 3. 如果程序中使用了标准程序，如检查点重启，异常终止模块，控制文件等，则包括测试用例，以验证模块是否已正确使用。 5. 测试数据 1. 测试数据的设置应在测试开始之前完成。 2. 切勿在未通知的情况下修改测试区域上的数据。 可能还有其他团队使用相同的数据，他们的测试将失败。 3. 如果在执行过程中需要生产文件，则应在复制或使用它们之前获得适当的授权。 ## 最佳做法 1. 如果运行批处理作业，则 MAX CC 0 表示该作业已成功运行。 这并不意味着该功能运行良好。 即使输出为空或不符合预期，该作业也将成功运行。 因此，总是希望在声明作业成功之前检查所有输出。 2. 进行测试工作总是一个好习惯。 空运行是使用空的输入文件完成的。 对于受测试周期更改影响的作业，应遵循此过程。 3. 在测试周期开始之前，应事先做好测试工作的设置。 这将有助于提前发现任何 JCL 错误，从而节省执行时间。 4. 通过 SPUFI 访问 DB2 表时（在仿真器上可以访问 DB2 表的选项），请始终将自动提交设置为“否”，以避免意外更新。 5. 测试数据可用性是批处理测试中的主要挑战。 所需数据应在测试周期之前很好地创建，并应进行完整性检查。 6. 一些在线交易和批处理作业可能会将数据写入 MQ（消息队列），以将数据传输到其他应用程序。 如果数据无效，则可能会禁用/停止 MQ，这将影响整个测试过程。 在测试之后，检查 MQ 是否工作正常是一个好习惯。 ## 大型机测试挑战和故障排除 | **挑战** | **方法** | | 要求不完整/不清楚 可以访问用户手册/培训指南，但与记录的要求不同。 | 从需求阶段开始，测试人员应参与 SDLC。 这将有助于验证需求是否可以测试。 | | 数据设置/标识 在某些情况下，应根据要求重新使用现有数据。 有时很难从现有数据中识别所需的数据。 | 对于数据设置，可以根据需要使用本地工具。 为了获取现有数据，应事先构建查询。 如果有任何困难，可以向数据管理团队提出请求，以创建或克隆所需的数据。 | | 作业设置 一旦将作业检索到 PDS 中，就需要在质量检查区域中设置作业。 这样就不会用生产限定符或路径详细信息提交作业。 | 应使用作业设置工具，以克服设置过程中发生的人为错误。 | | 临时请求 由于上游或下游应用程序问题，可能需要支持端到端测试。 这些请求增加了执行周期的时间和精力。 | 使用自动化脚本，回归脚本和框架脚本可以帮助减少时间和精力开销。 | | 范围变更 的按时发布在某些情况下，代码的影响可能会完全改变系统的外观。 这可能需要更改测试用例，脚本和数据。 | 范围变更管理过程和影响分析应到位。 | ## 遇到常见异常 1. S001 – An I/O error occurred. 原因–在文件末尾读取，文件长度错误，尝试写入只读文件。 2. S002 – Invalid I/O record. 原因–尝试写的记录长于记录的长度。 3. S004 – Error occurred during OPEN. 原因–无效的 DCB 4. S013 – Error opening a dataset. 原因– PDS 成员不存在，程序中的记录长度与实际记录长度不匹配。 5. S0C1 – Operation Exception 原因–无法打开文件，缺少 DD 卡 6. S0C4 –保护例外/违反存储 7. 原因–尝试使用该程序不可用的访问存储。 8. SC07 –程序检查异常–数据 9. 原因–记录布局或文件布局更改。 10. Sx22 –作业已被取消 11. S222 –作业被用户取消而没有转储。 12. S322 –作业或步进时间超过了指定的限制，或者程序处于循环中或时间参数不足。 13. S522 – TSO 会话超时。 14. S806 –Unable to link or load. 原因-作业 ID 无法找到指定的加载模块。 15. S80A –虚拟存储不足，无法满足 GETMAIN 或 FREEMAIN 请求。 16. S913 –尝试访问未经授权的数据集。 17. Sx37 –无法为数据集分配足够的存储。 错误辅助–一个非常流行的工具，可获取有关各种类型异常终止的详细信息。 ## 大型机测试期间面临的常见问题 * **作业异常终止** –为成功完成作业，您应该检查数据，输入文件和特定位置的模块。 可能由于多种原因而面临中止，最常见的是–数据无效，输入字段不正确，日期不匹配，环境问题等。 * **输出文件为空**-尽管作业可能成功运行（MaxCC 0），但输出可能与预期的不一样。 因此，在通过任何测试用例之前，测试人员必须确保对输出进行交叉验证。 然后再继续。 * **输入文件为空** –在某些应用程序中，将从上游进程接收文件。 在使用接收到的文件测试当前应用程序之前，应该对数据进行交叉验证，以避免重新执行和重做。 **摘要：** * 大型机测试与从需求收集，测试设计，测试执行和结果报告开始的任何其他测试过程一样。 * 为了有效地测试应用程序，测试人员应参加由开发和业务团队安排的设计会议。 * 测试人员必须习惯各种主机测试功能。 在测试周期开始之前，如屏幕导航，文件和 PDS 创建，保存测试结果等。 * 大型机应用程序测试是一个耗时的过程。 对于测试设计，数据设置和执行，应遵循清晰的测试时间表。 * 批处理测试和在线测试应有效完成，而不会丢失需求文档中提到的任何功能，并且不应保留任何[测试用例](/test-case.html)。