[CSTS] 요약 1. 테스트 개요

오류, 결함, 장애

• 오류 ; 사용자의 요구사항을 잘못 파악, 이해 또는 실수나 오타
• 결함 ; 소프트웨어 내 장애를 유발할 수 있는 문제
  • 결함이 있다고 해서 반드시 장애가 발생하는 것은 아님
  • 소프트웨어 동작의 장애를 유발할 수 있는 모든 개발 산출물에 존재
• 장애 ; 프로그램의 실행 결과와 요구사항에 차이가 있음

 

테스팅, 디버깅, 재테스팅

• 테스팅 ; 소프트웨어의 실제 동작과 요구사항 차이를 확인
  • 소스코드 수정에 관여하지 않음
• 디버깅 ; 테스팅을 통해 결함의 존재 확인 > 위치 파악 > 제거가 목적
  • 결함을 제거 위해 소스코드 수정
• 재테스팅 ; 개발자가 결함을 제거하면, 실제로 결함이 제거되었는지 확인

 

테스트와 품질 보증

테스트 < V&V < 품질 보증

 

테스트 설계 기법

정적 테스트

테스트 대상을 실행하지 않고 테스트를 수행 -> 실행 환경 필요 하지 않음
소스 코드 작성 전의 개발 단계에 대한 테스트 수행

• 리뷰
  • 산출물에 존재하는 결함 검출이나 프로젝트 진행 상황 점검
  • 유형 : 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사
• 정적 분석
  • 자동화된 도구 이용해 산출물의 결함 검출이나 복잡도 측정
  • 유형 : 코딩 표준, 복잡도 측정, 자료 흐름 분석

 

동적 테스트

테스트 대상 실행하여 테스트 수행 -> 소프트웨어 실행시키기 위한 환경 요구되지만 소스코드 사용되지 않음

• 명세 기반 테스트 ; 프로그램의 내부 논리 구조를 참조 하지 않음(소스 코드를 참고하지 않음)
  • 컴포넌트 테스트, 통합테스트, 시스템 테스트, 인수 테스트 등 전 과정에 걸쳐 사용
  • 소스 코드를 참고하지 않기 때문에 임의(랜덤) 테스트 방법도 명세 기반 테스트에 속함
• 구조 기반 테스트 ; 프로그램의 제어 흐름이나 흐름 정보 이용하여 테스트 케이스 설계
  • 구조적 테스트, 화이트 박스 테스트 라고도 불림
  • 소스코드의 특정 문장 또는 경로를 실행하기 위해 입력값을 결정한다면 구조 기반 테스트에 속함
• 경험 기반 테스트 ; 기존 테스트 경험, 시스템 및 해당 도메인에 대한 직관(경험) 바탕으로 테스트 수행
  • 오류 추정
    • 개발자가 범할 수 있는 실수를 추정, 이에 따른 결함이 검출되도록 테스트 케이스를 설계하는 방법
    • 동등 분할이나 경곗값 분석 같은 명세 기반 테스트 방법과 함께 사용될 수 있음
    • 특히, 일반적으로 예상되지 않는 상황이 사용자의 입력값으로 적절히 처리되고 있는지 확인할 때 유용
  • 탐색적 테스트
    • 사전에 구체적으로 테스트 케이스를 설계하지 않고, 테스트 대상에 대한 이해, 테스트 케이스 설계, 테스트 실행을 병행
      • 즉, 문서화 없이 해당 테스트를 바로 수행한 후 테스트의 결과를 바탕으로 다음 테스트를 결정
      • 효과는 테스터의 지식에 의존함
    • 테스트에 사용하는 자동화 도구를 통해 테스트 로그 및 테스트 결과 등이 자동으로 생성될 수 있음
    • 애자일 방법을 사용하는 웹 응용 시스템 테스트에 적합한 방법

 

테스트 유형

기능 테스트

• 기능의 요구사항 측면의 결함 검출 및 충족 여부 확인 목적
• 모든 테스트 수준에서 진행

비기능 테스트

• 성능, 보안성, 신뢰성 등 품질 요구사항 측면의 결함 검출 및 충족 여부 확인
• 시스템 테스트와 인수 테스트 수준에서 진행

 

테스트 레벨

컴포넌트 테스트(단위 테스트)

: 개별 단위 모듈을 독립적으로 테스트, 기능이 올바르게 작동하는지 테스트

FIRST 원칙 : 컴포넌트 테스트를 잘 수행하기 위한 원칙

