1. 소프트 웨어 개발 과정에서의 테스트
소프트웨어 개발 수명 주기(SDLC,Software Development Life Cycle)는 소프트웨어를 개발, 유지, 향상, 변경하는 방법에 대한 지침이다.
소프트웨어를 개발할 때에는 분석 - 디자인 - 구현 - 테스트 - 배포 - 유지보수의 단계를 거치면서 더 나은 서비스로 고도화하는 과정을 거친다.
이 개발 수명 주기에 맞춰, 소프트웨어를 개발하는 개발 방법론은 여러가지이지만, 방법론 중 V-model을 보면 테스트 단계에 대해 더 쉽게 이해할 수 있다.
요구사항을 토대로 요구사항 분석, 시스템 디자인, 설계, 모듈 설계의 순으로 작업을 세분화하여 구현했다면, 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트의 점차 커지는 방향으로의 구현에 대한 테스트를 거친다.
2. 테스트의 종류
- 단위 테스트(Unit Test)
: 단위 테스트는 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트이다. 보통은 메서드 레벨(기능 단위)를 테스트하는데 사용한다.
단위 테스트의 특징은 아래와 같다.
- 즉각적인 피드백이 나온다는 것이 훌륭한 장점이다.
- 가능한 한 간단하고, 디버깅이 쉽고, 실행이 빠르고, 프로그램의 가장 작은 빌딩 블록이 조립되기 전에 의도한 대로 기능하는지 증명하는데 도움이 된다.
- 하나의 메서드들이 잘 동작한다는 것은 보장할 수 있지만, 그들이 결합되었을 때 잘 동작한다는 것은 보장할 수 없다.
- 통합 테스트(Integration Test)
: 단위 테스트 이후 단위(Unit)를 결합하고 결과 조합이 올바르게 작동하는지 테스트한다.
- 하향식 테스트 유형(Top-Down)
: 가장 상부의 모듈부터 통합하며 테스트를 순차적으로 진행하는 방식
- 테스트 스텁(stub)을 사용
-> 설계상의 결함을 빨리 발견할 수 있음
- 상항식 테스트 유형(Bottom-Up)
: 최하위 모듈을 통합한 후, 상부의 모듈을 순차적으로 추가 테스트하는 방식
- 테스트 드라이버(Driver) 사용
-> 결함 격리가 쉬우며, 하위 모듈을 충분히 테스트 수행
-> 수정이 어려운 중요한 결함(설계상 결함)을 상부 구조에서 발견할 수 있음
- 샌드위치 테스트(Sandwich Test)
: 상향식과 하향식의 장점을 이용하는 방식
-> 병렬 테스트가 가능하고 시간 절약 가능
-> 스텁과 드라이버가 모두 필요함(비용이 많이 들어감)
- 시스템 테스트(System Test)
: 통합 테스트가 완료된 후에 완전한 시스템에 대해 수행하는 테스트
- 단위 테스트나 통합 테스트가 기능이 올바르게 수행되는지 검증하는 것에 중점이라면, 시스템 테스트는 시스템의 기능 측면에서 뿐만 아니라, 비기능적(사용성, 견고성, 신뢰성, 보안성, 성능)인 요구사항도 만족되는지를 검증
- ex) 견고성 테스트, 신뢰성 테스트 등
- 인수 테스트(Acceptance Test)
-
알파 테스트
: 회사 내의 다른 사용자에게, 또는 실제로 인수받을 사용자에게 개발 환경에서 통제된 상태로 테스트를 진행하도록 하며, 실시간으로 오류와 사용상의 문제를 파악하여, 여차하면 바로바로 수정할 수 있는 인수 테스트 방식 중 하나이다. -
베타 테스트
: 소프트웨어를 일부 사용자들에게 배포하여 직접 사용하도록 하여, 사용자들로 하여금 피드백을 받아 사용성을 파악하는 테스트 방식이다.
3. 소프트 웨어 테스트를 하는 이유
— 과연 내 코드가 잘 동작하는지 어떻게 확신할 수 있을까
소프트웨어의 기능은 요구사항이 아무리 명확하다 하더라도 생각치 못한 예외 흐름이 존재하게 되거나 기획적으로 수정할 부분이 생기고 이에 따라 개발을 하면서 조금씩 수정될 수 있다. 요구사항이 변하면서 개발자는 요구사항에 최적화된 구현을 하지 못할 가능성이 높다. 초기의 구현은 기능들이 점차 디벨롭 되면서 더더욱 코드의 구조나 관계들이 모호해 질 것 이다.
이러한 과정들이 반복되다 보면 코드의 품질이 하락하게 되고, 기능을 고치는데에 더 많은 시간과 비용을 투자하게 된다.
이를 최소화하게 위해 우리는 유지보수에 더 집중하고, 변경사항에 대한 안정성을 확보하기 위해 일련의 절차를 거친다.
유지 보수는 초기에 할수록 유지보수에 대한 비용이 줄여지게 된다. 유지보수를 위해 어떤 문제가 일어나고 있고, 내 코드가 잘 동작하는지 수치화해 확신할 수 있도록 하는 것, 변경사항에 대해 새롭게 발생하던 오류를 줄이고, 기존의 정상 동작하던 기능에 차질이 생기지 않도록 하는 것이 소프트웨어 테스트의 목표이다.
4. 효율적인 검증을 위한 테스트 코드 기초
1. F.I.R.S.T 단위 테스트 원칙
Fast — 유닛 테스트는 빨라야 한다.
Isolated — 다른 테스트에 종속적인 테스트는 절대로 작성하지 않는다.
Repeatable — 테스트는 실행할 때마다 같은 결과를 만들어야 한다.
Self-validating — 테스트는 스스로 결과물이 옳은지 그른지 판단할 수 있어야 한다. 특정 상태를 수동으로 미리 만들어야 동작하는 테스트 등은 작성하지 않는다.
Timely — 유닛 테스트는 프로덕션 코드가 테스트를 성공하기 직전에 구성되어야 한다. 테스트 주도 개발(TDD) 방법론에 적합한 원칙이지만 실제로 적용되지 않는 경우도 있다.
2. Given - When - Then 패턴
: 대표적인 테스트 코드 작성 스타일 페턴이다.
[준비 - 실행 - 검증] 의 과정을 거친다.
Given
테스트에서 구체화하고자 하는 행동을 시작하기 전에 테스트 상태를 설명하는 부분
When
구체화하고자 하는 그 행동
Then
어떤 특정한 행동 때문에 발생할거라고 예상되는 변화에 대한 설명5. 테스트 코드의 장점
- 실행가능 설명서 : 엑셀 문서같이 테스트 결과여부 기록이 아닌 실제로 메서드가 요구사항대로 작동하는지 확인가능하다.
- 테스트 시간 단축 : 불필요하게 수작업으로 할 필요가 없다. 코드상에서 테스트할 값만 넣으면 끝난다.
- 유연성 제공 : 수정사항이 생겨도 기존 기능들에 영향을 주는지 손쉽게 확인할 수 있다. 사이드이펙트에 대한 대비가 쉬워진다.
- 재사용성 가능 : 가장 큰 장점이다. 코드만 실행하면 테스트가 끝난다.
