# 大型機測試-完整教程 > 原文： [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)。