자동인수 테스트와 비기능 테스트

 

자동 인수 테스트

인수테스트는 요구 사항대로 기능이 구현됐는지를 확인하는 과정이다. 이 테스트에는 전체 시스템을 사용자 관점에서 시험하는 블랙박스 테스트가 포함되는데 테스트를 통과해야 비로소 인도할 수 있는 상태가 된다. 기능 및 비기능 요구사항을 검증하는 작업을 QA 담당자에게 의존하고 있는 상황에서는 이런 작업들은 프로그램을 이용해서 자동화 하는 것이 더 합리적이다.
그러나 자동화하는 것은 아래와 같은 이유들때문에 어려운 작업이 된다.
- 사용자 참여 : 실사용자와 함꼐 테스트를 작성해야 하며, 기술적 측면과 비기술적 측면이라는 두가지 상이한 영역을 모두 고려해야 한다.
- 의존성 통합 : 시스템이 전체적으로 잘 동작하는지 확인해야 하므로 테스트할 애플리케이션은 모든 의존성을 포함해 실행되어야 한다.
- 스테이징 환경 : 스테이징 환경은 프로덕션 환경과 동일해야 한다.
- 애플리케이션 동일성 : 애플리케이션은 한번만 빌드해야 하고 프로덕션에서도 동일한 바이너리를 사용해야 한다. 이는 실 환경들이 서로 달라 발생하는 문제를 제거한다.
- 릴리즈 준비 : 애플리케이션이 인수 테스트를 통과하면 사용자에게 바로 제공할 수 있도록 릴리스 준비가 되어야 한다.


도커 레지스트리 : 도커 이미지를 푸시하거나 가져올 수 있는 stateless 서버 애플리케이션이다. 보통 별도의 서버를 마련해 소프트웨어 패키지를 저장하고 불러오거나 검색하는데 이를 소프트웨어 리포지터리 또는 아티팩트 리포지터리라고 부른다.


아티팩트 리포지터리

컴파일된 라이브러리나 컴포넌트 같은 소프트웨어 바이너리 산출물을 저장해 나중에 완전한 애플리케이션을 빌드할 때 사용한다. 별도의 서버에 별도의 도구를 사용해서 저장하는 이유는 다음과 같다.

- 파일 크기 : 산출물은 파일 크기가 크기 때문에 업로드/다운로드에 최적화된 시스템이 필요하다. 
- 버전 관리  
- 리비전 매핑 : 각 산출물은 소스 관리 도구 내의 한개의 리비전과 정확히 매핑되어야 하며, 바이너리는 반복적으로 생성될 수 있어야 한다.
- 패키징 
- 접근제어 : 소스코드에 접근할 수 있는 사용자와 바이너리에 접근할 수 있는 사용자를 다르게 구성할 수 있다.
- 사용편의 : 아티팩트 바이너리는 모든 환경에서 정확히 동일 빌드 버전을 배포할 수 있으므로 문제 발생시 쉽게 롤백 할 수 있다.

개발자가 변경 사항을 소스코드 리포지터리로 푸시하면 파이프라인 빌드가 시작된다. 커밋 스테이지의 마지막 단계에서 생성된 바이너리는 아티팩트 리포지터리에 저장된다. 이후 인도 프로세스의 모든 단계에서 동일한 바이너리를 가져와 사용한다. 프로그래밍 언어와 기술에 따라 바이너리 형식은 달라진다. 도커로 작업할 경우 도커 이미지가 산출물이 되며, 도커 이미지는 도커 레지스터리에 저장된다.

 

아래는 비기능 요구사항을 검증하는 테스트 종류에 대해 설명한 것들이다.

비기능 테스트

비기능 테스트를 하기 위해서 다음 단계들을 수행해야 한다.
1. 핵심적인 비기능 요소가 무엇인지 정의한다.
2. 인수테스트에서와 같은 방식으로 테스트를 작성하고, 파이프라인에 비기능 테스트 스테이지를 추가한다.
3. 비기능 테스트를 통과한 애플리케이션만 릴리즈 스테이지로 보낸다.

기능 테스트는 시스템의 동작을 검증하는 반면에 비기능 테스트는 다른 측면을 고려한다.

성능테스트

