SW Testing Level에 대해서

앞서 설명한 V모델에 따르면 동적 테스트는 단계별로 테스트의 범위와 주체에 따라서 “단위테스트, 통합테스트, 시스템테스트, 인수테스트” 4가지로 구분할 수 있다.

① 단위 테스트(개발자가 개발 단계에 수행)

• 시스템의 소스 코드 로직 등을 점검하는 단계로, 소스코드의 클래스나 메서드 단위의 검증을 수행
• 개발단계에서 개발자 또는 개발팀 차원에서 직접 수행
• 주로 기능이 제대로 작동하는 지를 점검
  — 결함을 개발 중에 찾아낼 수 있다는 유용한 테스트 기법임
• 개발자가 직접 단위 테스트 코드를 구현해야 하기 때문에 개발자에 대한 부담이 가중됨
• 보통 개발자 3~5명 당 단위 테스트를 구현 및 수행하는 사람을 1명정도 배치함
• 가장 이상적인 케이스는 코딩 시간과 단위 테스트 구현 시간을 같이 고려하여 개발 일정을 짜고, 모듈을 개발한 개발자가 단위 테스트까지 같이 작성하는 것이 가장 효율이 높다.

테스트 주도 개발(TDD/ Test Driven Development): 요즘은 테스트 케이스를 먼저 만들어놓고 코드를 작성하는 형태의 테스트 주도 개발방식도 많이 사용된다. 이 경우 개발자가 테스트 케이스를 먼저 개발하고 그 다음에 코드를 개발하는 형태이기 떄문에 테스트를 빠짐없이 구현할 수 있다는 장점은 있으나, 그만큼 테스트 코드를 개발하는 시간이 많이 투여되기에 장단점이 있다.

1) 인 컨테이너 테스트(In Container Test): 자바 애플리케이션에서는 주로 JUnit과 같은 xUnit 시리즈의 단위 테스트 프레임 워크를 사용하나, 톰캣이나 웹로직과 같은 미들웨어 위에서 작동하는 애플리케이션의 경우 테스트가 반드시 미들웨어 위에서 동작해야 함. 이러한 테스트를 인 컨테이너 테스트라고 하며 지원하는 프레임 워크로 Cactus 등이 있다.

2) 모크업(Mock Up): 단위 테스트는 소프트웨어 구성요소와 각 컴포넌트를 독립된 환경에서 테스트 하는 것이나 일반적으로 소프트에어 컴포넌트는 혼자서 동작할 수 없고 다른 컴포넌트에 대해 종속성(Dependency)을 가지고 있다. 이런 경우 가상의 테스트용 클래스와 메서드를 구현하는데 이를 모크업(Mock-up) 클래스 라고 한다. EasyMock과 같은 프레임워크를 사용하면 조금 더 쉽게 구현이 가능하다.

3) 지속적통합(CI, Continous Integration): 구현이 끝난 코드는 단위테스트를 통해서 검증하고, 소스 관리 시스템에 저장(commit)하게 된다. 저장된 소스 코드는 다른 사람이 작성한 소스코드와 함께 다시 컴파일 돼서 모든 단위 테스트를 다시 거치게 된다.

즉, 이번 저장에 작성한 단위 테스트를 포함해서 이를 포함한 예전 단위 테스트까지 모두 같이 테스트하게 되는데, 이를 회귀테스트(Regrssion Test)라고 한다.

회귀테스트를 하는 이유는? 예전 코드의 변경이 없더라고 새로운 코드가 기존 로직에 영향을 줄 수 있기 때문에, 새 코드가 기존 코드에 대해서 결함을 발생시키지 않았음을 검증하기 위해서 수행한다.

② 통합 테스트(개발팀에서 개발 단계에 수행)

: 각 개발자 또는 단위 개발팀에서 개발된 모듈들을 서로 합쳐서 상호 연동이 제대로 되는지를 검증하는 테스트이다. 주로 시스템 연동의 기능적인 면을 검토하고 성능 등의 비기능적인 면은 검증하지 않고 시스템 테스트단계에서 수행한다.

③ 시스템 테스트(테스트팀에서 테스트 단계에 수행)

: 시스템 테스트는 통합이 완료된 시스템에 대해서 기능 테스트 및 비기능 테스트를 수행한다.

• 주로 부하를 주는 상황에서 수행하게 되며 비기능테스트(성능 등)를 중점적으로 진행한다.
• 애자일 개발 방식에서의 시스템 테스트는 스프린트가 종료될 때마다 개발 환경과 분리된 테스트 환경에서 진행한다.

비기능 테스트의 종류

1) 성능 테스트

시스템에 부하를 주면서 2가지 성능지표( TPS 초당 처리량/ 응답시간) 측정

• TPS(Throughput per Second) : 초 당 몇건의 요청을 처리하는지
• 응답시간(Response Time): 요청 당 응답시간
• 임계 성능(시스템이 허용하는 최대성능) 측정이 중요함

부하량을 늘려갈때 어느 부하량 이상이 되면 더는 TPS가 증가하지 않고 일정 수준을 유지하게 된다. 이때의 부하량 즉, 가상 사용자 수가 이 시스템의 처리 가능 용량이 되고 이 때의 TPS가 이 시스템의 최대 성능이 된다.

