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

메인프레임 테스트 개념을 배우기 전에 먼저 알아보도록 하겠습니다.

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

메인프레임은 고성능, 고속 컴퓨터 시스템입니다. 높은 가용성과 보안이 필요한 대규모 컴퓨팅 목적으로 사용됩니다. 금융, 보험, 소매 등 대용량 데이터를 여러 번 처리하는 중요한 분야에서 주로 사용됩니다.

메인프레임 테스트

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

메인프레임 테스트를 수행하는 동안 테스터는 CICS 화면 탐색에 대해서만 알면 됩니다. 특정 애플리케이션을 위해 맞춤 제작되었습니다. COBOL, JCL 등의 코드가 변경되면 테스터는 머신에 설정된 에뮬레이터에 대해 걱정할 필요가 없습니다. 한 터미널 에뮬레이터에서 작동하는 변경 사항은 다른 터미널 에뮬레이터에서도 작동합니다.

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

메인프레임 속성

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

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

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

1. 일괄 작업 테스트 -

• 테스트 프로세스에는 현재 릴리스에 구현된 기능에 대한 일괄 작업 실행이 포함됩니다.
• 출력 파일과 데이터베이스에서 추출된 테스트 결과를 검증하고 기록합니다.

2. 온라인 테스트 -

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

메인프레임 테스트를 수행하는 방법

1. 사업팀은 요구 사항 문서를 준비합니다. 이는 특정 항목이나 프로세스가 릴리스 주기에서 어떻게 수정될지 결정합니다.
2. 테스트 팀과 개발팀은 요구 사항 문서를 받습니다. 그들은 변경 사항의 영향을 받는 프로세스 수를 알아낼 것입니다. 일반적으로 릴리스에서 사용자 지정 요구 사항의 영향을 받는 애플리케이션의 20-25%만 있습니다. 릴리스의 나머지 75%는 애플리케이션 및 프로세스 테스트와 같은 아웃박스 기능을 위한 것입니다.
3. 따라서 메인프레임 애플리케이션은 두 부분으로 테스트되어야 합니다.
   1. 테스트 요구 사항 – 요구사항 문서에 언급된 기능 또는 변경 사항에 대해 애플리케이션을 테스트합니다.
   2. 테스트 통합 – 영향을 받는 응용 프로그램으로 데이터를 받거나 보내는 전체 프로세스 또는 기타 응용 프로그램을 테스트합니다. Regression Testing 이 테스트 활동의 주요 초점입니다.

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

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

• 렉스
• 뛰어나다
• QTP

메인프레임 테스트 방법론

예를 들어 보겠습니다. XYZ 보험 회사에는 회원 등록 모듈이 있습니다. 회원 등록 화면과 오프라인 등록 모두에서 데이터를 가져옵니다. 앞서 논의한 것처럼 메인프레임 테스트에는 온라인 테스트와 배치 테스트라는 두 가지 접근 방식이 필요합니다.

• 온라인 테스트 회원가입 화면에서 진행됩니다. 웹페이지와 마찬가지로 데이터베이스는 화면을 통해 입력된 데이터로 검증됩니다.
• 오프라인 등록 종이 등록 또는 제3자 웹사이트 등록이 될 수 있습니다. 오프라인 데이터(배치라고도 함)는 배치 작업을 통해 회사 데이터베이스에 입력됩니다. 입력 플랫 파일은 규정된 데이터 형식에 따라 준비되고 배치 작업 시퀀스에 공급됩니다. 따라서 메인프레임 애플리케이션 테스트를 위해 다음 접근 방식을 사용할 수 있습니다.
• 배치 작업 라인의 첫 번째 작업은 입력된 데이터의 유효성을 검사합니다. 예를 들어 특수 문자, 숫자 전용 필드의 알파벳 등을 가정해 보겠습니다.
• 두 번째 작업은 비즈니스 조건에 따라 데이터의 일관성을 검증합니다. 예를 들어, 자녀 등록에는 부양가족 데이터, 회원 우편번호(등록된 플랜에서 서비스를 제공할 수 없음) 등이 포함되어서는 안 됩니다.
• 세 번째 작업은 데이터베이스에 입력할 수 있는 형식으로 데이터를 수정합니다. 예를 들어 플랜 이름 삭제(데이터베이스에는 플랜 ID 및 보험 플랜 이름만 저장됨), 입력 날짜 추가 등이 있습니다.
• 네 번째 작업은 데이터를 데이터베이스에 로드합니다.
• 일괄 작업 테스트 이 프로세스는 두 단계로 수행됩니다.
• 각 작업은 별도로 검증되며,
• 작업 간의 통합은 첫 번째 작업에 입력 플랫 파일을 제공하고 데이터베이스의 유효성을 검사하여 유효성을 검사합니다. (중간 결과는 추가적인 주의를 위해 검증되어야 합니다)

