[정보처리기사] 6강 어플리케이션 테스트 관리

 

1. 어플리케이션 테스트

어플리케이션에 잠재 되어 있는 결함을 찾아내고, 고객의 요구사항을 만족하는지 확인하는 활동

- 테스트의 기본 원리

완벽한 테스트는 불가능

결함 집중(=파레토 법칙) : 결함의 20%에 80%의 에러가 집중이 되어있다.

살충제 페러독스 : 동일한 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견 되지 않는다.

정황 의존 : 정황에 따라 테스트가 달라 질 수 있으니 정황에 따라 다르게 테스트를 수행 해야한다.

오류-부재의 궤변 : 오류는 없지만, 사용자의 요구 사항을 만족 시키지 못한다면 좋은 소프트웨어가 아니다.

 

2. 어플리케이션 테스트 분류

- 프로그램 실행 여부에 따른 테스트

정적 테스트 : 프로그램을 실행하지 않고 명세서나 코드를 대상으로 분석하는 테스트

-예시 : 워크스루, 인스펙션, 동료검토

동적 테스트 : 프로그램을 실행하여 오류를 찾는 테스트로, 모든 단계에서 테스트 가능하다.

-예시 : 블랙, 화이트 박스 테스트

 

- 테스트 기반에 따른 테스트

명세 기반 테스트 : 사용자의 요구사항에 대한 명세를 모두 테스트 케이스로 만들어 구현하고 있는지 확인

구조 기반 테스트 : 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트

경험 기반 테스트 : 테스터의 경험을 기반으로 수행하는 테스트

 

- 시각에 따른 테스트

검증 테스트: 개발자의 시각에서 재품의 생산 과정을 테스트 하는 것으로, 제품이 명세대로 개발되었는지

확인 테스트 : 사용자의 시각에서, 요구대로 그리고 정상적으로 완성되었는지

 

- 목적에 따른 테스트

회복테스트 : 여러 가지 결함을 주어 실패하게 한 후, 올바르게 복구 되는지를 점검

안전테스트 : 불법적인 침임으로부터 시스템을 보호 할 수 있는지를 점검

강도테스트: 시스템에 과도한 정보량이나 빈도를 부과하여, 과부하 시에도 정상적으로 작동하는지 점검

성능테스트 : 실시간 성능이나 효율성을 진단하는 테스트로, 소프트웨어 응답시간, 처리량을 점검

구조테스트 : 내부의 논리적인 경로, 소스 코드의 복잡성을 점검

회귀테스트 : 변경 또는 수정된 코드가 결함 없음을 점검

병행테스트 : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터 입력을 하여 결과를 점검

 

3. 테스트 기법에 따른 어플리케이션 테스트

- 화이트박스 테스트

원시코드를 오픈 시킨 상태에서 원시 코드의 논리적인 몯느 경로를 테스트하여 설계

설계된 절차에 초점을 둔 구조적 테스트로써, 프로시저 설계의 제어구조를 사용하여 설계한다.

원시 코드를 모두 한 번 이상 실행함으로써 수행한다.

-화이트 박스 테스트의 종류

기초 경로 검사 : 절차적, 논리적 복잡성을 측정 할 수 있게 해주는 테스트 기법

제어 구조 검사 : 조건 검사, 루프 검사, 데이터 흐름 검사

-화이트 박스 테스트의 검증 기준

문장 검증 기준 : 소스코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계

분기 검증 기준 : 소스코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계

조건 검증 기준 : 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계

분기/조건 기준 : 소스 코드의 모든 조건문과 각 조건문에 포함된개별 조건식의 결과가 rue인 경우와 False인 경우가 한 번이상 수행되도록 테스트 설계

 

- 블랙박스 테스트

소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트

부정확하거나 누락된 기능, 인터페이스 오류, 자료구조나 데이터 베이스 오류 등을 발견하기 위해, 테스트 후반부에 사용한다.

-블랙박스 테스트 종류

동치 분할 검사: 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사하는 방법

경계값 분석 : 입력 조건의 중간 값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용

원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로

오류 예측 검사 : 과거의 경험이나 확인자의 감각으로 하는 테스트

비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여, 동일한 결과가 출력되는지 테스트하는 기법이다.

 

 

4. 개발 단계에 따른 어플리케이션 테스트

 

- 단위 테스트

코딩 직후 소프트웨어 설계의 최소단위인 모듈에 초점을 맞춰 테스트 하는 것을 의미

-종류

구조 기반 테스트 : 프로그램 내부 구조 및 복잡도를 검증하는 화이트 박스 테스트 시행

명세 기반 테스트 : 목적 및 실행 코드 기반의 블랙 박스 테스트 시행

- 통합 테스트

단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성 시키는 과정에서의 테스트

 

- 시스템 테스트

개발된 소프트웨어가 해당 컴퓨터 시스테에서 완벽하게 수행되는가를 점검하는 테스트

기능적, 비기능적을 구분하여 각각을 만족하는지 테스트 해야한다.

 

- 인수 테스트

사용자의 요구 사항을 맞추는지에 중점을 두고 테스트한다.

 

5. 통합 테스트

- 종류

비점진적 통합 방식

미리 결합 되어 있는 프로그램 전체를 테스트 하는 방식으로, 주로 규모가 작은 소프트웨어에 유리하다.

점진적 통합 방식

모듈 단위로 단계적으로 통합하면서 테스트하는 방식.

하향식 통합 테스트

프로그램 상위모듈에서 하위 모듈 방향으로 통합하면서 테스트 하는 기법이다.

테스트 초기부터 사용자에게 구조를 보여줄 수 있다.

