17. 애플리케이션 테스트케이스설계 - 1과목 소프트웨어 구축

17. 애플리케이션 테스트케이스설계 - 1과목 소프트웨어 구축

이번 파트는 암기해야할 내용이 많습니다. 테스트에 관해서는 매 시험마다 한번씩 나올 정도로 중요합니다. 테스트 커버리지 중 코드 커버리지와 V모델은 꼼꼼히 읽어보시길 바랍니다.

목차

소프트웨어 테스트

구현된 소프트웨어가 사용자의 요구사항을 만족하는지 확인하며 결함을 찾는 활동

소프트웨어 테스트의 필요성

오류를 발견하고 예방하면, 품질이 향상된다는 것을 기억해주세요.

• 오류 발견 : 결함을 찾아서 수정
• 오류 예방 : 테스트롤 통해 미래의 결함을 발생을 방지
• 품질 향상 : 프로그램 전반적인 기능 품질 향상

소프트웨어 테스트의 기본 원칙

테스팅은 결함을 찾아내는 활동을 말함. 테스팅은 주로 소프트웨어의 결함을 찾아내기 위한 활동으로 이루어집니다.

1. 완벽한 테스팅은 불가능: 모든 가능한 상황을 고려하여 소프트웨어를 테스트하는 것은 불가능합니다.
2. 테스팅은 개발 초기에 시작해야 한다: 테스트는 개발 초기에 시작하여 소프트웨어의 품질을 향상시키는 데 도움이 됩니다.
3. 결합 집중: 소프트웨어 결함의 대부분은 소수의 특정 모듈에 집중되어 있습니다.
4. 파레토 법칙: 전체 결과의 80%가 전체 원인의 20%에서 발생하는 현상입니다.
5. 살충제 페러독스: 반복적인 테스트로는 새로운 결함을 찾기가 어려울 수 있습니다.
6. 테스팅 방법은 특정 상황에 의존적: 테스팅 방법은 특정한 상황에 따라 달라질 수 있습니다.
7. 오류-부재의 궤변: 오류가 없어도 소프트웨어가 요구사항을 충족하지 않으면 의미가 없습니다.

테스트 프로세스

계획-> 분석 및 디자인 -> (설계) 케이스 및 시나리오 작성 -> 수행 -> 결과 평가 및 리포팅

분석 : DFD - DD - Minispec - STD > ERD

케이스는 하나의 단위 테스트를 말함. 시나리오는 케이스를 엮은 것을 말함.

1. 계획: 테스트의 범위, 목적, 일정, 리소스 등을 계획합니다.
2. 분석 및 디자인: 시스템을 분석하고 테스트할 기능을 식별하며, 테스트 케이스 및 시나리오를 디자인합니다.
   • 분석: DFD(데이터 흐름도), DD(데이터 딕셔너리), Minispec(최소 사양), STD(소프트웨어 테스트 문서), ERD(개체-관계 다이어그램) 등을 활용하여 시스템을 분석합니다.
3. 케이스 및 시나리오 작성: 각각의 기능이나 요구사항에 대한 테스트 케이스를 작성하고, 이를 시나리오로 묶어서 테스트 시나리오를 작성합니다.
   • 케이스는 하나의 단위 테스트를 말하며, 시나리오는 케이스를 조합하여 전체 시스템을 테스트하는 데 사용됩니다.
4. 수행: 작성된 테스트 케이스를 실행하고, 시스템의 동작을 확인합니다.
5. 결과 평가 및 리포팅: 테스트의 결과를 평가하고, 발견된 결함을 추적하고 보고서에 기록합니다.

테스트 산출물

산출물	설명
계획서	테스트의 범위, 목적, 일정, 리소스 등을 기록한 문서
케이스	단일 테스트를 수행하기 위한 입력, 실행 조건 및 기대 결과를 포함한 명세서
시나리오	테스트 케이스들의 연속적인 동작 순서를 기록한 문서
결과서	테스트 수행 결과와 결함 보고, 성과 등을 정리한 문서

 

