본문 바로가기

자격증/정보처리기사 - 필기

소프트웨어 개발 - 애플리케이션 테스트 관리

728x90

애플리케이션 테스트 : 애플리케이션의 결함을 찾는 테스트

● 고객의 요구사항을 만족시키는지 확인

● SW가 기능을 정확히 수행하는지 검증

-> Validation( 확인 ) : 사용자의 입장으로 SW가 고객의 요구사항에 맞게 구현되었는지 확인

-> Verification( 검증 ) : 개발자의 입장으로 SW가 명세서에 맞게 만들어졌는지 검증

< 필요성 >

● 프로그램 실행 전 오류 발견하여 예방

< 기본 원리 >

● 완벽한 SW 테스팅 불가능

● 파레토 법칙 : 애플리케이션의 20%에 해당하는 코드에서 전체 80%의 결함이 발견

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

-> 살충제 패러독스 : 더 이상 결함이 발견되지 않음

● 오류-부재의 궤변 : SW의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 SW는 품질이 높다고 말할 수 없다.

 

정적 테스트

● 프로그램 실행하지 않고 소스 코드를 대상으로 분석

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

-> 워크스루 : SW 개발자의 작업 내역을 전문가들이 검토

-> 인스펙션 : SW 개발 단계에서 산출된 결과물의 품질을 평가

 

동적 테스트

● 프로그램 실행하여 SW 개발의 모든 단계에서 테스트 수행

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

 

명세 기반 테스트 : 요구사항에 대한 명세를 테스트 케이스로 만들어 구현 확인

구조 기반 테스트 : SW 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인

경험 기반 테스트 : 테스트 시간에 제약이 있는 경우 수행

회복 테스트 : 시스템에 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인

안전 테스트 : 침입으로부터 시스템을 보호할 수 있는지 확인

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

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

회귀 테스트 : 변경/수정된 코드에 새로운 결함이 없음을 확인

 

화이트박스 테스트

● 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스 설계  ● 테스트 과정의 초기에 적용

● 모듈 안의 작동을 직접 관찰  ● 모든 문장을 한 번 이상 실행

< 종류 >

● 기초 경로 검사 : 논리적 복잡성을 측정

● 제어 구조 검사

-> 조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트

-> 루프 검사 : 반복 구조에 초점을 맞춰 실시

-> 데이터 흐름 검사 : 변수 사용의 위치에 초점을 맞춰 실시

< 검증 기준 >

문장 검증 기준 : 모든 구문이 한 번 이상 수행

분기 검증 기준 : 모든 조건문이 한 번 이상 수행

조건 검증 기준 : 모든 조건문에 대해 조건이 True/False인 경우가 한 번 이상 수행

분기/조건 기준 : 각 조건문에 포함된 개별 조건식의 결과가 True/False인 경우가 한 번 이상 수행

 

블랙박스 테스트

● 각 기능이 완전히 작동되는 것을 입증  ● 기능 테스트

● SW 인터페이스에서 실시  ● 테스트 과정의 후반에 적용

< 종류 >

동치 분할 검사 : 타당한/타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력에 맞는 결과가 출력되는지 확인

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

원인-효과 그래프 검사

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

비교 검사 : 여러 버전의 프로그램에 동일한 자료를 제공하여 동일한 결과인지 비교

 

테스트 단계

1. 단위 테스트 : 모듈이나 컴포넌트에 초점을 맞춰 테스트

2. 통합 테스트

-> 모듈/컴포넌트 간 상호 작용 오류 검사

3. 시스템 테스트

-> 실제 사용 환경과 유사하게 만든 테스트 환경에서 수행

4. 인수 테스트

-> 사용자가 직접 테스트

-> 알파 테스트

● 사용자가 개발자 앞에서 하는 수행

-> 베타 테스트

● 사용자가 여러 명의 사용자 앞에서 수행

 

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

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

< 절차 >

1. 주요 제어 모듈의 종속 모듈들은 스텁으로 대체

