[Study] CSTS 7장 - 테스트 자동화

테스트 자동화

도구를 사용하여 테스트 프로세스의 일부 혹은

전부를 자동화하는 것을 의미한다.

 

사람이 수행하는 단순하고 반복적인 일에

도구를 사용하여 효율적으로 작업을 수행할 수 있게 하고,

테스터의 부담을 줄여 좀 더 창의적인 작업에 집중할 수 있게 한다.

 

도구분류

(테스트를 지원하는 업무에 따라 도구를 분류한 것)

지원업무	도구종류
테스트 관리	테스트 관리 도구, 요구사항 관리, 인시던트 관리(이슈 추적), 형상 관리	• 테스트 계획, 노력 추정, 테스트 일정과 관련된 작업 수행 • 테스트 진행과 보고 • 테스트 문서 관리 • 요구사항과 테스트 케이스 추적성 관리 • 이슈 등록 및 추적 • 변경 관리 및 통제
정적 테스트	리뷰 프로세스 지원 도구, 정적 분석 도구, 모델링 도구	• 표준 코딩 규칙 검사 • 복잡도 검사 • 자료 흐름 검사
동적 테스트	테스트 설계 도구, 테스트 데이터 준비 도구	• 모델이나 소스 코드에서 테스트 케이스 생성 • 테스트 실행에 필요한 데이터 자동 생성
테스트 실행 및 로깅	테스트 실행 도구, 테스트 하네스 (Harness)/단위 테스트 프레임워크, 테스트 비교기, 커버리지 측정 도구, 보안 도구	• 테스트 케이스 실행 • 모의 객체 생성 • 기대 결과와 실행 결과 비교 • 커버리지 측정
성능 및 모니터링	동적 분석 도구, 성능/스트레스/부하 테스트 도구, 모니터링 도구	• 메모리 누수 검사 •부하 발생 • 성능 측정

 

현재 개발 중인 웹 사이트의 로그인 기능이

올바르게 동작하는지 테스트하기 위해

로그인 검증을 위한 테스트 단계들을 수행해야 하는

상황을 가정해 보자.

 

만약, 아래 단계들을 수작업으로 수행해야 한다면

굉장히 단순한 작업인데도 수작업으로

많은 실수가 발생할 가능성이 있다.

 

웹 사이트 주소나 아이디,

또는

비번을 잘못 입력할 수 있고,

주어진 절차를 빠뜨리거나 따르지 않으면

올바른 테스트를 수행할 수 없게 된다.

또한, 로그인 기능이 올바르게 동작하는지

확인하기 위해 웰컴 페이지를

사람이 직접 확인해야 한다.

 

로그인 검증을 위한 테스트 단계

(1) 웹 사이트 주소 입력
(2) Id 필드에 가입한 아이디 입력
(3) 패스워드 필드에 비번 입력
(4) 로그인 버튼 클릭
(5) 웰컴(welcome) 페이지 확인

 

아래 코드는 위 로그인 검증을 위한 테스트 단계를

셀레늄(Seleniumn)의 JUnit Webdriver 코드로 변환한 것이다.

셀 레늄은 웹 애플리케이션 테스트를 위한 프레임워크이며

Java, CH, PHP, Buby 등 많은 언 어를 지원한다.

TE, Chrome, Firefox 등 대부분의

브라우저 및 윈도와 리눅스 등

많은 플랫폼에서 실행이 가능하다.