가장 널리 사용되는 비기능 테스트이다. 시스템의 반응성과 안정성을 측정한다.
가장 단순한 방법으로는 웹서비스에 요청을 보내고 응답을 받을때까지 왕복시간(RTT)를 측정하는 방법을 사용한다.
그 외로도 다양하게 테스트 할 수 있는데 부하테스트, 스트레스 테스트, 확장성 테스트 등이 있다. 때로는 화이트 박스 테스트라고 부르기도 한다.
성능 테스트를 위해 전용 프레임워크(ex: Jmeter)를 사용하거나 인수 테스트에서 사용했던 것과 같은 동일한 도구를 사용한다. 단순한 성능 테스트는 보통 파이프라인 스테이지에서 인수 테스트 바로 뒤에 추가된다. 이 테스트는 RTT가 기준 시간을 초과하거나 지연을 일으키는 버그가 있을 경우 실패하도록 구성된다.

부하테스트 

다량의 동시 요청이 발생한 경우 시스템의 동작을 확인하는데 사용된다. 시스템이 한 개의 요청을 매우 빠르게 처리한다는 것이 백 개의 요청도 빠르게 처리한다는 것은 아니다. 
보통 다수의 기기에서 생성한 많은 요청에 따른 평균 요청-응답 시간을 측정한다. 부하테스트는 릴리즈 주기에서 매우 일반적인 QA 단계이다. 이를 자동화하려면 간단한 성능 테스트와 같은 도구를 사용한다.

 

스트레스 테스트 

용량테스트나 처리량테스트라고도 부른다. 서비스에 얼마나 많은 동시 사용자가 접속할 수 있는지를 결정하는 테스트이다. 
부하테스트의 경우 동시 사용자수를 정해놓고 응답시간을 측정해 기준을 넘어가면 실패하는 것이지만, 스트레스 테스트는 시스템이 여전히 동작 가능한 상태에서 대기 시간을 일정하게 유지하고 처리량을 늘려 최대 동시 호출 수를 알아낸다는 점에서 차이가 있다.
따라서 스트레스 테스트의 결과로 사용량이 가장 높은 시간대에 대한 대비를 할 수 있게 해준다. 스트레스 테스트는 동시 요청 수를 늘려가며 오랫동안 테스트해야 하기 때문에 지속적 인도 프로세스에는 적합하지 않고 별도 젠킨스 파이프라인 스크립트로 준비되어서 사용한다.

확장성 테스트

서버나 서비스를 추가할때 대기 시간과 처리량이 어떻게 변하는가를 점검하는 테스트이다. 이 테스트의 이상적인 형태는 선형이다. 기기의 수와 동시 사용자의 수의 관계를 보여주는 그래프로 제공해주고 이런 데이터는 시스템의 한계를 정하고, 더 많은 기기를 추가해도 도움이 되지 않는 지점을 찾아내는데에 도움을 준다. 
확장성 테스트 역시도 지속적 인도 파이프라인에 포함시키기는 어렵기 때문에 별도로 운영된다.

내구성 테스트

수명 테스트라고도 불리며 시스템을 장시간 실행하면서 시간이 지남에 따라 성능이 저하되는지를 확인한다. 즉 메모리 누수와 안정성 문제를 점검한다. 시스템을 꽤 오랜 시간 실행해야 하므로 이 역시도 지속적 인도 파이프라인에 넣지 않고 따로 운영된다.

보안테스트

보안 매커니즘이나 데이터 보호와 관련된 다양한 측면을 다룬다. 지속적 인도 프로세스 내의 파이프라인 스테이지로 포함되어야 한다. 이 테스트는 인수 테스트와 같은 프레임 워크로 작성되거나 전용 보안 테스트 프레임 워크로 작성될 수 있다.

유지보수 테스트 : 시스템의 유지보수가 얼마나 간단하지 점검한다. 즉 코드 품질을 판단한다.

복구 테스트

소프트웨어 또는 하드웨어 오류로 시스템에 충돌 문제가 발생한 후 얼마나 빨리 복구될 수 있는지를 확인하는 기술이다. 가장 좋은 것은 일부가 중단되더라도 시스템에 문제를 끼치지 않는 것이다. (ex: 넷플릭스사의 Chaos Monkey 도구로 프로덕션 환경에서 임의로 인스턴스를 무작위로 중단시켜서 확인)