2. 테스트 분류와 테스팅 방법

 

• 테스트 분류에서는 테스트 레벨(컴포넌트, 통합, 시스템, 인수), 테스트 유형(기능, 품질), 테스트 설계 기법을 기준으로 테스트 분류를 설명함
• 테스팅 방법에는 개발 생명 주기, 프로젝트 단계 등 프로젝트의 상황을 고려하여 현실적으로 적용할 수 있는 테스트 방법을 설명

---

테스트 분류

---

• 테스트 레벨은 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류
• 테스트 유형은 기능 테스트, 성능 테스트, 신뢰성 테스트, 보안 테스트 등으로 분류
• 테스트 유형에서 기능 테스트를 제외한 성능 테스트, 신뢰성 테스트, 보안 테스트 등을 비기능 테스트라고 부름

---

테스트 레벨에 의한 분류

• 컴포넌트/단위 테스트 : 시스템을 구성하는 단위 모듈을 테스트 대상으로 해서 개별 단위 모듈을 독립적으로 테스트
• 통합 테스트 : 시스템을 구성하는 단위 모듈들이 정확하게 통합되었는지에 초점을 둠. 시스템 내부 구성 모듈과 이들 간의 관계를 정의한 구조 설계 명세서를 바탕으로 테스트 진행
• 시스템 테스트 : 전체 시스템을 테스트 대상으로 하여 테스트가 진행. 요구사항 명세서에 명시된 방식대로 시스템이 동작하는지 확인하는 데 초점을 둠
• 인수 테스트 : 시스템 테스트와 마찬가지로 전체 시스템을 하나의 단위로 보고 테스트가 진행됨. 시스템 테스트와 달리 고객/사용자의 관점에서 고객이 기대하는 방식으로 소프트웨어가 동작하는지 확인

---

테스트 유형에 의한 분류

• 기능 테스트 : 기능 요구사항 측면의 결함 검출 및 충족 여부 확인을 목적으로 함. 모든 테스트 수준에서 진행.
• 비기능 테스트 : 성능, 보안성, 신뢰성 등 품질 요구사항 측면의 결함 검출 및 충족 여부를 확인. 보통 시스템 테스트, 인수테으트 수준에서 진행

기능 적합성	완전성, 정확성, 타당성
사용성	타당성 식별력, 학습성, 운영 용이성, 사용자 오류 보호, 사용자 인터페이스 미학, 접근성
성능 효율성	시간 행동, 자원 활용성, 수용성
호환성	공존성, 상호운영성
신뢰성	성숙성, 가용성, 장애 허용성, 회복 가능성
보안성	기밀성, 무결성, 부인방지, 책임성, 진본성
유지보수성	모듈성, 재사용성, 분석성, 변경 용이성, 테스트 용이성
이식성	적응성, 설치 용이성, 대치 용이성

• 이 여덟 개의 주특성별로 세부적인 품질 특성을 부특성의로 정의하고 있음
• 소프트웨어가 충족해야 하는 요소, 기능 요구사항과 더불어 소프트웨어 요구사항의 한 유형
• 각 품질 특성을 충족하는 테스트를 수행(성능 효율성 테스트, 신뢰성 테스트 등)

---

테스트 설계 기법에 따른 분류

• 정적 테스트와 동적 테스트로 분류

 

정적 테스트

• 테스트 대상을 실행하지 않는 방식으로 테스트를 수행
• 리뷰, 정적 분석이 있음

리뷰

• 리뷰 절차 : 경영진 준비 -> 리뷰 계획 -> 리뷰 절차 개요 설명 -> 작업물 개요 설명 -> 개별 준비 -> 그룹 검토 -> 재작업 -> 후속작업
• 목적 및 구체적인 수행 방법에 따라 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사로 구분
• 관리 리뷰 : 프로젝트 진행 상황에 대한 검토를 바탕으로 일정, 인력, 범위 등에 대한 통제 및 의사 결정 지원
• 기술 리뷰 : 정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행
• 인스펙션 : 문제를 식별하고 문제에 대한 올바른 해결을 검증
• 워크쓰루 : 문제를 식별하고 더 나아가서 대안 조사, 개선 활동, 학습 기회 제공 수행
• 감사 : 객관적인 표준과 규제에 대한 준수를 독립적으로 평가

