01 애플리케이션 테스트 케이스 설계
1. 애플리케이션 테스트
애플리케이션에 잠재 되어있는 결함을 찾아내는 일련의 행위 또는 절차
2. 애플리케이션 테스트원리
완벽한 테스팅은 불가능 | 결함을 줄일 수 있으나 결함이 없다고 증명할 수 없음 |
개발 초기에 테스팅 시작 | 요르돈의법칙 : 개발 초기에 테스팅 하지 않으면 비용이 커진다. |
파레토법칙 (Pareto Principle) | 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙 |
살충제 패러독스 (Pesticide Paradox) | 동일한 테스트를 반복하면 더이상 결함이 발견되지 않는 현상 |
정황 의존성 | 소프트웨어 성격에 맞게 테스트 실시 |
오류-부재의 궤변 | 요구사항을 충족시키지 못한다면 결함이 없다고해도 품질이 높다고 볼 수 없음 |
3. 테스트의 분류
1) 테스트 시각에 따른 분류
검증 (Verification) | 소프트웨어 개발 과정을 테스트, 개발자 혹은 시험자의 시각 |
확인 (Validation) | 소프트웨어 결과를 테스트, 사용자시각 |
2) 테스트 목적에 따른 분류 - 회안성 구회병
분류 | 설명 |
회복테스트 (Recovery) |
시스템에 고의로 실패를 유도하고 시스템의 정상적 복귀 여부를 테스트 |
안전테스트 (Security) |
소스내 보안적인 결함을 미리 점검하는 테스트 |
성능테스트 (Performance) |
응답시간, 반응속도, 처리량 등 측정하는 테스트 |
구조테스트 (Structure) |
시스템의 내부 논리경로, 소스코드의 복잡도 테스트 |
회귀테스트 (Regression) |
오류제거와 수정에의해 새로 유입된 오류가 없는지 확인하는 일종의 반복 테스트 |
병행 테스트 (Parallel) |
변경된 시스템과 기존 시스템에 동일한 데이터 입력 후 결과 비교 |
(1) 성능 테스트 상세 유형 - 부스스내
분류 | 설명 |
부하테스트 (Load) |
시스템에 부하를 계속 증가시키면서 시스템의 임계점을 찾음 |
스트레스테스트 (Stress) |
임계점 이상의 부하를 가해 비정상적인 상황에서의 처리를 테스트 |
스파이크테스트 (Spike) |
짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트 |
내구성테스트 (Endurance) |
오랜 시간동안 시스템에 높은 부하를 가해 테스트 |
3) 테스트 목적에 따른 분류 - 명구경
- 명세 기반 테스트
- 구조 기반 테스트
- 경험 기반 테스트
(1) 정적테스트
정적분석 | 자동화된 도구를 이요하여 산출물의 결함을 검출하거나 복잡도 측정 | |
리뷰 | 소프트웨어의 다양한 산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검하기 위한 활동으로 전문가가 수행 (사람) | |
인스펙션 (동료검토) | 형식적 검토기법 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아냄 |
|
워크스루 | 비형식적 검토기법 검토자료를 회의전에 배포해서 사전 검토한 후 짧은 시간동안 회의를 진행하는 형태 |
(2) 동적테스트
- 화이트박스테스트 (구조 기반 테스트) - 구결조 조변다 기제데
원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
구문 (문장) 커버리지 (Statement Coverage) |
프로그램 내의 모든 명령문을 적어도 한 번 수행 ex) a=1; b=2; c=a+b; d=c*2; 이렇게 구문 4개 모두 실행 |
결정 (분기) 커버리지 (Decision/Branch Coverage) |
결정 포인트 내의 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행 ex) 모든 결정문 (if-else) 가 참과 거짓을 각각 한번씩 수행 |
조건 커버리지 (Condition Coverage) |
결정 포인트 내의 각 개별조건식이 적어도 한번은 참과 거짓의 결과가 되도록 수행 ex) 각 개별조건식 (a>b)와 (c<d) 가 각각 참일때와 거짓일때 한번씩 실행 |
조건/결정 커버리지 (Condition/Decision Coverage) |
전체 조건식 + 개별 조건식 모두 참 한번, 거짓 한번 결과가 되도록 수행 ex) 각 개별조건식 (a>b)와 (c<d)가 각각 참, 거짓일때 수행하고 if(a>b && c<d)도 한번씩 실행 |
변경 조건/결정 커버리지 (Modified Condition/Decision Coverage) |
개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함 ex) a>b와 c<d가 각각 전체 조건식의 결과에 영향을 줄 수 있는 값들로 테스트 |
다중 조건 커버리지 (Multiple Coverage) |
결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100%보장 ex) a>b, c<d 각각 참또는 거짓인경우 수가 4가지 있으므로 4가지 경우 모두 테스트 |
기본 경로 커버리지 (Base Path Coverage) |
수행 가능한 모든 경로를 테스트 * 맥케이브 복잡도 : 간선수 - 노드수 +2 |
제어 흐름 테스트 (Control flow) |
프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직 테스트 |
데이터 흐름 테스트 (Data flow) |
제어 흐름 테스트에 데이터 사용 현황 추가 |
//예시 코드
a = 1;
b = 2;
c = a + b;
d = c * 2;
if (a > b && c < d) {
System.out.println("True");
} else {
System.out.println("False");
}
https://itwiki.kr/w/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%ED%85%8C%EC%8A%A4%ED%8A%B8_%EB%B3%80%EA%B2%BD_%EC%A1%B0%EA%B1%B4/%EA%B2%B0%EC%A0%95_%EC%BB%A4%EB%B2%84%EC%A7%80%EB%A6%AC
- 블랙박스테스트 (명세 기반 검사) - 동결 결상 유분 폐원비
사용자의 요구사항 명세를 보면서 수행하는 테스트
동등 분할 테스트 (Equivalence Partitioning) |
입력 데이터 영역의 유사한 도메인별로 유효값/무효값을 그룹핑하여 대표값 테스트를 케이스를 도출하여 테스트 하는 기법 |
경곗값 분석 테스트 (Boundary Value Analysis) |
최소값 바로 위, 최대 치 바로 아래 등 입력값의 극한 한계를 테스트하는 기법 |
결정 테이블 테스트 (Decision Table) |
요구사항의 논리와 발생 조건을 테이블 형태로 나열하여 조건과 행위를 모두 조합하여 테스트 |
상태 전이 테스트 (State Transition) |
이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 |
유스케이스 테스트 (Use Case) |
프로세스 흐름을 기반으로 테스트케이스를 명세화하여 수행하는 테스트 |
분류 트리 테스트 (Classification Tree) |
SW의 일부 또는 전체를 트리구조로 분석 및 표현하여 테스트케이스 설계해 테스트 |
페어와이즈 테스트 (Pairwise) |
테스트 데이터 값들간에 최소한 한번씩 조합하는 방식 |
원인-결과 그래프 테스트 (Cause-Effect Graphing) |
그래프를 활용해 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석 |
비교테스트 (Comparision) |
여러 프로그램에 같은 입력값을 넣어 비교해 테스트 |
- 경험 기반 테스트 (블랙박스테스트)
탐색적 테스트 | 테스트 스크립트를 문서로 작성하지 않고 경험에 바탕을 두고 탐색적으로 기능을 수행해보며 테스트 |
오류 추정 | 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스 설계 테스트 |
체크리스트 | 테스트 할 내용과 경험을 분류하고 나열하고 하나씩 확인 |
툭성 테스트 | 품질 모델에 있는 품질 특성을 염두에 두고 이를 근간으로 테스트 케이스 설계, 테스트 |
4) 테스트 케이스
사용자의 요구사항을 정확하게 준수 했는지 확인하기 위해 설계된 테스트 항목에 대한 명세서
5) 테스트 오라클 - 참샘휴일
테스트 결과가 올바른지 판단하기 위해 사전에 정의 된 참 값을 대입하여 비교하는 기법
참 오라클 (True) |
모든 입력값에 대하여 기대하는 결과 제공하는 오라클 |
샘플링 오라클 (Sampling) |
특정한 몇개의 입력 값에 대해서만 기대하는 결과를 제공하는 오라클 |
휴리스틱 오라클 (Heuristic) |
특정 입력값에 대해 올바른 결과를 제공하고 나머지 값들에 대해서는 추정 (휴리스틱)으로 처리하는 오라클 |
일관성 검사 오라클 (Consistent) |
애플리케이션 변경이 있을때 수행 전과 후의 결괏값이 동일한지 확인하는 오라클 |
4. 테스트의 레벨 종류
1) 테스트 레벨
함께 편성되고 관리되는 테스트의 활동
2) 테스트 레벨 종류 - 단통시인
단위 테스트 | 사용자 요구사항에 대한 단위 모듈, 서브 루틴 등을 테스트 | |
목(Mock) 객체 | 객체 지향 프로그램에서 독립적인 컴포넌트 테스트를 위해 스텁의 객체지향 버전인 목객체 필요 | |
더미 객체 : 객체만 필요ㅛ하고 기능까지 필요하지 않은경우 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행 테스트 드라이버 : 테스트 대상 하위 모듈을 호출, 파라미터 전달, 모듈 테스트 수행 후 결과 도출 테스트 스파이 : 테스트 대상 클래스와 협력하는 클래스 가짜 객체 : 실제 협력 클래스의 기능을 대체해야 할 경우 생성 |
||
통합 테스트 | 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정 테스트 | |
빅뱅 테스트 (비 점증적 방식) |
모든 모듈을 동시에 통합 후 테스트 수행 드라이버, 스텁 없이 실제 모듈로 테스트 |
|
상향식 테스트 (점증적 방식) |
최하위 모듈부터 점진적으로 상위 모듈과 함께 테스트 테스트 드라이버 필요 |
|
하향식 테스트 (점증적 방식) |
최상위 모듈부터 하위모듈들을 통합하면서 테스트 테스트 스텁 필요 |
|
샌드위치 테스트 (점증적 방식) |
상향식 + 하향식 테스트, 병렬 테스트 가능 (테스트 드라이버, 스텁 필요) |
|
시스템 테스트 | 개발된 소프트웨어가 정상적으로 수행되는지 검증하는 테스트 | |
인수 테스트 | 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 |
|
알파테스트 | 사용자가 개발자 환경에서 수행하는 테스트 | |
베타테스트 | 실제 환경에서 일정 사용자에게 소프트웨어를 사용하게 하고 피드백을 받는 테스트 |
02 애플리케이션 통합 테스트
1. 테스트 자동화 도구
반복적 테스트 작업을 스크립트 형태로 구현함으로써 테스트 시간 단축과 인력 투입비용을 최소화 하는 한편 쉽고 효율적인 테스트를 구행할 수 있는 방법
테스트 자동화 도구 유형 | 설명 |
정적 분석 도구 (Static Analysis Tools) |
만들어진 애플리케이션을 실행하지 않고 분석하는 도구 |
테스트 실행도구 (Text Execution Tools) |
테스트를 위해 작성된 스크립트를 실행하고 스크립트 언어를 사용하여 테스트 실행하는 도구 |
성능 테스트 도구 (Performance Test Tools) |
가상의 사용자를 생성하고 테스트를 수행하여 목표 달성했는지 확인하는 도구 |
테스트 통제 도구 (Test Control Tools) |
테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구 |
테스트 하네스 도구 (Test Harness Tools) |
테스트가 실행될 환경을 시뮬레이션하여 컴포넌트 및 모듈이 정상적으로 테스트 되도록 하는 도구 |
- 테스트 드라이버 - 테스트 스텁 - 테스트 슈트 : 테스트 케이스 집합 - 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세 - 목 오브젝트 : 사용자의 행위를 조건부로 사전 입력해두면 그 상황에 예정된 행위 수행 |
2. 소프트웨어 결함
개발자 오류로 인해 만들어지는 문서 또는 코딩상의 결점으로 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 현상
1) 결함 분석 방법 - 구고일
방법 | 설명 |
구체화 (Specification) |
결함을 발생시킨 입력값, 테스트 절차, 환경을 명확히 파악 |
고립화 (Isolation) |
어떤 요소가 결함 발생에 영향을 미치는지 분석 |
일반화 (Generalization) |
결함 발생에 영향을 주는 요소를 최대한 일반화 시킴 |
2) 결함 심각도 - 치주보경단
방법 | 설명 |
치명적 결함 (Critical) |
기능이나 제품의 테스트를 완전히 방해, 데이터 손실, 시스템 충돌 |
주요 결함 (Major) |
기능이 기대와 다르게 동작 |
보통 결함 (Normal) |
일부 기능 부자연스러움, 사소한 기능 오작동 |
경미한 결함 (Minor) |
사용상의 불편함 유발, UI 잘림 |
단순 결함 (Simple) |
사소한 버그, 미관상 좋지 않음 |
3. 어플리케이션 성능 개선
1) 애플리케이션 성능 측정 지표 - 처응경자
분류 | 설명 |
처리량 (Throughput) |
애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션 수 |
응답시간 (Response Time) |
메뉴 클릭시 해당 메뉴가 나타나기 까지 걸리는 시간 응답 출력이 개시될 때까지 시간 |
경과시간 (Turnaround Time) |
트랜잭션 처리 후 결과 출력이 완료할 때 까지 시간 사용자가 요구를 입력한 시점부터 트랜잭션 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간 |
자원 사용률 (resource usage) |
트랜잭션 동안 사용되는 CPU/메모리/네트워크 사용량 |
2) 데이터 베이스 관련 성능 저하 원인
원인 | 설명 |
데이터 베이스 락 (DB Lock) |
대량의 데이터 조회, 과도한 업데이트 시 발생하는 현상 |
불필요한 DB 패치 (DB Fetch) |
대량의 데이터 요청이 들어올 경우 응답시간 저하 현상 발생 |
연결 누수 (Connection Leak) |
DB연결과 관련한 JDBC객체를 사용후 종료 하지 않을 경우 |
부적절한 커넥션 풀 크기 (Connection Pool Size) |
너무 작거나 크게 설정한 경우 |
3) 베드코드
프로그램 로직이 복잡하고 다른 개발자들이 이해하기 어려운 코드
사례 | 설명 |
외계인 코드 | 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 아주 어려운 코드 |
스파게티코드 | 스파게티처럼 코드가 복잡하게 얽힘, 정상작동 하지만 코드의 작동을 파악하기 어려운 코드 |
알 수없는 변수명 | 변수나 메서드에 대한 이름 정의를 알 수 없는 코드 |
로직 중복 | 동일한 처리 로직이 중복되게 작성된 코드 |
4) 클린코드
잘 작성되어 가독성이 높고, 단순하며, 의존성을 줄이고 중복을 최소화 하여 깔끔하게 잘 정리된 코드
- 클린 코드 특징 : 가독성이 높아 쉽게 이해됨, 개선도 쉬움, 버그찾기도 쉬워 프로그래밍 속도 빨라짐
- 클린 코드 작성 원칙 : 가단의중추 (가독성, 단순성, 의존성 최소, 중복성 제거, 추상화)
5) 리팩토링 (Refactoring)
기능을 변경하지 않고 복잡한 소스코드를 수정, 보완하여 가둉성 및 가독성 높이는 기법
6) 소스 코드 품질분석 도구
- 정적 분석도구
pmd | 자바 및 타언어 소스 코드에 대한 버그, 데드코드 분석 |
cppcheck | C/C++ 코드에 대한 메모리 누수, 오버플로우 등 문제 분석 |
checkstyle | 자바 코드에 대한 코딩 표준 검사 도구 |
- 동적 분석도구
Avalanche | Valgrind , STP 기반 소프트웨어 에러 및 취약점 동적 분석 도구 |
Valgrind | 자동화된 메모리 및 스레드 결함 발견 분석 도구 |
'|Developer_Study > 정보처리기사' 카테고리의 다른 글
[정보처리기사] C언어 구조체, 포인터이동 (0) | 2023.03.09 |
---|---|
[정보처리기사 실기] 11과목 - 응용 SW 기초 기술 활용 (0) | 2023.03.08 |
[정보처리기사] 예상 문제1 (0) | 2023.03.06 |
[정보처리기사 실기] 9과목 - 소프트웨어 개발 보안 구축 (0) | 2023.03.02 |
[정보처리기사] C언어 포인터, 배열포인터, 포인터 배열 (0) | 2023.02.28 |
댓글