2022 정보처리기사 실기 Chapter 10 애플리케이션 테스트 관리

알아두면쓸데있는신기한잡학사전/정보처리기사

2022 정보처리기사 실기 Chapter 10 애플리케이션 테스트 관리

대범하게 2022. 5. 6. 23:10

01 애플리케이션 테스트 케이스 설계

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

=> 발예향

오류 발견 관점/오류 예방 관점/품질 향상 관점

▶ 소프트웨어 테스트 원리

=> 결완초집 살정오

결함 존재 증명
완벽 테스팅은 불가능
초기 집중 > 요르돈의 법칙(Snowball Effect, 눈동이 법칙): 개발 초기에 테스팅 하지 않으면 비용이 커진다.
결함 집중 > 파레토 법칙: 소프트웨어 테스트에서 오류의 80%는 전체 모듈의 20% 내에서 발견된다.
살충제 페러독스: 동일한 테스트 케이스에 의한 반복적 실행은 새로운 버그를 잡아내지 못 한다./테스트 케이스의 정기적 리뷰와 개선 및 다른 시각에서의 접근 필요
정황 의존성: 소프트웨어의 성격에 맞게 테스트 실시
오류-부재의 궤변: 요구사항을 충족시키지 못 한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없다.

▶ 소프트웨어 테스트 산출물

테스트 계획서
테스트 베이시스: 분석 설계, 단계의 논리적인 Case로 테스트 설계를 위한 기준이 되는 문서(요구사항 명세서, 관련 기준 또는 표준 등)
테스트 케이스: 테스트를 위한 설계 산출물/응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행조건, 기대 결과로 구성된 테스트 항목의 명세서
테스트 슈트(Test Suites): 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트 케이스의 집합/시나리오가 포함되지 않은 단순한 테스트 케이스들의 모음
테스트 시나리오(Test Scenario): 애플리케이션의 테스트 되어야 할 기능 및 특징 테스트가 필요한 상황을 작성한 문서
테스트 스크립트(Test Script): 테스트 케이스의 실행순서(절차)를 작성한 문서
테스트 결과서

▶ 화이트박스 테스트(구조 기반 테스트)

각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트

테스트 커버리지: 프로그램 내의 테스트 수행 정도를 나타내는 값

-> 기능 기반, 라인, 코드 커버리지

▶ 화이트박스 테스트 유형

=> 구결조 조변다 기제데

구문(문장) 커버리지(Statement): 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지
결정(선택, 분기)(Decision, Branch) 커버리지: 결정 포인트 내의 전체 조건식이 적어도 한번은 참(True)과 거짓(False)의 결과를 수행하는 커버리지
조건(Condition) 커버리지: 결정 포인트 내의 각 개별 조건식이 적어도 한번은 참(True)과 거짓(False)의 결과가 되도록 수행하는 커버리지
조건/결정 커버리지(Condition/Decision): 전체 조건식 뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행하는 테스트 커버리지
변경 조건/결정 커버리지(Modified Condition/Decision): 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함. 조건/결정 커버리지 향상시킨 것.
기본경로(Base Path) 커버리지: 수행 가능한 모든 경로를 테스트, 멕케이브 순환 복잡도
- 멕케이브복잡도: V(G)=E-N+2/간선 수(화살표) - 노드 수(원) +2
제어 흐름(Control Flow) 커버리지: 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트
데이터 흐름 테스트: 제어 흐름 그래프에 사용현황 추가

▶ 블랙박스 테스트(명세기반 테스트)

외부 사용자의 요구사항 명세를 보면서 수행하는 테스트(기능 테스트)

▶ 블랙박스 테스트 유형

=> 동경결상 유분페원비

