[CSTS 요약] 3 소프트웨어 개발 단계와 테스트

컴포넌트 테스트

컴포넌트(단위) 테스트는 개별적인 모듈(또는 컴포넌트)의 테스트를 의미

구현 단게에서 각 모듈을 구현한 후에 수행

개별적인 모듈에 대한 컴포넌트 테스트를 위해 모듈을 단독으로 실행시킬 수 있는 환경 필요

- 테스트베드(테스트 환경)의 주요 구성 요소로 테스트 드라이버와 테스트 스텁이 활용됨

컴포넌트 테스트를 위한 테스트 환경

 

각 컴포넌트의 테스트를 위해 컴포넌트의 입력값과 출력값의 전달을 위한 드라이버와 스텁을 구성함

위 예시에서 컴포넌트 2의 경우, 다른 컴포넌트를 호출하지 않으므로 스텁이 쓰이지 않음

 

모의 객체 생성 프레임워크

객체 지향 프로그램에서는 컴포넌트 테스트를 수행할 때 테스트되는 메소드가 다른 클래스의 객체에 의존해야 할 수 있음.

메소드를 고립화하여 테스트하는 것이 불가능하므로 절차 지향적 프로그래밍에서의 스텁과 같은 개념이 필요

모의(Mock) 객체

스텁의 객체 지향 버전

모의 객체의 분류

• 더미(Dummy): 테스트 시 객체만 필요하고 해당 기능은 필요하지 않은 경우
  더미 객체의 메소드가 호출되면 정상 동작은 수행하지 않고 예외 처리함
• 테스트 스텁(Stup): 더미 객체에 단순한 기능성을 넣어 추가 객체의 특정 상태를 가정하여 특정한 값을 리턴하거나 특정한 메시지 출력
• 테스트 스파이(Spy): 테스트 대상 클래스(CUT)와 협력하는 클래스
  추력을 검증하는 데 사용되며 CUT가 실행되는 동안 특정 협력 클래스로의 호출(또는 호출 결과)을 잡아내 실행이 끝난 후 정상 호출되었는지 검사
• 가짜(Fake): 실제 협력 클래스의 기능을 대체해야하는 경우 사용
  실제 협력 클래스의 기능 중 전체나 일부를 훨씬 단순하게 구현
  실제 협력 클래스가 구현되지 않았거나 너무 느리거나 테스트 환경에서는 사용할 수 없을 경우 이용

 

FIRST 원칙

컴포넌트 테스트 수행을 위한 원칙

• Fast: 컴포넌트의 빠른 실행 속도
• Isolated: 컴포넌트 테스트가 다른 컴포넌트 테스트에 의존적이지 않고 독립적 수행
• Repeatable: 테스트 결과 신뢰를 위해 반복적인 테스트 실행 후 동일한 결과 확인 가능
• Self-Validating: 테스트 결과 판단을 자동화하여 사람의 개입 없이 이뤄지도록 작성
• Timely: 테스트 대상이 되는 코드가 작성되는 시점에 수행

 

통합 테스트

컴포넌트를 통합하는 과정에서 수행되는 테스트

컴포넌트 간의 상호 연동이 제대로 수행되는지 검사

통합 테스트

통합 테스트의 목적:

1. 컴포넌트 간 연결의 정확성
2. 연결된 컴포넌트의 기능성

상호작용에 초점을 둔 통합 테스트. 두 컴포넌트 간에 전송•수신된 데이터 중심

기능에 초점을 둔 통합 테스트. 데이터 전달의 적합성이 아닌 연결된 두 컴포넌트의 기능적인 측면에서 적합성 확인

 

점진적 통합

빅뱅 방식:

• 통합 대상 컴포넌트가 많은 경우, 전체 컴포넌트를 한 번에 통합하여 테스트
• 테스트를 통해서 오작동이 확인되었을 때 어느 컴포넌트가 결함을 가지고 있는지 판단하기 어려움

점진적 방식:

