[CSTS 요약] 7 테스트 자동화

테스트 자동화 분야 및 테스트 도구

완성도 높은 자동화 인프라는 테스트 케이스의 실행을 자동으로 하는 것을 핵심요소로 간주하는 것 뿐만이 아닌, 전체적인 테스트 활동의 전문성과 안전성에 관여

SEARCH 모델: 자동화 모델의 예, 각 단계의 자동화로 효율 증진과 실수 예방, 전문성과 일관성 유지 가능

• 셋업(Set up)
• 실행(Execution)
• 분석(Analysis)
• 보고(Report)
• 정리(Clean up)
• 도움말(Help)

ISO/IEC/IEEE 29119 동적 테스트 프로세스

• 테스트 설계 및 구현: 테스트 케이스 및 테스트 절차를 개발
• 테스트 환경 구축 및 관리: 테스트 환경 요구사항에 따라 테스트 환경을 구축하고 관리
• 테스트 실행: 테스트 절차를 실행하고 그 결과를 저장
• 결함 보고: 테스트 결과를 분석하여 결함이 식별되었을 때 이를 보고

 

테스트 설계 도구

테스트 케이스를 생성하는 도구로, 테스트 형태에 따라 명세 기반 테스트 설계 도구와 구조 기반 테스트 설계 도구로 분류

• 명세 기반 테스트 설계 도구: 요구사항 명세서 바탕 테스트 케이스 설계 및 생성을 지원
  주어진 명세 형태에 따라 테스트 케이스를 생성하며 조합 테스트를 위한 테스트 도구도 존재
• 구조 기반 테스트 설계 도구: 코드를 입력으로 받아 테스트 케이스를 생성
  테스트 케이스를 구성하는 기대 결과값은 코드로 끌어낼 수 없어 대부분의 구조 기반 테스트 도구는 테스트 입력값만을 생성
  커버리지 측정과 결과를 연동하여 동작

테스트 설계 도구 기반 생성된 테스트 케이스를 리그레션 테스트 시에 활용할 수 있음(ex. EvoSuite: 기대 결과를 생성하기 위해 명세 정보 활용 않고, 실제 프로그램을 실행하여 실행 결과를 기대 결과로 대신하는 방식)

 

테스트 환경 구축 도구

테스트 환경 구축은 원활한 테스트 수행을 위한 가장 기본적이면서 중요한 작업

IaC(Infrastructure as Code): 시스템 환경을 수동으로 구성하는 대신 시스템 환경 구성 정보를 기록한 스크립트를 사용하여 자동으로 인프라를 구성(ex. 도커Docker: 애플리케이션 실행 환경을 자동으로 설치)

 

테스트 실행 도구

테스트 케이스를 자동으로 실행할 수 있도록 스크립트로 변환하여 실행

Record&Playback 방식으로 사용자가 시스템을 사용하는 행위와 시스템 반응을 스크립트로 기록하여 이를 반복 실행할 수 있도록 함. 도구 사용자가 테스트 스크립트 언어에 관한 지식 없이도 테스트 케이스 설계하여 실행 가능(ex. Katalon Studio: Selenium IDE 기능 제공)

테스트 실행 프레임워크를 지원하는 스크립팅 언어 수준에 따른 분류

• 선형(Linear) 프레임워크: 스크립트를 작성하는 가장 간단한 형태
  모듈과 같은 스크립트를 구조화하는 수단을 제공하지 않으며 테스트 단계들을 순차적인 흐름으로 실행
• 모듈 기반(Modular Based) 프레임워크: 스크립트를 모듈화할 수 있는 여러 수단 제공
  한 스크립트에서 다른 스크립트를 호출할 수 있는 모듈 호출 기능을 통해 하나의 큰 스크립트를 유지가 용이한 여러 개의 작은 스크립트로 분할 관리 가능. 여러 스크립트에서 공통적으로 필요로 하는 스크립트 개발 비용을 줄일 수 있음
• 데이터 주도(Data-Driven) 프레임워크: 테스트에 사용되는 데이터를 테스트 스크립트의 로직과 분리 보관하는 프레임워크
  여러 개의 입력 데이터로 반복하여 테스트 가능, 입력 데이터 수정으로 테스트 스크립트 개수가 줄어듦, 테스트 스크립트의 변경이나 테스트 데이터의 변경이 상호 영향을 주지 않음
• 키워드 주도(Keyword-Driven) 프레임워크: 테스트 케이스와 애플리케이션 간 강한 결합으로 인하여 관련 테스트 케이스를 변경해야 하는 것을, 키워드를 사용한 테스트 케이스를 작성하여 애플리케이션이 변경되어도 테스트 케이스에 직접적으로 영향을 주지 않도록 함.
  키워드: 애플리케이션을 테스트할 때 요구되는 다양한 액션이나 단계를 캡슐화하는 테스트 케이스를 구성하는 빌딩 블록

