메인프레임 테스트 – 전체 튜토리얼

메인프레임 테스트 개념을 배우기 전에 먼저 테스트가 실행되는 플랫폼을 살펴보겠습니다.

메인프레임이란 무엇입니까?

메인프레임은 고성능 및 고속 컴퓨터 시스템입니다. 높은 가용성과 강력한 보안이 요구되는 대규모 컴퓨팅에 사용됩니다. 주로 금융, 보험, 소매업 및 기타 중요 분야에서 사용되며, 이러한 분야에서는 하루에도 여러 번 대량의 데이터를 처리합니다.

메인프레임 테스트

메인프레임 테스트 메인프레임 테스트는 메인프레임 시스템 기반의 소프트웨어 애플리케이션 및 서비스를 테스트하는 프로세스입니다. 메인프레임 테스트의 목적은 검증 및 유효성 검사 방법을 통해 소프트웨어 애플리케이션 또는 서비스의 성능, 신뢰성 및 품질을 보장하고 배포 준비가 완료되었는지 확인하는 것입니다.

메인프레임 테스트를 수행하는 동안 테스터는 주로 CICS 화면 탐색 방법을 알아야 합니다. 이러한 화면은 특정 애플리케이션에 맞게 맞춤 제작됩니다. COBOL, JCL 및 유사 언어로 작성된 코드에 변경 사항이 발생할 경우, 테스터는 시스템에 설정된 에뮬레이터에 대해 걱정할 필요가 없습니다. 왜냐하면 한 터미널 에뮬레이터에서 작동하는 변경 사항은 다른 에뮬레이터에서도 동일하게 작동하기 때문입니다.

• 메인프레임 애플리케이션(또는 작업 배치)은 요구사항을 기반으로 개발된 테스트 케이스를 사용하여 테스트됩니다.
• 메인프레임 테스트는 일반적으로 입력 파일에 설정된 다양한 데이터 조합을 사용하여 배포된 코드에서 수행됩니다.
• 메인프레임에서 실행되는 애플리케이션은 터미널 에뮬레이터를 통해 접근할 수 있습니다. 클라이언트 컴퓨터에 설치해야 하는 소프트웨어는 에뮬레이터뿐입니다.

메인프레임 플랫폼은 웹 스택과 동작 방식이 다르기 때문에, 어떤 메인프레임 특성이 테스트 설계에 영향을 미치는지 아는 것이 중요합니다. 따라서 메인프레임 테스트는 다른 테스트들과 함께 다뤄집니다. 소프트웨어 테스트 유형 그 어떤 것도 교체하는 대신에.

메인프레임 속성

1. 가상 스토리지
   • 프로세서가 실제 스토리지 용량보다 더 큰 메인 스토리지를 시뮬레이션할 수 있도록 하는 기술이다.
   • 다양한 크기의 작업을 저장하고 실행하기 위해 메모리를 효과적으로 사용하는 기술입니다.
   • 실제 스토리지의 확장으로 디스크 스토리지를 사용합니다.
2. 다중 프로그래밍
   • 컴퓨터는 동시에 여러 프로그램을 실행할 수 있습니다. 하지만 특정 순간에는 오직 하나의 프로그램만 CPU를 제어할 수 있습니다.
   • CPU를 효율적으로 사용하기 위해 제공되는 기능입니다.
3. 일괄 처리
   • 모든 작업을 작업이라는 단위로 수행하는 기술입니다.
   • 작업으로 인해 하나 이상의 프로그램이 순차적으로 실행될 수 있습니다.
   • 작업 스케줄러는 작업이 실행되어야 하는 순서를 결정합니다. 평균 처리량을 최대화하기 위해 작업은 우선순위와 클래스에 따라 예약됩니다.
   • 배치 처리에 필요한 정보는 JCL(작업 제어 언어)을 통해 제공됩니다. JCL은 배치 작업에 필요한 프로그램, 데이터 및 리소스를 설명합니다.
4. 시간 공유
   • 시분할 시스템에서 각 사용자는 터미널 장치를 통해 시스템에 액세스할 수 있습니다. 나중에 실행되도록 예약된 작업을 제출하는 대신, 사용자는 즉시 처리되는 명령을 입력합니다.
   • 따라서 이를 "대화형 처리"라고 합니다. 이를 통해 사용자는 컴퓨터와 직접 상호 작용할 수 있습니다.
   • 시간 공유 처리를 "포그라운드 처리"라고 하며 일괄 작업 처리를 "백그라운드 처리"라고 합니다.