@Test
public void shouldVisitWelcomePage) throws IOException i
	driver• get("웹 사이트 주소");
	driver.findElement （By.id（"id'））.sendkeys（"아이디"）；
	driver.findElement (By.id("pwd")). sendKeys("비번");
	driver.findElement (By. id ("btnsignIn")). cLick();
    
	assertEquaLs("월컴 메시지","driver".findELement (By.xpath('blch blan") getText())
}

(JUnit Webdriver 코드 변환)

 

이와 같이 도구를 사용하여

실행할 수 있도록 자동화하면

테스터는 단순하면서

반복적인 업무에서 벗어나

일관성을 유지하면서

빠르게 테스트를 수행할 수 있다.

 

성능 테스트, 부하 테스트,

스트레스 테스트 등과 같이

실제 자동화하지 않으면

효과적인 테스트를 할 수 없는 분야가 있다.

ex)

부하 테스트나 스트레스 테스트를 위해

100명의 사용자가 동시에

시스템에 접근해야 하는 경우,

100명의 사용자를

실제 고용해서 테스트를 수행한다면,

시간과 비용이 너무 많이 들 것이고,

사용자들이 테스트 목적을 위해

정확하게 테스트를

수행한다는 것을 보장하기는

매우 어려울 것이다.

반면에 주어진 테스트 스크립트를

100개의 쓰레드나 프로세스를 이용하여

자동으로 수행한다면

훨씬 효과적으로 테스트를 수행할 수 있다.

물론, 모든 경우에 테스트 작업을

자동화하는 것이 정답은 아니다.

ex)

자주 반복적으로 수행되는 테스트가 아니고

한 두번 수행되는 경우에는

굳이 테스트를 자동화할 필요가 없을 것이다.

경우에 따라서는 자동화된 테스트보다

매뉴얼 테스트(Manual test)가 효과적일 때도 있다.

ex)

사용자 인터페이스 테스트를 수행할 때

화면 배경 색상과 버튼 배경 색상이 동일하여

버튼을 구분하기 어렵거나

화면 전환이 부자연스러운 경우는

사람이 화면을 지켜보고 있을 때

쉽게 발견할 수 있을 것이다.

---

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

전통적인 테스트 자동화

테스트 케이스의 실행을 자동으로 하는 자동화를

핵심요소로 간주하기 쉽지만 완성도 높은 자동화 인프라는

테스트의 여러 단계에 걸쳐

전체적인 테스트 활동의 전문성과 안정성에 관여한다.

 

위와 같은 자동화 모델의 예

키스 스토비(Keith Stobie)와

마크 버그먼(Mark Bergman)의

SEARCH 모델이 있다.

 

SEARCH 모델의 테스트 자동화

셋업(Set up), 실행(Execution), 분석(Analysis),

보고(Report), 정리(Clean up), 도움말 (Help)

총 6단계로 구성된다.

 

각 단계를 자동 화함으로써 효율을 높이고

사람의 실수(Human error)를 예방할 수 있으며,

이를 통해 전 문성과 일관성을 가진 테스트를 할 수 있다.

 

ISO/IEC/IEEE 29119는 테스트 프로세스를

조직 테스트 프로세스, 테스트 관리 프로세스 및

동적 테스트 프로세스로 분류하였으며,

이들 테스트 프로세스에 관련된 활동들은

모두 자동화 대상이 될 수 있다.

 

ISO/IBC/IEBE 29119의 동적 테스트 프로세스 활동을 지원하는 도구

IS0/IBC/IBBE 29119의 동적 테스트 프로세스

다음과 같은 네 가지 프로세스로 구성되며

이들이 모두 테스트 자동화의 대상이 될 수 있다.

테스트 설계 및 구현	테스트 케이스 및 테스트 절차를 개발하는 프로세스
테스트 환경 구축 및 관리	테스트 환경 요구사항에 따라 테스트 환경을 구축하고 관리하는 프로세스
테스트 실행	테스트 절차를 실행하고 그 결과를 저장하는 프로세스
결함 보고	테스트 결과를 분석하여 결함이 식별되었을 때 이를 보고하는 프로세스 이 절에서는 위 프로세스를 바탕으로 테스트 자동화 도구를 테스트 설계 도구, 테스트 환경 구축 도구, 테스트 실행 도구, 결함 보고 프로세스를 지원하는 이슈 관리 도구로 분류하여 기술한다.

