테스트 스크립트의 유지보수성 및 재사용성을 늘리려면 구현하기 전에 해당 스크립트를 구성해야 합니다. 여러 테스트 스크립트에 나타나는 조치가 있음을 알게 됩니다. 목적은 조치 구현을 재사용할 수 있도록 조치를
식별하는 것입니다.
예를 들어 테스트 스크립트는 레코드에서 수행할 수 있는 서로 다른 조치의 조합일 수 있습니다. 이 테스트 스크립트는 다음과 같이 레코드의 추가, 수정 및 삭제를 조합한 것일 수 있습니다.
-
(이전 항목) 추가, 수정, 삭제
-
추가 삭제, 수정
-
추가, 삭제, 추가, 삭제, ...
-
추가, 추가, 추가, ...
이 조치를 별도의 테스트 스크립트로 식별 및 구현한 후 기타 테스트 스크립트에서 재사용하는 경우 상위 레벨의 재사용을 달성할 수 있습니다.
다른 목적은 대상 소프트웨어를 변경하면 테스트 스크립트에서 변경사항을 로컬에 저장하고 제어할 수 있도록 테스트 스크립트를 구성하는 것입니다. 그러면 테스트 스크립트가 대상 소프트웨어의 변경에도 더 탄력적으로
대응합니다. 예를 들어 소프트웨어의 로그인 부분이 변경된 경우를 가정해 보십시오. 로그인 부분을 순회하는 모든 테스트 케이스에서 로그인과 관련된 테스트 스크립트만 변경해야 합니다.
테스트 스크립트의 높은 유지보수성을 달성하려면 테스트 대상의 변경사항에 거의 영향을 받지 않도록 기록해야 합니다. 예를 들어 대화 상자 필드에서 채우는 테스트 스크립트의 경우 다음과 같이 한 필드에서 다음 필드로
진행하는 방법에 대한 선택사항이 제공됩니다.
-
TAB 키 사용
-
마우스 사용
-
키보드 단축키 사용
이 선택사항 중 일부는 기타 사항보다 디자인 변경에 더 영향을 받기 쉽습니다. 새 필드가 화면에 삽입된 경우 TAB 키 접근 방식은 확실하지 않습니다. 단축키를 재지정해도 좋은 기록을 제공하지 않습니다. 필드를
식별할 때 마우스를 사용하는 방법이 변경에 영향을 받는 경우 역시 신뢰할 수 있는 방법은 아닙니다. 그러나 일부 테스트 자동화 도구에는 개발 도구(PowerBuilder, SQLWindows 또는 Visual
Basic)에서 지정한 해당 오브젝트 이름과 같이 보다 신뢰할 수 있는 방법을 사용하여 필드를 식별하도록 지시할 수 있는 테스트 스크립트 레코더가 있습니다. 이 방법을 사용하는 경우 기록된 테스트 스크립트는 사용자
인터페이스의 사소한 변경(예: 레이아웃 변경, 필드 레이블 변경, 형식화 변경 등)에도 영향을 받지 않습니다.
많은 테스트 스크립트는 지정된 데이터 입력 화면에 여러 필드 데이터 세트를 입력하여 필드, 유효성 검증 기능, 오류 처리 등을 확인하는 작업과 관련이 있습니다. 프로시저 단계는 동일합니다. 데이터만 다릅니다. 모든
입력 데이터 세트에서 테스트 스크립트를 기록하는 대신, 단일 레코딩을 작성하여 다중 데이터 세트를 처리하도록 수정해야 합니다. 예를 들어 올바르지 않은 데이터 때문에 동일한 오류를 생성하는 모든 데이터 세트는
기록된 동일한 테스트 스크립트를 공유할 수 있습니다. 테스트 스크립트는 변수 정보로 데이터를 처리하고 파일 또는 기타 외부 소스에서 데이터 세트를 읽으며 모든 관련 데이터 세트에서 루프를 실행하도록 수정됩니다.
테스트 스크립트 또는 테스트 코드를 개발하여 입력 및 출력 데이터 세트에서 루프를 실행하는 경우 데이터 세트를 설정해야 합니다. 이 데이터 세트에서 사용할 일반 형식은 텍스트 파일에서 쉼표로 구분된 필드의
레코드입니다. 이 형식은 테스트 스크립트 및 테스트 코드에서 읽기 쉬우며 작성 및 유지보수가 용이합니다.
대부분의 데이터베이스 및 스프레드시트 패키지는 쉼표로 구분된 텍스트 출력을 생성할 수 있습니다. 이 패키지를 사용하여 데이터 세트를 구성하거나 캡처하는 경우 두 가지 중요한 이점이 있습니다. 첫 번째로 단순히 문서
편집기 또는 워드 프로세서를 사용하는 것보다 데이터 입력 및 편집 시 보다 구조적인 환경을 제공합니다. 두 번째로 대부분 기존의 데이터베이스를 조회하고 리턴된 데이터를 캡처하는 기능이 있으므로 기존 소스에서 데이터
세트를 쉽게 추출할 수 있습니다.
기록된 테스트 스크립트는 실행 순서가 순차적입니다. 분기점은 없습니다. 테스트 스크립트의 강력한 오류 처리에는 오류 조건에 응답하는 추가 로직이 필요합니다. 오류 발생 시 사용할 수 있는 결정 로직은 다음과
같습니다.
-
서로 다른 테스트 스크립트 분기 지정.
-
오류 조건을 정리하려는 스크립트 호출.
-
스크립트 종료 및 다음 스크립트 시작.
-
스크립트 및 소프트웨어 종료, 실패한 스크립트 이후 다음 테스트 스크립트 다시 시작 및 테스트 재개.
각 오류 처리 기법에는 테스트 스크립트에 추가된 프로그램 로직이 필요합니다. 가능한 이 논리를 하위 레벨 테스트 스크립트의 시퀀스를 제어하는 상위 레벨 테스트 스크립트로 제한해야 합니다. 그러면 하위 레벨 테스트
스크립트가 레코딩으로 완전히 작성될 수 있습니다.
스트레스 테스트를 수행하는 경우 사전 정의된 시간에 시작할 수 있도록 종종 테스트 스크립트를 동기화하는 경우가 있습니다. 시스템 시간과 원하는 시작 시간을 비교하여 특정 시간에 테스트 스크립트를 시작하도록 수정할
수 있습니다. 네트워크 시스템에서 각 테스트 스테이션은 네트워크를 통해 동일한 클럭을 공유합니다. BASIC으로 작성된 스크립트의 다음 예제에서 명령문은 스크립트 시작 위치에 삽입되어 요청된 시간에 도달할 때까지
스크립트 실행을 일시중단합니다.
InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
DoEvents
Loop
[Start script]
이 예제에서 필수 시작 시간은 파일에 저장됩니다. 그러면 테스트 스크립트를 변경하지 않고 시작 시간을 변경할 수 있습니다. 시간은 StartTime$ 변수에서 읽고 해당 변수에 저장됩니다.
Do While 루프는 시작 시간에 도달할 때까지 계속 실행됩니다. 이때 DoEvents 명령문이 중요합니다. 이 명령문을 통해 테스트 스크립트를 일시중단한 후 시작을
대기하는 동안 배경 타스크를 실행할 수 있습니다. DoEvents 명령문이 없으면 시스템은 시작 시간에 도달할 때까지 응답을 하지 않습니다.
새로 기록된 테스트 스크립트가 기록된 동일한 소프트웨어에서 실행되면 오류는 발생하지 않습니다. 기록되는 경우 환경 및 소프트웨어는 서로 동일합니다. 테스트 스크립트가 실행되지 않는 인스턴스가 있을 수 있습니다.
테스트 스크립트를 테스트하면 이 경우가 밝혀지며 실제 테스트에서 사용하기 전에 스크립트를 정정할 수 있습니다. 두 개의 일반 문제점 유형을 다음에서 논의합니다.
-
사용자 인터페이스에서 항목을 선택할 때 사용하는 방법의 모호함 때문에 재생 시 테스트 스크립트가 서로 다르게 작동할 수 있습니다. 예를 들어 텍스트 또는 캡션에서 인지한 두 개의 항목에 동일한 텍스트가 있을
수 있습니다. 스크립트 실행 시 모호함이 존재합니다.
-
테스트 실행/세션 특정 데이터(즉, 포인터, 날짜/시간 소인 또는 일부 기타 시스템 생성 데이터 값)가 기록되지만 재생 시 서로 다릅니다.
재생 및 레코딩에서 타이밍에 차이가 나면 문제점이 발생할 수 있습니다. 테스트 스크립트를 기록하면 실행하는 것보다 프로세스 속도가 원래 더 느립니다. 때때로 이 시간 차이 때문에 소프트웨어 이전에 테스트 스크립트가
실행됩니다. 이 경우 테스트 스크립트를 소프트웨어 속도로 억제하도록 대기 상태를 삽입할 수 있습니다.
|