정적 분석

• 산출물의 구조적 속성을 이용하여 자동화된 방식으로 도구에 의해 수행
• 코딩 표준 : MISRA-C, MISRA-C++ 등의 코딩 표준에 대한 준수 여부 검사
• 복잡도 측정 : 사이클로매틱 복잡도 등, 프로그램의 복잡도 측정
• 자료 흐름 분석 : 프로그램 자료 흐름에 이상 존재 여부 존재

 

동적 테스트

• 테스트 대상을 실행하여 결함을 검출하는 방법, 적절한 입력값(테스트 케이스)를 결정해야 함
• 소프트웨어의 어느 부분에 결함이 존재하는지 알 수 없으므로 가능한 한 많은 경우의 수를 조사
• 결함을 누락하지 않으면서도 테스트 비용을 절감하려면 가능한 한 적은 수의 테스트 케이스를 사용하도록 설계

명세 기반 테스트

• 소스 코드를 참고하지 않고 테스트 케이스 결정
• 임의 테스트 방법
• 동등 분할, 분류 트리 기법, 경곗값 분석, 신텍스 테스트, 조합 테스트, 상태 전이 테스트, 인과 그래핑, 결정표 테스트, 시나리오 테스트

구조 기반 테스트

• 구현된 소스 코드를 참고해서 테스트 케이스 결정
• 소스 코드의 특정 문장 또는 특정 경로를 실행하기 위한 입력 값을 결정
• 문장 테스트, 결정 테스트, 조건 테스트, 결정/조건 테스트, 다중 조건 테스트, 변형 조건/결정 테스트, 기본 경로 테스트

경험기반 테스트

• 기존의 테스트 경험, 테스트 대상이 되는 시스템 및 해당 도메인에 대한 경험 등을 바탕으로 수행하는 테스트 방법

     오류 추정

• 개발자가 범할 수 있는 실수를 추정하고 이에 따라 결함이 검출되도록 테스트 케이스 설계
• 기본 아이디어는 발생할 수 있는 오류 상황을 나열하는 것에서 시작
• 동등 분할이나 경곗값 분석 같은 명세 기반 테스트 방법과 함께 사용될 수 있음
• 동등 분할 방법에서 유효한 분할은 테스트 대상에 대한 명세를 통해 식별되지만 유효하지 않은 값의 영역은 명세의 정의가 명확하지 않아서 테스터의 경험과 직관을 활용하여 유효하지 않은 분할을 결정할 수 있음
• 오류가 검출된 대표적인 사례를 이용하는 것이 가장 효과적

필수 입력	필수 입력 항목인 경우 값이 입력되지 않는 상황을 테스트
입력 항목의 길이	입력 항목의 길이에 제약이 있는 경우, 더 작거나 더 긴 항목이 입력되는 상황을 테스트 e.g. 주민등록번호 앞자리는 여섯 자리여야 함
입력 항목의 형식	입력 항목에 대한 형식을 위반하는 상황을 테스트 e.g. 생년월일 형식
입력 값의 명시적 제약사항	입력 항목의 값에 대해 명시적으로 정해진 범위를 위반하는 상황을 테스트 e.g. 월 : 01~12 / 일 : 01~31
입력값의 묵시적 제약사항	입력 항목의 값에 대해 명시되지 않았지만, 상식적으로 가정되는 범위를 위반하는 상황을 테스트 e.g. 올해가 21년일 때 19년 입력

 

     탐색적 테스트

• 테스트 대상에 대한 이해, 테스트 케이스 설계, 테스트 실행을 병행하는 방식
• 테스트 대상에 대한 이해를 바탕으로 즉석에서 테스트 케이스를 결정하고 문서화 없이 해당 테스트를 바로 수행
• 테스트를 위한 문서를 작성하지 않음, 테스트에 사용하는 자동화 도구로 테스트 로그, 결과 등을 자동으로 생성
• 에자일 방법을 사용하는 웹 응용 시스템의 테스트에 적합한 방법
• 명확한 가이드가 없으면 : 초기에 시스템에 대한 정보 및 이해가 부족해서 명확한 목표 없이 탐색하는 데만 과도한 시간을 사용할 위험이 있음 / 여러 명, 여러 팀이 동일한 기능을 중복해서 반복적으로 테스트 할 위험이 있음 / 테스트 범위를 명확하게 문서화하지 않아서 테스트의 적합성(커버리지)에 대한 판단을 할 수 있음

 

