애플리케이션 테스트 관리

< 애플리케이션 테스트 >

애플리케이션의 결함을 찾아냄

● 확인( Validation ) : 고객의 요구사항에 맞게 구현되었는가

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

- 완벽한 테스트 불가능   - 결합 집중 : 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80% 발견

- 살충제 패러독스 : 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함 발생 안함

- 정황 의존 : 테스트는 정황에 따라 테스트 결과가 달라짐   - 오류-부재의 궤변

● 정적 테스트 : 프로그램 실행 X, 소스 코드 대상 분석

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

● 동적 테스트 : 프로그램 실행하여 오류 찾음, 개발 모든 단계에서 테스트 수행 가능

ex. 블랙박스/화이트박스 테스팅

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

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

ex. 동등 분할, 경계 값 분석

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

ex. 구문 기반, 결정 기반, 조건 기반

- 경험 기반 : 테스터의 경험을 기반으로 수행

ex. 에러 추정, 체크 리스트

● 목적에 따른 테스트

- 회복 : 여러 결함을 주어 실패하도록 한 후 올바르게 복구되는지

- 안전 : 불법적인 침입으로부터 시스템 보호 가능한지

- 강도 : 과부하

- 성능 : 실시간 성능이나 전체적인 효율성 진단

- 회귀 : 수정된 코드에 새로운 결함이 없음 확인

- 병행 : 변경된 SW와 기존 SW에 동일한 데이터 입력하여 결과 비교

 

< 화이트박스 테스트 >

코드의 모든 문장을 한 번 이상 실행, 테스트 초기에 적용

● 종류

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

- 제어 구조 검사 : 조건 검사( 논리적 조건 ), 루프 검사( 반복 구조에 초점 ), 데이터 흐름 검사( 변수 정의와 사용 위치 )

● 검증 기준

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

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

- 조건 검증 기준 : 조건이 T/F인 경우가 한 번 이상 수행

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

 

< 블랙박스 테스트 >

기능 테스트, 테스트 후반부에 적용

● 종류

- 동치 분할 검사 : 입력 자료에 초점, 해당 입력 자료에 맞는 결과가 출력 되는지 확인

- 경계 값 분석   - 원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황 분석

- 오류 예측 검사   - 비교 검사

 

< 소프트웨어 개발 단계 >

요구사항 - 분석 - 설계 - 구현

 

< 테스트 단계 >

1. 단위 : 최소 단위인 모듈이나 컴포넌트에 초점

2. 통합 : 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서 테스트, 통합된 컴포넌트 간 상호 작용 오류 검사

3. 시스템 : 실제 사용 환경과 유사하게 테스트

4. 인수 : 사용자가 직접 테스트

-> 알파 테스트 : 사용자가 개발자 앞에서 진행   -> 베타 테스트 : 사용자가 여러 사용자 앞에서 진행

 

< 하향식 통합 테스트 > - 점진적 통합 방식

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

● 스텁 : 일시적으로 필요한 조건만을 가진 시험용 모듈

● 순서 : 스텁 대체 - 스텁들이 하나씩 실제 모듈로 교체 - 모듈 통합 될때마다 테스트 실시 - 회귀 테스트

( 회귀 테스트 : 이미 테스트된 프로그램의 테스팅 반복 )

 

< 상향식 통합 테스트 > - 점진적 통합 방식

● 하위 모듈을 클러스터로 결합

● 클러스터 필요 : 하나의 주요 제어 모듈과 관련된 종속 모듈 그룹

● 드라이버 작성 : 더미 모듈

● 순서 : 클러스터로 결합 - 드라이버 작성 - 클러스터 단위로 테스트 - 클러스터는 상위로 이동하여 결합, 드라이버는 실제 모듈로 대체

 

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

● 순서 : 계획 - 분석/디자인 - 테스트 케이스/테스트 시나리오 작성 - 테스트 수행 - 결과 평가 - 결함 추적/관리

● 테스트 완료 시 테스트 케이스, 테스트 시나리오, 테스트 결과서 산출

● 결함 관리 순서 : 발견 - 등록 - 분석 - 확정 - 할당 - 조치 - 검토

 

< 테스트 케이스 >

구현된 SW가 요구사항을 준수했는지 확인

● 작성 순서 : 계획 검토 - 우선순위 결정 - 요구사항 정의 - 구조 설계 - 테스트 케이스 정의 - 타당성 확인/유지보수

 

< 테스트 시나리오 >

테스트 케이스들을 묶은 집합

 

< 테스트 오라클 >

테스트 결과가 올바른지 판단

ex. 참 오라클, 샘플링 오라클, 추정 오라클

 

< 테스트 자동화 >

휴먼 에러 줄임, 정확성 유지

● 유형

- 정적 분석 도구 : 프로그램 실행 X, 남은 결함 확인

- 테스트 실행 도구 : 테스트 데이터와 수행 방법이 포함된 스크립트 작성 후 실행

- 성능 테스트 도구 : 처리량, 응답 시간, 경과 시간을 인위로 적용한 가상의 사용자를 만들어 테스트

- 테스트 하네스 : 테스트를 지원하기 위해 생성된 코드와 데이터

● 테스트 하네스 구성요소

- 테스트 드라이버 : 하위 모듈 호출

- 테스트 스텁 : 타 모듈 기능 단순히 수행

- 테스트 슈트 : 테스트 케이스 집합

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

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

 

< 결함 >

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

● 결함 추적 순서 : 등록 - 검토 - 할당 - 수정 - 조치 보류 - 종료 - 해제

● 결함 처리 순서 : 관리 계획 - 기록 - 검토 - 수정 - 재확인 - 모니터링 - 보고서 작성

 

< 애플리케이션 성능 분석 >

성능 테스트 도구와 시스템 모니터링 도구로 나눠짐

● 성능 측정 지표

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

- 응답 시간 : 요청 전달부터 응답 도착까지 시간

- 경과 시간 : 작업 의뢰부터 처리 완료까지 시간

- 자원 사용률

● 분석 절차

1. 모니터링 도구 유형 파악

2. 점검 계획서 작성

3. 테스트 케이스 작성

4. 성능 테스트 수행

5. 결과 분석

6. 저하 요인 찾아 분석

 

< 소스 코드 최적화 >

● 클린 코드 : 누구나 쉽게 이해

-> 작성 원칙 : 가독성, 단순성, 중복성 최소화, 추상화

● 나쁜 코드 : 로직이 복잡, 이해하기 어려움

● 최적화 유형

- 느슨한 결합 : 클래스 간 의존성 최소화

- 코딩 형시 준수   - 좋은 이름 사용