프레임워크	장점	단점
선형	- 프로그래밍 지식 불필요 - 쉬운 테스트 케이스 작성	- 유지보수 어려움 - 테스트 기록 시점과 조건이 조금이라도 다르면 테스트 작동하지 않음 - 데이터가 스크립트에 직접 기록되어 다양한 데이터를 사용한 테스트 어려움
모듈 기반	- 여러 스크립트에서 공통적으로 필요한 스크립트 개발 비용 절감 - 애플리케이션 변경시 관련 스크립트만 변경 스크립트가 통과되는 경우와 그렇지 않은 경우를 구분하여 작성 가능	- 스크립트 작성 시 프로그래밍 지식 요구됨 - 다양한 데이터 활용 테스트 어려움
데이터 주도	- 다양한 데이터 사용 테스트 가능 - 데이터 파일 관리 용이	- 프로그래밍 지식 요구 - 데이터 파일 관리 요구 - 데이터 검증 필요
키워드 주도	- 테스트 설계와 자동화 분리 - 테스트 케이스 유지보수 용이 - 프로그래밍 지식 불필요 - 기술적 관점 아닌 비즈니스 관점에서 테스트 - 키워드 재사용 가능	- 프레임워크 구축 시 자동화 지식과 전문화된 테스트 자동화 인력 필요 - 테스트 라이브러리 구성 등 높은 초기 비용

 

이슈 관리 도구

테스트 프로세스 관련 문제만이 아닌 프로젝트 진행시 발행사는 모든 사항을 관리

• 신규 고객 요구사항
• 기능 개선
• 버그 수정
• 문서 작업
• 시스템 설치 작업

테스트를 통해 검출된 이슈는 시스템의 품질을 약화시키고 사용자 불만족을 유발할 수 있으며, 해결 완료를 위해 관리 필요

소스코드 수정 이후 결함이 제거되지 않았거나 새로운 결함 발생 가능성으로 인해 수정한 소스 코드 대상 재테스트 필요

결함 생명 주기 예

• 신규 상태: 수행한 테스트 결과 식별된 결함이 해결될 수 있도록 결함에 관한 정보를 기록하고 보고
  사소한 결함의 경우 바로 "완료" 상태로 변경하며, 적절한 수정이 필요한 경우 "진행"으로 변경
• 진행 상태: 지시된 결함 해결을 위한 개발자의 소스 코드 수정 작업
  개발자 스스로 결함 해결 판단이 서면 테스터에게 재테스트 요청하며 "해결"로 변경
• 해결 상태: 실제 결함이 해결되었는지 해당 결함 검출시 사용된 테스트 케이스를 다시 사용하여 테스트
  결함이 해결되고 새로운 결함이 발견되지 않았다면 "완료"로 변경, 기존 결함 발견되거나 다른 결함이 검출된 경우 "진행"으로 변경
• 완료 상태: 재테스트를 통해 결함 해결 확인 상태
  검출된 테스트 케이스 종결

테스트 도구 선정

자주 반복되는 테스트거나 속도가 느린 작업 혹은 도구를 사용하는 것이 더 안전하게 작업을 수행하는 경우 테스트 자동화의 대상이 됨

테스트 조직 및 프로세스 상황에 따라 반자동화 또는 일부 자동화(Semi-Automation) 고려 필요

테스트 피라미드

테스트 피라미드: 테스트 자동화 대상 관련 각 영역의 넓이는 각 테스트 타입의 투자 대비 효과(ROI)와 자동화해야 하는 양으로, 컴포넌트 테스트에 자동화가 많이 이뤄질수록 투자 대비 효과가 많아진다는 것을 의미

새로운 테스트 케이스를 개발할 때나 UI 혹은 통합 테스트 케이스 형태로 개발하는 대신 가능한 한 단위 테스트 케이스로 개발해야 효율적임을 시사. 단위 테스트 케이스로 테스트하지 못할 때만 통합 테스트 케이스를 개발하고, 단위나 통합 테스트 케이스로 부족할 때만 UI 테스트 케이스를 개발

테스트 도구 선정 프로세스

테스트 자동화를 위한 도구 선정 프로세스

• 요구사항 정의: 테스트 도구에 대한 요구사항 식별 정의
  도구 도입시 조직의 프로세스 및 능력 고려
• 도구 조사: 요구사항 고려하여 상업용 도구나 오픈소스 소프트웨어 혹은 자체 개발 가능성 검토
• 도구 평가: 평가 기준 통해 도구가 요구사항에 얼마나 부합하는지 평가
  도구 공급자의 명성, 사후 관리, 도구 갱신 주기 등 여러 요소 고려
• 파일럿 프로젝트: 도구의 시험판 버전이나 파일럿 프로젝트 통해 품질 평가하고 도구의 문제점을 도출하고 해결방안 검토
• 도구 선정: 도구 도입에 따른 테스트 프로세스 개선 효과 등 비용 대기 얻을 수 있는 이득을 추정하여 선택
• 도구 도입: 도구 도입에 따른 테스트 프로세스 개선
  도구 배포 계획 수립하고 교육 및 훈련 계획 수립