53. 애플리케이션 테스트 (⭐️⭐️⭐️⭐️)
1) 개념
애플리케이션에 잠재된 결함 찾는 일련의 행위
고객 요구 만족시키는지 확인(고객입장)과 기능 수행 검증(개발자입장)
3) 기본 원리
- 결함을 줄일 순 있지만 결함이 없다고 증명할 수는 없다
- 20%의 코드에서 80%의 결함 발견(파레토)
- 살충제 패러독스; 동일테스트케이스로 하면 결함 발견 어려움
- 정황에 따른 테스트 수행
- 오류부재의 궤변; 결함 제거해도 요구사항 만족시키지 못하면 품질 높은 SW가 아님
- 테스트와 위험은 반비례
- 테스트는 작은부분-> 큰부분
54. 애플리케이션 테스트 분류 (⭐️⭐️⭐️)
1) 프로그램 실행 여부에 따라
- 정적 테스트: 프로그램 실행 없이 명세서나 소스코드 대상으로 분석
워크스루, 인스펙션, 코드검사 등 - 동적 테스트: 프로그램 실행하여 오류 찾음
2) 테스트 기반에 따른 테스트
3) 시각에 따른 테스트
4) 목적에 따른 테스트
: 회복, 안전, 강도, 성능, 구조, 회귀, 병행 테스트
- 강도 테스트: 시스템에 과도한 정보량이나 빈도 부과하여 과부하시에도 정상실행되는지 테스트
55. 테스트 기법에 따른 애플리케이션 테스트 (⭐️⭐️⭐️⭐️)
1) 화이트박스 테스트
: 모듈의 원시코드 오픈한 상태에서 모든 논리경로 테스트하여 테스트 설계
- 원시코드(모듈) 모든문장 한번씩 실행하며 작동을 직접 관찰
- 논리적 경로 제어
2) 화이트박스 테스트 종류
- 기초 경로 검사: 대표적 화이트박스 기법, 절차적 설계의 논리복잡성 측정하게 하는 기법, 실행 기초경로를 정의하는데 지침으로 사용
- 제어 구조 검사: 조건검사, 루프검사, 데이터흐름 검사
3) 화이트박스 테스트 검증 기준
: 문장 검증 기준, 분기 검증 기준, 조건 검증 기준, 분기/조건 기준
4) 블랙박스 테스트
: 각 기능이 완전히 작동되는 것을 입증하는 테스트, 기능 테스트라고도 함
- 요구사항 명세 보면서 구현된 기능 테스트
- 인터페이스에서 실시
5) 블랙박스 테스트 종류
동치 분할 검사, 경계값 분석, 원인효과 그래프 검사, 오류 예측 검사, 비교 검사
- 동치 분할 검사: 테스트 케이스(동치 클래스) 만들어 타당/X타당 자료 넣어 맞게 출력되는지 검사
- 경계값 분석: 입력값에만 치중한 동치분할기법 보완, 경계값을 넣어 테스트
- 원인-효과 그래프 검사: 입력-출력 영향미치는 상황 체계적 분석후 효용성 높은 테스트케이스 선정하여 검사
56. 개발단계에 따른 애플리케이션 테스트 (⭐️⭐️⭐️⭐️)
1) 개요
소프트웨어 생명주기의 V-모델
요구사항 -> 분석 -> 설계 -> 구현 단계에 따라
단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트
2) 단위 테스트 (Unit Test)
코딩 직후 모듈이나 컴포넌트에 초점 맞춰 테스트
- 인터페이스, 외부 I/O, 독립적 기초경로,, 오류처리경로, 경계조건등 검사
- 사용자 요구사항 기반으로한 기능성 테스트 최우선
- 주로 구조기반 테스트
✓ 구조기반테스트: 화이트박스테스트
✓ 명세기반테스트: 블랙박스테스트
3) 통합 테스트 (Integration Test)
단위테스트 완료된 모듈 결합하여 하나의 시스템으로
모듈간 or 컴포넌트간 상호작용오류 검사
4) 시스템 테스트
5) 인수 테스트
사용자의 요구사항 충족하는지 중점 두고 테스트
- 사용자가 직접 테스트
- 사용자인수테스트, 운영상인수테스트, 계약인수테스트, 규정인수테스트, 알파테스트, 베타테스트
✓ 알파테스트: 개발자의 장소에서 통제환경 내에서 하는 테스트
✓ 베타테스트: 통제, 제어X 환경
57. 통합 테스트 (⭐️⭐️⭐️⭐️)
1) 통합테스트
단위테스트 끝난 모듈 통합과정에서 발생하는 오류, 결함 찾는 테스트 기법
- 비점진적 통합: 모든 모듈이 결합되어있는 프로그램 전체를 테스트, 규모 작은 소프트웨어에 유리, 단시간, 오류발견및 장애위치파악/수정 어려움
- 점진적 통합: 단계적으로 통합해가며 테스트
2) 하향식 통합 테스트 (Top Down)
프로그램의 상위모듈에서 하위모듈 방향으로 통합하며 테스트
- 주요제어모듈 기준으로 아래단계로 이동하며 통합
- 테스트 초기부터 시스템 구조 보여줄 수 있음
- 상위모듈에서는 테스트케이스 사용 어려움
✓ 테스트 스텁(stub): 제어모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요 조건만을 가지고있는 시험용 모듈
3) 상향식 통합 테스트
하위모듈에서 상위모듈로
- 스텁 필요 X, 주요 제어모듈과 관련된 종속모듈의 그룹인 클러스터가 필요
✓ 테스트 드라이버: 상위모듈 없고 하위모듈 있는 경우 하위모듈 구동, 바텀업시, 존재하는 하위모듈과 존재하지않는 상위모듈간의 인터페이스 역할, 개발 완료시 원래 모듈로 교체
✓ 테스트 스텁: 상위모듈 있지만 하위모듈 없는경우, 탑다운시, 가짜 시험용 모듈으로 드라이버보단 작성이 쉬움
5) 회귀 테스트
이미 테스트된 프로그램의 테스팅 반복하는 것
- 수정한 모듈이나 컴포넌트가 다른부분에 영향 미치는지, 오류생기는지 확인 보증 위해 반복 테스트
59. 테스트 오라클
5) 테스트 오라클
: 테스트결과 올바른지 판단 위해 사전 정의된 참 값 대입하여 비교
- 종류: 참, 샘플링, 휴리스틱(추정), 일관성 오라클
60. 테스트 자동화 도구
1) 개요
스크립트형태로 구현하는 자동화도구 적용하여 쉽고 효율적으로 테스팅
4) 유형
- 정적 분석 도구
- 테스트 케이스 생성 도구: 자료 흐름도, 기능 테스트, 입력 도메인 분석, 랜덤 테스트
- 테스트 실행 도구
- 성능 테스트 도구: 애플리케이션 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자 만들어 테스트 수행
- 테스트 통제 도구
- 테스트 하네스 도구: 드라이버, 스텁, 슈트, 케이스, 스크립트, 목 오브젝트
61. 결함(Fault) 관리
1) 결함의 정의
: 오류발생, 작동실패 포함하여 사용자 예상과의 차이나 업무내용과의 불일치등도 포함
62. 애플리케이션 성능 분석
1) 애플리케이션 성능
측정 지표: 처리량, 응답 시간, 경과 시간, 자원 사용률
63. 복잡도 (⭐️⭐️⭐️⭐️)
1) 개요
테스트나 개발 시 어느 정도의 자원이 소요되는지 예측하는데 사용
2) 시간 복잡도
알고리즘 수행 위해 프로세스가 수행하는 연산횟수 수치화한 것
3) 빅오 표기법
알고리즘의 실행시간이 최악일 때를 표기하는 방법으로, 가장 주로 사용됨
- O(1): 입력값에 관계 없이 문제 해결에 단 하나의 단계를 거침
- O(log2n): 이진 트리, 이진 검색
- O(n): for문
- O(nlog2n): 합병 정렬, 힙 정렬
- O(n^2): 삽입정렬, 쉘정렬, 선택정렬, 버블정렬, 퀵정렬
- O(2^n): 피보나치
4) 순환 복잡도
= 화살표의 수 - 노드의 수 + 2
또는 화살표로 구분되는 영역의 수
64. 애플리케이션 성능 개선 (⭐️⭐️⭐️⭐️)
1) 소스코드 최적화
나쁜코드 배제하고 클린코드로 작성하는 것
나쁜 코드 종류: 스파게티 코드 (로직이 복잡하게 얽혀있음), 외계인 코드(아주 오래되거나 참고문서 또는 개발자가 없어 유지보수가 어려움)
작성 원칙
- 가독성: 누구든 이해하기 쉽고 들여쓰기 잘 작성
- 단순성: 간단하게 작성, 클래스/메소드/함수 등 최소단위로 분리
- 의존성 배제: 코드가 다른 모듈에 미치는 영향 최소화
- 중복성 배제: 중복 최소화
- 추상화: 상위에서는 애플리케이션의 특성, 상세는 하위에서
3) 소스코드 품질분석도구
정적 분석 도구
- 실행 없이 코딩표준, 스타일, 결함 등 확인
- 개발 초기에 결함 찾는데 사용, 완료 후에는 검증차원
- 자료흐름이나 논리흐름 분석하여 비정상적 패턴 찾음
- 코드의 복잡도, 모델 의존성, 불일치성 등 분석
- pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
동적 분석 도구
- 실행하여 코드 내의 메모리 누수, 스레드 결함 등을 분석
- Avalanche, Valgrind 등
참고 문헌 📚
2022 시나공 정보처리기사 필기
