개발공부/정보처리기사
[정보처리기사 실기] 10장 애플리케이션 테스트 관리
햄❤️
2023. 4. 15. 23:27
728x90
정보처리기사 수제비 2022 실기 문제집을 요약하며 공부했습니다! 😁
10-1. 애플리케이션 테스트 케이스 설계
10-1-1. 애플리케이션 테스트 케이스 작성
📌 소프트웨어 테스트 원리
- 결함 존재 증명: 결함이 존재함을 밝히는 활동
- 완벽한 테스트 불가능: 완벽하게 테스팅하려는 시도는 불필요한 시간과 자원 낭비
- 초기 집중: 초기 테스트 설계시 테스팅 기간 단축 및 결함 예방(요르돈의 법칙; snowball effect)
- 결합 집중: 적은 수의 모듈에서 대다수의 결함이 발견 - 파레토 법칙(Pareto Principle)
- 살충제 패러독스: 동일한 테스트를 반복하면 더 이상 새로운 버그를 찾지 못함
- 정황(Cpntext) 의존 : 소프트웨어 성격에 맞게 테스트 실시
- 오류-부재의 궤변 : 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없음
📌 소프트웨어 테스트 산출물
- 테스트 계획서(Test Plan): 테스트 목적, 범위 정위, 수행 절차, 종료 조건 등 테스트 수행을 계획한 문서
- 테스트 베이시스(Test Basis): 분석, 설계 단계의 논리적인 Case로 테스트 설계를 위한 기준이 되는 문서
- 테스트 케이스(Test Case): 테스트를 위한 설계 산출물로 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서
- 테스트 슈트(Test Suites): 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트 케이스의 집합
- 테스트 시나리오(Test Scenario): 테스트가 필요한 상황을 작성한 문서
- 테스트 스크립트(Test Script): 테스트 케이스의 실행 순서(절차)를 작성한 문서
- 테스트 결과서(Test Results): 테스트 결과를 정리한 문서로 테스트 프로세스 리뷰, 결과 평가
📌 소프트웨어 테스트 기법에 따른 분류
- 화이트박스 테스트: 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트 웨어. 모듈 내부를 테스트하는 방법
= 구조 기반 테스트, 코드 기반 테스트, 로직 기반 테스트, 글래스 박스 테스트- 구문 커버리지(문장 커버리지) - 결정 커버리지 - 조건 커버리지 - 조건/결정 커버리지 - 변경 조건/결정 커버리지 - 다중 조건 커버리지 - 기본 경로 커버리지 - 제어 흐름 테스트 - 데이터 흐름 테스트
- 블랙 박스 테스트: 외부 사용자의 요구사항 명세를 보면서 수행하는 기능 테스트
- 동등 분할 테스트(동치 분할, 균등 분할), 경계값 분석 테스트, 결정 테이블 테스트, 상태 전이 테스트, 유스케이스 테스트, 분류 트리 테스트, 페어와이즈 테스트, 원인-결과 그래프 테스트, 비교 테스트
📌 테스트 목적에 따른 분류
- 회복 테스트(Recovery Testing): 시스템에 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트하는 기법
- 안전 테스트(Security Testing): 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트 기법
- 성능 테스트(performance Testing): 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 측정하는 테스트 기법
- 부하 테스트(Load Testing): 부하를 계속 증가시키면서 시스템의 임계점을 찾는 테스트
- 강도 테스트(Stress Testing): 시스템 처리 능력 이상의 부하, 즉 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
- 스파이크 테스트(Spike Testing): 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트
- 내구성 테스트(Endurance Testing): 오랜 시간 동안 시스템에 높은 부하를 가하여 시스템 반응 테스트
- 구조 테스트(Structure Testing): 시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 기법
- 회귀 테스트(Refression Testing): 시스템의 변경 또는 수정된 코드에 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법
- 병행 테스트(Parallel Testing): 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 기법
📌 정적 테스트
- 리뷰
- 동료 검토(Peer Review): 2-3명이 진행하는 리뷰 형태로 이해 관계자들이 설명을 들으면서 결함 발견
- 인스펙션(Inspection): 저작자 외의 다른 전문가 또는 팀이 검사하여 문제에 대한 올바른 해결을 찾아내는 형식적 검토 기법
- 워크 스루(Walk Throughts): 회의 전 검토 자료를 배포해서 사전 검토 후 짧은 시간 동안 회의를 진행하는 형태로 가장 비형식적 검토 기법
- 정적분석(Static Analysis): 도구의 지원을 받아 정적 테스트를 수행하는 방법
📌 화이트 박스 테스트
- 테스트 커버리지: 테스트 수행 정도를 나타내는 값( 100% 는 불가능)
✏️ 테스트 커버리지 유형
- 기능 기반 커버리지: 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수 측정. UI가 많은 경우 화면수를 모수로 사용
- 라인 커버리지: 전체 소스코드의 라인 수를 모수로, 테스트가 수행된 라인 수를 측정하는 법. 단위 테스트의 척도
- 코드 커버리지: 일반적인 테스트 커버리지로, 소스 코드의 구문, 조건, 결정 등의 구조가 얼마나 테스트 되었는지를 측정
- 구문(문장) 커버리지(Statement Coverage): 프로그램 내의 모든 명령문을 적어도 한번 수행하는 테스트. 조건문 결과와 관게없이 구문 실행 개수로 계산
- 결정 커버리지(Decision Coverage): 결정 포인트 내의 전체 조건식이 적어도 한번은 참과 거짓의 결과를 수행하는 테스트 커버리지. = 선택 커버리지, 분기 커버리지
- 조건 커버리지(Condition Coverage): 결정 포인트 내의 개별 조건식이 적어도 한번은 참과 거짓의 결과가 되도록 수행하는 테스트 커버리지
- 조건/결정 커버리지(Condition/Decision Coverage): 전체 조건식뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 테스트 커버리지
- 변경 조건/결정 커버리지(Modified Condition/Decision Coverage): 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 전체 조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시키는 테스트 커버리지
- 다중 조건 커버리지(Multiple Condition Coverage): 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 테스트 커버리지
- 기본 경로 커버리지(Base Path Coverage): 맥케이브의 순환 복잡도를 기반으로 커버리지 계산. 수행 가능한 모든 경로를 테스트
계산식: V(G) = E - N + 2 (복잡도 = 간선 - 노드 수 + 2) - 제어 흐름 테스트(Control Flow Testing): 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트 하는 기법
- 데이터 흐름 테스트(Data Flow Testing): 제어 흐름 그래프에 데이터 사용 현황을 추가한 그래프를 통해 테스트
📌 블랙 박스 테스트
- 동등 분할 테스트(Equivalence Partitioning Testing): 프로그램의 입력 영역을 유사한 도메인별로 유효값/무효값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트하는 기법
- 경곗값 분석 테스트(Boundary Value Analysis Testing): 입력 조건의 경계 값에서 오류 발생 확률이 높다는 점을 이용하여 경곗값을 포함하여 테스트 케이스를 생성하는 테스트 기법
- 결정 테이블 테스트(Decision Table Testing): 논리와 발생 조건을 테이블 형태로 나열하여, 조건과 행위를 모두 조합하여 테스팅 하는 기법
- 상태 전이 테스팅(State transition): 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법
- 유스케이스 테스트(Use Case Testing): 시스템이 실제 사용되는 유스케이스로 모델링 되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행하는 테스트
- 분류 트리 테스트(Classification Tree Method Testing): SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하여 테스트하는 기법
- 페어와이즈 테스트(Pairwise testing): 테스트 데이터값들 간에 최소한 한 번씩을 조합하는 방식이며, 커버해야할 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 기법
📌 테스트 오라클
- 테스트의 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참값을 입력하여 비교하는 기법
✏️ 테스트 오라클 종류
- 참(True) 오라클 : 모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
- 샘플링(Sampling) 오라클 : 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클
- 휴리스틱(Heuristic) 오라클 : 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 추정(휴리스틱)으로 처리하는 오라클
- 일관성 검사(Consistent) 오라클 : 애플리케이션 변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클
10-1-2. 애플리케이션 테스트 시나리오 작성
📌 테스트 레벨의 종류
- 단위 테스트 : 사용자 요구사항에 대한 단위 모듈, 컴포넌트, 서브루틴 등을 테스트하는 단계
- 통합 테스트 : 단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호 작용을 검증하는 테스트 단계
- 시스템 테스트 : 개발된 소프트웨어가 시스템에서 정상적으로 수행되는지 검증하는 테스트 (기능적, 비기능적 요구사항 T)
- 인수 테스트 : 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트
- 사용자 인수 테스트, 운영상의 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파 테스트, 베타 테스트
📌 테스트 시나리오
- 테스트 수행을 위한 여러 테스트 케이스의 집합으로써 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세한 문서
10-2. 애플리케이션 통합 테스트
10-2-1. 애플리케이션 테스트 수행
📌 단위 테스트(Unit Test)
- 구현 단계에서 각 모듈을 구현한 후 수행한다.
✏️ 목 객체 유형
- 더미 객체: 테스트 시 객체만 필요하고 해당 객체의 기능까지는 필요하지 않을 경우 사용
- 테스트 스텁: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구
- 테스트 드라이버: 테스트 대상 하위 모듈을 호출하고, 모듈 테스트 수행 후의 결과 도출
- 테스트 스파이: 테스트 대상 클래스와 협력하는 클래스로 가는 출력을 검증하는테 사용
- 가짜 객체: 실제 협력 클래스의 기능을 대체해야할 경우 사용
📌 통합 테스트(Integration Test)
- 단위 테스트 후 제시한 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인하는 테스트
- 하향식 통합 개념: 깊이 우선, 너비 우선 방식으로 통합 - 스텁 필요
- 상향식 통합: 위쪽 방향으로 제어의 경로를 따라 이동하면서 구축과 테스트 수행 - 드라이버 필요
- 샌드위치 통합: 상향식 + 하향식 통합 테스트 결합
📌 테스트 자동화 도구 유형
- 정적 분석 도구(Static Analysis Tools): 만들어진 애플리케이션을 실행하지 않고 분석하는 도구
- 테스트 실행 도구(Test Execution Tools): 테스트를 위해 작성된 스크립트를 실행하고, 작성된 스크립트는 각 스크립트마다 특정 데이터와 수행방법을 포함한다.
- 데이터 주도 접근 방식(데이터를 스프레드 시트에 저장), 키워드 주도 접근 방식(테스트 동작 키워드와 데이터를 스프레드 시트에 저장)
- 성능 테스트 도구(Performance Test Tools): 처리량, 응답시간, 경과 시간, 자원 사용률에 대한 테스트를 수행. 성능 목표 달성 여부 확인
- 테스트 통제 도구(Test Control Tools): 테스트 관리 도구, 형상 관리 도구, 결함 추적/관리 도구 등이 있다.
📌 테스트 하네스
- 테스트를 지원하기 위한 코드와 데이터를 말하며, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성
- 테스트 드라이버 : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구, 일시적으로 필요한 조건만을 가지고 있는 테스트 용 모듈
- 테스트 슈트(Test Suites) : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
- 테스트 케이스 : 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서
- 테스트 시나리오(Test Scenario): 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서
- 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서
- 목 오브젝트(Mock Object) : 사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
10-2-2. 애플리케이션 개선 조치사항 작성
📌 테스트 커버리지
- 주어진 테스트 케이스에 의해 수행되는 소프트웨어 테스트 범위를 측정하는 테스트 품질 측정 기준
- 테스트 커버리지 유형: 기능 기반 / 라인 기반 / 코드 커버리지
📌 결함 심각도별 분류
- 치명적 결함(Critical): 제품의 테스트를 완전히 방해하거나 못하게 하는 결함
- 주요 결함(Major): 기능이 기대와 많이 다르게 동작. 그 기능이 해야할 것을 못하는 결함
- 보통 결함(Normal): 특정 기준을 충족하지 못하거나 일부 기능이 부자연스러운 결함
- 경미함 결함(Minor): 사용상의 불편함 유발
- 단순 결함(Simple): 사소한 버그. 기능에 영향 X
📌 결함 우선순위
- 결정적: 24시간 안에 즉시 수정
- 높음: 일반적으로 결함으로 인해 다른 기능을 사용할 수 없을때 분류
- 보통: 올바른 에러 메시지가 출력되지 않는 것과 같은 에러
- 낮음: 디자인 강화 및 UX 향상을 위한 작은 기능 구현 요청건
10-3. 애플리케이션 성능 개선
10-3-1. 애플리케이션 성능 분석
📌 애플리케이션 성능 측정 지표
- 처리량(Throughput) : 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수
- 응답 시간(Response Time) : 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간
- 경과 시간(Turnaround Time) : 애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션을 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간
- 자원 사용률(Resource Usage) : 애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량
📌 DB 관련 성능 저하 원인
- 데이터베이스 락(DB Lock), 불필요한 데이터베이스 패치(DB Fetch), 연결 누수(Connection Leak), 부적절한 커넥션 풀 크기(Connection Pool Size), Commit 관련
728x90