[정보처리기사] 실기 - 10과목 애플리케이션 테스트 관리 정리

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

 

▶ 소프트웨어 테스트 원리 

*결완초집 살정오*

 - 테스팅은 결함이 존재함을 밝히는 것 : 결함이 존재함을 밝히는 활동

 - 완벽한 테스팅은 불가능 : 완벽한 테스팅 시도는 시간 낭비

 - 개발 초기에 테스팅 시작 : 요르돈의 법칙 (눈덩이 법칙) / 개발 초기에 테스팅하지 못하면 비용이 커짐

 - 결함집중 : 파레토 법칙 / 오류의 80%는 전체 모듈의 20%에서 발견

 - 살충제 패러독스 : 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함

 - 테스팅은 정황에 의존적 : 소프트웨어의 성격에 맞게 테스트 실시

 - 오류-부재의 궤변 : 요구사항을 충족시키지 못하면, 결함이 없다해도 품질이 높다고 볼 수 없음

 

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

 - 테스트 계획서 (Test Plan) : 테스트 수행을 계획한 문서

 - 테스트 베이시스 (Test Basis) : 테스트 설계를 위한 기준이 되는 문서

 - 테스트 케이스 (Test Case) : 테스트를 위한 설계 산출물

 - 테스트 슈트 (Test Suites) : 테스트 케이스의 집합

 - 테스트 시나리오 (Test Scenario) : 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서 

 - 테스트 스크립트 (Test Script) : 테스트 케이스의 실행 순서를 작성한 문서

 - 테스트 결과서 (Test Results) : 테스트 결과를 정리한 문서

 

▶ 프로그램 실행 여부에 따른 분류

 - 정적 테스트 : 테스트 대상 실행 x / 리뷰, 정적분석

• 리뷰 : 소프트웨어의 다양한 산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검하기 위한 활동. 전문가가 수행
  • 관리 리뷰 : 전반적인 검토 바탕으로 의사 결정 지원
  • 기술 리뷰 : 계획 및 명세를 준수하는지에 대한 검토 수행
  • 인스펙션(=동료검토) : 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 해결을 찾아내는 기법
  • 워크스루 : 검토자료를 회의 전에 배포해서 사전 검토한 후, 짧은 시간 동안 회의를 진행
  • 감사 : 소프트웨어 제품 및 프로세스가 규제, 가이드라인 등을 준수하고 있는지 독립적으로 평가
• 정적 분석 : 도구의 지원을 받아 정적 테스트 수행
  
  • 코딩 표준 / 복잡도 측정 / 자료 흐름 분석

 - 동적 테스트 : 소프트웨어 실행하여 결함 검출 / 화이트박스 테스트, 블랙박스 테스트, 경험기반 테스트

 

▶ 화이트박스 테스트 (구조 기반 테스트) : 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트

*구결조 조변다 기제데*

 - 구문/문장 커버리지 (Statement) : 프로그램 내 모든 명령문을 적어도 한 번 수행

 - 결정/선택/분기 커버리지 (Decision/Branch) : 결정 포인트 내의 전체 조건식이 적어도 한번은 T/F 수행

 - 조건 커버리지 (Condition) : 결정 포인트 내의 각 개별 조건식이 적어도 한번은 T/F 수행

 - 조건-결정 커버리지 (Condition-Decision) : 전체 조건식 뿐만 아니라 개별 조건식도 T/F 수행

 - 변경 조건-결정 커버리지 (Modified Condition-Decision) : 개별 조건식이 전체 조건식에 독립적으로 영향

 - 다중 조건 커버리지 (Multiple Condition) : 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장

 - 기본 경로/경로 커버리지 (Base Path) : 수행 가능한 모든 경로를 테스트

• 맥케이브 순환 복잡도 : V(G) = E-N+2  *브에노이*

 - 제어 흐름 테스트 (Control Flow) : 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트

 - 데이터 흐름 테스트 (Data Flow) : 제어흐름 그래프 + 데이터 사용현황 추가한 그래프로 테스트

 