동등분할 테스트(Equivalence Partitioning Testing): 입력 데이터의 영역을 유사한 도메인별로 유효값/무효값을 그룹핑하여 대푯값 테스트 케이스를 도출해 테스트
경계값 분석 테스트(Boundary Value Analysis Testing): 최소값 바로 위, 최대값 바로 아래 등 입력값의 극한 한계를 테스트 하는 기법
결정 테이블 테스트(Decision Table Testing): 요구사항의 논리와 발생조건을 테이블 형태로 나열해, 조건과 행위를 모두 조합해 테스트
상태 전이 테스트(State Transition Testing): 어느 한 상태에서 다른 상태로 전이 되는 경우의 수를 수행하는 테스트
유스케이스 테스트(Use Case Testing): 시스템이 실제 사용되는 유스케이스로 모델링 되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행하는 테스트
분류 트리 테스트(Classification Tree Method): SW의 일부 또는 전체를 트리구조로 분석 및 표현하는 테스트 케이스를 설계해 테스트
페어와이즈 테스트(Pairwise): 테스트 데이터 값들 간에 최소한 한 번씩을 조합하는 방식
원인-결과 그래프 테스트: 그래프를 활용해 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석
비교 테스트(Comparison Testing): 여러 버전의 프로그램에 같은 입력값을 넣어 비교해 테스트

▶ 경험기반 테스트 유형

탐색적 테스트, 오류 추정, 체크리스트, 특성 테스트

▶ 테스트 시각에 따른 분류

검증(Verification): 소프트웨어 개발 과정 테스트, 개발자 혹은 시험자 시각
확인(Validation): 소프트웨어 결과 테스트, 사용자 시각

▶ 테스트 목적에 따른 분류

=> 회안성 구회병

회복 테스트(Recovery Testing): 시스템에 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트
안전 테스트(Securtiy Testing): 소스 내 보안적인 결함을 미리 점검하는 테스트
성능 테스트(Performance Testing): 응답 시간, 반응 속도, 처리량 등을 측정하는 테스트
구조 테스트(Structure Testing): 시스템의 내부 논리 경로, 소스 코드의 복잡도를 테스트
회귀 테스트(Regression Testing): 오류 제거와 수정에 의해 새로 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법/반복적 성향이 강해서 자동화된 테스트에 적합
병행 테스트(Parallel Testing): 변경된 시스템과 기존 시스템에 동일한 데이터 입력 후 결과 비교

▶ 성능 테스트의 상세 유형

=> 부스스내

부하 테스트(Load Testing): 시스템에 부하를 계속 증가시키면서 시스템의 임계점을 찾음
강도 테스트(Stress Testing): 임계점 이상의 부하를 가해 비정상적인 상황에서의 처리를 테스트
스파이크 테스트(Spike Testing): 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트
내구성 테스트(Endurance Testing): 오랜 시간 동안 시스템에 높은 부하를 가해 테스트

▶ 테스트 종류에 따른 분류

=> 명구경

명세 기반 테스트(블랙박스 테스트) => 구결조 조변다 기제데
구조 기반 테스트(화이트박스 테스트) => 동경결상 유분페원비
경험 기반 테스트(블랙박스 테스트) => 탐색적 테스트, 오류 추정

▶ 정적분석

=> 동워인

동료검토: 2~3명이 진행하는 리뷰의 형태로 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행하는 검토기법이다.
워크스루: 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 가장 비형식적인 검토 기법이다.
인스펙션: 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법이다.

▶ 테스트 케이스

요구사항이 준수하는지를 확인하기 위해서 개발된 입력값, 실행조건, 예상된 결과의 집합

▶ 테스트 시나리오(Test Scenario)

애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성

▶ 테스트 오라클

테스트 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참값을 입력하여 비교하는 기법

▶ 테스트 오라클 종류

=> 참샘휴일

참 오라클(True Oracle): 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생된 오류 모두 검출
샘플링 오라클(Sampling Oracle): 특정 입력값에 대해서만 기대하는 결과를 제공
휴리스틱 오라클(Heuristic): 샘플링 오라클을 개선, 특정 입력값에 대해 올바른 입력값 제공, 나머지 값들에 대해서는 휴리스틱(추정) 처리
일관성 검사(Consistent) 오라클: 애플리케이션 변경이 있을 때, 수행 전과 후의 결과값이 동일한지 확인