---

테스트 설계 도구

테스트 설계 도구는 테스트 케이스를 생성하는 도구이다.

테스트 케이스를 생성하기 위해서는

테스트 형태에 따라 명세 기반 테스트 설계 도구와

구조 기반 테스트 설계 도구로 분류할 수 있다.

 

명세 기반 테스트 설계 도구

요구사항 명세서를 바탕으로

테스트 케이스의 설계 및 생성을 지원하는 도구이다.

주어지는 명세서의 형태에 따라

분류 트리(Classification tree) 형태로

명세서가 주어질 수도 있고 상태 전이도 형태로

명세서가 주어질 수 있다.

 

다양한 명세기반 테스트 설계 도구가 존재하는데,

요구사항 명세 모델을 입력으로 받아

테스트 케이스를 생성한다.

 

그뿐만 아니라 조합 테스트를 위한 테스트 도구도 존재한다.

마이크로소프트에서 만든 PICT 도구는

입력 인자와 입력 인자들이 취할 수 있는 값.

그들 간의 제약사항을 제공하면 제약 조건을 만족하는

페어와이즈 테스트 케이스 조합을 생성한다.

 

구조기반 테스트 설계 도구

코드를 입력으로 받아

테스트 케이스를 생성하는 도구이다.

 

명세 기반 테스트 설계 도구와는 달리

테스트 케이스를 구성하는 기대 결과값은

코드에서 이끌어낼 수 없기 때문에

대부분의 구조 기반 테스트 도구는

테스트 입력값만을 생성한다.

 

커버리지 측정과 결과를 연동하여 동작한다.

ex)

결정 커버리지를 만족하는

테스트 입력값을 산출하는 도구에서는

아직까지 실행되지 않은 분기들을 식별하여

이들을 실행할 수 있는 입력값을 생성한다.

대부분의 구조 기반 테스트 설계 도구

기대 결맛값은 생성하지 않지만,

몇몇 구조 기반테스트 설계 도구는 기대 결과도 생성한다.

ex)

EvoSuite

유전자 알고리즘(GA, Genetic Algorithm)에 바탕을 두고

소스 코드를 분석하여 테스트 케이스를 생성한다.

EvoSuite는 기대 결과를 생성하기 위해

명세 정보를 활용하지 않고,

실제 프로그램을 실행하여 실행 결과를

기대 결과로 대신하는 방식을 취한다.

이러한 도구는 레거시 시스템을 기반으로

프로젝트를 진행할 때

이렇게 생성된 테스트 케이스들을

리그레션 테스트 케이스로 활용할 수 있다.

ex)

레거시 시스템에 새로운 기능을 추가하기 위해서

시스템을 변경할 때, 기존의 기능이 영향을 받았는지

테스트하기 위해 실행 결과를

기대 결과로 대신하는 테스트 케이스들을 실행할 수 있다.

---

테스트 환경 구축 도구

테스트 환경 구축

테스트를 원활하게 수행하기 위한

가장 기본적이면서 중요한 작업이다.

 

개발자 환경에서 작동이 되는 애플리케이션이

실제 테스트 환경이나 운영 환경에서는

작동이 되지 않는 경우가 있다.

 

이렇게 일관성 없이 애플리케이션이 실행되는 이유는 매우 다양하다.

운영 및 테스트 환경 설정이 개발 환경과 다르거나

사용하는 라이브러리 버전이 다를 수도 있다.

 

뿐만 아닌 애플리케이션 환경을 설정하는 작업은

대부분 매우 까다롭기 때문에 환경을 구축하는 동안

실수를 하거나 구성 단계를 누락하기도 하고

순서를 지키지 않을 수도 있다.

 

최근에 IaC(Infrastructure as Code) 개념이 등장하였다.

IaC 는 말 그대로 "인프라를 코드 화한다",

