[01 애플리케이션 테스트] ★★
01-1 애플리케이션 테스트 개념
: 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
1) 확인(Validation) : 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 (사용자의 입장에서)
2) 검증(Verification) : 소프트웨어가 기능을 정확히 수행하는지 (명세서에 맞게 구현 되었는지)
애플리케이션 테스트 실행 전, 소프트웨어 유형 분류 및 특성 정리
* 소프트웨어의 분류
상용 소프트웨어 - 산업 범용 소프트웨어(시스템 소프트웨어, 미들웨어, 응용 소프트웨어), 산업 특화 소프트웨어
서비스 제공 소프트웨어 - 신규 개발 소프트웨어, 기능 개선 소프트웨어, 추가 개발 소프트웨어, 시스템 통합 소프트웨어
01-2 애플리케이션 테스트의 필요성
-프로그램 실행 전 오류 발견, 예방 가능
-사용자의 요구사항이나 기대 수준을 만족 시키는지 반복적으로 테스트, 제품의 신뢰도↑
-개발 초기부터 테스트 계획 후 시작 -> 오류 발견 및 새로운 오류 유입 예방
01-3 애플리케이션 테스트의 기본 원리
- 완벽한 소프트웨어 테스팅은 불가 (잠재적 결함은 줄일 수 있지만 완전히는 어려움)
- 파레토(Pareto) 법칙 : 개발자의 특성, 애플리케이션의 기능적 특성으로 인해 특정 모듈에 결함이 집중(애플리케이션의 20%에 해당하는 코드에서 전체 80%의 결함이 발견됨)
- 동일한 테스트 케이스로 동일한 테스트 X / 테스트 케이스의 지속적인 보완 및 개선 필요
- 소프트웨어 특징, 테스트 환경, 테스터 역량 등 정황(context)에 따라 결과가 달라질 수 있다
- 오류-부재의 궤변(Absence of Errors Fallacy): 사용자의 요구사항을 만족시키지 못하면 소프트웨어의 품질이 높다고 말할수 없다
- 테스트 ↑, 위험↓ / 작은 부분에서 확대하며 진행 / 개발자와 관련없는 별도의 팀에서 수행
[02 애플리케이션 테스트의 분류] ★★
02-1 프로그램 실행 여부에 따른 테스트
1) 정적 테스트: 프로그램 실행 X, 명세서나 소스 코드 대상으로 분석하는 테스트 / 개발 초기에 결함 발견 가능, 개발 비용 ↓ (ex 워크스루, *인스펙션, 코드 검사)
*인스펙션: 워크스루의 발전된 형태, 품질 평가 및 개선 방법 제시
2) 동적 테스트: 프로그램 실행 O, SW 개발의 모든 단계에서 수행 가능 (ex 블랙박스 테스트, 화이트박스 테스트)
02-2 테스트 기반(Test Bases)에 따른 테스트
1) 명세 기반 테스트: 사용자의 요구사항을 빠짐없이 테스트 케이스에 반영 (ex 동등 분할, 경계 값 분석)
2) 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스 작성 (ex 구문 기반, 결정 기반, 조건 기반)
3) 경험 기반 테스트: 유사 소프트웨어나 기술에 대한 테스터의 경험을 테스트 케이스로 / 요구사항에 대한 명세가 불충분 or 테스트 시간에 제약이 있는 경우 효과적 (ex 에러 추정, 체크 리스트, 탐색적 테스팅)
02-3 시각에 따른 테스트
1) 검증(Verification) 테스트 : 개발자의 시각 / 제품의 생산 과정 테스트 / 명세서대로 완성 되었는지
2) 확인(Validation) 테스트 : 사용자의 시각 / 제품의 생산 결과 테스트 / 사용자의 요구사항대로 완성 되었는지
02-4 목적에 따른 테스트
1) 회복(Recovery) 테스트 : 시스템에 여러 결함을 주고 올바르게 복구 되는지 확인
2) 안전(Security) 테스트 : 시스템 보호 도구가 불법 침입으로부터 시스템을 잘 보호할 수 있는지 확인
3) 강도(Stress) 테스트 : 과도한 정보량이나 빈도를 부과해 과부화 시에도 잘 작동하는지 확인
4) 성능(Performance) 테스트 : 실시간 성능이나 전체적인 효율성 진단, 응답 시간과 처리량 확인
5) 구조(Structure) 테스트 : 내부의 논리적 경로 및 소스코드의 복잡도 평가
6) 회귀(Regression) 테스트 : 변경된 코드에 새 결함이 없는지 확인
7) 병행(Parallel) 테스트 : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터 입력 후 동일한 결과 출력하는지 비교
[03 테스트 기법에 따른 애플리케이션 테스트] ★★★
*내부 구조의 참조 여부에 따라 화이트박스 / 블랙박스 나뉨
03-1 화이트박스 테스트(White Box Test) *논리 키워드가 중요
: 원시 코드를 오픈 시킨 상태에서 코드의 논리적인 모든 경로 테스트
-구조적 테스트(설계된 절차 기반), 설계의 제어 구조 사용해 테스트 케이스 설계, 테스트 과정의 초기에 적용
-제품의 내부 요소들이 명세서에 따라 수행되고 충분히 실행되는지를 테스트
-모듈 안의 작동 직접 관찰 / 모든 문장을 한 번 이상 실행
-프로그램의 제어 구조에 따라 선택, 반복 등 분기점 부분들을 수행하고 논리적 경로 제어
03-2 화이트박스 테스트의 종류
1) 기초 경로 검사 : 대표적인 화이트박스 테스트 기법. 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성 측정, 측정 결과를 실행 경로의 기초 정의 지침으로 사용
2) 제어 구조 검사
- 조건 검사(Condition Testing) : 논리적 조건 초점 맞춘 테스트 케이스 설계 기법
- 루프 검사(Loop Testing) : 반복(Loop) 구조에 초점 맞춘 테스트 케이스 설계 기법
- 데이터 흐름 검사(Data Flow Testing) : 변수의 정의와 변수 사용의 위치에 초점 맞춘 테스트 케이스 설계 기법
03-3 화이트박스 테스트의 검증 기준
1) 문장 검증 기준(Statement Coverage) : 소스코드의 모든 구문이 한 번 이상 수행되도록 설계
2) 분기 검증 기준(Branch Coverage) : 모든 조건문이 한 번 이상 수행되도록 설계
3) 조건 검증 기준(Condition Coverage) : 모든 조건문의 True와 False가 한 번 이상 수행되도록 설계
4) 분기/조건 기준(Branch/Condition Coverage) : 모든 조건문과 각 조건문 안의 개별 조건식의 True, False가 한 번 이상 수행되도록 설계
*검증 기준(Coverage)의 종류
- 기능 기반 커버리지 : 실제 테스트가 수행된 기능 수 / 전체 기능 수
- 라인 커버리지 : 테스트 시나리오가 수행한 소스 코드의 라인 수 / 전체 라인 수
- 코드 커버리지 : 소스 코드의 구문, 분기, 조건 등 구조 코드 자체가 얼마나 테스트 되었는지 측정 (화이트박스 테스트에서 사용되는 분기, 조건 검증 기준은 코드 커버리지에 해당)
03-4 블랙박스 테스트(Black Box Test) *기능 키워드가 중요
: 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트 (기능 테스트)
- 사용자의 요구사항 명세에 따라 테스트, 부정확하거나 누락된 기능 또는 오류들을 발견하기 위해 테스트 과정의 후반부에 사용
03-5 블랙박스 테스트의 종류 (=명세 기반 테스트)
1) 동치 분할 검사(Equivalance Partitioning Testing) : 입력 자료에 초점을 맞춰 테스트 케이스 제작, 검사 = 동등 분할 기법 / 타당한 입력 자료와 타당하지 않은 입력 자료의 수가 균등하도록 테스트 케이스 작성, 해당 입력 자료에 맞는 결과가 나오는지 확인
2) 경계값 분석(Boundary Value Analysis) : 입력 자료에만 치중한 동치 분할 기법을 보완, 입력 조건의 경계값을 테스트 케이스로 선정 (경계값은 중간값보다 오류 발생 확률 높음)
3) 원인-효과 그래프 검사(Cause-Effect Graphing Testing) : 입력 데이터 간의 관계, 출력에 미치는 영향 체계적으로 분석, 그 중 효용성 높은 테스트 케이스 선정 후 검사
4) 오류 예측 검사(Error Guessing) : 다른 블랙박스 테스트로는 검출할 수 없는 오류 찾는 보충적 검사 기법 (=데이터 확인 검사)
5) 비교 검사(Comparison Testing) : 동일한 테스트 자료 제공, 동일한 결과가 출력되는지 검사
[04 개발 단계에 따른 애플리케이션 테스트] ★★
04-1 개발 단계에 따른 애플리케이션 테스트
-테스트 레벨: 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류한 것
-개발 단계에서부터 테스트를 수행하므로 코드 상의 오류, 요구 분석 오류, 설계 인터페이스의 오류 발견 가능
-V-모델 : 애플리케이션 테스트 & 소프트웨어 개발 단계
◀ V-모델
04-2 단위 테스트 (Unit Test)
: 코딩 직후 모듈이나 컴포넌트에 초점 맞춰 테스트
- 인터페이스, 외부적 I/O, 자료구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등 검사
- 사용자의 요구사항을 기반으로 한 기능성 테스트 최우선
1) 구조 기반 테스트 (주로 시행)
: 내부 구조 및 복잡도 (논리) 검증하는 화이트박스 테스트 시행 / 제어 흐름과 조건 결정이 목적
2) 명세 기반 테스트
: 목적 및 실행 코드 기반 (기능) 검증하는 블랙박스 테스트 시행 / 동등 분할과 경계값 분석이 목적
04-3 통합 테스트(Integration Test)
: 단위 테스트가 완료된 모듈 결합 -> 하나의 시스템으로 완성하는 과정의 테스트 / 상호작용 오류 검사
04-4 시스템 테스트(System Test)
: 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행 되는지
- 실제 사용 환경과 유사한 곳에서 테스트 해야함
1) 기능적 요구사항 : 블랙박스 테스트 시행
2) 비기능적 요구사항 : 화이트박스 테스트 시행
04-5 인수 테스트(Acceptance Test)
: 개발한 소프트웨어가 사용자의 요구사항 충족하는지
- 사용자가 직접 테스트하며, 문제가 없으면 프로젝트는 종류
1) 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부 확인
2) 운영상의 인수 테스트 : 시스템 인수 시 수행. 백업/복원 시스템, 재난 복구 등을 확인
3) 계약 인수 테스트 : 인수/검수 조건 준수 여부 확인
4) 규정 인수 테스트 : 정부 지침, 법규, 규정에 맞게 개발 되었는지 확인
5) 알파 테스트 : 개발자 앞에서 사용자가 행하는 테스트. 통제된 환경에서 진행되며 개발자가 문제점을 사용자와 함께 확인
6) 베타 테스트 : 사용자 선정하여 테스트. 개발자에 의해 제어되지 않은 상태에서 행해지고 문제점을 기록해 개발자에게 주기적으로 보고
[05 통합 테스트] ★★★
05-1 통합 테스트(Integration Test)
: 모듈 통합 과정에서 발생하는 결함 체크하는 테스트
1) 비점진적 통합 방식 : 단계적 통합 절차 X, 모든 모듈이 미리 결합된 프로그램 전체를 테스트 (ex 빅뱅 통합 테스트) / 규모가 작은 소프트웨어에 유리, 단시간에 가능 / 하지만 오류 발견 및 장애 위치 파악 어려움
2. 점진적 통합 방식 : 단계적 통합 절차 O, 하향식, 상향식, 혼합식 통합 방법이 있음 / 오류 수정이 용이하며 인터페이스와 관련된 오류를 완전히 테스트
*빅뱅 통합 테스트 : 모듈 간 상호 인터페이스 고려 없이 단위 테스트가 끝난 모든 모듈을 한번에 결합시켜 테스트함
05-2 하향식 통합 테스트(Top Down Integration Test)
: 상위 모듈 -> 하위 모듈 방향으로 통합하며 테스트
- 깊이 우선 통합법
- 넓이 우선 통합법
- 테스트 초기부터 사용자는 시스템 구조 확인 가능
- 절차
1) 주요 제어 모듈은 작성된 프로그램 사용, 주요 제어 모듈의 종속 모듈은 스텁(Stub)으로 대체 (*Stub: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구)
2) 깊이 우선 또는 넓이 우선 통합 방식에 따라 스텁들이 한번에 하나씩 실제 모듈로 교체됨
3) 모듈이 통합될 때마다 테스트 재실시
4) 오류 검출 위한 회귀 테스트(테스트 반복)
05-3 상향식 통합 테스트(Bottom Up Integration Test)
: 하위 모듈 -> 상위 모듈 방향으로 통합하며 테스트
- 하위 모듈부터 통합 및 테스트가 수행되어 스텁은 필요 X, 하나의 주요 제어 모듈과 관련 종속 모듈의 그룹인 클러스터 필요
- 절차
1) 하위 모듈을 클러스터(Cluster)로 결합
2) 상위 모듈에서 데이터의 입출력 확인 위해 더미 모듈인 드라이버 작성
3) 통합된 클러스터 단위로 테스트
4) 클러스터는 프로그램 구조의 상위로 이동, 결합 및 드라이버 대체
테스트 드라이버는 상향식 통합 테스트에, 테스트 스텁은 하향식 통합 테스트에서 필요
05-4 혼합식 통합 테스트
- 하위에서는 상향식 통합, 상위에서는 하향식 통합 -> 샌드위치식 통합 테스트 방법
05-5 회귀 테스팅(Regression Testing)
- 새로운 오류 검출 위한 반복 테스트
- 변경된 부분을 테스트 할 수 있고, 기능 변경에 의한 파급 효과가 큰 테스트 케이스 선정
[06 애플리케이션 테스트 프로세스] ★
06-1 애플리케이션 테스트 프로세스
: 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 테스트
1) 테스트 계획
2) 테스트 분석 및 디자인
3) 테스트 케이스 및 시나리오 작성
4) 테스트 수행
5) 테스트 결과 평가 및 리포팅
6) 결함 추적 및 관리
=> 테스트 계획서, 테스트 케이스(요구사항을 얼마나 준수했는지), 테스트 시나리오(테스트 케이스 동작 순서), 테스트 결과서가 산출
06-2 테스트 계획
: 프로젝트 계획서, 요구 명세서 등을 기반으로 테스트 목표 정의, 테스트 대상 및 범위 결정
- 테스트 대상 시스템 구조 파악, 조직 및 비용 산정, 시작 및 종료 정의
06-3 테스트 분석 및 디자인
: 테스트의 목적과 원칙 검토, 사용자의 요구사항 분석
- 테스트에 대한 리스크 분석 및 우선순위 결정
- 테스트 데이터(실제 데이터/가상 데이터), 테스트 환경, 테스트 도구 등을 준비
*실제 데이터 : 선행된 연산에 의해 만들거나 실제 운영되는 데이터를 복제한 것
*가상 데이터 : 스크립트를 통해 인위적으로 만든 것
06-4 테스트 케이스 및 시나리오 작성
: 테스트 케이스 설계 기법에 따라 테스트 케이스 작성 -> 검토 및 확인 -> 테스트 시나리오 작성
- 테스트용 스크립트 작성 (테스트의 실행 절차나 수행 방법 등을 컴파일 없이도 실행 가능한 스크립트 언어로 작성)
06-5 테스트 수행
: 환경 구축(하드웨어, 소프트웨어, 가상 시스템 등) 후 테스트 수행, 실행 결과 측정해 기록
06-6 테스트 결과 평가 및 리포팅
: 테스트 결과를 비교 분석해 테스트 결과서를 작성
- 테스트 결과서 : 결함 내용, 결함 재현 순서 등 결함 위주로
06-7 결함 추적 및 관리
: 테스트 수행 후 발생한 결함 추적하고 관리
- 동일 결함 발견 시 처리 시간 단축, 결함의 재발 막을 수 있음
- 에러 발견 -> 에러 등록(관리대장) -> 에러 분석(실제 결함 여부 분석) -> 결함 확정 -> 결함 할당 -> 결함 조치 -> 결함 조치 검토 및 승인
[07 테스트 케이스 / 테스트 시나리오 / 테스트 오라클] ★★
07-1 테스트 케이스(Test Case)
: 구현된 소프트웨어가 사용자의 요구사항 준수 했는지 확인 / 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서 (명세 기반 테스트의 산출물)
07-2 테스트 케이스 작성 순서
1) 테스트 계획 검토 및 자료 확보 : 시스템 요구사항과 기능 명세서 검토, 테스트 대상 시스템 정보 확보
2) 위험 평가 및 우선순위 결정 : 결함의 위험 정도에 따른 우선순위 결정
3) 테스트 요구사항 정의 : 테스트 대상 및 요구사항 재검토, 테스트 특성, 조건, 기능 분석
4) 테스트 구조 설계 및 테스트 방법 결정 : 절차, 장비, 도구, 테스트 문서화 방법 결정
5) 테스트 케이스 정의 : 요구사항에 따라 테스트 케이스 작성, 입력 값, 실행 조건, 예상 결과 작성
6) 테스트 케이스 타당성 확인 및 유지 보수 : 기능 또는 환경 변화에 따라 테스트 케이스 갱신, 테스트 케이스 유용성 검토
07-3 테스트 시나리오
: 테스트 케이스를 적용하는 순서에 따른 여러 테스트 케이스의 집합
- 테스트 순서에 대한 구체적 절차, 사전 조건, 입력 데이터 설정
07-4 테스트 시나리오 작성 시 유의 사항
- 시스템별, 모듈별, 항목별로 여러 개의 시나리오로 분리하여 작성
- 사용자의 요구사항과 설계 문서 등을 토대로 작성
- 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인 포함해서 작성
- 유스케이스(Use Case)(사용자 측면의 요구 사항) 간 업무 흐름이 정상적인지
- 개발된 모듈 또는 프로그램 간 연계가 정상적인지
07-5 테스트 오라클
: 테스트 결과가 올바른지 판단 위해 사전에 정의된 참 값을 대입해 비교함 (예상 결과 계산 및 확인)
- 제한된 검증 : 테스트 오라클은 모든 테스트 케이스에 적용 X
- 수학적 기법 : 테스트 오라클의 수학적 기법을 이용해 구할 수 있음
- 자동화 기능 : 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 자동화
07-6 테스트 오라클 종류
1) 참(True) 오라클 : 모든 테스트 케이스의 입력에 대한 결과를 제공, 주로 미션 크리티컬(단 한 번이라도 다운되면 치명적인 시스템)한 업무에 사용
2) 샘플링 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 결과 제공
3) 추정(Heuristic) 오라클 : 샘플링 오라클 + 나머지 입력 값들에 대해서는 추정으로 처리
4) 일관성 검사(Consistent) 오라클 : 애플리케이션의 변경이 있을 대, 테스트 케이스의 수행 전과 후의 결과가 동일한지 확인
[08 테스트 자동화 도구] ★
08-1 테스트 자동화의 개념
: 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함 -> 쉽고 효율적인 테스트 수행
- 휴먼 에러(Human Error) ↓, 테스트 품질 ↑, 테스트의 정확성 유지
08-2 테스트 자동화 도구의 장단점
- 장점 : 반복적인 작업 자동화해 인력 및 시간 ↓ / 다중 플랫폼 호환성, 소프트웨어 구성, 기본 테스트 등 향상된 테스트 품질 보장 / 요구사항을 일관성 있게 검증 / 테스트 결과에 대한 객관적 평가 기준 제공 / 결과를 그래프 등 다양하게 표시 / UI가 없어도 정밀 테스트 가능
- 단점 : 자동화 도구의 사용법에 대한 교육 및 학습 필요 / 프로세스 단계별로 자동화를 적용하기 위한 시간, 비용, 노력이 필요 / 비공개 상용 도구(특정 기업체 전용)의 경우 고가의 비용 추가
08-3 테스트 자동화 수행 시 고려사항
- 재사용, 측정이 불가한 테스트 프로그램 제외
- 용도에 맞는 적절한 도구 선택 (모든 테스트 과정을 자동화하기는 어려움)
- 자동화 도구의 환경 설정 및 습득 기간 고려
- 반드시 프로젝트 초기에 테스트 엔지니어 투입
08-4 테스트 자동화 도구의 유형
1) 정적 분석 도구(Static Analysis Tools)
- 프로그램을 실행하지 않고 분석하는 도구
2) 테스트 실행 도구(Test Execution Tools)
- 스크립트 언어를 사용해 테스트 실행, 테스트 데이터와 테스트 수행 방법이 포함된 스크립트 작성 후 실행
- 데이터 주도 접근 방식: 스프레드 시트에 테스트 데이터 저장 후 실행 / 다양한 테스트 데이터를 동일한 테스트 케이스로 반복 가능
- 키워드 주도 접근 방식: 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터 저장해 실행하는 방식 (키워드로 테스트를 정의함)
3) 성능 테스트 도구(Performance Test Tools) : 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트
4) 테스트 통제 도구(Test Control Tools) : 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구 (형상 관리 도구, 결함 추적/관리 도구)
5) 테스트 하네스 도구(Test Harness Tools) : 테스트를 지원하기 위해 생성된 코드와 데이터. 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분 / 테스트가 실행될 환경을 시뮬레이션
-Test Driver : 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후의 결과 도출
-Test Stub : 일시적으로 필요한 조건만을 갖고 있는 테스트용 모듈
-Test Suites : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스들의 집합
-Test Case: 사용자 요구사항을 준수했는지 확인 위한 입력 값, 실행 조건, 기대 결과로 만들어진 명세서
-Test Script : 자동화된 테스트 실행 절차에 대한 명세서
-Mock Object : 미리 사용자의 행위를 조건부로 입력하면 그 상황에 맞는 예정된 행위를 하는 객체
08-5 테스트 수행 단계별 테스트 자동화 도구
*테스트 수행 단계 : 테스트 계획 / 테스트 분석 및 설계 / 테스트 수행 / 테스트 관리
1) 테스트 계획 - 요구사항 관리 : 사용자의 요구사항 정의 및 변경 사항 관리
2) 테스트 분석 및 설계 - 테스트 케이스 생성 : 테스트 데이터 및 테스트 케이스 작성 지원
3) 테스트 수행 - 테스트 자동화 : 테스트의 효율성↑
4) 테스트 수행 - 정적 분석 : 코딩 표준, 런타임 오류 관리
5) 테스트 수행 - 동적 분석 : 시뮬레이션을 통해 오류 검출
6) 테스트 수행 - 성능 테스트 : 가상의 사용자 생성해 시스템 처리 능력 측정
7) 테스트 수행 - 모니터링 : CPU, Memory 등 시스템 자원 상태 확인 및 분석
8) 테스트 관리 - 커버리지 분석 : 테스트 완료 후 테스트의 충분성 여부 검증
9) 테스트 관리 - 형상 관리 : 테스트 수행에 필요한 도구 및 데이터 관리
10) 테스트 관리 - 결함 추적/관리 : 테스트의 결함 추적 및 관리 지원
[09 결함 관리] ★
09-1 결함(Fault)
: 오류 발생, 작동 실패 등 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것
- 예상 결과 ≠ 실행 결과, 업무 내용과의 불일치도 결함에 해당
09-2 결함 관리 프로세스 (발견한 결함의 처리 과정)
1) 결함 관리 계획 : 결함을 어떻게 관리할 것인지 계획
2) 결함 기록 : 테스터가 결함을 결함 관리 DB에 등록
3) 결함 검토 : 테스터, 프로그램 리더(책임자), 품질 관리(QA) 담당자가 결함 검토 후 개발자에게 전달
4) 결함 수정 : 개발자가 결함 수정
5) 결함 재확인 : 테스터가 수정 사항 확인 후 다시 테스트 수행
6) 결함 상태 추적 및 모니터링 활동 : 결함 관리 DB로 프로젝트별 결함 유형과 발생률을 대시보드나 게시판 형태로 볼 수 있도록 함
7) 최종 결함 분석 및 보고서 작성 : 결함에 대한 정보와 이해관계자들의 의견 반영한 보고서 작성 후 결함 관리 종료
09-3 결함 상태 추적
: 결함은 지속적인 상태 변화 추적 및 관리가 필요
- 결함 관리 측정 지표 : 결함 분포, 결함 추세, 결함 에이징
09-4 결함 추적 순서 (상태)
1) 결함 등록(Open) - 결함이 등록된 상태
2) 결함 검토(Reviewed) - 결함이 테스터, QA 담당자, 프로그램 리더 등에게 검토된 상태
3) 결함 할당(Assigned) - 문제 해결 담당자와 개발자에게 결함이 할당된 상태
4) 결함 수정(Resolved) - 개발자가 결함 수정을 완료한 상태
5) 결함 조치 보류(Deferred) - 결함 수정이 불가해 연기된 상태
6) 결함 종료(Closed) - 결함이 해결된 상태
7) 결함 해제(Clarified) - 결함이 아니라고 판명된 상태
09-5 결함 분류
1) 시스템 결함 - 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
2) 기능 결함 - 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함
3) GUI 결함 - 사용자 화면 설계에서 발생된 결함
4) 문서 결함 - 요구사항의 불일치 등 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함
09-6 결함 심각도
- High : 핵심 요구사항 미구현, 장시간 시스템 응답 지연, 시스템 다운 등 더 이상 프로세스 진행 불가한 결함
- Medium : DB 에러나 부정확한 기능 같은 시스템 흐름에 영향 미치는 결함
- Low : 에러 시 메시지 미출력 등 시스템 흐름에는 영향을 미치지 않는 결함
09-7 결함 우선순위
: 결함 처리에 대한 신속성을 나타내는 척도 / 결함의 중요도와 심각도에 따라 설정
- 심각도가 높다고 무조건 우선순위가 높은 것은 아니다
- Critical(결정적) > High(높음) > Medium(보통) > Low(낮음) or 즉시 해결, 주의 요망, 대기
09-8 결함 관리 도구
- Mantis : 결함 및 이슈 관리 도구 (단위별 작업 내용 기록 가능)
- Trac : 결함 추적, 결함 통합해 관리 가능한 도구
- Redmine : 프로젝트 관리 및 결함 추적이 가능한 도구
- Bugzilla : 결함 신고, 확인, 처리 등 결함을 지속적으로 관리 가능한 도구 / 결함의 심각도와 우선순위 지정
* 결함 에이징 : 특정 결함 상태로 지속되는 시간 측정
[10 애플리케이션 성능 분석] ★
10-1 애플리케이션 성능
: 사용자가 요구한 기능을 최소한의 자원을 사용해 최대한 많은 기능을 신속히 처리하는 정도
- 처리량(Throughput) : 일정 시간 내 애플리케이션이 처리하는 양
- 응답 시간(Response Time) : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지의 시간
- 경과 시간(Turn Around Time) : 애플리케이션에 작업을 의로한 시간부터 처리가 완료될 때까지 걸린 시간
- 자원 사용률(Resource Usage) : 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등
=> 애플리케이션의 성능 측정 지표
- 애플리케이션의 성능 분석 도구 : 성능 테스트 도구, 시스템 모니터링 도구
10-2 성능 테스트 도구
: 애플리케이션의 성능을 테스트 / 애플리케이션에 부하나 스트레스를 가해 애플리케이션의 성능 측정 지표를 점검
- JMeter : HTTP, FTP 등 프로토콜 지원하는 부하 테스트 도구 (Cross-Platform)
- LoadUI : 서버 모니터링, Drag&Drop 등 사용자 편리성이 강화된 부하 테스트 도구 (Cross-Platform)
- OpenSTA : HTTP, HTTPS에 대한 부하 테스트 및 생산품 모니터링 도구 (Windows)
10-3 시스템 모니터링 도구
: 애플리케이션이 실행되었을 때 시스템 자원의 사용량 확인, 분석
- 성능 저하의 원인 분석, 시스템 부하량 분석, 사용자 분석 등 시스템 안정적 운영 기능 제공
- Scouter : 인프라 통합 모니터링, 애플리케이션의 성능을 모니터링 및 통제하는 도구 (Cross-Platform)
- Zabbix : 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구 (Cross-Platform)
10-4 애플리케이션 성능 저하 원인 분석
: 애플리케이션 로직(애플리케이션을 DB에 연결하기 위한 Connection 객체 생성하거나 쿼리 실행)에서 많이 발생
- DB에 필요 이상의 많은 데이터를 요청한 경우
- DB Lock(한 사람이 사용하고 있으면 다른 사람이 사용할 수 없도록 잠금)의 해제를 기다리며 앱이 대기하거나 타임아웃 된 경우
- 커넥션 풀(DB와 연결된 커넥션이 필요할 때 풀에서 꺼내 사용 후 반환하는 기법)의 크기를 너무 작거나 크게 설정한 경우
- 미들웨어 사용 후 종료하지 않아 연결 누수가 발생 (사용 후 커넥션이 반납되지 않아 커넥션 풀이 지속적으로 줄어들음)
- 트랜잭션이 확정(Commit) 되지 않고 커넥션 풀에 반환됨 / 코드 오류로 인해 불필요한 Commit 발생
- 인터넷 접속 불량으로 인해 클라이언트가 정상적 읽기 불가
- 대량의 파일을 업로드 하거나 다운로드하여 처리 시간이 길어진 경우
- 트랜잭션 처리 중 외부 호출이 장시간 수행, 타임아웃됨
- 네트워크 관련 장비 간 데이터 전송 실패 / 데이터 전송 지연으로 데이터 손실 발생
[11 애플리케이션 성능 개선] ★★
11-1 소스 코드 최적화
: Bad Code 배제, Clean Code 작성
- 클린 코드(Clean Code) : 단순 명료한 코드, 잘 작성된 코드
- 나쁜 코드(Bad Code) : 프로그램의 로직이 복잡하고 이해하기 어려운 코드, 스파게티 코드, 중복된 코드, 외계인 코드
- 클린 코드 작성 원칙: 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화
11-2 소스 코드 최적화 유형
- 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행 (응집도 ↑)
- 느슨한 결합(Loosely Coupled) : 인터페이스 클래스 이용해 의존성 최소화
- 코딩 형식 준수
- 좋은 이름 사용
- 적절한 주석문 사용
11-3 소스 코드 품질 분석 도구
: 소스 코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구
- 정적 분석 도구 : 코드 실행 없이 코드를 분석함. 개발 초기의 결함 찾기, 개발 소스 코드의 품질 검증(개발 완료 시점), 동적 분석 도구로는 찾지 못하는 어려운 결함 찾을 수 있음
- 동적 분석 도구 : 작성한 소스 코드 실행해 메모리 누수, 스레드 결함을 분석하는 도구
11-4 소스 코드 품질 분석 도구의 종류
- 정적 분석 도구 : pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura
- 동적 분석 도구 : Avalanche, Valgrind
'정처기' 카테고리의 다른 글
| [2과목] 5. 인터페이스 구현 (0) | 2021.02.02 |
|---|