메인프레임 테스트 방법은 다음과 같습니다.

단계 1) 성능 시험 운전/연기 테스트

이 단계의 주요 초점은 배포된 코드가 올바른 테스트 환경에 있는지 확인하는 것입니다. 또한 코드에 중요한 문제가 없는지 확인합니다.

단계 2) 시스템 테스트

다음은 시스템 테스트의 일부로 수행되는 테스트 유형입니다.

1. 배치 테스트 – 본 테스트는 테스트 범위 내 배치 작업에 의해 수행된 출력 파일 및 데이터 변경 사항에 대한 테스트 결과를 검증하고 이를 기록하는 방식으로 수행됩니다.
2. 온라인 테스트 – 이 테스트는 메인프레임 애플리케이션의 프런트 엔드에서 수행됩니다. 여기에서는 보험 플랜, 플랜에 대한 이자 등과 같은 올바른 입력 필드에 대해 애플리케이션을 테스트합니다.
3. 온라인 일괄 통합 테스트 – 이 테스트는 일괄 처리 및 온라인 응용 프로그램이 있는 시스템에서 수행됩니다. 온라인 화면과 배치 작업 간의 데이터 흐름과 상호 작용이 검증됩니다.

   (이러한 유형의 테스트에 대한 예 – 이자율 인상과 같은 계획 세부 정보 업데이트를 고려하세요. 이자율 변경은 업데이트 화면에서 수행되고, 영향을 받는 계정의 잔액 세부 정보는 야간 일괄 작업에 의해서만 수정됩니다. 이 경우 테스트는 계획 세부 정보 화면과 모든 계정을 업데이트하기 위한 일괄 작업 실행을 검증하여 수행됩니다.

4. 데이터베이스 테스트 – 메인프레임 애플리케이션(IMS, IDMS, DB2, VSAM/ISAM, 순차 데이터 세트, GDG)의 데이터가 레이아웃 및 데이터 저장에 대해 검증되는 데이터베이스입니다.

단계 3) 시스템 통합 테스팅

이 테스트의 주요 목적은 테스트 중인 시스템과 상호 작용하는 시스템의 기능을 검증하는 것입니다.

이러한 시스템은 요구 사항의 직접적인 영향을 받지 않습니다. 그러나 테스트 중인 시스템의 데이터를 사용합니다. 시스템 간 흐름이 가능한 인터페이스와 다양한 유형의 메시지(예: 작업 성공, 작업 실패, 데이터베이스 업데이트 등)와 개별 시스템에서 수행되는 결과 작업을 테스트하는 것이 중요합니다.

이 단계에서 수행되는 테스트 유형은 다음과 같습니다.

1. 배치 테스트
2. 온라인 테스트
3. 온라인 – 일괄 통합 테스트

단계 4) Regression Testing

회귀 테스트는 모든 유형의 테스트 프로젝트에서 일반적인 단계입니다. 메인프레임에서의 이 테스트는 테스트 중인 시스템과 직접 상호 작용하지 않는(또는 요구 사항 범위에 속하지 않는) 배치 작업과 온라인 화면이 현재 프로젝트 릴리스의 영향을 받지 않는다는 것을 보장합니다.

효과적인 회귀 테스트를 실시하려면 복잡성에 따라 특정 테스트 사례 세트를 선정하고 회귀 베드(테스트 사례 저장소)를 만들어야 합니다. 이 세트는 릴리스에 새로운 기능이 출시될 때마다 업데이트해야 합니다.