▶ 블랙박스 테스트 : 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트

*동경결상 유분페원비*

 - 동등분할 테스트 (Equivalence Partitioning) : 입력 데이터의 영역을 유사한 도메인별로 유효값/무효값을 그룹핑하여 대푯값 테스트 케이스 도출하여 테스트

 - 경곗값 분석 테스트 (Boundary Value Analysis) : 경곗값 포함하여 테스트 케이스를 설계하여 테스트

 - 결정 테이블 테스트 (Decision Table) : 요구사항의 논리와 발생조건을 테이블 형태로 나열해, 조건과 행위를 모두 조합하여 테스트

 - 상태 전이 테스트 (State transition) : 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행

 - 유스케이스 테스트 (Use Case) : 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행

 - 분류 트리 테스트 (Classification Tree Method) : SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스 설계하여 테스트

 - 페어와이즈 테스트 (Pairwise) : 테스트 데이터값들 간에 최소한 한 번씩을 조합

 - 원인-결과 그래프 테스트 (Cause-Effect Graphing) : 그래프를 활용해 입력 데이터 간 관계 및 출력에 미치는 영향 분석

 - 비교 테스트 (Comparison) : 여러 버전의 프로그램에 같은 입력값을 넣어 동일한 결과 데이터가 나오는지 비교

 

▶ 테스트 시각에 따른 분류

 - 검증 (Verification) : 소프트웨어 개발 과정을 테스트 / 올바른 제품을 생산하고 있는지 검증

 - 확인 (Validation) : 소프트웨어 결과를 테스트 / 제대로 동작하는지 확인

 

▶ 테스트 목적에 따른 분류

*회안성 구회병*

 - 회복 테스트 (Recovery) : 고의로 실패를 유도하고 정상적 복귀여부 테스트

 - 안전 테스트 (Security) : 소스 코드 내 보안적인 결함을 미리 점검

 - 성능 테스트 (Performance) : 시스템이 응답하는 시간, 특정 시간 내 처리하는 업무량, 시스템 반응 속도 측정

 *부스스내*

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

 - 구조 테스트 (Structure) : 내부 논리 경로, 소스코드의 복잡도 평가

 - 회귀 테스트 (Regression) : 새로 유입된 오류가 없는지 확인

 - 병행 테스트 (Parallel) : 변경된 시스템과 기존 시스템에 동일 데이터 입력 후 결과 비교

 

▶ 테스트 종류에 따른 분류

 - 명세 기반 (블랙박스 테스트) : 요구사항 명세서 기반 테스트 케이스 선정 *동경결상 유분페원비*

 - 구조 기반 (화이트박스 테스트) : 소프트웨어 내부 논리 흐름에 따라 테스트 케이스 작성/확인 *구결조 조변다 기제데*

 - 경험 기반 (블랙박스 테스트) : 테스터의 경험을 토대로 한, 직관과 기술 능력을 기반으로 수행 *탐오체특*

 

▶ 경험 기반 테스트 유형

*탐오체특*

 - 탐색적 테스트 : 테스트 케이스를 문서로 작성하지 않고, 경험에 바탕을 두고 탐색적으로 기능을 수행해보며 테스트

 - 오류 추정 : 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트케이스 설계하여 테스트

 - 체크리스트 : 테스트하고 평가해야할 내용을 나열하여 하나씩 확인

 - 특성테스트 : 품질 특성을 염두에 두고 이를 근간으로 경험적으로 테스트 케이스를 설계하고 테스트

 

▶ 테스트 케이스 : 특정 요구사항에 준수하는 지를 확인하기 위해 개발된 입력값, 실행조건, 예상된 결과의 집합

 

▶ 테스트 테이스 구성요소

*식항입출 환특의*

 : 식별자 / 테스트 항목 / 입력 명세 / 출력 명세 / 환경 설정 / 특수절차요구 / 의존성 기술

 

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

 

▶ 테스트 오라클 종류

