728x90
애플리케이션 테스트 관리
애플리케이션 테스트
확인 / 검증
- 확인 : 사용자의 입장에서 개발한 소프트웨어가 고객의 요구사항에 맞게 구현되었는지를 확인하는 것
- 검증 : 개발자의 입장에서 개발한 소프트웨어가 명세서에 맞게 만들어졌는지를 점검하는 것
파레토 법칙
소프트웨어 테스트에서 오류의 80%는 전체 모듈의 20%내에서 발견된다는 법칙
결함 집중
- 애플리케이션 대부분의 결함이 소수의 특정 모듈에 집중해서 발생하는 것을 의미
- 파레토 법칙이 좌우한다.
- 결함은 발생한 모듈에서 계속 추가로 발생할 가능성이 높다.
애플리케이션 테스트의 분류
강도 테스트
시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하시에도 소프트웨어가정상적으로 실행되는지를 확인하는 테스트
테스트 기법에 따른 애플리케이션 테스트
화이트박스 테스트
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
- 원시 코드의 모든 문장을 한 번 이상 실행함으로써 수행된다
- 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.
화이트박스 테스트의 종류
- 기초 경로 검사
- 제어 구조 검사 : 조건 검사, 루프 검사, 데이터 흐름 검사
블랙박스 테스트로 발견 가능한 오류
- 비정상적인 자료를 입력해도 오류 처리를 수행하지 않는 경우
- 정상적인 자료를 입력해도 요구된 기능이 제대로 수행되지 않는 경우'
- 결계값을 입력할 경우 요구된 출력 결과가 나오지 않는 경우
블랙박스 테스트의 종류
- 동치 분할 검사 : 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과각 출력되는지 확인하는 기법
- 경계값 분석 : 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
- 원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
- 오류 예측 검사 : 과거의 경험이나 확인자의 감각으로 테스트하는 기법
- 비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트 하는 기법
개발 단계에 따른 애플리케이션 테스트
소프트웨어 생명 주기의 V-모델
- 개발 단계와 테스트 단계를 병행하여 진행하는 검증과 확인 중심의 개발 모델
- 폭포수 모델을 기반으로 하되, 각 개발 단계에 맞는 테스트를 대응시키는 구조로 설계

출처 : https://naminal.tistory.com/185
단위 테스트
- 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
- 단위 테스트로 발견 가능한 오류
- 알고리즘 오류에 따른 원치 않는 결과
- 탈출구가 없는 반복문의 사용
- 틀린 계산 수식에 의한 잘못된 결과
인수 테스트
- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
- 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법
- 베타 테스트 : 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법, 필드 테스팅 이라고도 불림
통합 테스트
하향식 통합 테스트
- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트 하는 기법
- 깊이 우선 통합법이나 넓이 우선 통합법을 사용
상향식 통합 테스트
- 프로그램의 하위 모듈에서 상위 모듈 방향을 통합하면서 테스트하는 기법
- 스텁은 필요하지 않지만 클러스터가 필요
테스트 드라이버
- 테스트 대상의 하위 모듈을 호출하는 도구로, 매개 변수를 전달하고, 모듈 테스트 수행 후의 결과를 도출
- 상위 모듈 없이 하위 모듈이 있는 경우 하위 모듈을 구동
- 상향식 통합 테스트에 사용
테스트 스텁
- 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
- 상위 모듈은 있지만 하위 모듈이 없는 경우 하위 모듈을 대체
- 하향식 통합 테스트에 사용
테스트 케이스 / 테스트 오라클
테스트 케이스
- 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과등으로 구성된 테스트 항목에 대한 명세서
- 테스트 케이스는 테스트 목표와 방법을 설정한 후 작성
테스트 오라클
테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동
테스트 오라클의 종류
- 참 오라클 : 모든 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클로, 발생된 모든 오류를 검출할 수 있음
- 샘플링 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
- 추정 오라클 : 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
- 일관성 검사 오라클 : 애플리케이션의 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일하지를 확인하는 오라클
테스트 자동화 도구
테스트 케이스 생성 도구
- 자료 흐름도
- 기능 테스트
- 입력 도메인 분석
- 랜덤 테스트
성능 테스트 도구
애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인한다.
결함 관리
결함
오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것을 의미
복잡도
주요 최악의 시간 복잡도
- O(1) : 입력값(n)에 관계 없이 일정하게 물제 해결에 하나의 단계만을 거침(EX 스택의 PUSH, POP)
- O(nlog2n) : 문제 해결에 필요한 단계가 O(nlog2n)번만큼 수행됨(EX 힙 정렬)
순환 복잡도

출처 : https://velog.io/@alpaka206/52.-%EB%B3%B5%EC%9E%A1%EB%8F%84
애플리케이션 성능 개선
클린 코드
누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드
클린 코드 작성 원칙
- 가독성 : 누구든지 코드를 쉽게 읽을 수 있도록 작성
- 단순성 : 코드를 간단하게 작성
- 의존성 배제 : 코드가 다른 모듈에 미치는 영향을 최소화
- 중복성 최소화 : 코드의 중복을 최소화함
- 추상화 : 상위 클래스 / 메소드 / 함수에서는 간략하게 애플리케이션의 특성을 나타내고, 상세 내용은 하위 클래스 / 메소드 / 함수에서 구현함
외계인 코드
아주 오래되거나 참고문서 또는 개발자가 없어 유지 보수 작업이 어려운 코드
소스 코드 품질 분석 도구 - 정적 분석 도구
- 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인
- 하드웨어적인 방법 또는 소프트웨어적인 방법으로 코드를 분석한다.
- 종류 : pmd, checkstyle, cppcheck 등
728x90
'개발공부 > 자격증 공부' 카테고리의 다른 글
| 정보처리기사 - 데이터베이스 구축(1장) 정리 (0) | 2025.05.08 |
|---|---|
| 정보처리기사 - 소프트웨어 개발(5장) 정리 (0) | 2025.05.08 |
| 정보처리기사 - 소프트웨어 개발(3장) 정리 (0) | 2025.05.07 |
| 정보처리기사 - 소프트웨어 개발(2장) 정리 (1) | 2025.05.07 |
| 정보처리기사 - 소프트웨어 개발(1장) 정리 (0) | 2025.05.07 |