정처기 필기 요약 - 애플리케이션 테스트 관리

애플리케이션 테스트

애플리케이션에 잠재된 결함을 찾아내는 과정

확인 (Validation) : 개발된 소프트웨어가 요구사항을 만족시키는지 사용자의 입장에서 확인

검증 (Verification) : 기능을 제대로 수행하고 명세서에 맞게 만들었는지 개발자의 입장에서 점검

테스트 전 개발한 소프트웨어의 유형을 분류하고 특성을 정리해서 중점적으로 테스트할 사항을 정리

 

애플리케이션 테스트의 필요성

미리 오류를 발견하고 새로운 오류의 유입 예방

사용자의 요구사항에 만족하는지 테스트해 제품의 신뢰도 향상

 

애플리케이션 테스트의 기본 원리

잠재적인 결함을 줄일 수 있지만 소프트웨어 자체 결함이 없다곤 할 수 없음

결함은 특정 모듈에 집중되어 있어 애플리케이션의 20%에 해당하는 코든에서 80%의 결함이 발견된다고 하여 파레토 법칙을 적용하기도 함

살충제 패러독스 현상을 방지하기 위해 테스트 케이스를 지속적으로 보완 및 개선

테스트를 정황에 따라 다르게 진행

결함을 모두 제거해도 사용자의 요구사항을 만족할 수 없으면 안 됨

작은 부분에서 시작해서 점점 확대하며 진행

 

 

애플리케이션 테스트의 분류

 

프로그램 실행 여부에 따라

- 정적 테스트

프로그램을 실행하지 않고 소스코드나 명세서를 분석하여 테스트

개발 초기에 결함을 발견할 수 있어 비용이 절감

워크 스루, 인스펙션, 코드 검사 등

 

- 동적 테스트

프로그램을 실행하여 테스트

개발의 모든 단계에서 진행

블랙박스 테스트, 화이트 박스 테스트

 

테스트에 따라 

- 명세 기반 테스트

사용자의 요구사항을 테스트 케이스로 만들어 구현하고 있는지 확인하여 테스트

동등 분할, 경계 값 분석

- 구조 기반 테스트

소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 만들어 테스트

구문 기반, 결정 기반, 조건 기반, 결정 기반 등

- 경험 기반 테스트

테스터의 경험을 기반으로 테스트

요구사항에 대한 명세가 부족하거나 시간의 제약이 있는 경우

에러 추정, 체크 리스트, 탐색적 테스팅

 

시각에 따라

- 확인 테스트

사용자의 시각에서 결과를 테스트

요구사항을 만족하면서 정상적으로 동작이 되는지 테스트

- 검증 테스트

개발자의 시각에서 과정을 테스트

명세서에 맞게 완성되었는지 테스트

 

테스트의 목적에 따라

- 회복 테스트 : 결함을 주고 잘 복구되는지 테스트

- 안전 테스트 : 시스템 보호 도구가 불법적인 침입으로부터 보호할 수 있는지 테스트

- 강도 테스트 : 과부하 시 정상적으로 실행되는지 테스트

- 성능 테스트 : 응답 시간, 처리량 등을 테스트

- 구조 테스트 : 내부의 논리적인 경로, 소스 코드 복잡도 등을 평가

- 회귀 테스트 : 변경 혹은 수정에 따른 새로운 결함이 없는지를 테스트

- 병행 테스트 : 기존의 소프트웨어와 변경된 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트

 

 

동적 테스트

 

화이트 박스 테스트

모듈의 원시 코드를 오픈하여 논리적인 모든 경로를 한번 이상 실행하면서 테스트하여 테스트 케이스를 설계

테스트 과정의 초기에 진행

설계된 절차에 초점을 둔 구조적 테스트

모듈 안의 동작을 직접 관찰

 

화이트 박스 테스트의 종류

- 기초 경로 검사

테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법

테스트 측정 결과를 통해 실행 결로의 기초를 정의

