2과목 소프트웨어 개발 애플리케이션 테스트 관리 054 ~ 065
054. 애플리케이션 테스트
: 애플리케이션에 잠재되어 있는 결함을 찾아내는 절차.
- Validation 확인 : 소프트웨어가 고객 요구사항 만족하는지 (사용자 입장)
- Verification 검증 : 소프트웨어가 기능을 정확히 수행하는지 (개발자 입장)
- 결함은 특정 모듈에 집중되어 있다. (파레토 법칙 : 오류의 80%는 전체 모듈의 20%내에서 발견..)
- 살충제 패러독스 : 동일 테스트 케이스로 동일 테스트를 반복하면 결함 발견X > 테스트 케이스 지속적 보완 및 개선 필요.
- 오류-부재의 궤변 : 결함을 모두 제거해도 사용자 요구사항을 만족시키지 못하면 품질이 높다고 말할 수 없다.
- 테스트는 개발자 별도의 팀에서 수행.
055. 애플리케이션 테스트의 분류
1) 프로그램 실행 여부에 따른 테스트
- 정적 테스트 : 프로그램 실행 x (워크스루, 인스펙션, 코드검사)
- 동적 테스트 : 실행하여 오류 찾는다. (블랙박스, 화이트박스 테스트)
2) 테스트 기반에 따른 테스트
- 명세 기반 : 요구사항 명세
- 구조 기반 : 내부 논리 흐름에 따라
- 경험 기반 : 유사 소프트웨어나 기술 테스트 경험 기반.
3) 시각에 따른 테스트
- 검증 테스트 (Verification : 개발자의 시각
- 확인 테스트 (Validation) : 사용자의 시각
4) 목적에 따른 테스트
- 회복 테스트 : 결함 복구
- 안전 테스트 : 시스템 보호
- 강도 테스트 : 과부하 시에도 실행되는지
- 성능 테스트 : 실시간 성능/ 효율성
- 구조 테스트 : 내부 논리적 경로, 소스코드의 복잡도
- 회귀 테스트 : 변경/수정 코드에 결함 확인
- 병행 테스트 : 기존 소프트웨어 & 변경 소프트웨어 비교
056. 테스트 기법에 따른 애플리케이션 테스트
1) 화이트박스 테스트
: 모듈의 원시 코드를 오픈한 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스 설계>
- 모듈 안의 작동을 직접 관찰.
- 원시 코드의 모든 문장 실행.
- 기초 경로 검사 (Base Path Testing) : 절차적 설계의 논리적 복잡성 측정
- 제어 구조 검사 (Control Structure Testing) : 조건 검사/ 루프 검사/ 데이터 흐름 검사
- 검증 기준 : 문장 검증 기준, 분기 검증 기준(결정 검증 기준), 조건 검증 기준, 분기/조건 기준
2) 블랙박스 테스트
: 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트.
- 테스트 과정 후반부에 적용.
- 프로그램의 구조 고려X
- 동치 분할 검사(동치 클래스 분해) : 입력 자료에 초점 > 테스트 케이스(동치 클래스) 만들고 검사.
- 경계값 분석 : 입력 조건의 경계값을 테스트케이스로 선정
- 원인-효과 그래프 검사 : 입력데이터 간의 관계와 출력레 영향을 미치는 상황 분석
- 오류 예측 검사 : 과거의 경험이나 확인자의 감각으로 테스트
- 비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료 제공하여 동일 결과 출력되는지 테스트
057. 개발 단계에 따른 애플리케이션 테스트
V-모델
개발 단계 : 요구사항 > 분석 > 설계 > 구현
테스트 단계 : 단위 > 통합 > 시스템 > 인수
1) 단위 테스트 : 코딩 직후 소프트웨어 설계 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트.
- 인터페이스, 외부적 I/O, 자료구조, 독립적 기초 경로, 오류 처리 경로, 경계조건 등 검사.
- 주로 구조 기반 테스트(화이트박스 테스트/ 제어흐름, 조건 결정 테스트) 시행
cf) 명세 기반 테스트 (블랙박스 테스트/ 동등분할, 경계 값 분석 테스트)
- 발견 가능한 오류 : 알고리즘 오류에 따른 결과, 탈출구가 없는 반복문의 사용, 틀린 계산 수식에 의한 잘못된 결과
2) 통합 테스트 : 단위테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트.
3) 시스템 테스트 : 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검. > 기능적 요구사항/ 비기능적 요구사항으로 구분.
4) 인수 테스트(Acceptance test) : 개발된 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트. (사용자가 직접 테스트).
- 사용자 인수 테스트 : 사용자가 적절성 여부 확인
- 운영상의 인수 테스트 : 시스템 관리자가 인수 시 수행. (백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검)
- 계약 인수 테스트 : 계약상 인수/검수 조건 준수 여부.
- 규정 인수 테스트 : 정부 지침, 법규, 규정 에 맞게 개발 여부.
- 알파 테스트 : 사용자가 개발자 앞에서 행하는 테스트
- 베타 테스트 : 최종 사용자가 여러명의 사용자 앞에서 행하는 테스트 기법.
058. 통합 테스트
: 단위테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
- 비점진적 통합 방식 : 모든 모듈이 미리 결합되어 있는 프로그램 전체 테스트 (빅뱅 통합 테스트)
- 점진적 통합 방식 : 모듈 단위로 단계적으로 통합하며 테스트 (하향식, 상향식, 혼합식 통합 방식)
** 테스트 드라이버: 테스트 대상의 하위 모듈을 호출하는 도구.
** 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구. (일시적으로 필요한 조건만 가지고 있는 시험용 모듈)
1) 하향식 통합 테스트(Top down) : 상위 모듈에서 하위 모듈 방향으로 통합하며 테스트.
- 깊이 우선 통합법
- 넓이 우선 통합법
- 상위 모듈에서는 테스트 케이스를 사용하기 어려움.
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁으로 대체.
- 깊이 우선/넓이 우선 등 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
- 모듈이 통합될 때마다 테스트 실시
- 새로운 오류 발생하지 않음을 보증하기 위해 회귀 테스트를 실시.
2) 상향식 통합 테스트 (Bottom up) : 하위 모듈에서 상위 모듈 방향으로 통합하며 테스트.
- 하위 모듈들을 클러스터(Cluster)로 결합.
- 상위 모듈에서 데이터 입출력을 확인하기 위해 더미 모듈인 드라이버 작성.
- 통합된 클러스터 단위로 테스트
- 테스트 완료 > 클러스터는 프로그램 구조의 상위로 이동하여 결합/ 드라이버는 실제 모듈로 대체됨.
3) 혼합식 통합 테스트 : 하위 수준에서는 상향식 / 상위 수준에서는 하향식 통합 사용하여 최적의 테스트를 지원하는 방식.
4) 회귀 테스팅 (Regression testing) : 이미 테스트된 프로그램의 테스팅 반복. 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인.
059. 애플리케이션 테스트 프로세스
1) 테스트 계획 : 프로젝트 계획서, 요구명세서 등 기반으로 테스트 목표 정의, 테스트 대상 및 범위 결정. / 투입 조직 및 비용 산정 / 대상 시스템 구조 파악/ 시작 및 종료 조건 정의 / 테스트 계획서 작성
2) 테스트 분석 및 디자인 : 테스트 목적과 원칙 검토 & 사용자 요구사항 분석 / 리스크 분석 및 우선순위 결정 / 테스트 데이터, 테스트 환경, 테스트 도구 등 준비
3) 테스트 케이스 및 시나리오 작성 : 테스트 케이스 작성, 검토 및 확인 > 테스트 시나리오 작성 (테스트 스크립트 작성)
4) 테스트 수행 : 테스트 환경 구축 후 테스트 수행. (하드웨어, 소프트웨어, 가상 시스템)
5) 테스트 결과 평가 및 리포팅 : 결과 비교 분석하여 테스트 결과서 작성. (결함 내용, 결함 재현 순서)
6) 결함 추적 및 관리 : 에러 발견 > 에러 등록 > 에러 분석 > 결함 확정 > 결함 할당 > 결함 조치 > 결함 조치 검토 및 승인
060. 테스트 케이스/ 테스트 시나리오 / 테스트 오라클
1) 테스트 케이스 : 사용자의 요구사항을 정확히 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서.
- 테스트 계획 검토 및 자료 확보 > 위험 평가 및 우선순위 결정 > 테스트 요구사항 정의 > 테스트 구조 설계 및 테스트 방법 결정 > 테스트 케이스 정의 > 테스트 케이스 타당성 확인 및 유지 보수
2) 테스트 시나리오 : 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합. 적용하는 구체적인 절차를 명세한 문서.
- 시스템별, 모듈별, 항목별 등 여러 개의 시나리오 분리.
- 유스케이스 간 업무 흐름이 정상적인지를 테스트 할 수 있도록 작성.
3) 테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동.
- 제한된 검증 (모든 케이스에 적용 불가)
- 수학적 기법
- 자동화 가능
종류
- 참오라클 : 모든 케이스의 입력 값에 대해 기대하는 결과 제공 (항공기, 은행, 발전소 소프트웨어 등 )
- 샘플링 오라클 : 몇몇 케이스 입력 값들에만 기대하는 결과 제공
- 추정 오라클 : 몇몇 케이스 입력 값들에만 기대하는 결과 제공 + 나머지 입력 값들에 대해서는 추정으로 처리
(샘플링&추정 : 일반적인 업무, 게임, 오락 등에 사용)
- 일관성 검사 오라클 : 애플리케이션의 변경이 있을 때 테스트 케이스 수행 전과 후 결과 값이 동일한지 확인
061. 테스트 자동화 도구
: 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용.
- 테스트 자동화 도구 유형
1) 정적 분석 도구 : 프로그램 실행하지 않고 분석하는 도구.
2) 테스트 케이스 생성 도구 : 자료 흐름도 / 기능 테스트 / 입력 도메인 분석 / 랜덤 테스트
3) 테스트 실행 도구 : 스크립트 언어를 사용하여 테스트 실행.
4) 성능 테스트 도구 : 애플리케이션 처리량, 응답 시간, 경과 시간, 자원 사용률 등 인위적으로 적용한 가상의 사용자를 만들어 테스트 수행.
5) 테스트 통제 도구 : 테스트 계획 및 관리, 테스트 수행, 결함 관리 등 수행. (형상 관리 도구, 결함 추적/관리 도구)
6) 테스트 하네스 도구 : 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록.
- 테스트 드라이버 : 테스트 대상의 하위 모듈을 호출 & 매개 변수 전달 & 모듈 테스트 수행 후의 결과를 도출하는 도구
- 테스트 스텁 : 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
- 테스트 슈트 : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트케이스의 집합
- 테스트 케이스 : 입력 값, 실행조건, 기대 결과 등으로 만들어진 테스트 항목 명세서
- 테스트 스크립트 : 실행절차 명세서
- 목 오브젝트 : 사전에 사용자의 행위를 조건부로 입력해두면 그 상황에 맞는 예정된 행위를 수행하는 객체.
- 테스트 수행 단계별 테스트 자동화 도구
| 테스트 계획 | - 요구사항 관리 |
| 테스트 분석/설계 | - 테스트 케이스 생성 |
| 테스트 수행 | - 테스트 자동화 - 정적 분석 - 동적 분석 - 성능 테스트 - 모니터링 |
| 테스트 관리 | - 커버리지 분석 - 형상 관리 - 결함 추적/관리 |
062. 결함 관리
- 프로세스
1) 결합 관리 계획
2) 결함 기록
3) 결함 검토
4) 결함 수정
5) 결함 재확인
6) 결함 상태 추적 및 모니터링 활동
- 결함 상태 추적
- 순서 : 결함 등록 (open) > 결함 검토 (Reviewed) > 결함 할당 (Assigned) > 결함 수정(Resolved) > 결함 조치 보류 (Deferred) > 결함 종료(closed) > 결함 해제 (Clarrified)
- 결함 분류 : 시스템 결함 / 기능 결함 / GUI 결함 / 문서 결함
7) 최종 결함 분석 및 보고서 작성
- 결함 관리 도구 : Mantis / Trac / Redmine / Bugzilla
063. 애플리케이션 성능 분석
: 사용자가 요구한 기능을 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도.
- 지표 : 처리량(Throughput) / 응답 시간(Response Time) / 경과 시간 (Turn Around Time) / 자원 사용률 (Resource Usage)
- 성능 테스트 도구 : JMeter, LoadUI, OpenSTA
- 시스템 모니터링 도구 (시스템 자원의 사용량을 확인하고 분석) : Scouter, Zabbix
- 성능 저하 원인 : 애플리케이션을 DB에 연결하기 위해 Connection 객체를 생성하거나 쿼리를 실행하는 애플리케이션 로직에서 많이 발생.
- DB에 필요 이상의 많은 데이터 요청
- DB 락이 해제되기를 기다리면서 애플리케이션이 대기하거나 타임아웃된 경우
- 커넥션 풀의 크기를 너무 작거나 크게 설정한 경우
- JDBC나 ODBC 같은 미들웨어를 사용한 후 종료하지 않아 연결누수(Connection Leak)가 발생한 경우
- 트랜잭션이 확정(commit)되지 않고 커넥션 풀에 반환되거나 / 잘못 작성된 코드로 인해 불필요한 커밋이 자주 발생하는 경우
- 인터넷 접속 불량으로 인해 서버 소켓에 쓰기는 지속되나, 클라이언트에서 정상적인 읽기가 수행되지 않는 경우
- (** 소켓 : 프로세스 사이의 대화를 가능하게 하는 쌍방향 통신 방식) (**서버 소켓 : 요청을 받아들이는 소켓)
- 대량의 파일을 업로드/다운로드 하여 처리시간이 길어진 경우
- 트랜잭션 처리 중 외부 호출이 장시간 수행되거나 타임아웃된 경우
- 네트워크 장비 간 데이터 전송 실패 / 전송 지연으로 인해 데이터 손실이 발생한 경우.
064. 복잡도
: 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말.
- 시간 복잡도 : 알고리즘의 실행시간, 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것!!
- 낮을수록 실행시간이 짧다.
- 시간이 아닌 명령어의 실행횟수를 표기함
- > 점근 표기법 (빅오 표기법(실행시간 최악일 때 표기), 세타 표기법(실행시간 평균일 때 표기), 오메가 표기법(실행시간 최상일 때))
- 빅오 표기법 : 실행시간 최악일 때 표기
| O(1) | 입력값(n)에 관계 없이 일정하게 하나의 단계만 거친다. - 스택의 push, pop |
| O(log n) | 문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소한다. 데이터가 두배 증가할 때마다 한 단계씩 늘어나는 알고리 - 이진트리, 이진 검색 |
| O(n) | 단계가 입력값(n)과 1:1 관계를 가진다 - for문 |
| O(n log n) | n(log n)번만큼 수행 - 힙 정렬, 2-Way 합병 정렬 |
| O(n^2) | 단계가 입력값(n)의 제곱만큼 수행 - 선택 정렬, 쉘 정렬, 삽입 정렬, 버블정렬, 퀵정렬 |
| O(2^n) | 2의 입력값(n) 제곱만큼 수행 - 피보나치 수열 |
- 순환 복잡도 (Cyclomatic Complexity) : 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도.
프로그램의 독립적인 경로의 수를 정의 / 모든 경로가 한 번 이상 수행되었음으로 보장하기 위해 행해지는 테스트 횟수의 상한선 제공
V(G) 순환 복잡도 = E 화살표 수 - N 노드의 수 + 2
065. 애플리케이션 성능 개선
- 소스 코드 최적화 : 나쁜 코드 배제, 클린 코드로 작성
- 클린 코드 작성 원칙 :
- 가독성
- 단순성
- 의존성 배제
- 중복성 최소화
- 추상화 : 상위 클래스/메서드/함수에서는 간략하게 애플리케이션의 특성을 나타내고, 상세 내용은 하위 클래스/메서드/함수에서 구현
- 나쁜 코드
- 스파게티 코드 : 로직이 서로 복잡하게 얽혀있는 코드
- 외계인 코드 : 아주 오래되거나 참고문서/개발자가 없어 유지보수 작업이 어려운 코드
- 소스코드 최적화 유형
- 클래스 분할 배치 (응집도를 높이고/ 크기를 작게)
- 느슨한 결합 (인터페이스 이용하여 추상화된 자료구조/메서드 구현)
- 코딩 형식 준수 (줄바꿈/ 종속 함수/ 호출 함수 선배치 / 지연변수 맨 처음에 선언)
- 좋은 이름 사용
- 적절한 주석문 사용
- 소스코드 품질 분석 도구 : 소스코드 코딩 스타일, 코딩 표준, 코드 복잡도, 메모리 누수 현상, 스레드 결함 등 발견하기 위해 사용하는 분석 도구
- 정적 분석 도구 (실행 X) : pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura
- 동적 분석 도구 (실행 O) : Avalanche, Valgrind