2. 깊이/넓이 우선 방식에 따라 스텁들이 한번에 하나씩 실제 모듈로 교체

3. 모듈 통합 시 테스트 실시

4. 회귀 테스트 실시( 새로운 오류가 발생하지 않음을 보장 )

 

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

● 클러스터 필요

< 절차 >

1. 하위 모듈들을 클러스터로 결합

2. 상위 모듈에서 더미 모듈인 드라이버 작성

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

4. 테스트 완료 시 클러스트는 상위로 이동하여 결합, 드라이버는 실제 모듈로 대체

 

애플리케이션 테스트 프로세스 : SW가 사용자의 요구대로 만들어졌는지, 결함 여부 테스트

< 단계 >

1. 계획

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

3. 테스트 케이스 및 시나리오 작성

● 테스트 케이스/시나리오, 테스트용 스크립트 작성

4. 테스트 수행

5. 테스트 결과 평가 및 리포팅 단계 : 결함 중점적 기록

6. 결함 추적 및 관리 단계

 

테스트 케이스 : SW가 사용자의 요구사항을 정확하게 준수했는지 확인

 

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

< 종류 >

참 오라클, 샘플링 오라클, 추정 오라클, 일관성 검사 오라클

 

테스트 자동화 : 테스트 절차를 스크립트 형태로 구현

● 휴먼 에러 줄임  ● 테스트의 정확성 유지

● 테스트 품질 향상  ● 비공개 사용 도구의 경우 고가의 추가 비용 필요

< 고려사항 >

● 재사용 및 측정이 불가능한 테스트 프로그램 제외

● 용도에 맞는 적절한 도구 선택

● 프로젝트 초기 테스트 엔지니어의 투입 시기를 계획

 

테스트 하네스 : 애플리케이션의 컴포넌트 및 모듈을 테스트

< 구성 요소 >

테스트 스텁 : 타 모듈의 기능을 수행

테스트 케이스 : 사용자의 요구사항을 정확하게 준수했는지 확인

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

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

 

결함 : SW가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것

● 결함 심각도 : 결함이 전체 시스템에 미치는 치명도

- High / Medium / Low

● 결함의 우선순위 : 결함의 중요도와 심각도에 따라 설정

- 심각도가 높다고 반드시 우선순위가 높은 것은 아니다.

< 결함 관리 프로세스 순서 >

1. 계획

2. 결함 기록 : 발견된 결함을 결함 관리 DB에 등록

3. 결함 검토 : 결함을 수정할 개발자에게 전달

4. 결함 수정

5. 결함 재확인

6. 결함 상태 추적 및 모니터링

7. 최종 결함 분석 및 보고서 작성

< 결함 추적 순서 >

1. 결함 등록

2. 결함 검토

3. 결함 할당 : 문제 해결 담당자에게 결함 할당

4. 결함 수정

5. 결함 조치 보류 : 결함의 수정이 불가능해 연기된 상태

6. 결함 종료

7. 결함 해제

 

애플리케이션 성능 : 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

< 측정 지표 >

● 처리량 : 일정 시간 내 처리하는 일의 양

● 응답 시간 : 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간

● 경과 시간 : 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간

● 자원 사용률 : 작업을 처리하는 동안의 CPU/메모리/네트워크 사용량

< 성능 테스트 도구 >

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

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

- OpenSTA : 부하 테스트 및 생산품 모니터링 도구

< 시스템 모니터링 도구 >

- Scouter : 튜닝에 최적화된 이프라 통합 모니터링 도구

- Zabbix : 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

< 성능 저하 주요 원인 >

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

● DB의 락이 해제되기를 기다리면서 애플리케이션이 대기하거나 타임아웃된 경우

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

● 미들웨어를 사용한 후 종료하지 않아 연결 누수가 발생한 경우

● 잘못 작성된 코드로 인해 불필요한 Commit이 자주 발생하는 경우