• Fast ; 빠르게 수행되어야 한다.
• Isolated ; 컴포넌트 테스트가 다른 컴포넌트 테스트에 의존하지 않도록 해야한다.
  즉, 독립적으로 수행할 수 있어야 한다.
• Repeatable ; 테스트를 몇 번 실행해도 동일한 결과가 나오도록 해야한다.
• Self-Validating ; 사람의 개입없이 테스트가 통과될 수 있도록 작성해야한다.
• Timely ; 컴포넌트 테스트는 제때 수행되어야 한다.

 

통합 테스트

: 단위 모듈들이 정확하게 통합되었는지 초점, 상호 연동이 제대로 수행되는지 테스트
컴포넌트 테스트가 수행되었더라도, 컴포넌트 통합한 후 결함이 발생할 수 있다.

점진적 통합

• 빅뱅 방식 : 통합 대상 컴포넌트가 많은 경우, 전체 컴포넌트를 한 번에 통합하여 테스트 하는 방법
• 점진적 방식은 오작동의 원인이 되는 컴포넌트를 찾기 쉽지만,
  테스트 드라이버 및 스텁을 여러 번 개발해야 한다. 테스트 수행 시에는 각각 개발해야 한다.
• 상향식 통합 방법, 하향식 통합 방법, 샌드위치 통합 방식 존재
  • 컴포넌트
    • 상위 컴포넌트 : 시스템의 기능을 결정 | 하위 컴포넌트 : 시스템이 제공하는 기능을 보조
  • 상향식 통합 방법
    • 하위 컴포넌트를 충분히 테스트 할 수있음
    • 테스트 스텁을 제공하는 비용이 들지 않음
  • 하향식 통합 방법
    • 상위 컴포넌트의 결함을 빠르게 발견할 수 있음
  • 샌드위치 통합 방법
    • 상향식 통합 방법 + 하향식 통합 방법 

 

시스템 테스트

전체 시스템을 대상으로 테스트 진행. 시스템 명세서에 명시된 방식대로 동작하는지 확인

목적 : 시스템의 기능 측면 + 비기능적인 요구사항을 만족하는지도 검증

비기능적인 요구사항 : 성능, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성 등

 

인수 테스트

고객/사용자의 관점에서 기대하는 방식으로 동작하는지 확인

목적 : 결함 검출이 아닌 시스템을 인수해도 되는지 고객의 입장에서 평가
개발자가 수행한 테스트로 발견되지 않은 결함이 발견 될 가능성이 있음

• 알파테스트
  • 선택된 사용자(실제 사용자)가 개발자 환경에서 통제된 상태로 수행
• 베타테스트
  • 일정 수의 사용자에게 소프트웨어를 사용하게 한 후, 피드백 받음
    개발자가 참여하지 않음

 

테스팅 방법

리그레션 테스트

소프트웨어가 변경되면 컴포넌트 테스트 - 통합테스트 - 시스템 테스트 각 레벨마다 리그레션 테스트 수행

유지보수 단계에서도 소프트웨어 수정 후에 변경이 의도치 않게 결함을 만들진 않았는지 검증
유지보수 단계에서는 개발 단계에서 사용한 테스트 케이스를 사용하여 검사한다.

•  유형
  • Reset-All ; 기존에 개발된 모든 테스트 케이스를 사용하는 방식. 많은 시간과 자원이 필요함
  • 선택적 리그레션 테스트 ; 기존의 테스트 케이스 중 일부만 선정하는 방식
  • 테스트 최소화 방식 ; 중복된 테스트 케이스를 제거하여 테스트 케이스의 수를 줄이는 방식
    
    • 중복된 테스트 케이스를 식별하기 위해 커버리지 개념을 사용
  • 테스트 우선화 방식 ; 테스트 케이스에 우선순위를 두어, 우선순위가 높은 테스트 케이스만을 활용하는 방식
    • APFD : 테스트 케이스 우선순위 효과성 평가 척도
      • 테스트 케이스의 실행 수 대비 검출된 결함의 비율을 측정
      • 높은 APFD : 많은 결함을 빨리 검출하였음을 의미

 

소프트웨어 생명주기 모델

순차적 개발 모델 ; 테스트 구현이 완료된 시점에 1회 수행

• 폭포수 모델
  • 소프트웨어 생명 주기 모형 중 가장 오래된 전통적인 모형
  • 테스트를 하나의 개발 단계로 간주, 테스트 작업에 필요한 정보를 쉽게 얻을 수 있음
  • 구현이 완료된 후 테스트 시작하여 개발이 거의 완료될 무렵에 결함을 발견하면, 수정 시 비용과 시간이 많이 사용된다.