▶ 테스트 레벨

프로젝트에서 책임과 연관되어 있으며, 서로 독립적인 성격을 갖지만 함께 편성되고 관리되는 테스트 활동의 그룹

▶ 테스트 레벨의 종류

=> 단통시인

단위 테스트: 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트 하는 단계
통합 테스트: 단위테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계/인터페이스 간 시스템이 실행되는지 확인
시스템 테스트: 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 단계
인수 테스트: 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계
- 알파테스트: 선택된 사용자가 개발자 환경에서 통제된 상태로 개발자와 함께 수행
- 베타테스트: 실제 환경에서 일정한 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 테스트

02 애플리케이션 통합 테스트

▶ 목(Mock) 객체

객체 지향 프로그램에서는 컴포넌트 테스트 수행 시 테스트 되는 메서드가 다른 클래스의 객체에 의존한다. 이런 경우 메서드를 고립화하여 테스트하는 것이 불가능하므로 독립적인 컴포넌트 테스트를 위해서는 스텁의 객체지향 버전인 목 객체가 필요하다.

▶ 목 객체 유형

=> 더스드 스가

더미 객체: 객체만 필요하고 해당 객체의 기능까지는 필요하지 않은 경우
테스트 스텁: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구
테스트 드라이버: 테스트 대상 하위 모듈을 호출, 파라미터 전달, 모듈 테스트 수행 후 결과 도출
테스트 스파이: 테스트 대상 클래스와 협력하는 클래스
가짜 객체: 실제 협력 클래스의 기능을 대체해야 할 경우

▶ 통합 테스트의 분류

빅뱅 테스트: 모든 모듈을 동시에 통합 후 테스트
상향식 테스트 - 테스트 드라이버
하향식 테스트 - 테스트 스텁
샌드위치 테스트: 상향식 + 하향식 테스트, 병령 테스트 가능

▶ 테스트 자동화 도구 유형

=> 정실성통(테스트 자동화 도구의 유형은 출제 가능성 있음)

정적 분석 도구(Static Analysis Tools): 만들어진 애플리케이션을 실행하지 않고 분석, 코딩 표준, 코딩 스타일 등 남은 결함을 발견하기 위해 사용
테스트 실행 도구(Test Execution Tools): 작성된 스크립트를 실행
성능 테스트 도구(Performance Test Tools): 처리량, 응답시간, 경과시간, 자원사용률에 대해 가상의 사용자를 생성하고 테스트 수행
테스트 통제 도구(Test Control Tools): 테스트 관리, 형상 관리, 결함 추적/관리 도구

▶ 테스트 하네스(Test Harness)

애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터를 말하며, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성한다.

▶ 테스트 하네스 구성요소

=> 드 스슈 케시스목

테스트 드라이버
테스트 스텁
테스트 슈트: 테스트 대상 컴포넌트나 모듈 시스템에 사용되는 테스트 케이스의 집합
테스트 케이스: 요구사항에 준수하는지 확인하기 위해 개발된 입력값, 실행조건, 결과값의 집합
테스트 시나리오: 애플리케이션의 테스트 되어야할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서
테스트 스크립트: 자동화된 테스트 실행 절차에 대한 명세
목 오브젝트: 사용자의 행위를 조건부로 사전 입력해 두면, 그 상황에 예정된 행위 수행

▶ 결함

개발자 오류로 인해 만들어지는 문서 또는 코딩상의 결점
소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 현상

▶ 결함 관련 용어

오류(Error): 결함의 원인
결점(Fault): 시스템이 고장(Failure)을 일으키게 하며, 오류(Erro)가 있는 경우 발생하는 현상
버그(Bug): 프로그램로 인해 예상치 못한 결과가 나는 현상
고장(Failure)/문제(Problem): 소프트웨어 제품에 포함된 결함이 실행될 때 발생하는 현상