*참샘휴일*

 - 참 오라클 : 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클

 - 샘플링 오라클 : 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클

 - 휴리스틱 오라클 : 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들은 휴리스틱으로 처리하는 오라클

 - 일관성 검사 오라클 : 애플리케이션 변경 수행 전과 후의 결괏값이 동일한지 확인하는 오라클

 

▶ 테스트 레벨 : 함께 편성되고 관리되는 테스트 활동의 그룹

 

▶ 테스트 레벨 종류

*단통시인*

 - 단위 테스트 (Unit Test) : 단위 모듈, 서브 루틴 등을 테스트

 - 통합 테스트 (Integration Test) : 모듈 사이의 인터페이스, 통합된 컴포넌트 간 상호작용을 검증 -> 빅뱅, 샌드위치, 상향식, 하향식 테스트

 - 시스템 테스트 (System Test) : 시스템에서 정상적으로 수행되는지 검증

 - 인수 테스트 (Acceptance Test) : 계약상 요구사항이 만족되었는지 확인 -> 알파, 베타 테스트

• 알파 테스트 : 선택된 사용자가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트
• 베타 테스트 : 실제 환경에서 일정 수의 사용자에게 대상 소프트웨어를 사용하게 하고 피드백을 받는 인수 테스트

---

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

 

▶ 목 객체 : 스텁의 객체지향 버전

*더스드 스가*

 - 더미 객체 (Dummy) : 테스트할 때 객체만 필요하고 기능은 필요하지 않은 경우 사용

 - 테스트 스텁 (Stub) : 타 모듈의 기능을 단순히 수행하는 도구 

 - 테스트 드라이버 (Driver) : 테스트 대상 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후의 결과 도출

 - 테스트 스파이 (Spy) : 테스트 대상 클래스와 협력하는 클래스로 가는 출력을 검증하는데 사용

 - 가짜 객체 (Fake) : 실제 협력 클래스의 기능을 대체해야 할 경우 사용

 

▶ 통합 테스트 : 각 모듈 간 인터페이스 관련 오류 및 결함을 찾기 위한 테스트 기법

 ① 빅뱅 테스트 : 모든 모듈을 동시에 통합 후 테스트 -> 시간 단축 가능 / 장애 위치 파악 어려움

 ② 하향식 테스트 : 메인 모듈부터 아래 방향으로 통합하며 테스트 -> 스텁

 ③ 상향식 테스트 : 최하위 모듈부터 위쪽 방향으로 이동하며 테스트 -> 드라이버

 ④ 샌드위치 테스트 : 상향식 + 하향식

 

▶ 테스트 자동화 도구 : 반복적인 테스트 작업을 스크립트 형태로 구현하여 시간 단축하며 테스트 수행

 

▶ 테스트 자동화 도구 유형 

 - 정적 분석 도구 : 만들어진 애플리케이션을 실행하지 않고 분석하는 도구 

 - 테스트 실행 도구 : 스크립트를 실행

 - 성능 테스트 도구 : 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트

 - 테스트 통제 도구 

 

▶ 테스트 하네스 : 테스트를 지원하기 위한 코드와 데이터

*드 스슈케 스목*

 - 테스트 드라이버 : 테스트 대상 하위 모듈 호출, 파라미터 전달, 테스트 수행 후 결과 도출 -> 상향식

 - 테스트 스텁 : 타 모듈의 기능을 단순히 수행 -> 하향식

 - 테스트 슈트 : 테스트 케이스의 집합

 - 테스트 케이스 : 입력값, 실행 조건, 기대 결과 등의 집합

 - 테스트 스크립트 : 테스트 실행 절차에 대한 명세

 - 목 오브젝트 : 사용자 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체

 

▶ 소프트웨어 결함

 - 에러/오류 : 결함의 원인. 사람에 의해 생성된 실수

 - 결함/결점/버그 : 에러 또는 오류가 원인이 되어 제품에 포함된 결함

 - 실패/문제 : 소프트웨어 제품에 포함된 결함이 실행될 때 발생되는 현상

 

