1. 애플리케이션 테스트 케이스 설계
🔷 소프트웨어 테스트
개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능과 성능, 사용성, 안정성 등을 만족하는지 확인하고, 노출되지 않은 숨어있는 소프트웨어의 결함을 찾아내는 활동
◼ 필요성
- 오류 발견
- 오류 예방
- 품질 향상
◼ 기본 원칙 ⭐
- 테스팅은 결함이 존재함을 밝히는 것
- 완벽한 테스팅은 불가능
- 개발 초기에 테스팅 시작
요르돈의 법칙 : 초기에 체계적인 테스트가 없으면 그 결과가 후반에 영향을 미쳐 비용이 커짐 - 결함 집중
파레토 법칙( Pareto Principle ) : 오류 80%는 전체 모듈의 20% 내에서 발견 - 살충제 패러독스
동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함
( 정기적 리뷰 + 개선 + 새로운 시각에서의 접근 필요 ) - 테스팅은 정황에 의존적
SW의 성격에 맞는 테스트 수행 - 오류 부재의 궤변
요구사항을 충족시켜주지 못한다면, 결함이 없어도 품질이 높다고 볼 수 없음
◼ 프로세스
- 테스트 계획
- 테스트 분석 및 디자인
- 테스트 케이스 및 시나리오 작성
- 테스트 수행
- 테스트 결과 평가 및 리포팅
◼ 산출물 #PBCSSSR
- 테스트 계획서 ( Test Plan )
- 테스트 베이시스 ( Test Basis )
- 테스트 케이스 ( Test Case )
- 테스트 슈트 ( Test Suites )
- 테스트 시나리오 ( Test Scenario )
- 테스트 스크립트 ( Test Script )
- 테스트 결과서 ( Test Results )
◼ 유형 ⭐
❐ 프로그램 실행 여부에 따른 분류
- 정적 테스트
- 실행 X, 구조 분석하여 논리성 검증
- 리뷰 ( Review )
- 정적 분석 ( Static Analysis )
- 동적 테스트
- SW 실행 O, 테스트를 수행하여 결함 검출
- 화이트 박스 테스트
- 블랙 박스 테스트
- 경험 기반 테스트
❐ 테스트 기법에 따른 분류
- 화이트 박스 테스트 ( White-Box Test ) #구결조 조변다 기제데
- 각 응용 프로그램의 내부 구조와 동작을 검사하는 SW 테스트
- 모듈 내부 테스트
- 유형- 구문 ( 문장 ) 커버리지 : 프로그램 내의 모든 명령문을 적어도 한 번 수행
- 결정 ( 선택 / 분기 ) 커버리지 : 결정 포인트 내의 전체 조건식이 적어도 한 번은 T와 F의 결과가 되도록 수행
- 조건 커버리지 : 결정 포인트 내의 개별 조건식이 적어도 한 번은 T와 F의 결과가 되도록 수행
- 조건/결정 커버리지 : 전체 조건식 + 개별 조건식
- 변경 조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 독립적으로 영향
- 다중 조건 커버리지 : 결정 조건 내 모든 개별 조건식의 가능한 모든 조합을 100% 보장
- 기본 경로 ( 경로 ) 커버리지 : 수행 가능한 모든 경로를 수행 (맥케이브 복잡도 : Edge - Node + 2)
- 제어 흐름 테스트 : 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트
- 데이터 흐름 테스트 : 제어 흐름 그래프에 데이터 사용현황 추가
- 블랙 박스 테스트 ( Black-Box Test ) #동경결상 유분페원비
- 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트 ( 기능 테스트 )
- 명세 테스트 라고도 부름
- 유형- 동등 분할 ( 동치 분할 / 균등 분할 / 동치 클래스 분해 ) 테스트 : 입력 데이터의 영역을 유사한 도메인별로 그룹핑하여 대푯값 테스트 케이스 도출
- 경곗값 분석 ( 한곗값 ) 테스트 : 등가 분할 후 경곗값에서 오류 발생 확률이 높으므로 경곗값을 포함하여 테스트 ( 최솟값 바로 위, 최대치 바로 아래 등 입력값의 극한 한계 )
- 결정 테이블 테스트 : 요구사항의 논리와 발생조건을 테이블 형태로 나열, 조건과 행위를 모두 조합
- 상태 전이 테스트 : 어느 한 상태에서 다른 상태로 전이 되는 경우의 수를 수행
- 유스케이스 테스트 : 프로세스 흐름을 기반으로 테스트케이스를 명세화
- 분류 트리 테스트 : SW의 일부 또는 전체를 트리구조로 분석 및 표현
- 페어와이즈 테스트 : 테스트 데이터 값들 간에 최소한 한 번씩 조합하여 테스트
- 원인-결과 그래프 테스트 : 그래프를 활용해 입력 데이터 간의 관계 및 출력에 미치는 영향 분석
- 비교 테스트 테스트 : 여러 버전의 프로그램에 같은 입력값을 넣어서 동일한 결과가 나오는지 테스트
❐ 테스트 시각에 따른 분류
- 검증 ( Verification ) : SW 개발 과정 테스트 ( 개발자 혹은 시험자 시각 )
- 확인 ( Validation ) : SW 결과 테스트 ( 사용자 시각 )
❐ 테스트 목적에 따른 분류
- 회복 테스트 ( Recovery Testing )
고의로 실패 유도 후, 정상적 복귀를 테스트하는 기법 - 안전 테스트 ( Security Testing )
불법적인 SW가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적인 결함을 미리 점검하는 기법 - 성능 테스트 ( Performance Testing )
사용자의 이벤트에 시스템이 반응하는 시간을 측정하는 기법- 부하 테스트 ( Load Testing )
시스템에 부하를 계속 증가시키면서 시스템의 임계점을 찾는 테스트
병목지점을 찾아 병목 현상을 제거하는 과정 반복 - 스트레스 테스트 = 부하 테스트 ( Stress Testing )
시스템 처리 능력 이상의 부하, 즉 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리 테스트 - 스파이크 테스트 ( Spike Testing )
짧은 시간에 사용자가 몰릴 경우 시스템의 반응 측정 테스트 - 내구성 테스트 ( Endurance Testing )
오랜 시간동안 시스템에 높은 부하를 가하여 시스템 반응 테스트
- 부하 테스트 ( Load Testing )
- 구조 테스트 ( Structure Testing )
시스템의 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트 기법 - 회귀 테스트 ( Regression Testing )
오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법 - 병행 테스트 ( Parallel Testing )
변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 기법
❐ 테스트 종류에 따른 분류
- 명세 기반 테스트 ( 블랙 박스 테스트 ) : 요구사항 명세서 기반
- 구조 기반 테스트 ( 화이트 박스 테스트 ) : SW 내부 논리 흐름에 따라 테스트 케이스 작성 & 확인
- 경험 기반 테스트 ( 블랙 박스 테스트 ) : 유사 SW 또는 기술 평가에서 테스터의 경험을 통대로 한, 직관 & 기술 능력 기반의 테스트 기법
🔷 정적 테스트 ⭐
◼ 리뷰
SW의 다양한 산출물에 존재하는 결함을 검출하거나, 프로젝트의 진행 상황을 점검하기 위한 활동 ( 전문가가 수행 )
- 관리 리뷰 ( Management Reiew ) : 프로젝트 진행 상황에 대한 전반적인 검토
- 기술 리뷰 ( Technical Review ) : 정의된 계획, 명세를 준수하는지 등에 대한 검토 ( 대표 엔지니어 & 관리자 참석 )
- 인스펙션 ( Inspection ) : 저작자 이외의 다른 전문가 또는 팀이 검토 ( = 동료검토 )
- 워크스루 ( Walk Throughs ) : 검토 자료를 회의 전에 배포한 후, 짧은 시간동안의 회의를 통해 검토
- 감사 ( Audit ) : 독립적으로 평가 ( SW 제품의 제공자, 소비자, FDQ와 같은 제 3기관 수행 가능 )
◼ 정적 분석
리뷰는 사람이 직접 수행하는 수작업 중심의 방법이지만, 정벅 분석은 도구의 지원을 박아 정적 테스트를 수행하는 방법
- 코딩 표준
- 복잡도 측정
- 자료 흐름 분석
🔷 동적 테스트 ⭐
◼ 화이트 박스 테스트 ( 구조 기반 테스트 ) #구결조 조변다 기제데
- 각 응용 프로그램의 내부 구조와 동작을 검사하는 SW 테스트
- 모듈 내부 테스트
- 구문 ( 문장 ) 커버리지 : 프로그램 내의 모든 명령문을 적어도 한 번 수행
- 결정 ( 선택 / 분기 ) 커버리지 : 결정 포인트 내의 전체 조건식이 적어도 한 번은 T와 F의 결과가 되도록 수행
- 조건 커버리지 : 결정 포인트 내의 개별 조건식이 적어도 한 번은 T와 F의 결과가 되도록 수행
- 조건/결정 커버리지 : 전체 조건식 + 개별 조건식
- 변경 조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 독립적으로 영향
- 다중 조건 커버리지 : 결정 조건 내 모든 개별 조건식의 가능한 모든 조합을 100% 보장
- 기본 경로 ( 경로 ) 커버리지 : 수행 가능한 모든 경로를 수행 (맥케이브 복잡도 : Edge - Node + 2)
- 제어 흐름 테스트 : 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트
- 데이터 흐름 테스트 : 제어 흐름 그래프에 데이터 사용현황 추가
◼ 블랙 박스 테스트 ( 명세 기반 테스트 ) #동경결상 유분페원비
- 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트 ( 기능 테스트 )
- 명세 테스트 라고도 부름
- 동등 분할 ( 동치 분할 / 균등 분할 / 동치 클래스 분해 ) 테스트 : 입력 데이터의 영역을 유사한 도메인별로 그룹핑하여 대푯값 테스트 케이스 도출
- 경곗값 분석 ( 한곗값 ) 테스트 : 등가 분할 후 경곗값에서 오류 발생 확률이 높으므로 경곗값을 포함하여 테스트 ( 최솟값 바로 위, 최대치 바로 아래 등 입력값의 극한 한계 )
- 결정 테이블 테스트 : 요구사항의 논리와 발생조건을 테이블 형태로 나열, 조건과 행위를 모두 조합
- 상태 전이 테스트 : 어느 한 상태에서 다른 상태로 전이 되는 경우의 수를 수행
- 유스케이스 테스트 : 프로세스 흐름을 기반으로 테스트케이스를 명세화
- 분류 트리 테스트 : SW의 일부 또는 전체를 트리구조로 분석 및 표현
- 페어와이즈 테스트 : 테스트 데이터 값들 간에 최소한 한 번씩 조합하여 테스트
- 원인-결과 그래프 테스트 : 그래프를 활용해 입력 데이터 간의 관계 및 출력에 미치는 영향 분석
- 비교 테스트 테스트 : 여러 버전의 프로그램에 같은 입력값을 넣어서 동일한 결과가 나오는지 테스트
◼ 경험 기반 테스트
- 유사 SW나 기술 평가에서 테스터의 경험을 토대로 하 ㄴ직관과 기술 능력을 기반으로 수행하는 테스트 기법
- 탐색적 테스트 : 테스트 스크립트 또는 테스트 케이스를 문서로 작성하지 않고, 경험에 바탕을 두고 탐색적으로 기능을 수행해 보면서 테스트하는 기법
- 오류 추정 : 개발자가 범할 수 있는 실수를 추정하고, 이에 따른 결함이 검출되도록 테스트 케이스를 설계하여 테스트하는 기법
- 체크리스트 테스트하고 평가해야할 내용과 경험을 분류하여 나열한 후 하나씩 확인하는 테스트 기법
- 특성테스트 : 품질 모델에 있는 품질 특성을 염두해두고, 경험적으로 테스트 케이스를 설계하고 작성하는 기법
🔷 테스트 케이스 ( Test Case )
특정 요구사항에 준수하는지 확인하기 위해 개발된 입력값, 실행조건, 예상된 결과의 집합
🔷 테스트 오라클
테스트의 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참값을 입력하여 비교하는 기법
- 참 ( True ) 오라클 : 모든 입력값에 대하여
- 샘플링 ( Sampling ) 오라클 : 특정한 몇 개의 입력값에 대해서만
- 휴리스틱 ( Heuristic ) 오라클 : 샘플링 오라클을 개선한 오라클 / 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱 ( 추정 )으로 처리하는 오라클
- 일관성 검사 ( Consistent ) 오라클 : 애플리케이션 변경이 있을 때, 수행 전과 후의 결괏값이 동일한지 확인하는 오라클
🔷 테스트 레벨 ( Test Level ) #단통시인
애플레케이션 테스트를 SW의 개발 단계에 따라 분류한 것
- 함께 편성되고 관리되는 테스트 활동
- 프로젝트에서 책임과 연관
- 서로 독립적
- 단위 테스트
- 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계
- 기법- 자료 구조 테스트
- 실행 경로 테스트
- 오류 처리 테스트
- 인터페이스 테스트
- 통합 테스트
- 단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계
- 기법- 빅뱅 테스트
- 샌드위치 테스트
- 상향식 테스트
- 하향식 테스트
- 시스템 테스트
- 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 단계
- 기법- 기능 요구사항 테스트 ( 블랙 박스 테스트 )
- 비기능 요구사항 테스트 ( 화이트 박스 테스트 )
- 인수 테스트
- 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트
- 기법- 계약 인수
- 규정 인수
- 사용자 인수
- 운영상의 인수
- 알파 테스트 : 선택된 사용자가 개발자 환경에서 통제된 상태로 개발자와 함께 수행하는 인수 테스트
- 베타 테스트 : 실제 환경에서 일정 수의 사용자에게 대상 SW를 사용하게 하고 피드백을 받는 인수 테스트
🔷 테스트 시나리오
테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서 / 테스트를 위한 절차를 명세한 문서
2. 애플리케이션 통합 테스트
🔷 단위 테스트
◼ 목 ( Mock ) 객체
객체지향 프로그램에서는 컴포넌트 테스트 수행 시 테스트 되는 메소드는 다른 클래스의 객체에 의존하는데,
이런 경우 메소드를 고립화하여 테스트하는 것이 불가능하므로 독립적인 컴포넌트 테스트를 위해서는 스텁의 객체지향 버전인 목(Mock) 객체가 필요
- 더미 객체 : 객체만 필요하고 기능까지는 필요하지 않은 경우
- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행 ( 하위 모듈 개념 )
- 테스트 드라이버 : 테스트 대상 하위 모듈 호출, 파라미터 전달 ( 상위 모듈 개념 )
- 테스트 스파이 : 테스트 대상 클래스와 협력하는 클래스
- 가짜 객체 : 실제 협력 클래스의 기능을 대체 할 경우 사용
🔷 통합 테스트
소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 기법
- 빅뱅 테스트 : 모든 모듈을 통합 후 테스트 수행
- 상향식 테스트 : 최하위 모듈부터 점진적으로 수행 ( 테스트 드라이버 )
- 하향식 테스트 : 최상위 모듈부터 하위 모듈 통합하며 수행 ( 테스트 스텁 )
- 샌드위치 테스트 : 상위는 하향식 + 하위는 상향식
🔷 테스트 자동화 도구
🔷 테스트 결과 분석
🔷 결함 관리
🔷 결함 추이 분석
🔷 데스트 커버리지
🔷 결함 식별 및 관리
3. 애플리케이션 성능 개선
🔷 애플리케이션 성능 분석
◼ 애플리케이션 성능 측정 지표
- 처리량 ( Throughput ) : 주어진 시간에 처리할 수 있는 트랜잭션의 수
- 응답 시간 ( Response Time ) : 사용자 입력이 끝난 후, APP의 응답 출력이 개시될 때까지의 시간
- 경과 시간 ( Turnaround Time ) : 사용자가 요구를 입력한 시점부터 트랜잭션을 처리 후 결과를 출력할 때까지 걸리는 시간
- 자원 사용률 ( Resource Usage ) : 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량
❐ 유형별 성능 분석 도구
- 성능 ( Performance ) / 부하 ( Load ) / 스트레스 ( Stress ) 점검 도구
- 모니터링 ( Monitoring ) 도구
❐ 성능 분석 도구 유형
-
성능 테스트 도구
- JMeter
- LoadUI
- OpenSTA
-
시스템 모니터링 도구
- Scouter
- Zabbix
◼ 애플리케이션 성능 저하 원인
❐ 데이터베이스 관련
- 데이터베이스 락 ( DB Lock )
- 불필요한 데이터베이스 패치 ( DB Fetch )
- 연결 누수 ( Connection Leak)
- 부적절한 커넥션 풀 크기 ( Connection Pool Size )
- 확정 ( Commit ) 관련
❐ 내부 로직
- 웹 애플리케이션의 인터넷 접속 불량
- 특정 파일의 업로드, 다운로드로 인한 성능 저하
- 정상적으로 처리되지 않은 올 처리로 인한 성능 저하
❐ 외부 호출 ( HTTP, 소켓 통신 )
- 외부 트랜잭션( 외부 호출 )의 장시간 수행
- 타임아웃 발생
❐ 잘못된 환경 설정 / 네트워크 문제
- 환경 설정으로 인한 성능 저하
- 네트워크 장비로 인한 성능 저하
◼ 애플리케이션 성능 테스트 프로세스
◼
🔷 애플리케이션 성능 개선
◼ 소스 코드 최적화
읽기 쉽고 변경 및 추가가 쉬운 클린 코드를 작성하는 것
소스 코드의 품질ㅇ르 위해 기본적으로 준수해야 할 원칙과 기준을 정의
❐ 배드 코드 ( Bad Code )
다른 개발자가 로직을 이해하기 어렵게 작성된 코드
-
사례
- 외계인 코드 ( Alien Code ) : 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수가 매우 어려운 코드
- 스파게티 코드 ( Spaghetti Code ) : 작동은 정상적으로 하나, 코드가 복잡하게 얽혀 가독성이 매우 떨어짐
- 알 수 없는 변수명 : 변수나 메소드의 이름 정의를 알 수 없는 코드
- 로직 중복 : 동일한 처리 로직이 중복되게 작성된 코드
-
유형
- 오염
- 문서 부족
- 의미 없는 이름
- 높은 결합도
- 아키텍처 침식
❐ 클린 코드 ( Clean Code )
잘 작성되어 가독성이 높고, 단순하며, 의존성을 줄이고, 중복을 최소화하여 깔끔하게 잘 정리된 코드를 말함
-
작성원칙
- 가독성
- 단순성
- 의존성 최소
- 중복성 제거
- 추상화
-
유형
- 의미있는 이름
- 간결하고 명확한 주석
- 보기 좋은 배치
- 작은 함수
- 읽기 쉬운 제어 흐름
- 오류 처리
- 클래스 분할 배치
- 느슨한 결합 ( Loosley Coupled ) 기법 활용
- 코딩 형식 기법 적용
◼ 소스 코드 품질분석
소스 코드에 대한 코딩 스타일, 설정된 코딩 표준, 복잡도, 메모리 누수 현황, 스레드의 결함 등을 발견하기 위한 활동
❐ 정적 분석 도구
애플리케이션 실행 X ( 소스 코드 자체만으로 분석 )
❐ 동적 분석 도구
애플리케이션 실행 O
◼ 애플리케이션 성능 개선 방안
🔷
◼
❐
⭐ 📝