응답시간이 중요한 시스템의 경우에는 TPS의 임계점을 기준으로 하지 않고 목표 응답시간을 기준으로 성능의 임계점을 정해야 하는데, 부하량과 응답시간의 상관관계는 x²이다. 이 응답 시간이 목표한 응답시간 이상으로 올라가는 시점을 임계성능으로 측정하고 이때의 TPS를 시스템의 최대 성능으로 정한다.

* 대용량 분산 시스템에서 임계치

근래의 서비스 시스템 특징으로 대용량 서비스가 가능한 분산 아키텍처 구조를 가지면서 임계 성능이라는 개념이 없어지고, 서버를 증설할 수록 선형적으로 성능이 비례하여 증가하는 형태를 보인다.

클라우드 컴퓨팅을 사용하면서 하드웨어 자원을 무한적으로 늘릴 수 있는 상황에 해당하는데, 부하량이 늘어감에 따라서 하드웨어를 무한적으로 증설할 수 있는 경우이다.

• 대용량 분산 시스템의 경우는 TPS가 부하량에 따라서 선형적으로 증가
• 응답시간은 부하량이 늘어나도 일정하게 유지
• 분산 시스템은 무한적으로 성능이 증가하기에 성능이 임계치 측정이 의미가 없음, 임계치 측정보다는 부하량이 증가함에 따른 TPS의 증가치를 측정하는데에 성능테스트의 목적을 둠.

2) 장애 테스트

시스템이 장애가 났을 때 이에 대한 감지와 장애 복구능력을 검증하는 테스트이다.

장애가 발생할 수 있는 곳에 부하를 주는 등의 강제적으로 장애를 일으켜 테스트 진행한다.

장애 유형에 따른 테스트

① 미들웨어 장애 테스트： 서버 소프트웨어를 가동하기 위한 미들웨어(DBMS, 웹서버, 웹 애플리케이션 서버 등)가 장애가 났을 경우에 대한 장애 대응능력 검증함. 주로 미들웨어 자체의 클러스터링 기능에 의해서 처리되는 경우가 많다.

② 하드웨어 장애 테스트: 하드웨어의 전원을 강제적으로 내림으로써 인위적으로 장애를 발생시켜 대처능력을 검증한다.

③ 네트워크 장애 테스트: 각 서버 간의 네트워크 연결 장애에 대한 대응능력 검증으로 장애를 발생시키고 테스트를 수행한다. 이러한 장애에 대한 대처를 하드웨어나 소프트웨어에 대한 클러스터링(Clustering)이나 이중화(High Availibility) 구성을 통해서 이루어지는 것이 일반적이다.

* 페일오버(Fail-Over): 장애가 났을 때의 테스트

=> 장애가 났을 때 장애가 나지 않은 나머지 시스템으로 요청을 전달하여 처리하는 것

* 페일백(Fail-Back): 장애가 복구되었을 때의 테스트

=> 장애 복구 테스트는 장애 테스트와 역순으로 진행하는데, 서버를 강제 종료시켰다면 서버를 재가동하거나 네트워크 선을 뽑았다면 다시 연결해서 상황이 정상화되었을 때 장애가 났던 시스템이 다시 정상적으로 작동하는지 확인한다.

3) 안정성 테스트: 시스템을 오랫동안 운영하더라도 문제가 없는지 검증하는 테스트로 부하를 수일 동안 주면서 시스템이 문제없이 서비스가 되는 지 체크한다.

메모리 누수(Memory Leak)가 있거나 인프라 자원을 효율적으로 반납하지 못하는경우 장애가 발생한다.

• 메모리 누수(Memory Leak)란?

코드 상에서 메모리를 요청한 후 반납하지 않아서 사용 가능한 메모리 용량이 줄어드는 현상으로 메모리를 자동으로 관리해 주는 자바의 경우도 발생한다.

4）확장성 테스트: 시스템을 증설함에 따라 용량이 선형적으로 증가하는지를 확인하는 테스트이다.

크게 2가지 수직적 확장성(Vertical Scalability)과 수평적 확장성(Horizontal Scalability).

• 수직적 확장성: 서버의 수는 유지한 채 CPU나 메모리 용량을 증설하는 방법

=> 가상머신(Virtual Machine)에 할당되는 CPU 코어 수와 메모리를 늘려 테스트 진행, 용량 증가에 따라 TPS가 선형적(y=ax)으로 증가하는지를 확인.

• 수평적 확장성: 서버의 대수를 늘려서 용량을 증설하는 방법

=> 서버의 대수가 증가한다고 해서 용량이 증가될 수 있는 것이 아니라 시스템 자체가 서버 증설에 대해서 확장할 수 있는 아키텍처로 설계가 되어있는 지 확인

④ 인수 테스트(테스트팀 또는 고객이 출시 전 단계에 수행): 개발이 완료된 후 시스템을 출시 하기 전에 최종적으로 수행되는 테스트로 고객의 주도로 테스트가 이루어진다.

• 다른 레벨의 테스트와는 다르게 결함의 발견이 목적이 아닌, 제품의 출시 여부를 판단하는 것을 목적으로 한다.
• 요구사항, 디자인 스펙에 대한 준수 여부는 기본 범위이고 이 외에 법적인 사항과 사용자 경험 등을 검증한다.

⑤ 테스트 레벨별 주체와 시점

이 글은 코드프레소 DevOps Roasting 코스를 수강하면서 작성한 글입니다.