• V 모델 (V&V)
  • 단계를 명확히 구분 즉, 레벨이 존재 (SDLC 개발 관련 단계 - STLC 테스트 관련 단계)
  • 개발 시작과 동시에 테스트 시작, 결함을 빠르게 발견할 수 있음
  • 동적 테스트와 더불어 개발 산출물에 대한 정적 테스트도 수행

진화적 개발 모델 ; 각 구성 요소와 추가 요구 사항을 여러 이터레이션을 통해 개선하고 발전

• 나선형 모델
  • 부분적으로 정의된 요구사항을 정제, 확장 > 완전한 시스템이 개발될 때 까지 반복
  • 비즈니스 가치를 만드는 요구사항 따라 프로토타입 개발 > 프로토타입에 대한 테스트 및 사용자 평가 > 다음 개발 주기 시작

 

애자일 개발 모델

• TDD 테스트 주도 개발 접근 방식을 따름(단위 테스트에 사용)
  • 테스트 케이스를 먼저 작성 > 실제 코드를 나중에 작성. 실제 코드에 영향을 줌
  • 테스트를 먼저 고려하여 코딩하기 때문에 용이성이 높고, 변경 요구에 쉽게 대응 가능

실천 규칙

• CI 지속적 통합 ; 계속해서 통합을 수행하는 것

• 추구하는 가치
  • 사람 및 상호 의사 교환이 프로세스, 도구보다 우선
  • 동작하는 소프트웨어가 포괄적인 문서보다 우선
  • 고객과의 협력이 계약 협상보다 우선
  • 변화에 반응하는 것이 계획을 따르는 것보다 우선

 

위험 기반 테스트

주어진 비용과 일정 내에서 테스트 수행
주어진 비용의 범위 내에서 단위테스트, 통합 테스트 등 시행 수준이 결정됨

 

모델 기반 테스트

모델을 바탕으로 테스트 계획 수립 ~ 테스트 케이스 ~ 절차 ~ 입력 및 예상 결과 결정

• 테스트 수행 : 테스트 계획 ~ 테스트 종료 까지 대부분의 활동 자동화 가능 
• 상세한 모델링 : 정형적 표현법 사용 (의사결정표, UML 상태 / 액티비티 다이어그램)

 

품질 특성과 비기능 테스트

품질 특성

 

비기능 테스트

기능 적합성 테스트 ; 요구되는 기능을 만족시키는 능력

• 기능 완전성 : 명세 기반 테스트로 테스트
• 기능 정확성 : 명세 기반 테스트, 구조 기반 테스트 모두 가능

성능 효율성 테스트 ; 적절한 자원의 사용 및 적정한 반응시간

• 벤치마크 : 시스템의 성능을 테스트하는 전통적인 방법
  • 실존하는 비교 대상을 두고 하드웨어나 소프트웨어의 성능을 비교 시험하고, 평가함
  • 실제와 상황이 같은 시험 환경에서 한개 또는 여러개의 대표적인 비교 대상과 반복하여 평가함
  • 시스템이 동작되는 운영 환경 및 작업 부하를 대표해야함
• 대표적인 성능 테스트
  • 부하 테스팅 ; 부하를 계속 증가시켜 시스템의 임계점을 찾아 병목 현상을 제거하는 과정 반복
  • 스트레스 테스팅 ; 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
  • 스파이크 테스팅 ; 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정
  • 내구성 테스팅 ; 오랜 시간 동안 시스템에 높은 부하를 가하여 반응 측정

호환성 테스트 ; 다른 시스템과의 상호 연동 능력

사용성 테스트 ; 사용자가 이해하고 배우기 쉬운 정도

• 사용성 평가 방법
  • 휴리스틱 평가 ;  3명~5명 정도의 인원에게 사용성 원칙을 기준으로 체크리스트를 통해 문제점을 도출하는 방법. 
  • FGI ; 공통점 있는 7명`8명을 그룹별로 인터뷰하여 필요한 정보를 수집
  • 인지적 워크쓰루 ; 실제 사용자를 대상으로 사전 설명 또는 안내 없이 제품을 주어진 과제를 달성하는지 확인

신뢰성 테스트 ; 규정된 조건에서 규정된 기간동안 오동작없이 의동된 기능을 수행

보안성 테스트 ; 정보 및 데이터를 보호하는 능력

유지보수성 테스트 ; 소프트웨어 유지보수의 용이성

이식성 테스트 ; 다양한 플랫폼에서 운영될 수 있는 소프트웨어의 능력