▶ 테스트 리포팅

 - 테스트 결과 정리 : 결과까지 모두 포함된 문서 작성

 - 테스트 요약 문서 : 소프트웨어의 품질 상태를 포함한 문서 작성

 - 품질 상태 : 테스트 성공률, 테스트 커버리지, 결함 수, 결함 중요도 포함

 - 테스트 결과서 : 결함과 관련한 사항을 중점적으로 기록

 - 테스트 실행 절차 리뷰 및 평가 : 단계별 테스트 종료 시 실행 절차 리뷰, 결과에 대한 평가 수행. 결과에 따라 실행 절차 최적화하여 다음 테스트에 적용

 

▶ 테스트 결함 관리 : 단계별 테스트 수행 후 발생한 결함의 재발 방지과 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동

 

▶ 결함 관리 프로세스

*계기검수 재추최*

 - 결함 관리 계획 : 계획 수립

 - 결함 기록 : 발견된 결함에 대한 정보를 DB에 기록

 - 결함 검토 : 주요 내용 검토, 개발자에게 전달

 - 결함 수정 : 결함의 프로그램 수정 

 - 결함 재확인 : 개발자가 수정한 내용 확인, 테스트 수행

 - 결함 상태 추적 및 모니터링 활동 : 게시판 형태의 서비스 제공

 - 최종 결함 분석 및 보고서 작성 : 보고서 작성 후 결함 관리 종료

 

▶ 결함 분석 방법

 - 구체화 (Specification) : 결함 원인을 찾기 위해 입력값, 테스트 절차, 테스트 환경을 명확히 파악

 - 고립화 (Isolation) : 입력값, 테스트 절차, 테스트 환경 중 어떤 요소가 결함 발생에 영향을 미치는지 분석

 - 일반화 (Generalization) : 결함 발생에 영향을 주는 요소를 최대한 일반화

 

▶ 결함 생명주기 별 결함 상태

 - 결함 등록 (Open) : 결함 분석 후 구체화, 고립화, 일반화한 결함으로서 보고된 상태

 - 결함 검토 (Reviewed) : 등록된 결함의 처리방안 검토

 - 결함 할당 (Assigned) : 개발자 결정, 결함 해결 요구

 - 결함 수정 (Resolved) : 개발자가 수정 사항에 대한 해결 처리

 - 결함 확인 (Verified) : 결함 처리가 정확한지 검증 완료

 - 결함 종료 (Closed) : 종료

 - 결함 재등록 (Reopen) : 다시 수정 요구

 - 결함 조치 보류 (Deferred) : Open된 결함을 바로 수정하지 않고 다음 릴리스에서 해결하기로 연기

 

▶ 결함 추이 분석 : 향후 애플리케이션의 모듈 또는 컴포넌트에서 결함이 발생할지 추정하는 작업

 

▶ 테스트 커버리지 : 테스트 케이스에 의해 수행되는 테스트의 범위를 측정하는 테스트 품질 측정 기준

*기라코*

 - 기능 커버리지 : 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정

 - 라인 커버리지 : 전체 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수를 측정

 - 코드 커버리지 : 소스 코드의 구조 코드 자체가 얼마나 테스트 되었는지 측정

 

▶ 결함 심각도 : 애플리케이션에 발생한 결함이 어떤 영향을 끼치며, 그 결함이 얼마나 치명적인지 나타내는 척도

*치주보경단*

 - 치명적 결함 (Critical) : 완전히 방해하거나 못하게 하는 결함

 - 주요 결함 (Major) : 기대와 다르게 동작하거나 기능이 해야하는 것을 못하는 결함

 - 보통 결함 (Normal) : 특정 기준을 충족 못하거나 일부 기능이 부자연 스러운 결함

 - 경미한 결함 (Minor) : 불편함 유발

 - 단순 결함 (Simple) : 사소한 버그

 

---

