배치 프로세싱(Batch processing)이란
- 배치 잡(batch Jobs)이라 불리는 일련의 프로그램들 집합을 간섭 없이 컴퓨터에서 실행하는 일
- 수시로 사용자의 입력을 받아 처리하는 온라인 또는 인터액티브 프로그램과 달리 배치 잡은 스크립트나 커맨드 라인 패러미터를 통해 모든 입력 데이터를 셋업하고 사용자의 간섭 없이 이를 처리하여 출력 데이터 파일을 생성한다.
배치 프로세싱 적용 분야
- 메인프레임 컴퓨팅 환경에서 널리 사용됨
- 정도 차이는 있지만 거의 모든 유형의 컴퓨터 시스템(유닉스 기반, MS 윈도우즈, 맥 OS X, 스마트폰 등)에서 정리 작업(housekeeping tasks)에 배치 프로세싱 수행
- 대부분의 비지니스 시스템이 하나 또는 그 이상의 배치 애플리케이션을 포함. 대표적인 예가 아래와 같다.
- 보고서 생성/출력: 은행의 경우 이자 계산, 일일 마감 보고서 생성, 타 시스템을 위한 데이터 생성, 재무제표 출력, 지불 프로세싱 등에 사용됨
- 빌링(Billing): 거의 모든 비즈니스에서 발생되는 빌링은 본질적으로 배치 기반 비즈니스 프로세스이다.
- 바이러스 스캔(Virus scanning): 불필요한 임시 파일의 주기적 삭제 같은 예정된 잡(jobs)을 돌리는 것도 배치 프로세싱 형태이다.
- 이메일 시스템(E-mail systems): 주기적으로 오래된 메시지를 보관(archive) 하고 압축하는 배치 잡 포함
- 데이터 처리: 대용량 데이터베이스 업데이트 및 자동 트랜잭션 처리에 배치 프로세싱 사용. 또한 컴퓨터 파일을 한 형식에서 다른 형식으로 전환(Converting) 하는데 사용되며, 데이터 웨어하우스의 ETL 작업도 본질적으로 배치 프로세스이다.
- 디지털 이미지의 다양한 오퍼레이션(리사이즈, 전환, 워터마크, 이미지 편집 등) 수행에 사용됨
배치 프로세싱 테스트
- 배치 프로세싱의 결과(출력물)가 사용자의 요구사항을 충족하는지 확인하는 작업
- 잡 셋업(job setup)이나 출력 분배(output distribution)에 있는 에러를 찾아서 수정하는데 목적이 있다.
- 배치 테스트 결과(주로 인쇄 보고서나 갱신된 파일)의 정확성 확인은 대개 수작업으로 하기는 어렵다. 비교기(comparator) 같은 도구 이용
- 배치 작업 관련 성능 요구사항이 있다면(예, 이 배치 작업은 3시간 만에 완성되어야 한다 등) 테스트에서 성능 요구사항이 충족되는지를 확인한다. 인터액티브 시스템에서는 반응시간(response time) 또는 지연(latency)이 중요한 성능 목표라면 배치 시스템은 처리량(throughput)이 매우 중요하다.
- 직접적인 사용자 인터페이스가 없는 배치 프로그램이 온라인 프로그램보다 자동화에 더 적합하다. 실행 중 파일 또는 데이터베이스로부터 받은 정보에 의해서 통제되는 배치 프로그램에서는 자동화를 위해 단순한 커맨드 파일(또는 스크립트)을 사용하여 데이터를 셋업하고, 프로그램을 호출하고, 그 결과를 비교한다.
배치 테스트와 온라인 테스트 차이점
배치 테스트 |
온라인 테스트 |
UI가 없어서 테스트 결과 바로 확인이 안됨 일단 start 시키면 장시간 run 테스트 결과 검증 시 도구(예, comparator) 이용 사용자 인터액션에 대한 프로그래밍이 필요 없어 테스트 자동화가 더 간단하며 효과적 |
대화형 테스트 시나리오를 작성한다. 테스트 수행 중에 그 결과를 즉각적으로 확보한다(주로 UI 화면상으로 나타남). 테스트 결과를 발생 시점마다 기록한다. 테스트 자동화를 위해 캡쳐앤드플레이 방식 또는 직접 프로그래밍 방식으로 사용자 인터액션을 프로그래밍 해야 함 |
배치 + 온라인 방식 시스템의 테스트
- 테스트될 시스템이 온라인과 배치로 혼합 구성되어 있고 특히 동일한 데이터를 온라인과 배치에서 갱신하는 시스템이라면 온라인 테스트와 배치 테스트의 적절한 조정이 필수적이다.
- 배치와 온라인 두 가지 유형의 테스트를 서로 다른 기법과 데이터를 이용하여 다른 부서에서 독립적으로 테스트할 수도 있지만 테스트 활동간의 상호 의존성은 매우 높다.
- 이런 시스템의 테스트 전략 중 하나는 테스트 초기에 배치와 온라인 테스트 환경을 분리하여 독립적으로 수행하고 각 테스트가 안정적이고 디버깅이 만족스럽게 수행되었다고 판단되는 시점에 조합하여 함께 테스트하는 방법을 들 수 있다(단점은 테스트 소요 시간이 길어지는 경향이 있다는 점).
배치 프로그램 단위 테스트 체크리스트 예
샘플 1
체크 항목 |
프로그래머 서명 |
검토자 서명 |
재시작 가능한 프로그램(Restartable program)은 반드시 리프레쉬(refresh) 후에 가동된다. |
|
|
코맨드 라인에서 정확한 수의 패러미터를 프로그램이 받아들인다. |
|
|
코맨드 라인에서 패러미터 수가 너무 적으면 프로그램이 중단된다. |
|
|
코맨드 라인에서 패러미터 수가 너무 많으면 프로그램이 중단된다. |
|
|
정확한 로그인이 주어질 때 성공적으로 가동된다. |
|
|
잘못된 로그인 일 때 프로그램이 중단된다. |
|
|
쓰레드가 정확히 작동한다. |
|
|
메시지가 정확한 로그 위치에 쓰여진다(에러는 에러 로그에, 시작/종료는 메시지 로그에) |
|
|
에러 메시지가 표준을 준수한다. |
|
|
에러 메시지는 완전한 문장과 올바른 문법으로 작성된다(생략/말줄임 안됨). |
|
|
디버거를 통한 비정상 종료 후에 프로그램이 성공적으로 재시작 한다. |
|
|
정확한 포맷의 입력 파일이 주어지면 성공적으로 가동된다. |
|
|
정확하지 않은 포맷의 입력 파일이 주어지면 중단된다. |
|
|
입력 파일이 부정확한 데이터 타입의 필드를 포함하고 있으면 중단된다. |
|
|
빈 입력 소스(파일, 데이터베이스 테이블)로 테스트 해본다(생성된 출력 파일 확인). |
|
|
입력 소스가 단일 레코드를 가지고 있는 경우를 테스트 해 본다. |
|
|
테스트 케이스가 결과 검증을 위한 SQL을 포함하고 있으면 이게 드라이빙 커서(the driving cursor)에 매치되는지 확인한다. |
|
|
샘플 2: 개발(응용-Batch) 체크리스트
체 크 항 목 |
|
[공 통]
|
1. 입력 인수에 대한 체크는 정확한가? 2. 계산 처리된 데이터 값은 정확히 확인 하였는가? 3. 첫번째 Data와 마지막번째 Data의 처리는 정확히 하였는가? 4. 프로그램 종료 시 메모리 해제는 하였는가? 5. Data 처리시 오류 발생에 대한 대응은 적절한가? 5.1 작업 중단 처리는 적절한가? 5.2 오류 안내 메시지는 적절한가? 5.3 오류 관련 Data 처리는 적절한가? 6. Input Data 건수는 확인하였는가? ( 건) Output Data 건수는 확인하였는가? ( 건) 7. 전체적인 안내 메시지는 적절한가? 8. 작업 결과에 따른 Log File은 생성되었는가? 9. 작업은 정상적으로 종료되었는가? |
[DATABASE] |
1. Host 변수선언 시 실제길이 + 1로 Buffer 처리하였는가?(초기화: NULL(0x00) Set) 2. Array buffer 처리 시 마지막 Loop 처리는 적절한가? 3. Dynamic SQL 사용 시 적절한 선택인가? |
[출력(인쇄)] |
1. Page Skip은 적절한가? 2. 출력 위치에 정확하게 Data가 기재 되었는가? |
'개발생명주기단계별 > 구현_단위 테스팅' 카테고리의 다른 글
영상자료 – 초보자를 위한 JUnit과 Mockito 튜토리얼 by Thippireddy (0) | 2019.07.24 |
---|---|
페이퍼요약 - 단위 테스팅 중단 기준으로서의 코드 커버리지에 대한 조사 by Smith (0) | 2019.07.22 |
문서요약 - JUnit과 CPPUnit에 의한 단위 테스팅 by Pietroszek (0) | 2019.07.08 |
문서요약 - 자동화된 단위 테스팅 프레임워크 by Simonsen (0) | 2019.07.01 |
페이퍼요약 - 단위 테스팅 관행에 대한 조사 by Runeson (0) | 2019.06.24 |