[2020 정보처리기사 필기] 애플리케이션 테스트 관리 (2)

55. 테스트 케이스 / 테스트 시나리오 / 테스트 오라클 ★★

1. 테스트 케이스(Test Case)

- 명세 기반 테스트의 설계 산출물이다.

- 가장 이상적인 테스트 케이스를 설계하려면 시스템 설계 시 작성해야 한다.

 

2. 테스트 케이스 작성 순서

- 테스트 계획 검토 및 자료 확보 -> 위험 평가 및 우선순위 결정 -> 테스트 요구사항 정의 -> 테스트 구조 설계 및 테스트 방법 결정 -> 테스트 케이스 정의 -> 테스트 케이스 타당성 확인 및 유지 보수

 

3. 테스트 시나리오

- 여러 개의 테스트를 집합으로, 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서이다.

- 테스트 시나리오에는 테스트 순서에 대한 구체적인 절차, 사전 조건, 입력 데이터 등이 설정되어 있다.

- 테스트 시나리오를 통해 테스트 순서를 미리 정함으로써 테스트 항목을 빠짐없이 수행할 수 있다.

 

4. 테스트 시나리오 작성 시 유의 사항

- 테스트 시나리오는 시스템별, 모듈별, 항목별 등과 같이 여러 개의 시나리오로 분리하여 작성해야 한다.

- 테스트 시나리오는 사용자의 요구사항과 설계 문서 등을 토대로 작성해야 한다.

- 테스트 시나리오는 유스케이스(Use Case) 간 업무 흐름이 정상적인지를 테스트할 수 있도록 작성해야 한다.

 

5. 테스트 오라클(Test Oracle)

- 테스트 오라클은 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동을 말한다.

- 테스트 오라클은 결과를 판단하기 위해 테스트 케이스에 대한 예상 결과를 계산하거나 확인한다.

- 테스트 오라클의 특징

       - 제한된 검증 : 테스트 오라클을 모든 테스트 케이스에 적용할 수 없다.

       - 수학적 기법 : 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있다.

       - 자동화 가능 : 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있다.

 

6. 테스트 오라클의 종류

- 참 오라클은 주로 항공기, 은행, 발전소 소프트웨어 등 미션 크리티컬한 업무에 사용되고, 샘플링 오라클과 추정 오라클은 일반적인 업무, 게임, 오락 등에 사용된다.

- 참(True) 오라클 : 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클로, 발생된 모든 오류를 검출할 수 있다.

- 샘플링(Sampling) 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클이다.

- 추정(Heurastic) 오라클 : 샘플링 오라클을 개선한 오라클로, 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클이다.

- 일관성 검사(Consistent) 오라클 : 애플리케이션의 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클이다.

 

핵심

- 테스트 케이스는 시스템 설계 시 설계하는 것이 가장 이상적이다.

- 테스트 오라클 : 테스트 케이스의 예상 결과로, 테스트 결과가 올바른지 판단하기 위한 근거가 되는 것

- 테스트 시나리오 : 테스트 수행을 위한 여러 개의 테스트 케이스들의 집합으로 시스템별, 모듈별, 항목별과 같이 여러 개의 시나리오로 분리하여 작성한다.

- 테스트 오라클의 종류 : 참 오라클, 샘플링 오라클, 추정 오라클, 일관성 검사 오라클

---

56. 테스트 자동화 도구 ★★

1. 테스트 자동화의 개념

- 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적으로 테스트를 수행할 수 있도록 한 것

 

2. 테스트 자동화 도구의 장점/단점

- 장점

       - 반복적인 작업을 자동화함으로써 인력 및 시간 절약이 가능

       - 다중 플랫폼 호환성 등 향상된 테스트 품질을 보장

       - 일관성 있게 검증

       - 테스트 결과에 대한 객관적인 평가 기준 제공

       - 테스트 결과를 그래프 등 다양한 표시 형태로 제공

       - UI가 없는 서비스도 정밀 테스트 가능

- 단점

       - 테스트 자동화 도구 사용 방법에 대한 학습이 필요

       - 자동화 도구를 프로세스 단계별로 적용하기 위한 시간, 노력 필요

       - 비공개 상용 도구의 경우 고가의 추가 비용 필요

 