"인프라를 코드로 기록한다"의 의미이다.

 

즉, IaC를 통해 시스템 환경을 수동으로 구성하는 대신

시스템 환경 구성 정보를 기록한 스크립트를 사용하여

자동으로 인프라를 구성한다.

 

이와 같이 인프라 구성 정보를 코드로 관리해 두면

애플리케이션 개발 시 Git 등과 같은 버전 관리 도구로

소스 코드를 관리하는 것처럼

변경 이력을 일원화하여 관리할 수 있다.

 

laC 개념을 바탕으로 한 도커(Docker)는

애플리케이션 실행 환경을

자동으로 설치할 수 있는 도구이다.

 

도커

소프트웨어 컨테이너(Container)라는 단위로 패키징 하며,

이 컨테이너에는 라이브러리, 미들웨어, 시스템 도구, 런타임 환경 등

애플리케이션을 실행하는 데 필요한 모든 것을 포함할 수 있다.

 

이러한 애플리케이션 실행 환경을 도커에서는

"Dockerfile"이라는 소스 코드로 환경 구성 정보를

기록하여 관리한다.

 

따라서

애플리케 이션을 신속하게 배포 및 확장할 수 있으며

코드가 문제없이 개발자 플랫폼에 구애받지 않고

실행될 것임을 확신할 수 있다.

즉, 누구라도 구성파일 실행을 통해

테스트 환경이나 운영 환경을

아주 손쉽게 구축할 수 있다.

---

테스트 실행 도구

테스트 실행

가장 전통적인 테스트 자동화의 핵심 분야이다.

 

테스트 실행 도구

테스트 케이스를 자동으로 실행할 수 있도록

스크립트로 변환하여 실행한다.

테스트 케이스를 컴퓨터가 실행할 수 있는

스크립트로 변환하는 방법 중에서

대표적인 것이 Becord&tPlayback 방식이다.

 

이 방식을 지원하는 도구는 사용자가 브라우저 등을 통해

시스템을 사용하는 행위와 시스 템 반응을 스크립트로 기록하고

이를 다시 반복 실행할 수 있도록 한다.

 

따라서

도구 사용 자가 테스트 스크립트 언어에 관한

특별한 지식이 없어도 테스트 케이스를

설계하여 실행할 수 있다.

 

 

Katalon Studto

Becord& Plasback 기능을 제공하는 도구이다.

크롬 브라우저의 플러그인으로 제공되며

기존의 Selenium IDE의 기능을 제공한다.

 

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

선형(Linear) 프레임워크

스크리부트를 작성하는 가장 간단한 형태이다.

모듈과 같은 스크립트를

구조화하는 수단을 제공하지 않으며,

스크립트의 테스트 단계들을 순차적인 흐름으로 실행한다.

이는 Record&Playback을 지원하는 도구에서 주로 찾아볼 수 있다.

 

모듈 기반(Modular Based) 프레임워크

스크립트를 모듈화 할 수 있는 여러 수단을 제공한다.

특히, 모듈 호출 기능은 한 스크립트에서

다른 스크립트를 호출할 수도 있다.

따라서

하나의 큰 스크립트를 유지가 용이한

여러 개의 작은 스크립트로 분할하여

관리하는 것이 가능하다.

 

여러 스크립트에서 공통적으로 필요로 하는

스크립트를 개발하는 비용을 줄일 수 있다.

 

데이터 주도(Data-Driven) 프레임워크

테스트에 사용되는 데이터를

테스트 스크립트의 로직과 분리하여

보관하는 프레임워크이다.

 

테스터는 빈번히 애플리케이션의 같은 기능을

다양한 입력 데이터로 여러 번 테스트해야 하는 상황과 마주한다.

이때,

테스트 데이터 셋을 스크립트 로직 내에 하드코딩 하지 않고

엑셀 시트, 텍스트 파일, CSV(Comma Separated Value) 파일 등에 보관하여