주요 제어 모듈은 작성된 프로그램을 사용하고 종속 모듈은 스텁으로 대체한다.

상향식 통합 테스트

하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법이다.

가장 하위 단계에서 부터 통합 및 테스트가 수행되므로 종속 모듈의 그룹인 클러스터가 필요하다.

1) 종속 모듈의 그룹을 클러스터로 결합 -> 2) 더미 모듈인 드라이버 작성 -> 통합된 클러스터 단위로 테스트 -> 4) 완료 되면 클러스터는 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체된다.

6. 어플리케이션 테스트 프로세스

테스트 계획 -> 분석 및 디자인 -> 케이스 및 시나리오 작성 -> 테스트 수행 -> 결과 평가 및 리포팅 -> 결함추적

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

- 테스트 케이스

구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계뙨 입력 값, 실행조건, 기대 결과등으로 구성된 테스트 항목에 대한 명세서로 명세 기반 테스트의 설계 산출물에 해당된다.

- 테스트 시나리오

테스트 케이스를 적용하는 순서에 따라여러 개의 테스트 케이스들을 묶은 집합

- 테스트 오라클

테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법

- 종류

참 오라클 : 모든 케이스의 입력 값에 대해 입력 값에 대해 기대하는 결과를 제공하는 오라클 -> 모든 오류 검출 가능

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

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

일관성 오라클 : 변경이 있을 때 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클이다.

 

8. 테스트 자동화 도구

- 장점

반복적인 작업을 자동화함으로써, 인력 및 시간을 줄일 수 있다.

사용자의 요구사항 등을 일관성 있게 검증 할 수 있다.

테스트 결과에 대한 객관적 평가 기준을 제시할 수 있다.

- 단점

테스트 자동화 도구에 대한 학습 및 교육이 필요하다.

고가의 추가 비용이 발생한다.

 

- 종류

정적 분석 도구 : 프로그램을 실행하지 않고 분석하는 도구로, 소스 코드에 대한 표준, 스타일 등을 통해 결함 등을 발견하기 위해 사용된다.

테스트 실행 도구 : 테스트를 실행하는 방법으로 테스트 데이터와 수행방법 등이 포함된 스크립트를 작성 한 후 실행된다.

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

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

테스트 하네스 도구 : 어플의 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위해 생성된 코드와 데이터를 의마한다. 하네스는 테스트가 실행될 환경을 시뮬레이션하여 컴포넌트의 동작여부를 테스트한다.

 

9. 어플 개선 조치사항 작성

테스트 커버리지

주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이며, 테스트의 정확성과 신뢰성을 향상 시키는 역할을 한다.

 

- 종류

기능 기반 커버리지 : 테스트 대상 어플의 전체 기능을 모수로 설정하고, 수행된 기능의 수를 측정

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

코드 커버리지 : 소스코드의 구문, 조건, 결정 등의 구조코드자체가 얼마나 테스트 되었는지를 측정하는 방법

- 코드 커버리지의 종류

구문 커버리지 : 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지

결정 커버리지 : 포르그램 내의 전체 결정문은 적어도 한 번은 참과 거짓의 결과로 수행하는 커버리지

조건 커버리지 :결정 명령문 내의 각 조건이 적어도 한 번은 참과 거짓으 ㅣ결과가 되도록 수행

결정/조건 커버리지 : 전체 조건식 뿐만 아니라 개별 조건식도 참, 거짓 한번씩 결과가 되도록 수행

변경조건/결정 커버리지 : 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상 시킨 커버리지

다중 조건 커버리지 : 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장하는 커버리지

 

결함도의 심각도별 분류

치명적 결함 : 기능이나 제품의 테스트를 완전히 방해하거나 못하게 하는 결함

주요 결함 : 기능이 기대와 많이 다르게 동작하거나 기능을 온전히 발휘하지 못함

보통 결함 : 제품이나 프로그램이 특정 기준을 만족하지 못하거나 전체에 영향을 주지 않는 부자연스러운 결함

경미한 결함 : 상요상의 불편함을 유발하는 결함

단순 결함 : 사소한 버그라고 하며, 기능에 영향을 주지 않는 결함

결함 우선 순위

결정적 : 24시간안에 즉시 수정, 전체적인 기능 마비

높음 : 중요한 결정이 수정되는 동안, 우선 순위의 결함은 종료 기준에 대한 테스트 활동을 하기 위해서 수정되어야 하는 동안 다음 후보가 됨

보통: 실패가 발생했을 떄 올바른 에러 메세지가 출력되지 않는 것과 같은 에러

낮음 : 디자인에 일부 강화하거나 사용자 경험을 향상 시키기 위한 작은 기능 구현에 대한 요청이 우선순위로 분류

 

10. 어플리케이션 성능 개선

- 처리 성능 측정 지표

처리량, 응답시간, 경과 시간 ,자원 사용률

-성능 개선 방법

Bad code [ 다른 개발자가 이해하기 어렵게 작성된 코드]

- 나쁜 코드의 유형

오염 : 비즈니스 기능을 수행하지 못하는 컴포넌트 존재

문서 부족 : 코드가 문서와 일치 x

의미 없는 이름 : 명확한 의미를 가지지 못하는 함수, 클래스, 변수

높은 결합도 : 클래스와 컴포넌트 간에 데이터와 컨트롤 흐름이 네트워크로 복잡하게 연결

 

-> Clean Code [ 가독성이 높고, 의존 & 중복 최소화 ]

- 클린 코드의 유형

의미 있는 이름

간결하고 명확한 주석

보기 좋은 배치

작은 함수

오류 처리