3. 테스트 자동화 수행 시 고려사항

- 테스트 절차를 고려하여 재사용 및 측정이 불가능한 테스트 프로그램은 제외

- 모든 테스트 과정을 자동화 할 수 있는 도구는 없으므로 용도에 맞는 적절한 도구를 선택해서 사용

- 자동화 도구의 환경 설정 및 습득 기간을 고려해 일정을 계획해야 한다.

- 테스트 엔지니어의 투입 시기가 늦어지면 프로젝트의 이해 부족으로 인해 불완전한 테스트를 초래할 수 있으므로 반드시 프로젝트 초기에 테스트 엔지니어의 투입 시기를 계획해야 한다.

 

4. 테스트 자동화 도구의 유형

- 정적 분석 도구 

       - 프로그램을 실행하지 않고 분석하는 도구로, 소스 코드에 대한 코딩 표준, 코드 복잡도 등을 발견하기 위해 사용

       - 테스트를 수행하는 사람이 작성된 소스코드를 이해하고 있어야만 분석이 가능

- 테스트 실행 도구

       - 스크립트 언어를 사용하여 테스트를 실행하는 방법

       - 테스트 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행하는 방식

       - 키워드 주도 접근 방식 : 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행하는 방식

- 성능 테스트 도구

       - 애플리케이션의 처리량, 응답 시간 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인

- 테스트 통제 도구

       - 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구로, 종류에는 형상 관리 도구, 결함 추적/관리 도구 등이 있다.

- 테스트 하네스 도구

       - 테스트 하네스는 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위해 생성된 코드와 데이터를 의미한다.

       - 테스트 하네스 도구는 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 한다.

 

5. 테스트 하네스의 구성 요소

- 테스트 드라이버 : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구

- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈

- 테스트 슈트 : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합

- 테스트 케이스 : 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서

- 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서

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

 

6. 테스트 수행 단계별 테스트 자동화 도구

- 요구사항 관리, 테스트 케이스 생성, 테스트 자동화, 정적 분석, 동적 분석, 성능 테스트, 모니터링, 커버리지 분석, 형상 관리, 결함 추적/관리

 

핵심

- 테스트 스텁은 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈

- 테스트 드라이버는 테스트 대상 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출한다.

---

57. 결함 관리 ★★

1. 결함(Fault)의 정의

- 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것

 

2. 결함 관리 프로세스

- 결함 관리 계획 -> 기록 -> 검토 -> 수정 -> 재확인 -> 결함 상태 추적 및 모니터링 활동 -> 최종 결함 분석 및 보고서 작성

 

3. 결함 상태 추적

- 테스트에서 발견된 결함은 지속적으로 상태 변화를 추적하고 관리해야 한다.

- 발견된 결함에 대해 결함 관리 측정 지표의 속성 값들을 분석하여 향후 결함이 발견될 모듈 또는 컴포넌트를 추정할 수 있다.

- 결함 관리 측정 지표 : 결함 분포(결함 수), 결함 추세(결함 수의 추이 분석), 결함 에이징(결함 지속 시간)

 

4. 결함 추적 순서

- 결함 등록 -> 검토 -> 할당 -> 수정 -> 조치 보류 -> 종료 -> 해제

 

5. 결함 분류

- 시스템 결함 : 시스템 다운, 애플리케이션 작동 정지 등 주로 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함

- 기능 결함 : 사용자의 요구사항 미반영/불일치

- GUI 결함 : UI 비일관성, 데이터 타입의 표시 오류 등에서 발생된 결함

- 문서 결함 : 사용자의 요구사항과 기능 요구사항의 불일치로 인한 불완전한 상태의 문서 등 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함

 

6. 결함 심각도

- High : 핵심 요구사항 미구현, 더 이상 프로세스를 진행할 수 없도록 만드는 결함

- Medium : 부정확한 기능이나 데이터베이스 에러 등과 같이 시스템 흐름에 영향을 미치는 결함

- Low : 부정확한 GUI 및 메시지 등 시스템 흐름에는 영향을 미치지 않는 결함

 

7. 결함 우선순위

- 결함의 우선순위는 발견된 결함 처리에 대한 신속성을 나타내는 척도로, 결함의 중요도와 심각도에 따라 설정되고 수정 여부가 결정된다.