스크립트의 입력 데이터에 전달하면 테스트 수행 효율을 크게 높일 수 있다.

 

여러 개의 입력 데이터로 반복하여 테스트 될 수 있고,

입력 데이터만 바꾸기 때문에 필요한 테스트 스크립트 개수가 줄어든다.

그리고

테스트 스크립트의 변경이 테스트 데이터에 영향을 주지 않고,

데이터의 변경 또한 테스트 스크립트에 영향을 주지 않는다.

 

키워드 주도(Keyword-Driven) 프레임워크

앞서 언급한 테스트 프레임워크의 공통적인 단점은

테스트 케이스와 애플리케이션 간에 결합이 강하여

애플리케이션이 변경되면 관련된 수 많은 테스트 케이스도

따라서 변경해야 한다는 것이다.

ex)

입력 필드의 위치만 변경되더라도 해당 필드를 사용하는

수많은 스크립트가 변경되어야 한다.

키워드 주도 테스트

키워드를 사용한 테스트 케이스를 작성하여

테스트 케이스와 애플리케이션 간에 결합을 줄임으로써

애플리케이션이 변경되어도 테스트 케이스에

직접적으로 영향을 주지 않도록 하였다.

 

여기서 키워드란..

애플리케이션을 테스트할 때 요구되는 다양한 액션이나 단계를

캡슐화하는 테스트 케이스를 구성하는 빌딩 블록이다.

ex)

고객 정보를 애플리케이션에 추가하기 위해서는

고객 이름 입력, 고객 주소 및 전화번호 입력 및 등록 버튼을 클릭하고

올바르게 추가되었는지 확인하는 여러 단계로 구성된다.

실제 이런 단계들은 구체적으로 입력 필드를 확인하고

필요한 정보를 전달하는 등의 여러 기술적인 로직이 필요하다.

그러나

키워드 주도 테스트에서는 이들 기술적인 단계를 모두 캡슐화하여

"ADD A NEW CUSTOMBR" 키워드로 정의한다.

테스트 설계자

이렇게 미리 정의된 키워드들을 조합하여 

테스트 케이스를 작성한다.

따라서

애플리케이션이 변경되어도

키워드로 작성된 테스트 케이스들은

변경할 필요가 없다.

 

테스트 프레임워크

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

---

이슈 관리 도구

과거에는 버그 추적 도구로 불렸다.

이슈는 사전적 의미로는 사건 또는 문제점으로 해석된다.

따라서

이슈는 버그로 한정되어 취급될 수 있다.

 

일반적인 인시던트

테스트 프로세스 수행 중에 검출된 문제 즉, 이슈에 해당한다.

그러나 현재 사용 중인 수많은 이슈 관리 도구는

테스트 프로세스에 관련된 문제만이 아닌

프로젝트를 진행하면서 발생하는 모든 사항을 이슈로 처리한다.

다음은 이슈에 해당하는 일부분을 나열한 것이다.

 

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

 

따라서

이슈 관리 도구는 프로젝트 관리 도구라고 해도 무리가 없다.

이 절에서는 테스트를 통해 발견된 문제에 한정해서

이슈 관리 도구를 기술한다.

 

테스트를 통해서 검출된 문제점 즉, 이슈는

시스템 품질을 악화시키고

사용자 불만족을 유발하는 원인이 될 수 있다.

 

그러므로

식별된 문제점은 소스 코드를 수정해서

제거될 수 있도록 해야 한다.

 

만약, 문제점이 코드 결함으로 판명되고

이 결함이 매우 단순해서 개발자가 즉각적으로 해결할 수 있으면

바로 소스 코드를 수정하고 결함이 제거된 시스템을 빌드하면 된다.

 

하지만

일반적으로 테스트를 통해서

식별된 결함은 재연이 잘되지 않거나

그 근본 원인을 파악하기 어려운 경우가 있다.

 