- 제어 구조 검사

조건 검사 : 프로그램 내의 논리적 조건을 테스트

루프 검사 : 프로그램 내의 반복 구조에 초점을 맞춰 테스트

데이터 흐름 검사 : 프로그램 내의 변수의 정의와 사용의 위치에 초점을 맞춰 테스트

 

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

- 문장 검증 기준 : 모든 구문이 한 번 이상 수행되도록 설계

- 분기 검증 기준 : 모든 조건문이 한 번 이상 수행되도록 설계

- 조건 검증 기준 : 모든 조건문에 대해 참 / 거짓인 경우가 한번 이상 수행되도록 설계

- 분기 / 조건 기준 : 모든 조건문과 조건문에 포함된 개별 조건식의 결과가 참 / 거짓인 경우가 한번 이상 수행되도록 설계

 

블랙박스 테스트

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

테스트 과정의 후반부에 진행

사용자의 요구사항 명세를 보면서 구현된 기능을 테스트

소프트웨어 인터페이스에서 실시

 

블랙박스 테스트의 종류

- 동치 (동등) 분할 검사 : 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사

- 경곗값 분석 : 입력 조건의 경곗값을 테스트 케이스로 선정하여 검사

- 원인 - 효과 그래프 검사 : 입력 데이터 간의 관계와 출력의 영향을 미치는 상황을 분석 후 효용성이 높은 테스트 케이스를 선정하여 검사

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

- 비교 검사 : 여러 프로그램에 동일한 테스트 자료를 제공하여 동일한 출력이 나오는지 확인하는 검사

 

 

개발 단계에 따른 애플리케이션 테스트

 

단위 테스트

코딩 직후 모듈이나 컴포넌트에 초점을 맞춰 테스트

인터페이스, 외부적 I/O, 자료 구조 등을 검사

사용자의 요구사항을 기반으로 한 기능성 테스트를 최수선으로 수행

- 구조 기반 테스트 : 화이트 박스 테스트를 시행하여 제어 흐름이나 조건 결정을 목적으로 함

- 명세 기반 테스트 : 블랙박스 테스트를 시행하여 동등 분할이나 경곗값 분석을 목적으로 함

 

통합 테스트

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

모듈 간 또는 통합된 컴포넌트 간 상호 작용 오류 검사

 

- 비점진적 통합 방식

모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트

빅뱅 통합 테스트 방식

오류 발견 및 장애 위치 파악이 어려움

 

- 점진적 통합 방식

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

하향식 / 상향식 / 혼합식 테스트 방식

오류 수정이 용이하고 인터페이스 관련 오류를 완전히 테스트할 수 있음

 

* 하향식 통합 테스트

상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트

깊이 우선 통합법이나 넓이 우선 통합법 사용

상위 모듈에선 테스트 케이스 사용이 어려움

스텁 : 상위 모듈은 있지만 하위 모듈이 없는 경우 하위 모듈 대체

1. 1단계 : 주요 제어 모듈은 작성된 프로그램을 사용, 주요 제어 모듈의 종속 모듈들은 스텁으로 대체

2. 2단계 : 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 설계 모듈로 교체

3. 3단계 : 모듈이 통합될 때마다 테스트

4. 4단계 : 회귀 테스트 실시

 

* 상향식 통합 테스트

하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트

하나의 주요 제어 모둘과 종속 모듈의 그룹인 클러스터가 필요

드라이버 : 상위 모듈 없이 하위 모듈이 있는 경우 하위 모듈 구동

1. 1단계 : 하위 모듈을 클러스터로 결합

2. 2단계 : 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버를 작성

3. 3단계 : 통합된 클러스터 단위 테스트

4. 4단계 : 클러스터는 프로그램 구조의 상위로 이동하여 결합, 드라이버는 실제 모듈로 대체

 

* 혼합식 통합 테스트

하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원

샌드위치 통합 테스트

 

- 회귀 테스팅