단계 5) 성능 시험

이 테스트는 프런트엔드 데이터, 온라인 데이터베이스 업그레이드 등 적중률이 높은 영역의 병목 현상을 식별하고 애플리케이션의 확장성을 예측하기 위해 수행됩니다.

단계 6) 보안 테스트

이 테스트는 보안 방지 공격에 대응하기 위해 애플리케이션이 얼마나 잘 설계되고 개발되었는지 평가하기 위해 수행됩니다.

시스템에서는 메인프레임 보안과 네트워크 보안이라는 두 가지 보안 테스트를 수행해야 합니다.

테스트에 필요한 기능은 다음과 같습니다.

1. Integrity
2. 기밀 유지
3. 권한 부여
4. 인증
5. 유효성

배치 테스트와 관련된 단계

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

테스트 보고 – 결함 실제 결과가 예상과 다를 경우 기록되어야 합니다.

온라인 테스트와 관련된 단계

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

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

온라인 관련 단계 – 일괄 통합 테스트

1. 작업을 실행합니다. 테스트 환경 온라인 화면에서 데이터의 유효성을 검사합니다.
2. 온라인 화면의 데이터를 업데이트하고 업데이트된 데이터로 일괄 작업이 제대로 실행되는지 확인합니다.

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

1. SUBMIT – 백그라운드 작업을 제출합니다.
2. CANCEL - 백그라운드 작업을 취소합니다.
3. ALLOCATE – 데이터세트를 할당합니다.
4. COPY – 데이터 세트 복사
5. RENAME – 데이터 세트 이름 바꾸기
6. DELETE – 데이터세트 삭제
7. JOB SCAN – 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(Generation Data Groups - 동일한 이름을 가지고 있지만 순차적인 버전 번호가 있는 파일 - MYLIB.LIB.TEST.G0001V00, MYLIB.LIB.TEST.G0002V00 등)를 사용하여 동일한 이름의 연속 파일에 데이터를 저장합니다.
   2. 파일에 대한 DISP(Disposition – 단계 또는 작업의 정상 또는 비정상 종료 후 데이터 세트를 유지하거나 삭제하는 시스템을 설명) 매개변수가 올바르게 코딩되어야 합니다.
   3. 작업 실행에 사용된 모든 파일이 저장되고 적절하게 닫혀 작업이 HOLD 상태가 되지 않도록 하십시오.
   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 테이블에 액세스하는 동안 실수로 업데이트되는 것을 방지하려면 항상 자동 커밋을 "NO"로 설정하세요.
5. 테스트 데이터 가용성은 배치 테스트의 주요 과제입니다. 필수 데이터는 테스트 주기 훨씬 전에 생성되어야 하며 완전성을 확인해야 합니다.
6. 일부 온라인 트랜잭션 및 배치 작업은 데이터를 다른 애플리케이션으로 전송하기 위해 MQ(Message Queue)에 데이터를 쓸 수 있습니다. 데이터가 유효하지 않으면 MQ를 비활성화/중지할 수 있으며 이는 전체 테스트 프로세스에 영향을 미칩니다. 테스트 후에는 MQ가 제대로 작동하는지 확인하는 것이 좋습니다.

메인프레임 테스트 과제 및 문제 해결