따라서 결함이 검출되고 이를 해결하기까지는

적지 않은 시간이 소요되며,

중요한 결함은 반드시 해결되었는지 관리하여야 한다.

또한,

시스템 테스트 시 테스터는 결함을 검출하지만

결함을 제거하기 위해서 소스 코드를 변경하는 작업은

개발자 즉 프로그래머의 역할이다.

 

이런 경우에는 테스터가 검출한 결함 정보가

개발자/프로그래머와 공유되어야 한다.

 

그리고 개발자/프로그래머가 소스 코드를 수정하여

결함을 제거했다고 생각하더라도

결함이 제거되지 않았거나

실수로 새로운 결함이 발생하였을 수도 있다.

그러므로

개발자/프로그래머가 수정한 소스 코드를 대상으로

다시 테스트를 해야 한다.

 

이와 같이 결함이 식별되면

그 결함을 완전히 해결할 때까지

검출된 결함은 추적/관리되어야 한다.

 

대부분의 이슈 관리 시스템

이렇게 하나의 결함이 식별부터 완료될 때까지의

이슈 상태를 추적 관리하는 생명 주기(Defect Life Cycle)를

조직 실정이나 프로젝트 특성에 맞게 조정할 수 있는 기능을 제공한다.

 

아래 그림은 간단한 결함 생명 주기를 보여 준다.

결함 생명 주기 예

 

신규 상태

테스터는 테스트를 수행함으로써 결함을 식별할 수 있다.

테스터는 식별된 결 함이 해결될 수 있도록

결함에 관련된 정보를 기록하고 보고한다.

이렇게 식별된 결함이 보고된 상태를 "신규"로 정의하도록 한다.

"신규" 상태에서는 보고된 결함에 대한 분석이 수행된다.

그리고

해결할 필요가 없는 경 우에는 해당 결함을 종결시키고

"완료" 상태로 변경한다.

ex)

검출된 결함이 매우 사소해서 수정할 필요가 없다거나

기존에 해결된 결함이라는 확신이 있으면

이런 결함은 바로 "완료" 상태로 변경하도록 한다.

만약, 보고된 결함이 해결해야 하는 결함이라면

적절한 개발자에게 해당 결함에 대한 수정이 지시되며,

결함 상태를 "진행"으로 변경한다.

 

즉, 결함에 대한 해결 작업이 진행되고 있음을 의미한다.

 

진행 상태

개발자는 지시된 결함을 해결하기 위해서 소스 코드를 수정한다.

그리고

개발자 스스로 결함이 해결되었다고 판단이 서면

테스터에게 재테스트를 요청하면서

결함 상태를 “해결"로 변경하도록 한다.

 

해결 상태

테스터는 개발자에게서 지시된 결함이 해결되었다는

보고를 받았으므로 실제 결함이 해결되었는지

테스트함으로써 확인한다.

즉, 해당 결합을 검출하는 데 사용된

동일한 테스트 케이스를 다시 사용해서

그 결함이 제거되었는지 확인한다.

 

만약, 결함이 해결되고 새로운 결함이 발견되지 않았다면

해당 결함 상태를 "완료"로 변경한다.

 

반면, 테스터가 재테스트를 수행하였을 때

기존 결함이 여전히 발견되거나

기존 결함은 해결되었지만 새로운 다른 결합이 검출된 경우

다시 개발자에게 해결을 지시할 수 있다.

그리고

해당 결함 상태를 진행"으로 변경한다.

 

완료 상태

테스터가 결함이 해결된 것을

재테스트를 통해서 확인한 상태이다.

그러므로 결함이 이 상태에 도달하게 되면

비로소 검출된 결함을 종결시킨다.

또는

"신규"로 등록된 결함이 매우 사소해서

테스트 관리자가 바로 종결시킬 때도

결함은 "완료" 상태가 될 수 있다.

 

실제로 결함 생명 주기는 이보다 복잡할 수 있다.

