정보처리기사_실기
정보처리기사 106 ~ 117 (애플리케이션 테스트 ~ 성능 개선)
치개
2022. 6. 26. 18:45
- 애플리케이션 테스트
- 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
- 고객의 요구사항을 만족시키는지 Validation 하고 기능을 정확히 수행하는지 Verification 한다
- Validation
- 사용자의 입장에서 소프트웨어가 고객싀 요구사항에 맞게 구현되었는지를 확인
- Verification
- 개발자의 입장에서 소프트웨어가 명세서에 맞게 만들어졌는지 점검
- 기본 원리
- 완벽한 테스트 불가능
- 잠재적인 결함을 줄일 수 있지만 결합이 완전히 없다고 증명할 수는 없음
- 파레토 법칙 (Pareto Principle)
- 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
- 살충제 패러독스 (Pesticide Paradox)
- 동일한 테스트 케이스를 사용하여 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
- 오류-부재의 궤변 (Absence of Errors Fallacy)
- 결함을 모두 제거해도 요구사항을 만족하지 못하면 품질이 높다고 말할 수 없음
- 테스팅은 정황(Context) 의존
- 정황 : 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등..
- 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함
- 테스트와 위험은 반비례
- 테스트를 많이 할 수록 미래에 발생할 위험을 줄일 수 있음
- 테스트의 점진적 확대
- 작은 부분에서 시작해서 점점 확대하며 진행해야 함
- 테스트의 별도 팀 수행
- 프로그램 실행 여부에 따른 테스트
- 정적 테스트
- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석
- 코딩 표준, 코딩 스타일, 남은 결함 등을 발견하기 위해 사용
- 워크스루, 인스펙션, 코드검사
- 동적 테스트
- 프로그램을 실행하여 오류를 찾는 테스트
- 개발의 모든 단계에서 수행
- 블랙박스 테스트, 화이트박스 테스트
- 테스트 기반에 따른 테스트
- 명세 기반 테스트
- 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인
- 동등 분할, 경계값 분석
- 구조 기반 테스트
- 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인
- 구문 기반, 결정 기반, 조건 기반
- 경험 기반 테스트
- 테스터의 경험을 기반으로 수행
- 에러 추정, 체크 리스트, 탐색적 테스팅
- 시각에 따른 테스트
- Verification 테스트
- 개발자의 시각에서 제품의 생산 과정을 테스트
- 제품이 명세서대로 완성됐는지 테스트
- Validation 테스트
- 사용자의 시각에서 생산된 제품의 결과를 테스트
- 제품의 정상 동작 여부, 요구사항이 잘 반영되었는지 테스트
- 목적에 따른 테스트
- 회복 테스트 : 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인
- 안전 테스트 : 시스템 보호 도구가 잘 작동되는지 확인
- 강도 테스트 : 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 정상적으로 실행되는지 확인
- 성능 테스트 : 실시간 서능이나 전체적인 효율성을 진단
- 구조 테스트 : 내부의 논리적인 경로, 소스코드의 복잡도 등을 평가
- 회귀 테스트 : 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
- 병행 테스트 : 변경된 소프트웨어와 기존의 소프트웨어에 동일한 데이터를 입력하여 결과 비교
- 동적 테스트
- 화이트박스 테스트
- 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스 설계
- 모듈 안의 작동을 직접 관찰
- 모든 문장을 한 번 이상 실행
- 종류
- 기초 경로 검사 (Base Path Testing)
- 절차적 설계의 논리적 복잡성을 측정
- 대표적인 화이트박스 테스팅 기법
- 제어 구조 검사 (Control Structure Testing)
- 조건 검사 (Condition Testing)
- 루프 검사 (Loop Testing)
- 프로그램의 반복(Loop)구조에 초점을 맞춰 수행
- 데이터 흐름 검사 (Data Flow Testing)
- 변수의 정의와 변수 사용 위치에 초점을 맞춰 수행
- 검증 기준
- 문장(구분) 커버리지 (Statement Coverage)
- 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계
- 분기 커버리지 (Branch Coverage)
- 모든 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
- 결정 커버리지 (Decision) 이라고도 함
- 조건 커버리지 (Condition Coverage)
- 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
- 분기/조건 커버리지
- 분기 커버리지와 조건 커버리지 기준을 모두 만족하는 설계
- 블랙박스 테스트
- 각 기능이 완전히 작동되는 것을 입증하는 테스트
- 기능 테스트 라고도 함
- 주로 구현된 기능을 테스트
- 소프트웨어 인터페이스를 통해 실시
- 종류
- 동치 분할 검사 (Equivalence Partitioning Testing)
- 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트
- 해당 입력 자료에 맞는 결과가 출력되는지 확인
- 동등 분할 기법 이라고도 함
- 경계값 분석 (Boundary Value Analysis)
- 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용
- 입력 조건의 경계값을 테스트 케이스로 선정
- 원인-효과 그래프 검사 (Cause-Effect Graphing Testing)
- 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 후 효용성이 높은 테스트 케이스를 선정
- 오류 예측 검사 (Error Guessing)
- 비교 검사 (Comparison Testing)
- 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 확인
소프트웨어 생명주기 V-모델
- 요구사항 → 분석 → 설계 → 구현 → 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트
- 소프트웨어 개발 단계에 따른 테스트
- 단위 테스트 (Unit Test)
- 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
- 인터페이스, 입.출력, 경계 조건 등을 검사
- 요구사항 기반의 기능성 테스트를 최우선으로 수행
- 구조 기반 테스트 / 명세 기반 테스트 → 주로 구조 기반 테스트를 시행
- 통합 테스트 (Integration Test)
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
- 시스템 테스트
- 개발된 소프트웨어가 완벽하게 수행되는가를 점검하는 테스트
- 기능적 요구사항 비기능적 요구사항으로 구분하여 테스트
- 인수 테스트 (Acceptance Test)
- 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
- 사용자가 직접 테스트
- 종류
- 사용자 인수 테스트
- 운영상의 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행
- 계약 인수 테스트
- 규정 인수 테스트
- 알파 테스트 : 개발자의 장소에서 사용자가 행하는 테스트
- 베타 테스트 : 사용자의 장소에서 사용자가 행하는 테스트
- 통합 테스트
- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트
- 종류
- 비점진적 통합
- 단계적으로 통합하는 절차 없이 모든 모듈들이 미리 결합되어 있는 프로그램 전체를 테스트
- 빅뱅 통합 테스트
- 점진적 통합
- 모듈 단위로 단계적으로 통합하면서 테스트
- 하향식 통합 테스트 (Top Down Integration Test)
- 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
- 깊이 우선 통합법 / 넓이 우선 통합법
- 절차
- 주요 제어 모듈의 종속 모듈들을 Stub으로 대체
- 통합 방식에 따라 하뒤 모듈인 스텁들이 하나씩 실제 모듈로 교체
- 모듈이 통합될 때 마다 테스트 실시
- 회귀 테스트 실시
- 스텁 (Stub)
- 타 모듈의 기능을 단순히 수행하는 도구
- 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
- 상향식 통합 테스트 (Bottom Up Integration Test)
- 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
- 절차
- 하위 모듈들을 클러스터로 결합
- 드라이버 작성
- 통합된 클러스터 단위로 테스트
- 클러스터 결합, 드라이버는 실제 모듈로 대체
- 클러스터 (Cluster)
- 드라이버 (Driver)
- 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 결과를 도축하는 도구
- 더미 모듈
- 혼합식 통합 테스트
- 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용
- 샌드위치 통합이라고도 함
- 회귀 테스트 (Regression Testing)
- 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트
- 이미 테스팅 된 프로그램을 반복 테스트
- 애플리케이션 테스트 프로세스
- 개발된 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차
- 테스트 계획 → 테스트 분석 및 디자인 → 테스트 케이스 및 시나리오 작성 → 테스트 수행 → 테스트 결과 평가 및 리포팅 → 결함 추적 및 관리
- 결함 관리 프로세스
- 에러 발경 → 에러 등록 → 에러 분석 → 결함 확정 → 결함 할당 → 결함 조치 → 결함 조치 검토 및 승인
- 테스트 케이스
- 사용자의 요구사항을 정확하게 준수했느지를 확인하기 위해 설계된 테스트 항목에 대한 명세서
- 테스트 시나리오
- 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합
- 테스트 케이스를 적용하는 구체적인 절차 명세
- 테스트 오라클 (Test Oracle)
- 테스트 결과가 올바른지 판단하기 위해 사전에 정의도니 참 값을 대입하여 비교하는 기법 및 활동
- 특징
- 종류
- 참(True) 오라클
- 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공
- 발생된 모든 오류 검출 가능
- 샘플링(Sampling) 오라클
- 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공
- 전수 테스트가 불가능한 경우 사용
- 추정(Heuristic) 오라클
- 특정 테스트 케이스의 입력 값에 대해서만 기대하는 결과를 제공하고 나머지 입력 값들은 추정으로 처리
- 일관성 검사(Consistent) 오라클
- 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클
- 테스트 자동화
- 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용하여 테스트
- 쉽고 효율적으로 테스트 수행 가능
- 정적 분석 도구 (Static Analysis Tools)
- 프로그램을 실행하지 않고 분석하는 도구
- 코딩 표준, 코딩 스타일, 남은 결함 등을 발견하기 위해 사용
- 테스트 실행 도구 (Test Execution Tools)
- 스크립트 언어를 사용하여 테스트를 실행
- 데이터 주도 접근 방식
- 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어서 실행
- 키워드 주도 접근 방식
- 스프레드시트에 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행
- 성능 테스트 도구 (Performance Test Tools)
- 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행
- 성능의 목표 달성 여부 확인
- 테스트 통제 도구 (Test Control Tools)
- 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
- 테스트 하네스 도구 (Test Harness Tools)
- 테스트가 실행될 환경을 시뮬레이션하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구
- 테스트 하네스
- 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분
- 구성 요소
- 테스트 드라이버
- 테스트 스텁
- 테스트 슈트 : 테스트 케이스의 집합
- 테스트 케이스
- 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서
- 목 오브젝트 : 사전에 사용자의 행위를 조건부로 입력해두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
- 결함 관리
- 결함 (Fault)
- 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
- 프로세스
- 결함 관리 계획 → 결함 기록 → 결함 검토 → 결함 수정 → 결함 재확인 → 결함 상태 추적 및 모니터링 → 최종 결함 분석 및 보고서 작성
- 결함 상태 추적
- 발견된 결함의 상태 변화를 지속적으로 추적하고 관리
- 측정 지표
- 결함 분포 : 결함의 수 측정
- 결함 추세 : 결함 수의 추이 분석
- 결함 에이징 : 결함이 지속되는 시간 측정
- 결함 추적 순서
- 결함 등록 → 결함 검토 → 결함 할당 → 결함 수정 → 결함 조치 보류 → 결함 종료 → 결함 해제
- 결함 분류
- 시스템 결함 : 애플리케이션 환경이나 DB 처리에서 발생한 결함
- 기능 결함 : 애플리케이션 기획, 설계 등의 단계에서 유입된 결함
- GUI 결함 : UI 설계에서 발견된 결함
- 문서 결함 : 의사소통이나 기록이 원활하지않아 발생한 결함
- 결함 심각도
- 애플리케이션에 발생한 결합이 전체 시스템에 미치는 치명도를 나타내는 척도
- High, Medium, Low // Critical, Major, Normal, Minor, Simple
- 결함 우선순위
- 결함 처리에 신속성을 나타내는 척도
- Critical, High, Medium, Low // 즉시 해결, 주의 요망, 대기, 개선 권고
- 결함 관리 도구
- Mantis
- Trac
- Redmine
- Bugzilla
- 결함 신고 등 결함을 지속적으로 관리할 수 있는 도구
- 결함의 심각도와 우선순위 지정 가능
- 애플리케이션 성능
- 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도
- 측정 지표
- 처리량 (Throughput)
- 일정 시간 내에 애플리케이션이 처리하는 일의 양
- 응답 시간 (Response Time)
- 요청을 전달한 시간 부터 응답이 도착할 때 까지 걸린 시간
- 경과 시간 (Turn Around Time)
- 작업을 의뢰한 시간부터 처리가 완료될 때 까지 걸린 시간
- 자원 사용률 (Resources usage)
- 작업을 처리하는 동안 CPU 사용령, 메모리 사용량 등의 자원 사용률
- 성능 테스트 도구
- 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구
- 부하(Load) 테스트 : 일정 시간 동안 부하를 가하면서 반응을 측정하는 테스트
- 강도(Stress) 테스트 : 부하테스트를 확장한 테스트, 과부하 상태에서 어떻게 작동하는지 테스트
- 종류
- JMeter
- HTTP, FTP 등 다양한 프로토콜을 지원하는 부하(Load) 테스트 도구
- 크로스 플랫폼
- LoadUI
- 서버 모니터링, Drag&Drop 등 사용자의 편리성이 강화된 부하(Load) 테스트 도구
- HTTP, JDBC 등 다양한 프로토콜 지원
- 크로스 플랫폼
- OpenSTA
- HTTP, HTTPS 프로토콜에 대한 부하(Load) 테스트
- 생산품 모니터링 도구
- Windows 플랫폼
- 시스템 모니터링 도구
- 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
- Scouter
- 단일 뷰 통합/실시간 모니터링, 튜닝에 최적화 된 인프라 통합 모니터링 도구
- 애플리케이션의 성능을 모니터링/통제 하는 도구
- Zabbix
- 복잡도 (Complexity)
- 시스템의 구성 요소 또는 소프트웨어의 복잡한 정도를 나타냄
- 어느 정도 수준까지 테스트해야 하는지, 개발하는데 어느 정도의 자원이 소요되는지 예측하는데 사용
- 시간 복잡도
- 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화
- 시간 복잡도가 낮을수록 알고리즘 실행 시간이 짧고, 높을수록 실행 시간이 길어짐
- 점근 표기법 종류
- 빅오 표기법 (Big-O Notation)
- 알고리즘의 실행시간이 최악일 때를 표기하는 방법
- 세타 표기법 (Big-θ Notation)
- 알고리즘의 실행시간이 평균일 때를 표기하는 방법
- 오메가 표기법 (Big-Ω Notation)
- 알고리즘의 실행시간이 최상일 때를 표기하는 방법
- 빅오 표기법 종류
- O(1) : 스택, 입력값에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침
- O(log₂n) : 이진 트리, 이진 검색, n에 따라 감소
- O(n) : for 문, n과 1:1 관계
- O(nlog₂n) : 힙 정렬, 2-way 합병 정렬, nlog₂n만큼 수행
- O(n²) : 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬, n의 제곱만큼 수행
- O(2ⁿ) : 피보나치 수열, 2의 n제곱만큼 수행
- 순환 복잡도 (Cyclomatic Complexity)
- 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
- 맥케이브 순환도 (McCabe's Cyclomatic) 이라고도 함
- 제어 흐름도 이론에 기초
- 계산식
- V(G) = E - N + 2
- 순환 복잡도 = 화살표의 수 - 노드의 수 + 2
- 애플리케이션 성능 개선
- 소스코드 최적화
- Bad Code를 배제하고 Clean Code로 작성하는 것
- Clean Code
- 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드
- 작성 원칙
- 가독성 : 누구든지 쉽게 읽을 수 있도록 작성
- 단순성
- 의존성 배제 : 다른 모듈에 미치는 영향을 최소화
- 중복성 최소화
- 추상화 : 상위부분에서는 애플리케이션의 특성을 나타내고, 하위부분에서 상세한 내용을 구현
- Bad Code
- 프로그램의 로직이 복잡하고 이해하기 어려운 코드
- 스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀 있는 코드
- 외계인 코드 : 아주 오래되거나 참고문서 또는 개발자가없어 유지보수 작업이 어려운 코드
- 소스코드 최적화 유형
- 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행하도록하여 응집도를 높임
- 느슨한 결합 : 인터페이스 클래스를 사용하여 추상화된 자료구조와 메소드를 구현함으로써 클래스 간의 의존성 최소화
- 소스코드 품질 분석 도구
- 정적 분석 도구
- 소스코드를 실행하지 않고 코딩 표준이나, 결함 등을 확인하는 코드 분석 도구
- 종류
- pmd : 미사용 변수, 최적화되지 않은 코드 등 결함을 유발할 수 있는 코드 검사
- cppcheck : C/C++ 코드에 대한 메모리 누수, 오버플로우 등 분석
- SonarQube : 중복 코드, 복잡도, 코딩 설계등을 분석하는 소스분석 통합 플랫폼
- chackStyle : JAVA 코드에 대해 표준을 따르고 있는지 검사
- ccm : 다양한 언어의 코드 복잡도를 분석
- cobertura : JAVA 언어의 코드 복잡도 및 테스트 커버리지 측정
- 동적 분석 도구
- 소스코드를 싱행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석
- 종류
- Avalanche : Valgrind 프레임워크 및 STP 기반으로 구현, 결함 및 취약점 등을 분석
- Valgrind : 프로그램 내에 존재하는 메모리 및 스레드 결함 등을 분석
'정보처리기사_실기' Related Articles