• 적은 수의 컴포넌트를 차례로 통합하여 테스트
• 오작동의 원인이 되는 컴포넌트를 찾기 쉬우나 테스트 드라이버 및 스텁을 여러 번 개발해야 함
• 테스트 수행 방식:
  • 상향식 통합: 하위에 있는 컴포넌트들을 시작으로 상위에 있는 컴포넌트들을 통합하는 방식
    하위 컴포넌트를 충분히 테스트할 수 있음
    하위 컴포넌트는 일반적으로 시스템이 제공하는 서비스에 필요한 공통적인 기능을 제공하는 역할을 하므로, 통합 과정에서 빈번하게 사용되는 하위 코드를 자주 테스트하게 됨
    하향식 통합에서 필요한 테스트 스텁을 제공하는 비용이 들지 않음
  • 하향식 통합: 시스템을 구성하는 컴포넌트들의 계층 구조에서 가장 상위에 있는 컴포넌트부터 시작하여 하위에 있는 컴포넌트들을 통합하는 방식
    기본적으로 상위 컴포넌트는 시스템의 기능을 결정하고, 하위 컴포넌트는 시스템이 제공하는 기능을 보조하는 역할로 상위 컴포넌트의 결함은 시스템 설계의 문제가 나타난 것으로 해석 가능
    많은 수의 테스트 스텁이 필요하므로 테스트 스텁 구현 비용이 많이 드는 경우 효과적이지 않음
  • 샌드위치 통합: 상향식과 하향식 통합 테스트 방식을 결합한 방식

 

시스템 테스트 및 인수 테스트

통합 테스트 완료 이후 전체 시스템이 시스템 명세에 따라 개발되었는지 검증

시스템의 기능 측면뿐만 아니라 성능, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성 등과 비기능적인 요구사항을 만족하는지 검증

시스템 테스트 완료 이후 실제 사용자의 요구사항을 만족하는지 확인하기 위한 인수 테스트 수행

결함 검출 아닌 시스템 인수 자체에 대해 고객의 입장에서 평가

개발자가 시스템을 테스트할 때 사용한 방식과 차이가 있을 수 있으므로, 개발자가 수행한 테스트로 발견되지 않은 결함 검출 가능

• 알파 테스트: 선택된 사용자(회사 내의 다른 사용자 또는 실제 사용자)가 개발자 환경에서 통제된 상태로 수행
• 베타 테스트: 일정 수의 사용자에게 소프트웨어를 사용하게 하고 피드백을 받음. 개발자 참여 않음

리그레션 테스트

• 결함 수정 작업: 소프트웨어 사용 중 발견된 결함 수정
• 기능 보강 작업: 소프트웨어의 기능을 추가하거나 성능 개선
• 적응 작업: 소프트웨어 시스템을 새로운 운영환경에 적용
• 예방 작업: 더 나은 유지보수를 위해 기존의 소프트웨어 시스템에 대한 문서를 준비하거나 시스템 구조를 유지보수하기 용이한 새로운 구조로 변경

소프트웨어 유지보수 활동 비율

리그레션 테스트 사이클

 

리그레션 테스트 방법

• Retest-All
  기존에 개발된 모든 테스트 케이스를 사용
  복잡한 테스트 절차를 요구하지 않지만 많은 시간과 자원이 필요
• 선택적 리그레션 테스트
  기존의 테스트 케이스 중에서 일부만 선정
  원래의 프로그램과 변경된 프로그램이 서로 다른 결과를 출력할 가능성이 있는 테스트 케이스 식별하여 수행
• 테스트 최소화
  중복된 테스트 케이스를 제거하여 테스트 케이스의 수를 줄이는 방식
  커버리지 개념을 사용하여 중복된 테스트 케이스가 제거되기 때문에 주의해야 함
• 테스트 우선 순위화
  테스트 케이스에 우선순위를 두어 우선순위가 높은 테스트 케이스만을 활용
  가능한 한 빨리 많은 결함을 검출할 수 있도록 테스트 케이스의 실행 순서 결정
  테스트 케이스 우선순위의 효과성을 평가하기 위한 척도로 APFD 사용

 

 

리그레션 테스트 절차