ex)

테스터가 결함 해결을 확인하고

그 후에 테스트 관리자가 재차 확인할 수도 있다.

그리고

개발자가 결함을 해결하려고 했는데

해당 결함이 재연되지 않아서

테스터에게 결함에 관한 구체적인 상황을

재요청할 수도 있다.

현재 시장에는 이슈 관리를 지원하는

다양한 제품들이 출시되어 있다.

 

아래표는 대표적인 이슈 관리 도구를 나열한 것이다.

이슈 관리 시스템을 도입할 때는 매우 신중해야 한다.

한 번 도입한 이슈 관리 시스템은

사용 중에 타제품으로 변경하는게 쉽지 않고

변경 시에는 데이터 이관 등에 많은 시간과 비용이 발생한다.

또한,

이슈 관리 도구는 업무 규칙이나 업무 흐름 등과

직접적으로 연관되므로 도입할 도구를

너무 쉽게 결정해서는 안 된다.

사용성, 비용, 제공하는 기능, 서비스 제공 형태 등과 같은

여러 요소를 고려해서 도구를 선정 도입하여야 한다.

 

이슈 관리 도구

이슈 관리 도구	개발 언어	홈페이지	비고
Redmine	Ruby	http://www.redmine.org	GNU v2
Jira	Java	https://www.atlassian.com/software/jira	상용
Mantis	PHP	http://www.mantisbt.org	GNU v2
Trac	Phython	http://trac.edgewall.org	BSD
Yona	Java	http://yona.io/	Apache 2

---

테스트 도구 선정

자주 반복되는 테스트를 수작업으로 수행하면 많은 비용을 초래한다.

마찬가지로 속도가 느린 작업이거나 도구를 사용하는 것이

더 안전하게 작업을 수행할 수 있는 경우라면

테스트 자동화의 대상이 될 수 있다.

반면, 몇 번 수행되지 않는 테스트를 자동화하는 작업도

비용 대비 효과가 별로 없다.

또한,

테스트 프로세스의 모든 작업을 100% 자동화하는 것도

올바른 선택이 아닐 수 있다.

ex)

요구사항이 자주 변경되는 경우

테스트 케이스도 같이 변경되어야 하며,

 

CAPTCHA

(Completely Automated Publie Turing test to tell

Computers and Humans Apart,

완전 자동화된 사람과 컴퓨터 판별, 캡차),

 

폰트나 색상 등이 관련된 경우엔

자동화된 테스트보다는 매뉴얼 테스트가 더 효과적이다.

따라서 테스트 자동화는 매뉴얼 테스트(Manual test)를 대치하기보다는

상호 보완하는 방향으로 가야 한다.

 

테스트 조직 및 프로세스 상황에 따라

반자동화 또는 일부 자동화(Semi-Automation)를

고려할 필요가 있다.

 

일반적으로 테스트 자동화를 할 때 먼저

자동화를 시도하는 부분이 UI 테스트이다.

 

UI 테스트를 위해 많은 도구가 소개되고 있으며

시스템 전체를 테스트 대상으로 한다는 점에서 매우 매력적이다.

 

그러나

UI 테스트를 위한 테스트 케이스가

많아질수록 문제가 발생할 가능성이 커진다.

UI 테스트는 시스템 전체의 실행을 전제로 하기때문에

수많은 UI 테스트 케이스들을 실행하는 작업은

속도가 느릴 수밖에 없다.

또한,

UI는 시스템을 사용하는 사용자가 가장 처음 마주하는 것으로

UI에 대한 요구사항은 자주 변경되기 마련이다.

 

UI가 변경되면 해당 테스트 스크립트도 변경해야 한다.

만약, 요구사항이 변경되었는데

해당 테스트 케이스들을 제때 변경하지 않으면

거짓 양성(Palse positive)이 나타나기 시작한다.

거짓 양성이란 실제 결함이 아닌데