5. 스풀링
   • SPOOLing은 Simultaneous Peripheral의 약자입니다. Opera온라인에서 이용 가능합니다.
   • SPOOL 장치는 프로그램이나 애플리케이션의 출력을 저장하는 데 사용됩니다. 스풀에 저장된 출력은 필요에 따라 프린터와 같은 출력 장치로 전송됩니다.
   • 버퍼링의 장점을 이용해 출력 장치를 효율적으로 활용할 수 있는 시설입니다.

메인프레임의 수동 테스트 분류

이러한 속성들은 메인프레임에서의 수동 테스트 작업을 두 개의 명확하게 구분된 흐름으로 나누었습니다.

메인 프레임 수동 테스트 두 가지 유형으로 분류할 수 있습니다.

1. 배치 작업 테스트 —

• 테스트 프로세스는 현재 릴리스에 구현된 기능에 대한 배치 작업 실행을 포함합니다.
• 시험 결과 예시trac출력 파일과 데이터베이스에서 추출된 데이터는 검증 및 기록됩니다.

2. 온라인 테스트 —

• 온라인 테스트는 웹 페이지 테스트와 유사하게 CICS 화면을 테스트하는 것을 의미합니다.
• 기존 화면의 기능을 변경하거나 새 화면을 추가할 수 있습니다.
• 다양한 애플리케이션에는 문의 화면과 업데이트 화면이 있을 수 있습니다. 이러한 화면의 기능은 온라인 테스트의 일부로 확인해야 합니다.

메인프레임 테스트 방법

1. 비즈니스 팀은 요구사항 문서를 작성하는데, 이 문서에는 특정 항목이나 프로세스가 출시 주기에서 어떻게 수정될 것인지가 명시되어 있습니다.
2. 테스트 팀과 개발 팀은 요구사항 문서를 받습니다. 그들은 변경 사항으로 인해 영향을 받는 프로세스 수를 파악합니다. 일반적으로 릴리스에서 애플리케이션의 20~25%만이 사용자 정의 요구사항의 직접적인 영향을 받습니다. 나머지 75~80%의 릴리스 작업은 주변 애플리케이션 및 프로세스 테스트와 같은 기본 기능 구현에 할애됩니다.
3. 따라서 메인프레임 애플리케이션은 두 부분으로 테스트되어야 합니다.
   • 테스트 요구 사항 — 요구사항 문서에 언급된 기능 또는 변경 사항에 대해 애플리케이션을 테스트합니다.
   • 테스트 통합 — 전체 프로세스 또는 해당 애플리케이션과 데이터를 주고받는 다른 애플리케이션을 테스트합니다. Regression Testing 이 테스트 활동의 주요 초점입니다.

메인프레임 자동화 테스트 도구

다음은 메인프레임에 사용할 수 있는 도구 목록입니다. 자동화 테스트.

• 렉스 — z/OS에 포함된 스크립팅 언어로, 반복적인 작업 제출 및 출력 검사에 널리 사용됩니다.
• 뛰어나다 — 매크로와 함께 사용하여 테스트 데이터 및 출력 파일을 생성, 비교 및 ​​보고합니다.
• OpenText UFT 한 — 업계에서 여전히 부르는 그 도구의 현재 이름 QTP 또는 QuickTest Professional을 사용하면 3270개의 터미널 화면을 자동화할 수 있습니다.
• 갈라사 — 오픈 소스, 오픈 메인프레임 프로젝트 심층 통합 테스트 프레임워크 이는 CI/CD 파이프라인을 통해 3270개의 화면, JCL 배치 작업 및 Db2를 구동합니다.
• 벤더 z/OS 테스트 스위트 - IBM Z 및 BMC AMI DevX Total Test용 테스트 가속기는 COBOL 단위 테스트 및 가상화된 테스트 환경을 지원합니다.

어떤 도구를 선택하든, 제대로 관리되는 환경 안에 있을 때만 제 역할을 다합니다. 테스트 자동화 프레임워크 그냥 흩어진 대본 더미가 아니라.

메인프레임 테스트 방법론

예를 들어 보겠습니다. XYZ 보험 회사는 회원 가입 모듈을 가지고 있습니다. 이 모듈은 회원 가입 화면과 오프라인 가입 모두에서 데이터를 가져옵니다. 앞서 논의한 바와 같이, 메인프레임 테스트에는 온라인 테스트와 배치 테스트라는 두 가지 접근 방식이 있습니다.