---

 

테스팅 방법

---

 

리그레션 테스트

유지보수 단계에서의 소프트웨어 변경

• 사용자가 사용 과정에서 발견한 결함이 보고될 경우 이를 제거기 위해 수정
• 기능을 추가하거나 성능을 개선하기 위해 수정
• 새로운 운영 환경에 적응하기 위해 수정
• 더 높은 수준의 유지보수성을 확보하기 위해 수정

리그레션 테스트는 변경 후에 수행되는 테스트, 소프트웨어에 가해진 변경이 의도치 않게 결함을 만들지 않았는지,

시스템이 기존의 요구사항을 충족하는지 등을 검증하기 위함

Retest-all 전략, 선택적 리그레션 테스트 전략, 테스트 최소화 전략, 테스트 우선순위화 전략

각 레벨 테스트 순서대로(컴포넌트, 통합, 시스템) 각 레벨 마다 리그레션 테스트 수행

 

 

소프트웨어 생명 주기 모델과 테스트

• 순차적 생명 주기 모델일 경우, 테스트는 구현이 완료된 시점에 1회 수행
• 에자일 모델처럼 반복적이고 점진적인 모델에서는 테스트도 반복적, 점진적으로 수행
• 폭포수 모델에서는 완료 후 테스트가 시작됨

     요구사항 명세부터 구조 설계 및 상세 설계 산출물을 비롯하여 소스 코드에 이르기까지 필요한 모든 자료가 존재

     검출된 결함을 해결하는 데 많은 비용과 시간이 소요될 가능성이 큼

 

• V모델은 개발 시작과 함께 테스트도 시작됨. 각 개발 단계에서 발생하는 결함을 검출할 수 있는 테스트 레벨 존재

     요구사항 분석 단계에서는 시스템 테스트를 위한 테스트 계획 설계 및 테스트 케이스와 절차를 도출

     구조 설계 단계에서는 통합테스트 테스트 계획 수립 및 테스트 케이스를 도출

     동적 테스트와 더불어 개발 산출물에 대한 정적 테스트도 수행

 

• 진화적 개발 모델 은 이터레이션과 점진적인 방식으로 개발을 진행

     시스템의 구성요소 중 핵심 부분을 개발하고, 각 구성 요소와 추가 요구사항을 여러 이터레이션을 통해 개선,발전

     각 이터레이션은 순차적 모델처럼 요구사항 분석, 설계, 구현, 테스트와 같은 단계로 구성

     각 개발 단계에서 테스트 관련 프로세스 수행

 

위험 기반 테스트

• 테스트 대상과 범위를 결정할 때는 테스트 미수행에 따른 위험을 고려해야 함
• 피처에 대한 위험 분석을 바탕으로 테스트에 대한 계획, 설계, 실행 등의 활동을 수행하는 것을 위험 기반 테스트라 함

 

모델 기반 테스트

• 모델은 자연어로 표현된 형식이거나 상태 전이도 또는 UML 다이어그램 같은 시각적인 표현 방식이 될 수 있음
• 테스트 절차를 수행할 수 있는 정보가 자동으로 추출될 수 있을 정도로 정형화되고 상세한 모델을 바탕으로 함
• 테스트 계획에서 테스트 종료까지 대부분의 활동을 자동화할 수 있다는 장점이 있음
• 장애가 발생했을 때 많은 비용이 유발되는 자동차, 의료 등 안전 필수 소프트웨어를 대상으로 수행
• 모델이 구축된 후에는 자동화를 통해 효율적인 테스트를 수행할 수 있다는 이점이 있음
• 정형적이고 상세한 테스트 모델을 구축하는 비용이 추가되는 단점이 있음
• 의사결정표, UML 상태 다이어그램, UML 액티비티 다이어그램을 비롯한 정형적 표현법을 사용할 수 있음