결함으로 잘못 판단한 경우를 의미한다.

 

즉, 프로그램 구현은 문제가 없으나

프로그램 구현 변경에 따라서

제때 수정이 안된 테스트 케이스들이

수정된 프로그램에 문제가 있다고 보고한다.

이러한 거짓 양성은 결과 확인 시 사람의 개입을 요구하여

결과적으로 자동화 효율성이 저하될 수밖에 없다.

테스트 피라미드

테스트 자동화 대상과 관련하여

Lisa Crispin의 테스트 피라미드 개념이 널리 알려져 있다.

 

위 그림은 테스트 피라미드를 보여준다.

피라미드에서 UL 테스트, 통합/API 테스트,

컴포넌트 테스트가 차지하는 영역의 넓이가 다른 것을 볼 수 있다.

 

각 테스트 타입이 차지하는 영역의 넓이는

투자 대비 효과(ROT)와 자동화해야 하는 양을 의미한다.

컴포넌트 테 스트에 자동화가 많이 이루어질수록

투자 대비 효과가 많아진다는 것을 의미한다.

 

컴포넌트 테스트 케이스

통합 테스트나 UI 테스트보다 쉽게 작성할 수 있으며

테스트 수 행에 따른 피드백이 빠르다.

또한,

결함이 발견되었을 때 단위 테스트는

결함을 발생시기는 부분을 쉽게 식별하여

수정이 가능한 반면, UI나 통합 테스트로 발견한 결함은

결함을 발생시키는 부분을 찾기 어려우므로

결함 수정에 시간이 많이 소요된다.

 

테스트 피라미드가 시사하는 점은

새로운 테스트 케이스를 개발할 때

UI 나 통합 테스트 케이스 형태로 개발하는 대신

가능한 한 단위 테스트 케이스로

개발할 것을 의미한다.

 

단위 테스트 케이스로 테스트하지 못할 때만

통합 테스트 케이스를 개발하고

단위나 통합 테스 트 케이스로 부족할 때만

UI 테스트 케이스를 개발한다.

테스트 도구 선정 프로세스

 

테스트 자동화를 위해 올바른 도구를

선정하는 작업은 매우 중요하다.

위 테스트 도구 선정 프로세스 그림은

테스트 도구를 선정하는 프로세스이며

각 단계는 다음과 같은 작업들을 수행한다.

 

요구사항 정의

테스트 도구에 대한 요구사항을 식별하여 정의한다.

도구를 도입할 때 조 직의 프로세스 및 능력을 고려해야 한다.

조직의 테스트 프로세스나 능력이 충분하게 성숙되어 있지 않으면

도구 사용에 따른 프로세스 변화에 적절하게 대처할 수 없기 때문에

그에 따른 충분한 효과를 볼 수 없다.

 

도구 조사

요구사항을 고려하여 상업용 도구나

오픈소스 소프트웨어 등을 조사한다.

또한,

자체 개발 가능성도 검토한다.

 

도구 평가

평가 기준을 준비하여

도구가 요구사항에 얼마나 부합하는지 평가한다.

이때,

도구 공급자의 명성이나

사후 관리 및 도구 갱신 주기 등과 같은

여러 요소를 고려한다.

 

파일럿 프로젝트

도구의 시험판 버전을 사용하거나

파일럿 프로젝트를 수행하여

도구의 품질을 평가한다.

또한,

도구의 문제점을 도출하고

해결방안을 검토한다.

 

도구 선정

도구 도입에 따른 테스트 프로세스의 개선 효과 등을 고려하여

비용 대비 대 얻을 수 있는 이득을 추정하여 도구를 선정한다.

 

도구 도입

실제로 도구를 조직에 도입하는 단계이다.

도구 도입에 따른 테스트 프로세스를 개선한다.

도구 배포 계획을 수립하고,

교육 및 훈련 계획을 수립한다.