- 결함 우선순위는 결정적(Critical), 높음(High), 보통(Medium), 낮음(Low) 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류된다.

 

8. 결함 관리 도구

- Mantis : 결함 및 이슈 관리 도구로, 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적이 가능한 도구

- Trac : 결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구

- Redmine : 프로젝트 관리 및 결함 추적이 가능한 도구

- Bugzilla : 결함 신고 등 결함을 지속적으로 관리할 수 있는 도구로, 결함의 심각도와 우선순위를 정할 수 있다.

 

핵심

- 결함은 소프트웨어가 사용자의 기대치를 만족시키지 못해 변경이 필요한 것이다.

- 결함의 우선순위는 결함의 중요도와 심각도에 따라 결정된다.

- 결함 에이징은 결함 상태로 지속되는 시간을 측정한다.

- 결함 분포는 결함 수 측정, 결함 추세는 진행 시간에 따른 결함 수의 추이 분석이다.

---

58. 애플리케이션 성능 분석 ★

1. 애플리케이션 성능

- 애플리케이션 성능이란 사용자가 요구한 기능을 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도를 나타낸다.

- 애플리케이션 성능 지표 : 처리량, 응답 시간, 경과 시간, 자원 이용률(CPU 사용량)

 

2. 성능 테스트 도구

- 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구이다.

- JMeter : HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구 

- LoadUI : 서버 모니터링, HTTP, JDBC 등 다양한 프로토콜 지원

- OpenSTA : HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구

 

3. 시스템 모니터링 도구

- 시스템 자원의 사용량을 확인하고 분석하는 도구

- Scouter, Zabbix

 

4. 애플리케이션 성능 저하 원인 분석

- DB에 연결하기 위해 Connection 객체를 생성하거나 쿼리를 실행하는 애플리케이션 로직에서 많이 발생한다.

- 애플리케이션의 성능 저하 현상을 발생시키는 주요 요인은 다음과 같다.

- DB에 필요 이상의 많은 데이터 요청한 경우

- 데이터베이스의 락이 해제되기를 기다리면서 애플리케이션이 대기하거나 타임아웃된 경우

- 커넥션 풀의 크기를 너무 작거나 크게 설정한 경우

- 연결 누수, 불필요한 Commit

- 서버 소켓에 쓰기는 지속되나, 클라이언트에서 읽기가 수행되지 않는 경우

 

핵심

- 애플리케이션 성능 측정 지표 : 처리량, 응답 시간, 경과 시간, 자원 이용률

- 애플리케이션 성능 저하 원인

---

59. 애플리케이션 성능 개선 ★

1. 소스 코드 최적화

- 나쁜 코드를 배제하고, 클린 코드로 작성하는 것

- 클린 코드 작성 원칙 : 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화

 

2. 소스 코드 최적화 유형

- 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고, 크기를 작게 작성한다.

- 느슨한 결합 : 인터페이스 클래스를 이용하여 추상화된 자료구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화한다.

- 코딩 형식 준수 : 줄 바꿈 사용, 개념적 유사성 높은 종속 함수 사용, 호출하는 함수는 선배치, 호출되는 함수는 후배치, 지역 변수는 각 함수의 맨 처음에 선언

- 좋은 이름 사용 : 명명규칙을 정의하고 규칙에 맞는 이름 사용

- 적절한 주석문 사용 : 중요한 코드 강조할 때 주석 사용

 

3. 소스 코드 품질 분석 도구

- 정적 분석 도구와 동적 분석 도구로 나뉜다.

- 정적 분석 도구

       - 소스 코드를 실행하지 않고 결함을 확인하는 코드 분석 도구이다.

       - 애플리케이션 개발 초기의 결함을 찾는데 사용

       - 소스 코드에서 코딩의 복잡도, 모델 의존성, 불일치성 등을 분석할 수 있다.

- 동적 분석 도구

       - 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구

 

핵심

- 클린 코드 작성 원칙

- 정적 분석 도구 : 실행하지 않고 결함 확인, 코딩의 복잡도, 모델 의존성, 불일치성 등을 분석

- 동적 분석 도구 : 실행하여 결함 확인, 메모리 누수, 스레드 결함 등을 분석