• 온라인 테스트는 회원 가입 화면에서 진행됩니다. 웹페이지와 마찬가지로, 데이터베이스를 통해 입력된 데이터로 검증합니다.
• 오프라인 등록은 종이 등록 또는 제3자 웹사이트를 통한 등록으로 이루어질 수 있습니다. 오프라인 데이터(배치 데이터라고도 함)는 배치 작업을 통해 회사 데이터베이스에 입력됩니다. 지정된 데이터 형식에 따라 입력 플랫 파일을 준비하여 일련의 배치 작업에 입력합니다. 따라서 메인프레임 애플리케이션 테스트에는 다음과 같은 접근 방식을 사용할 수 있습니다.
  • 일괄 작업의 첫 번째 작업은 입력된 데이터의 유효성을 검사합니다. 예를 들어 특수 문자나 숫자만 입력할 수 있는 필드에 알파벳이 있는지 등을 확인합니다.
  • 두 번째 작업은 비즈니스 조건에 따라 데이터의 일관성을 검증하는 것입니다. 예를 들어, 자녀 등록 정보에는 부양 가족 정보가 포함되어서는 안 되며, 등록된 플랜에서 서비스 제공이 불가능한 지역의 우편번호가 입력되어서도 안 됩니다.
  • 세 번째 작업은 데이터를 데이터베이스에 입력할 수 있는 형식으로 수정하는 것입니다. 예를 들어, 플랜 이름을 삭제하고(데이터베이스에는 플랜 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. 이용 가능 여부 (Availability)

배치 테스트에 포함되는 단계

1. QA 팀이 승인된 패키지(절차, JCL, 제어 카드, 모듈 및 유사 항목 포함)를 받으면 테스터는 필요에 따라 해당 내용을 미리 보고 PDS에 입력해야 합니다.
2. 프로덕션 JCL 또는 개발 JCL을 QA JCL(또는 JOB SETUP)로 변환합니다.
3. 프로덕션 파일을 복사하고 테스트 파일을 준비하세요.
4. 각 기능마다 정의된 작업 순서가 있습니다(메인프레임 테스트 방법론 섹션의 예시 참조). 테스트 데이터 파일과 함께 SUB 명령어를 사용하여 작업을 제출해야 합니다.
5. 누락되거나 오류가 발생한 데이터의 원인을 파악하려면 중간 파일을 확인하십시오.
6. 테스트 결과를 검증하려면 최종 출력 파일, 데이터베이스 및 스풀을 확인하십시오.
7. 작업이 실패하면 스풀에 작업 실패 이유가 표시됩니다. 오류를 해결하고 작업을 다시 제출하십시오.

테스트 보고 - A 결함 실제 결과가 예상 결과와 다를 경우 이를 기록해야 합니다.

온라인 테스트 진행 단계

1. 온라인 화면을 선택하세요 테스트 환경.
2. 허용 가능한 데이터에 대해 각 필드를 테스트하십시오.
3. 테스트 테스트 시나리오 화면에.
4. 온라인 화면에서 데이터 업데이트에 대한 데이터베이스를 확인합니다.

테스트 보고 실제 결과가 예상 결과와 다를 경우 결함으로 기록해야 합니다.

온라인 배치 통합 테스트에 포함되는 단계

1. 테스트 환경에서 작업을 실행하고 온라인 화면에서 데이터의 유효성을 검사하십시오.
2. 온라인 화면의 데이터를 업데이트하고 업데이트된 데이터를 사용하여 배치 작업이 올바르게 실행되는지 확인합니다.

메인프레임 테스트에 사용되는 명령어

이러한 단계는 터미널에서 실행되므로 간단한 명령어로 테스터의 하루 일과 대부분을 커버할 수 있습니다.

1. 제출 — 신원조회를 신청하세요.
2. 취소 — 신원조회를 취소하세요.
3. 할당하다 — 데이터셋을 할당합니다.
4. 복사 — 데이터셋을 복사합니다.
5. 이름 바꾸기 — 데이터셋 이름을 변경합니다.
6. 삭제 — 데이터셋을 삭제합니다.
7. 잡 스캔 — JCL을 실행하지 않고 프로그램, 라이브러리, 파일 및 기타 리소스와 연결합니다.

필요할 때 사용되는 다른 명령도 많이 있지만 그렇게 자주 사용되지는 않습니다.

메인프레임 테스트 시작을 위한 필수 조건

메인프레임 테스트에 필요한 기본 정보는 다음과 같습니다.

• 애플리케이션에 로그인하기 위한 로그인 ID와 비밀번호입니다.
• ISPF 명령어에 대한 기본적인 지식.
• 파일 이름, 파일 한정자 및 파일 유형.

메인프레임 테스트를 시작하기 전에 아래 사항들을 확인해야 합니다.

1. 일
   • 작업을 실행하기 전에 오류를 확인하려면 작업 검사(명령어 - JOBSCAN)를 수행하십시오.
   • CLASS 매개변수는 테스트 클래스를 가리켜야 합니다.
   • MSGCLASS 매개변수를 사용하여 작업 출력을 스풀 또는 JHS로 보내거나 필요에 따라 다른 방식으로 저장할 수 있습니다.
   • 작업에서 이메일을 스풀 또는 테스트 메일 주소로 재라우팅합니다.
   • 초기 테스트를 위해 FTP 단계를 주석 처리한 다음, 테스트 서버를 지정하도록 작업을 설정하십시오.
   • 작업 중에 IMR(사고 관리 기록)이 생성되는 경우, 작업 또는 파라미터 카드에 "테스트 목적"이라는 주석을 추가하십시오.
   • 작업의 모든 프로덕션 라이브러리를 변경하고 테스트 라이브러리를 가리켜야 합니다.
   • 작업을 방치해서는 안 됩니다.
   • 오류 발생 시 작업이 무한 루프에 빠지는 것을 방지하려면 TIME 매개변수에 지정된 시간을 추가해야 합니다.
   • 스풀을 포함하여 작업의 출력을 저장합니다. 스풀은 XDC를 사용하여 저장할 수 있습니다.
2. 입양 부모로서의 귀하의 적합성을 결정하기 위해 미국 이민국에
   • 필요한 크기의 테스트 파일만 생성하십시오. 동일한 이름의 연속된 파일에 데이터를 저장해야 하는 경우 GDG(Generation Data Groups, 즉 MYLIB.LIB.TEST.G0001V00 및 MYLIB.LIB.TEST.G0002V00과 같이 이름은 같지만 버전 번호가 순차적인 파일)를 사용하십시오.
   • 파일에 대한 DISP(Disposition - 단계 또는 작업이 정상적으로 또는 비정상적으로 종료된 후 데이터 세트를 유지할지 삭제할지를 시스템에 알려주는 매개변수) 매개변수는 올바르게 코딩되어야 합니다.
   • 작업 실행에 사용되는 모든 파일이 제대로 저장되고 닫혔는지 확인하여 작업이 보류(HOLD)되는 것을 방지하십시오.
   • GDG를 사용하여 테스트할 때는 올바른 버전이 지정되어 있는지 확인하십시오.
3. 데이터베이스
   • 작업 또는 온라인 프로그램을 실행하는 동안 의도치 않은 데이터가 삽입, 업데이트 또는 삭제되지 않도록 하십시오.
   • 또한 테스트에 올바른 Db2 지역이 사용되고 있는지 확인하십시오.
4. 테스트 케이스
   • 빈 파일, 첫 번째 레코드 처리 및 마지막 레코드 처리와 같은 경계 조건을 항상 테스트하십시오.
   • 항상 긍정적인 테스트 조건과 부정적인 테스트 조건을 모두 포함하세요.
   • 체크포인트 재시작, 비정상 종료 모듈 또는 제어 파일과 같은 표준 절차가 프로그램에 사용되는 경우, 다음을 포함하십시오. 테스트 케이스모듈이 올바르게 사용되었는지 확인하기 위한 것입니다.
5. 테스트 데이터
   • 테스트 데이터 설정은 테스트 시작 전에 완료해야 합니다.
   • 테스트 영역의 데이터를 수정할 때는 반드시 다른 팀에 알려야 합니다. 다른 팀에서 동일한 데이터를 사용하고 있을 수 있으며, 수정된 데이터는 해당 팀의 테스트에 오류를 발생시킬 수 있습니다.
   • 실행 중에 프로덕션 파일이 필요한 경우 복사하거나 사용하기 전에 적절한 승인을 받아야 합니다.

모범 사례

1. 배치 작업 실행 시 MAX CC 0은 작업이 성공적으로 실행되었음을 나타내는 지표입니다. 하지만 이는 기능이 정상적으로 작동한다는 것을 의미하지는 않습니다. 출력 결과가 비어 있거나 예상과 다르더라도 작업은 성공적으로 실행됩니다. 따라서 작업이 성공했다고 판단하기 전에 모든 출력 결과를 확인하는 것이 중요합니다.
2. 테스트 대상 작업에 대해 사전 실행(dry run)을 해보는 것은 항상 좋은 습관입니다. 사전 실행은 빈 입력 파일을 사용하여 수행합니다. 이 과정은 테스트 주기에서 변경 사항의 영향을 받는 작업에 대해 반드시 따라야 합니다.
3. 테스트 주기 시작 전에 테스트 작업 설정을 미리 완료해야 합니다. 이렇게 하면 JCL 오류를 사전에 발견하여 실행 시간을 절약할 수 있습니다.
4. SPUFI(에뮬레이터에서 Db2 테이블에 액세스하는 옵션)를 통해 Db2 테이블에 액세스할 때는 의도치 않은 업데이트를 방지하기 위해 자동 커밋을 항상 "아니요"로 설정하십시오.
5. 배치 테스트에서 가장 큰 어려움은 테스트 데이터의 가용성입니다. 필요한 데이터는 테스트 주기 훨씬 이전에 생성되어야 하며, 완전성을 확인해야 합니다. Tracking 공동으로 준비하는 과정 테스트 관리 리포지토리는 회귀 테스트 환경과 데이터 설정을 일관되게 유지합니다.
6. 일부 온라인 거래 및 배치 작업은 MQ(메시지 큐)에 데이터를 기록할 수 있습니다. transmit데이터를 다른 애플리케이션으로 전송할 때, 데이터가 유효하지 않으면 MQ가 비활성화되거나 중지될 수 있으며, 이는 전체 테스트 프로세스에 영향을 미칩니다. 테스트 후 MQ가 정상적으로 작동하는지 확인하는 것이 좋습니다.

메인프레임 테스트의 어려움과 문제 해결

이러한 관행이 시행되고 있음에도 불구하고, 거의 모든 메인프레임 릴리스에서 몇 가지 문제가 반복적으로 발생합니다. 아래 표는 각 문제와 해결 방법을 함께 보여줍니다.

도전	접근
불완전하거나 불분명한 요구사항	사용자 설명서나 교육 가이드를 참조할 수는 있지만, 이는 문서화된 요구사항과는 다릅니다. 테스터는 다음 사항에 참여해야 합니다. 소프트웨어 테스팅 수명주기 요구사항 단계부터 적용됩니다. 이는 요구사항이 테스트 가능한지 여부를 확인하는 데 도움이 됩니다.
데이터 설정/식별	필요에 따라 기존 데이터를 재사용해야 하는 경우가 있을 수 있습니다. 하지만 기존 데이터에서 필요한 데이터를 식별하는 것이 어려울 때도 있습니다. 데이터 설정 시에는 필요에 따라 자체 개발 도구를 사용할 수 있습니다. 기존 데이터를 가져오려면 사전에 쿼리를 작성해야 합니다. 어려움이 발생할 경우, 데이터 관리팀에 필요한 데이터의 생성 또는 복제를 요청할 수 있습니다.
작업 설정	PDS에서 작업을 불러온 후에는 프로덕션 한정자나 경로 세부 정보가 포함되지 않도록 QA 영역에서 작업을 설정해야 합니다. 설정 과정에서 발생할 수 있는 인적 오류를 방지하기 위해 작업 설정 도구를 사용하는 것이 좋습니다.
임시 요청	다음과 같은 상황이 있을 수 있습니다. 엔드 투 엔드 테스트 상위 또는 하위 애플리케이션의 문제로 인해 지원이 필요한 경우가 있습니다. 이러한 요청은 실행 주기에서 시간과 노력을 증가시킵니다. 자동화 스크립트, 회귀 스크립트 및 기본 스크립트를 사용하면 시간과 노력 부담을 줄이는 데 도움이 될 수 있습니다.
범위 변경을 위한 정시 릴리스	코드 변경으로 인해 시스템의 외관과 느낌이 완전히 바뀌는 상황이 발생할 수 있습니다. 이 경우 테스트 케이스, 스크립트 및 데이터를 변경해야 할 수도 있습니다. 따라서 범위 변경 관리 프로세스와 영향 분석이 마련되어 있어야 합니다.

흔히 발생하는 비정상 종료 현상

작업이 실패하면 스풀에 비정상 종료 코드가 보고됩니다. 아래 목록은 메인프레임 테스터가 가장 자주 접하는 코드와 일반적인 원인을 정리한 것입니다.

1. S001 — 입출력 오류가 발생했습니다.

   이유 — 파일 끝부분에서 읽기, 파일 길이 오류 또는 읽기 전용 파일에 쓰기 시도.

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), 출력 결과가 예상과 다를 수 있습니다. 따라서 테스트 케이스를 통과시키기 전에 테스터는 출력 결과를 교차 검증해야 합니다. 그런 다음 테스트를 진행해야 합니다.
• 입력 파일이 비어 있음 일부 애플리케이션에서는 상위 프로세스로부터 파일을 수신합니다. 수신된 파일을 현재 애플리케이션 테스트에 사용하기 전에 데이터의 정확성을 검증하여 재실행 및 재작업을 방지해야 합니다.

자주 묻는 질문