이미 테스트된 프로그램의 테스팅을 반복

통합 테스트로 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인

 

시스템 테스트

개발된 소프트웨어가 원하는 환경에서 수행되는지 테스트

실제 환경과 유사하게 만든 테스트 환경에서 진행

- 기능적 요구사항 : 명세서 기반의 블랙박스 테스트

- 비기능적 요구사항 : 구조적 요소에 대한 화이트 박스 테스트

 

인수 테스트

개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트

사용자가 직접 테스트

- 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부 확인

- 운영상의 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행

- 계약 인수 테스트 : 계약상의 조건을 준수하는지 확인

- 규정 인수 테스트 : 규정에 맞게 개발되었는지 확인

- 알파 테스트 : 개발된 환경에서 사용자가 개발자 앞에서 수행

- 베타 테스트 : 사용자의 환경에서 사용자가 직접 테스트 수행

 

 

애플리케이션 테스트 프로세스

개발된 소프트웨어가 제대로 만들어졌는지 테스트하는 절차

테스트를 마치면 테스트 계획서, 케이스, 시나리오, 결과서가 산출

에러는 빨리 발견될수록 좋음

1. 테스트 계획 : 프로젝트 계획서 및 요구 명세서를 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위 결정

2. 테스트 분속 및 디자인 : 테스트의 목적과 원칙을 검토하는 사용자의 요구사항 분석

3. 테스트 케스트 및 시나리오 작성 : 테스트 케이스를 작성, 검토 및 확인 후 시나리오 작성

4. 테스트 수행 : 테스트 환경 구축 후 테스트 수행

5. 테스트 결과 평가 및 리포팅 : 테스트 결과를 분석하여 테스트 결과 작성

6. 결함 추적 및 관리 : 테스트 수행 후 결함이 어디에서 발생했고 어떤 결함인 추적하고 관리

 

 

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

 

테스트 케이스

사용자의 요구사항이 준수되었는지 확인하기 위해 테스트 항목에 대한 명세서

명세 기반 테스트의 설계 산출물

 

테스트 케이스 작성 순서

1. 테스트 계획 검토 및 자료 확보

2. 위험 평가 및 우선순위 결정

3. 테스트 요구사항 정의

4. 테스트 구조 설계 및 테스트 방법 결정

5. 테스트 케이스 정의

6. 테스트 케이스 타당성 확인 및 유지보수

 

테스트 시나리오

테스트 케이스를 적용하는 구체적인 절차를 명세한 문서

 

테스트 오라클

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

 

테스트 오라클의 특징

- 제한된 검증 : 모든 테스트 케이스에는 적용 불가

- 수학적 기법 : 수학적 기법을 통해 테스트 오라클 값을 구할 수 있음

- 자동화 기능 : 테스트 대상에 대한 실행, 결과  비교 등을 자동화할 수 있음

 

테스트 오라클의 종류

- 참 오라클 : 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공

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

- 추정 오라클 : 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고 나머지 값에 대해서는 추정으로 처리

- 일관성 검사 오라클 : 변경 시 테스트 케이스 수행 전과 후의 결과 값이 동일한지 확인

 

 

테스트 자동화 도구

반복적인 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용하여 쉽고 효율적으로 테스트 수행

 

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

장점

- 반복적인 작업을 자동화해 인력 및 시간 절감

- 향상된 테스트 품질 보장

- 사용자의 요구사항 등을 일관성 있게 검증

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

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

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

 

단점

- 사용방법에 대한 교육 및 학습 필요

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

 

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

- 모든 과정이 아닌 그때그때 맞는 적절한 도구를 선택

- 자동화 도구를 고려하여 프로젝트 일정 계획

- 프로젝트 초기에 테스트 엔지니어 투입 시기 계획

 

테스트 자동화 도구의 유형

- 정적 분석 도구 : 프로그램을 실행하지 않고 소스 코드를 통해 결함을 발견

