본문 바로가기
CS-SQL-DB

[정보처리기사 실기] 애플리케이션 테스트 관리, 테스트케이스 설계

by Jann 2022. 5. 5.
728x90

애플리케이션 테스트 케이스 설계

 

소프트웨어 테스트의 원리

#결완초집살정오

- 테스팅은 함 존재함을 밝히는 것 : 테스팅 목적

- 벽한 테스팅은 불가능

- 개발 기에 테스팅 시작 : Snowball Effect 눈덩이 법칙(요르돈의 법칙)

- 결함 중 : Pareto Priciple 파레토법칙

- 충제 패러독스 : 동일한 테스트케이스를 반복해 테스트를 사용할 경우 새로운 버그를 발견하지 못한다.

- 테스팅은 황에 의존

- 류-부재의 궤변

 

소프트웨어 테스트의 산출물

- 테스트 계획서 : 테스트의 목적과 범위 정의, 대상 시스템 구조 파악, 수행절차 등을 계획한 문서 

- 테스트 베이시스 : 분석, 설계 단계의 논리적 케이스로 테스트 설계를 위한 기준이 되는 문서(요구사항 명세서 등)

- 테스트 케이스 : 테스트를 위한 설계 산출물로, 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서

- 테스트 슈트 : 테스트 케이스 실행환경에 따라 구분해 놓은 테스트 케이스의 집합으로 시나리오는 포함되지 않음

- 테스트 시나리오 : 애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서로 테스트 시나리오가 테스트 케이스와 일 대 다의 관계를 가질 수 있다.

- 테스트 스크립트 : 테스트 케이스의 실행순서(절차)를 작성한 문서로 테스트 스텝 또는 테스트절차서라고도 한다.

- 테스트 결과서 : 테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰하고, 테스트 결과를 평가하고 리포팅하는 문서 

 

프로그램 실행 여부에 따른 분류

- 정적 테스트 : 프로그램 실행없이 소스 코드의 구조를 분석해 논리적으로 검증하는 테스트로 인스펙션, 코드검사, 워크 스루 등이 해당한다.

- 동적 테스트 : 프로그램의 실행을 요구하는 테스트로 화이트박스 테스트와 블랙박스 테스트가 있다.

 

테스트 기법에 따른 분류

- 화이트 박스 테스트

: 코드 분석과 프로그램 구조에 대한 지식을 바탕으로 문제 발생 가능성 있는 모듈 내부를 직접 관찰하고 테스트하는 기법으로 산출물의 기능별로 적절한 프로그램의 제어 구조에 따라 선택, 반복 등의 부분들을 수행함으로써 논리적 경로를 점검한다. 구조 기반 테스트, 코드 기반 테스트, 로직 기반 테스트라고 부르며 단위, 통합테스트에 많이 사용된다. (내부 구조를 볼 수 있기에)

 

- 화이트 박스 테스트의 종류 

#구결조조변다기재데

1) 구문(문장) 커버리지 : 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지 

2) 결정(선택 / 분기) 커버리지 : 결정 포인트 내의 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행하는 테스트 커버리지

3) 조건 커버리지 : 결정 포인트 내 각 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행

4) 조건/결정 커버리지 : 전체 조건식, 개별 조건식 모두 참 한번, 거짓 한번 결과가 되도록 수행

5) 변경조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 하는 커버리지

6) 다중조건 커버리지 : 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 커버리지

7) 기본경로 커버리지 : 수행 가능한 모든 경로를 테스트, 맥케이브의 순한복잡도를 기반으로 커버리지를 계산

8) 제어흐름테스트 : 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트

9) 데이터흐름테스트 : 제어 흐름 그래프에 사용현황 추가한 테스트

 

- 블랙 박스 테스트

: 프로그램의 외부 사용자 요구사항 명세를 보며 테스트를 수행하고, 주로 구현된 기능을 테스트한다. 명세기반 기법이라고도 하며 주어진 명세(모델, 설계서 등)를 바탕으로 테스트 케이스를 도출한다.

 

- 블랙 박스 테스트의 종류 

#동경결상유분페원비

1). 동등(동치)분할 : 입력 데이터 영역을 유사한 도메인별로 유효값/ 무효값을 그룹핑하여 대푯값 테스트 케이스 도출

2) 경계값분석 : 등가 분할 후 경계값 부분에서 오류 발생 높기 때문에 경계값 포함하여 테스트 케이스 설계

3) 결정테이블 : 요구사항의 논리와 발생조건을 테이블 형태로 나열하고 조건과 행위를 모두 조합해 테스트

4) 상태전이 : 테스트 대상, 시스템이나 객체 상태 구분하고, 어느 한 상태에서 다른 상태로 전이되는 경우릐 수를 수행

5) 유스케이스 : 시스템이 실제 사용되는 유스케이스로 모델링 되어있을 때 프로세스 흐름 기반으로 테스트 케이스

6) 분류트리 : 소프트웨어 일부 또는 전체를 트리 구조로 분석하고 표현하여 테스트

7) 페어와이즈 : 테스트 데이터 값들 간 최소 한번씩 조합하는 방식

8) 원인-결과 그래프 : 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석하여 효용성이 높은 테스트케이스 선정

9) 비교테스트 : 여러 버전의 프로그램에 같은 입력값을 넣어 동일한 결과 데이터가 나오는지 비교해보는 테스트

 

테스트 목적에 따른 분류

#회안성구회병

- 회복 테스트 : 시스템에 고의로 실패를 유도하고, 시스템의 정상적 복귀 여부를 테스트

- 안전 테스트 : 불벅 소프트웨어가 접근해 시스템을 파괴하지 못하도록 소스 코드 내 보완 결함을 미리 점검하는 테스트

- 성능 테스트 : 사용자의 이벤트에 시스템이 응답하는 시간, 업무량, 반응 속도 등을 측정하는 테스트

- 구조 테스트 : 시스템 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트

- 회귀 테스트 : 오류 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로 유입된 오류 확인하는 일종의 반복 테스트

- 병행 테스트 : 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트

 

+ 성능 테스트의 상세 유형 

#부스스내

- 부하 테스트 Load : 시스템 부하를 계속 증가시키며 시스템 임계점을 찾는 테스트

- 스트레스 테스트 Stress : 시스템 처리 능력 이상의 부하, 임계점 이상의 부하를 가하여 비정상적인 상황 처리 테스트

- 스파이크 테스트 Spike : 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트 

- 내구성 테스트 Endure : 오랜 시간 동안 시스템에 높은 부하를 가하여 시스템 반응 테스트

 

애플리케이션 리뷰

: 소프트웨어의 다양한 산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검하기 위한 활동으로 전문가가 수행한다.

 

애플리케이션 리뷰 유형

#동워인

- 동료 검토 : 2-3명이 진행하는 리뷰 형태로 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 설명을 들이며 결함을 발견하는 형태로 진행하는 검토 기법

- 워크 스루 : 검토 자료를 회의 전 배포해 사전 검토 후 짧은 시간 동안 회의를 진행하는 형태로 비형식적(비공식적)

- 인스펙션 : 저작자 외 다른 전문가 또는 팀이 검사해 문제 식별과 문제에 대한 올바른 해결을 찾아내는 형식적인 검토

728x90

댓글