테스트 오라클 (Test Oracle)

테스트의 경로가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법 및 활동

소프트웨어의 테스트 결과를 평가하기 위해 사용되는 비교 기준이나 예상 결과를 제공하는 도구, 기법, 또는 활동을 의미

 

테스트 오라클 유형

참 오라클 - (모든 입력값)

샘플링 오라클 - (제한된 입력 값에 대해서만 결과 제공)

휴리스틱 오라클 - (샘플링

일관성 검사 오라클 (변경 전후 일관성 검증)

테스트 오라클 유형	설명	예시
참 오라클 (All-oracle)	모든 입력값에 대해 예상되는 결과를 제공하는 오라클	모든 가능한 입력에 대한 예상 결과를 제공하는 도구나 기법 (예: 수학적 모델, 사양, 완벽한 시스템)
샘플링 오라클 (Sampler)	일부 제한된 입력 값에 대해서만 결과를 제공하는 오라클	특정 범위의 입력값 또는 특정 시나리오에 대해서만 결과를 예측하거나 제공하는 도구나 기법
휴리스틱 오라클 (Heuristic)	휴리스틱이나 경험에 기반한 판단으로 결과를 제공하는 오라클	경험, 도메인 지식, 휴리스틱을 기반으로 입력값에 대한 결과를 추론하는 도구나 기법 (예: 경험적 규칙, 패턴 인식)
일관성 검사 오라클 (Consistency Checker)	변경 전후에 대한 일관성을 검증하여 결과를 제공하는 오라클	소프트웨어 변경 사항에 대한 영향을 확인하고 이전 결과와의 일관성을 검사하는 도구나 기법

테스트 레벨

V 모델

단통시인

단위 테스트 : 정적, 동적

단위 테스트는 소프트웨어의 개별 모듈 또는 구성 요소의 기능적 및 비기능적 측면을 검증하는 과정입니다.

모듈 설계 단계에서 준비되며, 코드 효율성 표준을 준수하여 개발됩니다.

• 개별 소프트웨어 모듈 또는 구성요소의 기능적, 비기능적 측면을 검증
• 모듈설계단계에서 준비.
• 코드 효율성 표준 준수

1. 정적 단위 테스트: 소스 코드를 실행하지 않고도 코드나 설계 문서를 분석하여 잠재적인 문제점을 찾습니다. 이는 코드 검사, 워크스루, 인스펙션 등을 통해 이루어집니다.
2. 동적 단위 테스트: 실제로 코드를 실행하여 코드의 동작을 확인하고 예상 결과와 실제 결과를 비교합니다. 이는 코드의 기능적 동작 및 비기능적 특성을 검증합니다.

 

통합테스트 

통합 테스트는 여러 모듈 또는 서브시스템을 통합하고 그 사이의 인터페이스 상호작용을 테스트하는 과정입니다. 상향(드라이버, 밑에서부터), 하향(스텁,. 위에서 아래), 빅뱅(비점진적 테스트), 백본(상+하)

 

여러 모듈또는 서브시스템을 통합하고 스 사이의 인터페이스 상호작용 테스트

• 상향식 통합 테스트: 하위 모듈을 하나씩 통합하면서 상위 수준의 기능을 테스트합니다. 필요에 따라 드라이버를 사용하여 하위 모듈을 호출합니다.
• 하향식 통합 테스트: 상위 수준 모듈의 기능을 테스트하기 위해 하위 모듈을 호출하며, 필요한 경우 스텁을 사용하여 하위 모듈을 대체합니다.
• 빅뱅 통합 테스트: 모든 모듈을 한 번에 통합하여 전체 시스템의 동작을 테스트합니다. 이는 전체 시스템의 통합이 완료된 후에 수행됩니다.
• 백본 테스트: 상향식과 하향식 통합 테스트를 결합하여 상위 수준 모듈과 하위 수준 모듈을 번갈아가며 테스트합니다

시스템 테스트 : 기능(요구한 기능), 비기능(성능, 보안)

시스템 테스트는 전체 소프트웨어 시스템의 기능 및 비기능적 요구 사항을 검증하는 과정입니다. 이는 시스템 사양간의 일치성을 확인하고, 성능, 보안 등의 비기능적 요구 사항을 평가합니다.

• 시스템 사양간의 일치성 검증, 비기능적 요구사항에 대한 검증도 포함
• 동적테스트
• 비기능 : 성능, 신뢰성, 안정성, 유효성, 적합성 등을 확인

인수 테스트 : 알파, 베타

인수 테스트는 시스템을 실제로 사용하기 전에 배포하거나 실제 사용 가능한지 확인하는 과정입니다. 이는 알파 테스트, 베타 테스트 및 사용자 인수 테스트로 구성됩니다.

 

• 알파 테스트는 개발자나 내부 사용자에 의해 수행
• 베타 테스트는 외부 사용자 또는 최종 사용자에 의해 수행
• 사용자 인수 테스트는 최종 사용자가 시스템 사용의 적합성을 확인하는 과정

소프트웨어 테스트 기법

정적 테스트

정적 테스트는 프로그램 실행 없이 소스 코드나 설계 문서 등을 분석하여 문제점을 찾는 방법입니다.

주로 코드의 가독성, 구조, 논리적 오류, 문제점 등을 확인하기 위해 사용됩니다.

1. 코드 검사: 소스 코드를 검사하여 구문 오류, 문법 오류, 코드 스타일 규칙 위반 등을 찾는 과정입니다.
2. 워크스루 (Walkthrough): 계획된 개발자 검토 회의로, 코드나 문서의 내용을 시스템 요구 사항과 비교하여 잠재적인 문제점을 식별하는 것을 목적으로 합니다.
3. 인스펙션 (Inspection): 공식적인 회의에서 진행되는 코드나 문서의 자세한 검토 과정으로, 사전에 정의된 검사 기준을 기반으로 코드나 문서를 검사하여 오류를 찾아내는 것을 목적으로 합니다.
4. 동료 검토 (Peer Review): 개발자들 간에 상호 검토를 통해 코드나 문서를 검사하는 과정으로, 피드백과 지적을 통해 오류를 개선하는 것을 목적으로 합니다.
5. 리팩토링 (Refactoring): 소프트웨어의 구조를 개선하고 코드를 재정리하여 가독성을 높이고 유지 보수성을 향상시키는 과정입니다.

동적 테스트

동적 테스트는 소프트웨어가 실제로 실행되고 동작하는 동안에 테스트를 수행하는 방법입니다.

소프트웨어의 기능, 성능, 안전성 등을 평가하기 위해 사용됩니다.

이러한 테스트는 코드의 실제 동작을 확인하고 예상한 결과와 실제 결과를 비교하여 오류를 찾아냅니다.

동적 테스트에는 다양한 방법과 도구가 사용될 수 있습니다.

테스트 기법

화이트 박스 테스트

화이트 박스 테스트은 소프트웨어의 내부 구조를 중심으로 테스트를 수행합니다. 이는 코드의 흐름, 분기, 조건 등을 검증하여 소프트웨어의 동작을 확인하는 것을 목적으로 합니다.

 

정적테스트로 보기에 어려울 수 있습니다. 분류 방법이 다르기 때문입니다.

소프트웨어의 내부 구조 중심 테스트입니다.

• 문장 검증: 코드 내부의 각 문장이 예상대로 실행되는지 확인합니다. 즉, 코드의 각 문장이 올바르게 동작하는지 확인합니다.
• 선택 검증: 모든 분기 및 선택문이 예상대로 작동하는지 확인합니다. 즉, 조건문이 제대로 동작하고 모든 가능한 분기가 테스트되었는지 확인합니다.
• 경로 검증: 모든 경로가 최소 한 번은 실행되는지 확인합니다. 즉, 프로그램의 모든 가능한 경로가 테스트되었는지 확인하여 누락된 경로가 없는지 확인합니다.
• 조건 검증: 각 조건이 참과 거짓으로 정확하게 평가되는지 확인합니다. 즉, 모든 조건문이 제대로 작동하고 예상대로 평가되는지 확인합니다.

기초 경로 검사(Base Path Testing)

테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법, 테스트 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용된

McCabe 검사

• V(g) = E-N+2
• 선-노드+2
• 6-4+2=4
• 기억이 안나면, 면을 구하면 됨. 면(밖으로 나갈 수 없는 내부 영역 + 외부를 감싸는 영역)

블랙박스 테스트

• 사용자 관점 테스
• 동등분할 기업 
• 경계값 분석
• 원인-효과 그래프
• 오류 예측 검사
• 비교 검사 
• 상태전이 검사

개념명	설명	예시
사용자 관점 테스트 (User Perspective Testing)	사용자가 제품 또는 서비스를 최종 사용할 때 발생할 수 있는 경험, 편의성, 유용성 등을 평가하는 것입니다. 사용자 테스트 케이스를 작성하고 실행하여 사용자의 관점에서 제품 또는 서비스를 평가합니다.	사용자 테스트 케이스 작성 및 실행
동등분할 기법 (Equivalence Partitioning)	입력값의 범위를 나누어 각각의 범위에 해당하는 대표값으로 테스트하는 방법입니다. 예를 들어, 주문 금액을 0, 100, 1000 등의 범위로 나누어 대표값으로 테스트합니다.	주문 금액: 0, 100, 1000 등
경계값 분석 (Boundary Value Analysis)	입력값의 경계 부근에서 오류가 가장 자주 발생하는 경향을 고려하여 테스트하는 방법입니다. 예를 들어, 로그인 시 아이디 길이가 5, 6, 7 등의 경계값을 테스트합니다.	로그인: 아이디 길이 5, 6, 7 등
원인-효과 그래프 (Cause-Effect Graph)	시스템의 여러 요소 간의 상호 작용을 시각적으로 표현하는 그래프입니다. 이를 통해 시스템 조건 변경에 따른 효과를 분석할 수 있습니다.	시스템 조건 변경에 따른 효과 분석
오류 예측 검사 (Error Guessing Testing)	는 사용자가 예상할 수 있는 오류를 식별하여 테스트하는 방법입니다. 사용자의 경험과 직관을 활용하여 테스트 케이스를 수립합니다.	사용자가 예상할 수 있는 오류 식별
비교 검사 (Comparison Testing)	두 버전 또는 두 시스템 간의 성능, 기능 등을 비교하여 테스트하는 방법입니다. 이를 통해 변화된 부분을 확인하고 성능을 평가할 수 있습니다.	두 버전 간의 성능 비교
상태전이 검사(State Transition Testing)	사용자 상태 변경에 따른 시스템의 동작을 테스트하는 방법입니다. 시스템이 다양한 상태로 전이될 때의 동작을 확인하여 테스트합니다.	사용자 상태 변경에 따른 테스트

 

테스트 시각

검증(verification) : 소프트웨어의 개발 과정을 테스트 , 개발자가 잘 만들고 있는 검증

확인(Validation) : 완성된 소프트웨어의 결과를 테스트, 사용자의 요구사항을 만족하는 지 검증

 

테스트 목적

개념명	설명
회복 (Recovery)	시스템이 일부러 장애 상태에 놓였을 때 정상 상태로 회복하는지 테스트합니다.
안전 (Safety)	시스템이 예기치 않은 상황에 대해 안전한지를 검증합니다. 허니팟(Honeypot)을 예시로 들 수 있습니다.
강도 (Stress)	시스템이 여러 요청에 대해 어떻게 견딜 수 있는지를 테스트합니다. 한번에 과부하시켜서 확인
성능 (Performance)	시스템의 성능을 측정하고 평가합니다.
구조 (Structural)	시스템의 내부 구조를 테스트합니다. 복잡도
회귀 테스트 (Regression Testing)	수정 전과 수정 후에도 시스템의 기능이 여전히 정상적으로 작동하는지를 확인하는 것입니다.
병행 (Concurrency)	동일한 입력을 사용하여 동시에 여러 기능 또는 프로세스를 테스트합니다.
A/B 테스트 (A/B Testing)	두 가지 이상의 버전을 동시에 제공하여 사용자 반응을 비교하는 테스트 방법입니다.
스모크 테스트 (Smoke Testing)	주요 기능이 정상적으로 작동하는지를 빠르게 확인하는 테스트로, 환경에 대한 테스트를 포함합니다.

 

테스트 종류

1. 명세기반 테스트 (Specification-based Testing)
   • 주어진 명세서나 요구사항을 기반으로 테스트 케이스를 작성하고 실행하여 시스템이 명세된 기능을 올바르게 수행하는지 확인하는 테스트입니다. 이는 시스템의 기능적 요구사항을 충족하는지를 확인하기 위해 사용됩니다.
   • 시간 많이 걸림
2. 구조기반 테스트 (Structure-based Testing)
   • 소프트웨어 시스템의 내부 구조나 코드에 기반하여 테스트 케이스를 작성하고 실행하는 테스트 방법입니다. 프로그램의 제어 흐름, 결정 테스트 등의 구조적인 요소를 기반으로 테스트를 수행하여 특정 구조적인 오류를 찾아내는 데 사용됩니다.
   • 시간 많이 걸림
3. 경험 기반 테스트 (Experience-based Testing)
   • 테스터의 경험, 직관, 지식을 활용하여 테스트 케이스를 작성하고 실행하는 테스트 방법입니다. 과거의 경험이나 도메인 지식을 기반으로 테스트 시나리오를 작성하고 시스템을 테스트하여 잠재적인 문제를 발견하는 데 사용됩니다.

테스트 커버리지

주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준

테스트의 정확성과 신뢰성을 향상시키는 역할

테스트를 얼마나 측정하는 기준

 

기능 기반 커버리지

• WBS를 기반으로 P/C 작성하면 임계경로 간트 차트를 작성함.
• 전체 기능을 모수로 하고 실제 테스한 기능 수
• 100% 달성을 목표

라인 커버리지

• 소스 코드의 각 라인이 테스트 케이스에 의해 실행되는 정도를 측정하는 지표입니다.
• 소스 코드의 각 라인이 테스트 케이스에 의해 실행되면 해당 라인은 테스트되었다고 간주됩니다.
• 전체 소스 코드 라인 중 테스트된 라인의 비율을 통해 라인 커버리지를 평가할 수 있습니다.
• 이는 소스 코드의 실행 경로를 얼마나 효과적으로 테스트하고 있는지를 나타냅니다.

코드 커버리지 (최 빈출)

충분성 지표중 하나, 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트 되었는지를 측정 하는 방법

 

구문 커버리지(Sentence Coverage)

모든 구문에 대해 한번 이상

def is_even(num):
    if num % 2 == 0:
        return True
    else:
        return False

조건 커버리지(Condition Coverage)

결정조건식(if문) 모든 개별 조건식에 대해 수행

A	B	결정 포인트
T	F	F
F	T	F

결정 커버리지(Decision Coverage)

결정 포인트 내의 모든 분기문에 대해 수행

A	B	결정 포인트
T	T	T
F	F	F

조건/결정 커버리지(Condition/Decision Coverage)

결정포인트도 개별포인트도 모두 수행

A	B	결정 포인트
T	T	T
T	F	F
F	T	F
F	F	F

변경 조건/결정 커버리지 (Modified Condition/Decision Coverage)

모든 결정포인트 내의 개별 조건식은 적어도 한번의 T/F를 가져야 한다.

A	B	결정 포인트
T	F	F
F	T	F

다중 조건 커버리지 (Multiple Condition Coverage)

결정 포인트 내 모든 개별 조건식의 가능한 조합을 100% 보장해야한다.

A	B	결정 포인트
T	T	T
T	F	F
F	T	F
F	F	F