도전	접근
불완전하거나 불분명한 요구사항 사용자 매뉴얼/교육 가이드에 액세스할 수 있지만 이는 문서화된 요구 사항과 동일하지 않습니다.	테스터는 요구 사항 단계부터 SDLC에 참여해야 합니다. 이는 요구 사항이 테스트 가능한지 확인하는 데 도움이 됩니다.
데이터 설정/식별 요구 사항에 따라 기존 데이터를 재사용해야 하는 상황이 있을 수 있습니다. 기존 데이터에서 필요한 데이터를 식별하는 것이 어려울 때가 있습니다.	데이터 설정을 위해 필요에 따라 자체 개발 도구를 사용할 수 있습니다. 기존 데이터를 가져오려면 쿼리를 미리 작성해야 합니다. 어려운 경우에는 데이터 관리팀에 필요한 데이터 생성 또는 복제를 요청할 수 있습니다.
작업 설정 작업이 PDS로 검색되면 QA 영역에서 작업을 설정해야 합니다. 작업이 생산 한정자 또는 경로 세부 사항과 함께 제출되지 않도록 합니다.	설정 중에 발생하는 인적 오류를 극복하려면 작업 설정 도구를 사용해야 합니다.
임시 요청 업스트림 또는 다운스트림 애플리케이션 문제로 인해 엔드 투 엔드 테스트를 지원해야 하는 상황이 있을 수 있습니다. 이러한 요청은 실행 주기의 시간과 노력을 증가시킵니다.	자동화 스크립트, 회귀 스크립트 및 뼈대 스크립트를 사용하면 시간과 노력 오버헤드를 줄이는 데 도움이 될 수 있습니다.
범위 변경을 위한 정시 릴리스 코드 영향으로 인해 시스템의 모양과 느낌이 완전히 바뀔 수 있는 상황이 있을 수 있습니다. 이를 위해서는 테스트 사례, 스크립트 및 데이터를 변경해야 할 수 있습니다.	범위 변경 관리 프로세스와 영향 분석이 마련되어 있어야 합니다.

일반적인 이상 종료 발생

1. S001 – I/O 오류가 발생했습니다.

   이유 – 파일 끝에서 읽는 중, 파일 길이 오류, 읽기 전용 파일에 쓰려고 합니다.

2. S002 – 잘못된 I/O 레코드입니다.

   이유 – 레코드 길이보다 긴 레코드를 쓰려고 시도했습니다.

3. S004 – OPEN 중 오류가 발생했습니다.

   이유 – 잘못된 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 – 데이터 세트에 충분한 스토리지를 할당할 수 없습니다.

Error Assist - 다양한 유형의 이상 종료에 대한 자세한 정보를 얻는 데 매우 널리 사용되는 도구입니다.

메인프레임 테스트 중에 직면하는 일반적인 문제

• 작업이 이상 종료됨 – 작업을 성공적으로 완료하려면 특정 위치에 있는 데이터, 입력 파일 및 모듈이 있는지 확인해야 합니다. 잘못된 데이터, 잘못된 입력 필드, 날짜 불일치, 환경 문제 등 여러 가지 이유로 이상 종료가 발생할 수 있습니다.
• 출력 파일이 비어 있음– 작업이 성공적으로 실행되더라도(MaxCC 0) 출력이 예상과 다를 수 있습니다. 따라서 테스트 케이스를 통과하기 전에 테스터는 출력이 교차 검증되었는지 확인해야 합니다. 그런 다음에만 계속 진행하십시오.
• 입력 파일이 비어 있음 – 일부 애플리케이션에서는 업스트림 프로세스로부터 파일을 수신합니다. 수신된 파일을 현재 애플리케이션 테스트에 사용하기 전에 데이터를 교차 검증하여 재실행 및 재작업을 방지해야 합니다.

요약

• 메인프레임 테스트는 요구 사항 수집, 테스트 설계, 테스트 실행 및 결과 보고부터 시작하는 다른 테스트 절차와 같습니다.
• 애플리케이션을 효과적으로 테스트하기 위해 테스터는 개발팀과 비즈니스팀이 계획한 디자인 회의에 참여해야 합니다.
• 테스터는 다양한 메인프레임 테스트 기능에 익숙해지는 것이 필수입니다. 테스트 주기가 시작되기 전에 화면 탐색, 파일 및 PDS 생성, 테스트 결과 저장 등과 같은 작업을 수행합니다.
• 메인프레임 애플리케이션 테스트는 시간이 걸리는 프로세스입니다. 테스트 설계, 데이터 설정 및 실행을 위해 명확한 테스트 일정을 따라야 합니다.
• 배치 테스트와 온라인 테스트는 요구 사항 문서에 언급된 기능을 놓치지 않고 효과적으로 수행되어야 하며, 테스트 케이스 아껴야합니다.