ch03 애플리케이션 성능 개선

 

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

*처응경자*

 - 처리량 (Throughput) : 주어진 시간에 처리할 수 있는 트랜잭션의 수

 - 응답시간 (Response Time) : 사용자 입력이 끝난 후, 응답 출력이 개시될 때까지의 시간

 - 경과시간 (Turnaround Time) : 사용자가 요구를 입력한 시점부터 트랜잭션 처리 후 결과의 출력이 완료할 때까지 걸리는 시간

 - 자원 사용률 (Resource Usage) : 트랜잭션을 처리하는 동안 사용하는 CPU 사용량

 

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

*락페릭사커*

 - 데이터베이스 락 (DB Lock) : 대량의 데이터 조회, 과도한 업데이트, 인덱스 생성시 발생하는 현상

 - 불필요한 데이터베이스 패치 (DB Fetch) : 실제 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 경우 응답 시간 저하 현상 발생

 - 연결 누수 (Connection Leak) : DB 연결과 관련한 JDBC 객체 사용 후 종료하지 않을 경우 발생

 - 부적절한 커넥션 풀 크기 (Connection Pool Size) : 너무 작거나 크게 설정한 경우 성능 저하 현상 발생 가능성 존재

 - 확정 관련 (Commit) : 트랜잭션이 커밋되지 않고 커넥션 풀에 반환될 때 성능 저하 가능성 존재

 

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

 - 외계인 코드 (Alien Code) : 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드

 - 스파게티 코드 (Spaghetti Code) : 소스코드가 복잡하게 얽혀있어 작동을 파악하기 어려운 코드

 - 알 수 없는 변수명 : 변수나 메서드에 대한 이름 정의를 알 수 없는 코드

 - 로직 중복 : 동일한 처리 로직이 중복되게 작성된 코드

 

▶ 베드 코드 유형

*오문이 결침*

 - 오염 : 재기능을 수행하지 x

 - 문서 부족 : 현재 코드와 문서가 일치하지 x

 - 의미 없는 이름 : 명확한 의미를 갖지 x

 - 높은 결합도 

 - 아키텍처 침식 : 아키텍처 변형으로 인해 시스템 품질 저하

 

▶ 클린 코드 : 가독성이 높고, 단순하며, 의존성을 줄이고, 중복을 최소화하여 잘 정리된 코드

 

▶ 클린 코드 작성 원칙

*가단의 중추*

 - 가독성 : 이해하기 쉬운 용어 사용

 - 단순성 : 한 번에 한 가지 처리만 수행

 - 의존성 최소 : 영향도 최소화

 - 중복성 제거 : 중복 코드 제거

 - 추상화 : 클래스/메서드/함수에 대해 동일한 수준의 추상화 구현

 

▶ 소스 코드 품질 분석 도구 

• 정적 분석 도구 : 소스 코드를 실행하지 않고 코드 자체만으로 분석하는 도구 
  • pmd : 자바 및 타 언어 소스 코드에 대한 버그 분석
  • cppcheck :  c/c++ 언어에 대한 문제 분석
  • SonarQube : 소스 코드 품질 통합 플랫폼
  • checkstyle : 자바 코드에 대한 코딩 표준 검사 도구
  • ccm : 다양한 언어의 코드 복잡도 분석 도구
  • cobertura : jcoverage 기반 테스트 커버리지 측정 도구
• 동적 분석 도구 : 애플리케이션을 실행하여 결함을 분석하는 도구
  • Avalanche : Valgrind 프레임 워크 및 STP 기반 소프트웨어 에러 및 취약점 분석 도구
  • Valgrind : 자동화된 메모리 및 스레드 결함 발견 분석 도구

 

▶ 리팩토링 : 기능은 수정하지 않고 내부 구조, 관계 등을 단순화하여 소프트웨어의 유지보수성을 향상시키는 기법

 

▶ 리팩토링 목적 : 유지보수성을 향상 / 유연한 시스템 / 생산성 향상 / 품질 향상