- 테스트 실행 도구 : 스크립트 언어를 사용하여 테스트를 실행

- 성능 테스트 도구 : 가상의 사용자를 만들어 테스트를 수행

- 테스트 통제 도구 : 테스트 계획 및 관리, 수행, 결함 관리 등을 수행

- 테스트 하네스 도구

: 테스트가 실행될 환경을 시뮬레이션하여 컴포넌트 및 모듈이 정상적으로 테스트하도록 함

테스트 하네스 도구의 구성요소 : 테스트 드라이버, 테스트 스텁, 테스트 슈트, 테스트 케이스, 테스트 스크립트, 목 오브젝트

 

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

테스트 계획 단계 : 요구사항 관리 도구

테스트 분석 및 설계 단계 : 테스트 케이스 생성 도구

테스트 수행 단계 : 테스트 자동화 / 정적 분석 / 동적 분석 / 성능 테스트 / 모니터링 도구

테스트 관리 단계 : 커버리지 분석 / 형상 관리 / 결함 추적 및 관리 도구

 

 

결함 관리

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

 

결함 관리 프로세스

애플리케이션 테스트에서 발견된 결함을 처리

.......

 

결함 상태 추적

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

- 결함 분포 : 특정 속성에 해당하는 결함 수 측정

- 결함 추세 : 시간에 따른 결함 수의 추이 분석

- 결함 에이징 : 결함 상태로 지속되는 시간 측정

 

결함 추적 순서

결함이 발견되고 해결될 때까지의 과정

1. 결함 등록

2. 결함 검토

3. 결함 할당

4. 결함 수정

5. 결함 조치 보류

6. 결함 해제

 

결함 분류

- 시스템 결함 : 주로 애플리케이션이나 데이터 베이스 처리에서 발생된 결함

- 기능 결함 : 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함

- GUI 결함 : 화면 설계에서 발생된 결함

- 문서 결함 : 기획자, 사용자, 개발자 간 의사소통 및 기록이 원활하지 않아 발생된 결함

 

결함 심각도

결함이 전체 시스템이 미치는 치명도를 High, Medium, Low로 나눔

 

결함 우선순위

발견된 결함 처리에 대한 신속성을 나타내는 척도

결함의 중요도와 심각도에 따라 설정되고 수정 여부 결정

Critical, High, Medium, Low 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류

 

결함 관리 도구

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

Trac : 결함 추적 및 통합 관리 도구

Redmine : 프로젝트 관리 및 결함 추적 도구

Bugzilla : 결함을 지속적으로 관리하고 심각도와 우선순위를 지정할 수 있는 도구

 

 

애플리케이션 성능 분석

 

애플리케이션 성능

사용자가 요구한 기능을 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

측정 지표 : 처리량, 응답 시간, 경과 시간, 자원 사용률

 

성능 테스트 도구

애플리케이션의 성능을 테스트하기 위해 부하나 스트레스를 가해 성능 특정 지표를 점검하는 도구

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

LoadUI : 사용자의 편리성이 강화된 부하 테스트 도구

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

 

시스템 모니터링 도구

애플리케이션 실행 중 시스템 자원의 사용량을 확인하고 분석하는 도구

성능 저하의 원인 / 시스템 부하량 / 사용자 분석과 같은 시스템을 안정적으로 운영할 수 있는 기능 제공

Scouter, Zabbix

 

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

애플리케이션을 DB에 연결하기 위해 커넥션 객체를 생성하거나 쿼리를 실행하는 애플리케이션 로직에서 자주 발생

 

 

애플리케이션 성능 개선

소스코드 최적화

나쁜 코드를 배제하고 클린 코드로 작성

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

 

소스 코드 최적화 유형

클래스 분할 배치, 느슨한 결합, 코딩 형식 준수, 좋은 이름 사용, 적절한 주석문 사용

 

 

 

 

 

추가자료 : yeolco.tistory.com/6

2020 ~ 2022 정보처리기사 필기 출제 기준