▶ 결함 관리 프로세스

(제품 품질을 높이기 위한 결함 관리 프로세스는 테스트 단원에서 중요한 부분)

▶ 결함 분석 방법

구체화(Specification): 결함을 발생시킨 입력값, 테스트 절차, 환경을 명확히 파악
고립화(Isolation): 어떤 요소가 결함 발생에 영향을 미치는지 분석
일반화: 결함 발생에 영향을 주는 요소를 일반화시키는 방법

▶ 결함 생명주기

결함 등록, 검토, 할당, 수정, 확인, 재등록, 조치 보류

▶ 결함 추이 분석

결함 관리 측정 지표의 속성값 들을 분석하고, 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생할지를 추정하는 작업

▶ 결함 추이 분석의 유형

⦁ 결함 분포 분석 : 각 APP 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수 측정해 분석

⦁ 결함 추세 분석 : 테스트 진행 시간의 흐름에 따른 결함 수 측정해 분석

⦁ 결함 에이징 분석 : 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정해 분석

▶ 테스트 커버리지

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

▶ 결합 심각도별 분류

=> 치주 보경단

치명적(Critical) 결함: 기능이나 제품의 테스트 완전히 방해, 데이터 손실, 시스템 충돌
주요(Major) 결함: 기능이 기대와 다르게 동작
보통(Normal) 결함: 일부 기능 부자연스러운, 사소한 기능 오작동
경미한(Minor) 결함: 사용상의 불편함 유발, UI 잘림
단순(Simple) 결함: 사소한 버그, 미관한 좋지 않음

▶ 결함 우선순위

발생한 결함이 얼마나 빠르게 처리되어야 하는지

=> 결정적-높음-보통-낮음

03 애플리케이션 성능 개선

▶ 애플리케이션 성능 측정 지표

=> 처응경자

처리량(Throughput): 주어진 시간에 처리할 수 있는 트랙잭션의 수
응답시간(Response Time): 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간
경과시간(Turnaround Time): 애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션을 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간
자원 사용률(Resource Usage): 애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량

▶ 데이터베이스 관련 성능 저하 원인

데이터베이스 락
불필요한 데이터베이스 패치
연결 누수
부적절한 커넥션 풀 크기

▶ 베드 코드

다른 개발자가 로직을 이해하기 어렵게 작성된 코드

외계인 코드(Alien Code): 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
스파게티 코드: 컴퓨터 프로그램의 소스코드가 복잡하게 얽힌 모습을 비유/코드 작동은 정상적이지만, 코드를 읽으면서 그 코드의 작동을 파악하기는 어려운 코드
알 수 없는 변수명, 로직 중복

▶ 클린 코드

잘 작성되어 가독성이 없고, 단순하며, 의존성을 줄이고, 중복을 최소화해 잘 정리된 코드클린

=> 가단의 중추

가독성
단순성
의존성 최소
중복성 제거
추상화: 클래스/메서드/함수에 대해 동일한 수준의 추상화 구현, 상세 내용은 하위클래스/메서드/함수에 구현

▶ 소스코드 품질분석 도구

정적 분석 도구
- pmd: 자바 및 타언어 소스코드에 대한 버그, 데드코드 분석
- cppCheck: C/C++ 코드에 대한 메모리 누수, 오버플로우 등 문제 분석
- checkstyle: 자바 코드에 대한 코딩 표준 검사 도구
동적 분석 도구
- Avalanche: Valgrind , STP 기반 소프트웨어 에러 및 취약점 동적 분석 도구
- Valgrind : 자동화된 메모리 및 스레드 결함 발견 분석 도구

▶ 리팩토링(Refactoring)

=> 기능 변경 x, 중복성 제거,

유지보수 생산성 향상을 목적으로 기능을 변경하지 않고, 복잡한 소스 코드를 수정, 보완해 가용성 및 가독성을 높이는 기법