정리 내용은 [수제비 2020 정보처리기사 실기]책을 기반으로 작성하였습니다.
2020 수제비 정보처리기사 실기(1권+2권 합본세트)
NCS 반영! 출제기준으로 전면개편한 교재이다. NCS 기반 반영 문제(예상문제 340제, 단원종합문제 360제, 모의고사 100제, 2020년기출문제)를 수록하였다. 수제비는 합격만을 위한 다양한 학습 콘텐츠
1. 통합 테스트
개념
소프트웨어 각 모듈 간 인터페이스 관련 오류 및 결함을 찾기 위한 체계적인 테스트 방법단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인하는 테스트
분류
비정증적 방식: 빅뱅 방식. 모든 컴포넌트를 사전에 통합하여 전체 프로그램을 한꺼번에 테스트
점증적 방식: 상향식 통합과 하향식 통합 방식
하향식 통합
제어모듈로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트 진행
깊이 우선 또는 너비 우선 방식으로 통합스텁을 사용하며 하위 컴포넌트를 대신함
* 깊이 우선: 루트 노드에서 시작해서 다음 분기로 넘어가기 전 해당 분기를 완벽하게 탐색하는 방법
* 너비 우선: 루트 노드에서 시작해서 다음 분기로 인접한 노드를 먼저 탐색하는 방법
* 스텁: 모듈 및 모든 하위 컴포넌트를 대신하는 더미 모듈. 스텁은 하위모듈의 반환 값만 전달
상향식 통합
최하위 레벨의 모듈 또는 컴포넌트로부터 위쪽방향으로 제어 경로를 따라 이동하면서 구축과 테스트 진행드라이버를 사용하여 상위 모듈을 대신함
* 드라이버: 상위 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈 상위 모듈 흐름을 작성하기 위해 스텁 개발하기 쉽다.
통합 테스트간 비교
분류 | 빅뱅테스트 | 상향식테스트 | 하향식 테스트 |
테스트 수행 방법 |
모든 모듈을 동시에 통합 후 테스트 수행 | 최하위 모듈로부터 점진적으로 상위모듈 함께 테스트 | 최상위 모듈로부터 하위모듈을 통합하면서 테스트 |
드라이버/스텁 | 드라이버/스텁 없이 실제 모듈로 테스트 | 테스트 드라이버 필요 | 테스트 스텁 필요 |
장점 | 단시간 테스트 가능 작은 시스템에 유리 |
장애 위치 파악 쉬움 모든 모듈 개발 시간 낭비 필요 없음 |
장애 위치 파악 쉬움 이른 프로토타입 가능 중요 모듈들의 선 테스트 가능 |
단점 | 장애 위치 파악이 어려움 모든 모듈이 개발되어야 함 |
중요 모듈들이 마지막 테스트 가능성 높음 이른 프로토타입이 어려움 |
많은 스텁 필요 하위 모듈로부터 불충분한 테스트를 수행 |
2. 테스트 자동화도구
개념
테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써 테스트 시간 단축 과 인력 투입 비용을 최소화하는 반면, 쉽고 효율적인 테스트를 수행할 수 있는 방법
장점
반복되는 테스트 데이터 재입력 작업의 자동화
사용자 요구 기능을 일관성 검증에 유리
테스트 결괏값에 대한 객관적인 평가 기준 제공
테스트 결과의 통계작업과 그래프 등 다양한 표시 형태 제공내가 없는 서비스의 경우에도 정밀한 테스트 가능
단점
도구 사용방법에 대한 교육 및 학습 필요
도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력 필요
상용 도구의 경우 고가, 유지관리 비용이 높아 추가 투자 필요
유형
정적 분석도구: 만들어진 애플리케이션을 실행하지 않고 분석하는 도구 / 테스트를 수행하는 사람이 작성된 소스 코드에 대해 이해를 바탕으로 도구를 이용해서 분석하는 것
테스트 실행도구: 테스트를 위해 작성된 스크립트를 실행하고, 작성된 스크립트는 각 스크립트마다 특정 데이터와 테스트를 수행하는 방법이 포함 / 데이터 주도 접근 방식 or 키워드 주도 접근 방식
성능 테스트 도구: 애플리케이션의 처리량, 응답시간, 경과시간, 자원사용률에 대한 가상의 사용자를 생성하고 테스트를 수행함으로써 성능 목표를 달성하였는지 확인하는 도구
테스트 통제도구: 테스트 관리 도구(테스트 계획 및 관리를 위한 도구) / 형상 관리 도구(테스트를 수행에 필요한 데이터와 도구를 관리) / 결함 추적 관리 도구(테스트에서 발생한 결함에 대해 관리하거나 협업을 지원)
테스트 단계별 테스트 자동화 도구
단계 | 자동화 도구 | 설명 |
테스트 계획 | 요구사항 관리 | 고객 요구사항 정의 및 요구사항 관리 지원 |
테스트 분석/ 설계 | 테스트케이스 생성 | 테스트 기법에 따른 테스트 작성과 테스트 데이터 생성 지원 |
테스트 수행 | 테스트 자동화 | 기능 테스트와 UI 테스트 등 단위 테스트 및 통합 테스트를 지원 |
정적 분석 | 코딩 표준, 런타임 오류 등을 검증 | |
동정 분석 | 대상시스템 시뮬레이션을 통한 오류 검출 | |
성능 테스트 | 부하생성기 등을 이용하여 가상 사용자를 생성하고, 시스템의 처리 능력을 측정하는 도구 | |
모니터링 | 시스템 자원의 상태 확인 및 분석 지원 | |
테스트 관리 | 커버리지 생성 | 테스트 완료 후 테스트 충분성 여부 검증 지원 |
형상 관리 | 테스트 수행에 필요한 데이터 및 문서 관리 | |
결함 추적/관리 | 테스트에서 발생한 결함 추적 및 관리 활동 지원 |
3. 테스트 하네스
개념
애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분
테스트를 지원하기 위한 코드와 데이터. 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성
구성요소
분류 | 설명 |
테스트 드라이버 | 테스트 대상 하위모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 등 상향식 테스트에 필요 |
테스트 스텁 | 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구. 하향식 테스트에 필요 |
테스트 슈트 | 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합 |
테스트 케이스 | 입력값, 실행조건, 기대 결과 등의 집합 |
테스트 스크립트 | 자동화된 테스트 실행 절차에 대한 명세 |
목 오브젝트 | 사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체 |
4. 테스트 결과 분석
소프트웨어 결함
에러/오류: 결함이 원인이 되는 것. 일반적으로 사람에 의해 생성된 실수
결함/결점/버그: 에러 또는 오류가 원인이 되어 소프트웨어 제품에 포함되어 있는 결함. 이를 제거하지 않으면 소프트웨어 제품이 실패하거나 문제가 발생실패/문제: 소프트웨어 제품에 포함된 결함이 실행될 때 발생하는 현상
테스트 완료 조건
단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 등 각 단게별 테스트를 언제 어떤 상황에서 종료할 것인지 결정하는 기준
테스트리포팅
테스트 결과 정리, 테스트 요약 문서, 품질 상태, 테스트 결과서, 테스트 실행 절차 및 평가를 포함
5. 결함 관리
개념
각 단계별 테스트 수행 후 발견된 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동
결함 관리 프로세스
에러 발견->에러 등록->에러 분석->결함 확정->결함 할당->결함 조치->결함 조치 검토 및 승인
6. 결함 추이분석
개념
테스트 완료 후 발견된 결함의 결함 관리 측정 지표의 속성값들을 분석하고 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생하는지를 측정
유형
결함 분포 분석: 각 애플리케이션 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수 측정하여 결함의 분포를 분석
결함 추세 분석: 테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석결함
에이징 분석: 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석
6. 테스트 커버리지
개념
주어진 테스트 케이스에 수행되는 소프트웨어 테스트 범위를 측정하는데 테스트 품질 측정 기준테스트 정확성과 신뢰성을 향상시키는 역할
유형
기능기반 커버리지: 테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정하는 방법100% 달성 목표, 일반적으로 UI가 많은 시스템의 경우 화면 수를 모수로 활용
라인 커버리지: 애플리케이션 전체 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수를 측정하는 방법 / 단위 테스트에서는 이 라인 커버리지를 척도로 삼음
코드 커버리지: 소프트웨어 테스트 충분성 지표 중 하나 / 소스 코드의 구문,조건, 결정 등의 구조 코드 자체가 얼마나 테스트되었는지를 측정
코드 커버리지 유형
분류 | 설명 |
구문 커버리지 | 프로그램 내 모든 명령문을 적어도 한번 수행하는 커버리지 조건문 결과와 관계없이 구문 실행 개수로 개선 |
결정 커버리지 | 프로그램 내의 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행하는 커버리지 |
조건 커버리지 | 결정 명령문 내의 각 조건이 적어도 한번은 참과 거짓의 결과가 되도록 수행하는 커버리지 |
조건/결정 커버리지 | 전체 조건식 뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행하는 커버리지 |
변경 조건/ 결정 커버리지 |
각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상 시킨 커버리지 |
다중 조건 커버리지 | 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100%보장하는 커버리지 |
7. 결함의 식별 및 관리
단계별 결함
기획시 유입되는 결함 / 설계 시 유입되는 결함 / 코딩시 유입되는 결함 / 테스트 부족으로 유입되는 결함
결함 심각도 별 분류
분류 | 설명 | 예시 |
치명적 결함 | 기능이나 제품의 테스트를 완전히 방해하거나 못하게 하는 결함 | 데이터 손실, 시스템 충돌 |
주요 결함 | 기능이 기대와 많이 다르게 동작하거나 기능이 해야 하는 것을 못하는 결함 | 기능 장애 |
보통 결함 | 제품이나 프로그램이 특정 기준을 충족하지 못하거나 전체에 영향 주지 않는 일부 기능이 부자연스러운 결함 | 사소한 오작동 |
경미한 결함 | 사용상의 불편함을 유발하는 결함 | 표준 위반, UI 잘림 |
단순 결함 | 사소한 버그. 기능에는 영향이 없지만 수정되어야 하는 결함 | 미관상 좋지 않음 |
결함 우선순위
결정적 / 높음 / 보통 낮음
결함 관리 항목
결함 내용 / 결함 ID / 결함 유형 / 발견일 / 심각도 / 우선순위 / 시정 조치 예정일 / 수정담당자
재 테스트 결과 / 종료일
'Study > 정보처리기사' 카테고리의 다른 글
[정보처리기사 실기] 8. SQL 응용-Chapter 1. 절차형 SQL 작성하기 (0) | 2022.01.18 |
---|---|
[정보처리기사 실기] 7. 애플리케이션 테스트 관리-Chapter 3. 애플리케이션 성능 개선 (0) | 2022.01.18 |
[정보처리기사 실기] 7. 애플리케이션 테스트 관리-Chapter 1. 애플리케이션 테스트 케이스 설계 (0) | 2022.01.16 |
[정보처리기사 실기] 6. 화면 설계-Chapter 2. UI 설계 (0) | 2022.01.15 |
[정보처리기사 실기] 6. 화면 설계-Chapter 1. UI 요구사항 확인 (0) | 2022.01.14 |