정보처리기사 요점정리 - 2. 소프트웨어 개발 (애플리케이션 테스트 관리) (2)

대표 이미지 애플리케이션 테스트 관리

 

테스트 자동화 도구

 

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

-. 테스트 자동화 도구는 테스트를 수행하는 유형에 따라 다음과 같이 분류된다.

 

1) 정적 분석 도구(Static Analysis Tools)

-. 프로그램을 실행하지 않고 분석하는 도구로, 소스 코드에 대한 코딩 표준, 코딩 스타일, 코딩 복잡도 및 남은 결함 등을 발견하기 위해 사용된다. 테스트를 수행하는 사람이 작성된 소스 코드를 이해하고 있어야만 분석이 가능하다.

 

2) 테스트 케이스 생성 도구(Test Case Generation Tools)

-. 자료 흐름도 : 자료 원시 프로그램을 입력받아 파싱한 후 자료 흐름도를 작성한다.

-. 기능 테스트 : 주어진 기능을 구동시키는 모든 가능한 상태를 파악하여 이에 대한 입력을 작성한다.

-. 입력 도메인 분석 : 원시 코드의 내부를 참조하지 않고, 입력 변수의 도메인을 분석하여 테스트 데이터를 작성한다.

-. 랜덤 테스트 : 입력 값을 무작위로 추출하여 테스트한다.

 

3) 테스트 실행 도구(Test Execution Tools)

-. 스크립트 언어를 사용하여 테스트를 실행하는 방법으로, 테스트 주도 접근 방식(스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행하는 방식으로 다양한 테스트 데이터를 동일한 테스트 케이스로 반복하여 실행할 수 있다.)과, 키워드 주도 접근 방식(스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행하는 방식)이 있다.

 

4) 성능 테스트 도구(Performance Test Tools)

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

 

5) 테스트 통제 도구(Test Control Tools)

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

 

6) 테스트 하네스 도구(Test Harness Tools)

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

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

 

---

 

결함 관리

 

1. 결함(Fault)의 정의

-. 결함은 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것을 의미 한다.

 

2. 결함 관리 프로세스

결함 관리 프로세스

-. 결함 상태 추적 및 모니터링 활동 : 결함 관리 DB를 이용하여 프로젝트별 결함 유형, 발생률 등을 한눈에 볼 수 있는 대시보드 또는 게시판 현태의 서비스를 제공 한다.

 

3. 결함 심각도

-. 결함 심각도는 애플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 척도이다.

-. 결함심각도를 우선순위에 따라 분류 하면 다음과 같다.

① High : 핵심 요구사항 미구현, 장시간 시스템 응답 지연, 시스템 다운 등과 같이 더 이상 프로세스를 진행할 수 없도록 만드는 결함

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

③ Low : 부정확한 GUI 및 메시지, 에러 시 메시지 미출력, 화면상의 문법/철자 오류 등과 같이 시스템 흐름에 영향을 미치지 않는 결함

 

참고) 애플리케이션 성능
-. 사용자가 요구한 기능을 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도를 나타내며, 성능 측정 지표는 다음과 같다.
-. 처리량(Throughput) : 일정 시간 내에 애플리케이션이 처리하는 일의 양
-. 응답 시간(Response Time) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
-. 경과 시간(Turn Around Time) : 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때가지 걸린 시간
-. 자원 사용률(Resource Usage) : 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

 

---

 

복잡도(Complexity)

 

1. 복잡도의 개요

-. 복잡도(Complexity)는 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말로, 시스템 또는 소프트웨어를 어느 정도의 수준까지 테스트해야하는지 또는 개발하는데 어느 정도의 자원이 소요되는지 예측하는데 사용된다.

-. 주요 복잡도 측정 방법에는 LOC(Line Of Code), 순환 복잡도(Cyclomatic Complexity)등이 있다.

 

1) 시간 복잡도

-. 시간 복잡도는 알고리즘의 실행시간, 즉 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것을 의미한다. 시간 복잡도가 낮을수록 알고리즘의 실행 시간이 짧고, 높을수록 실행 시간이 길어진다.

-. 실행시간이 하드웨어적 성능이나 프로그래밍 언어의 종류에 따라 달라지기 때문에 시간이 아닌 명령어의 실행 횟수를 표기하는데, 이러한 표기법을 점근 표기법이라 한다.

 

① 점근 표기법의 예 : 빅오 표기법(Big-O Notation)

-. 알고리즘의 실행시간이 최악일 때를 표기하는 방법. 알고리즘에 대한 최악의 시간 복잡도를 빅오 표기법으로 표현하면 다음과 같다.

구분	내용
O(1)	입력값(n)에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거친다.
O(log_2n)	문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소한다.
O(n)	문제 해결에 필요한 단계가 입력값(n)과 1:1의 관계를 갖는다.
O(nlog_2n)	문제 해결에 필요한 단계가 n(log_2n)번 만큼 수행된다.
O(n^2)	문제 해결에 필요한 단계가 입력값(n)의 제곱만큼 수행된다.
O(2^n)	문제 해결에 필요한 단계가 2의 입력값(n) 제곱만큼 수행된다.

 

2) 순환 복잡도(Cyclomatic Complexity)

-. 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도. 제어 흐름도 이론에 기초를 둔다. 순환복잡도를 이용하여 계산된 값은 프로그램의 독립적인 경로의 수를 정의하고, 모든 경로가 한 번 이상 수행되었음을 보장하기 위해 행해지는 테스트 횟수의 상한선을 제공한다.

 

3) LOC(Line Of Code)

-. 소프트웨어의 개별적인 기능에 대해 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산출하는 기법

 

---

 

애플리케이션 성능 개선

 

1. 소스 코드 최적화

-. 소스 코드 최적화는 나쁜 코드(Bad Code)를 배제하고, 클린 코드(Clean Code)로 작성하는 것이다.

 

1) 나쁜 코드(Bad Code)

-. 프로그램의 로직(Logic)이 복잡하고 이해하기 어려운 코드. 코드의 로직이 서로 복잡하게 얽혀 있는 코드(스파게티 코드) 또는 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업어 어려운 코드(외계인 코드) 등이 해당된다.

 

2) 클린 코드(Clean Code)

-. 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉, 잘 작성된 코드를 의미한다.

-. 클린코드 작성 원칙

① 가독성 : 코드 작성 시 이해하기 쉬운 용어를 사용하거나 들여쓰기 등을 사용하여 누구든지 코드를 쉽게 읽을 수 있도록 작성한다.

② 단순성 : 한 번에 한 가지를 처리하도록 코드를 작성하고 클래스/메소드/함수 등을 최소 단위로 분리하여, 코드를 간단하게 작성한다.

③ 의존성 배제 : 코드 변경 시 다른 부분에 영향이 없도록 코드가 다른 모듈에 미치는 영향을 최소화 한다.

④ 중복성 최소화 : 중복된 코드는 삭제하고 공통된 코드를 사용하여, 코드의 중복을 최소화 한다.

⑤ 추상화 : 상위 클래스/메소드/함수에서는 간략하게 애프리케이션의 특성을 나타내고, 상세 내용은 하위 클래스/메소드/함수에서 구현한다.

 

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

-. 소스코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구로, 크게 정적 분석 도구와 동적 분석 도구로 나뉜다.

 

1) 정적 분석 도구

-. 비교적 애플리케이션 개발 초기의 결함을 찾는데 사용되고, 개발 완료 시점에서는 개발된 소스 코드의 품질을 검증하는 차원에서 사용된다.

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

 

2) 동적 분석 도구

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