* 애플리케이션 테스트 관리 *
| 개요 | 능력단위 | 시험시간 |
| 지필평가 | 제품 소프트웨어 패키징 | 20분 |
| 애플리케이션 테스트 관리 |
학습모듈 자료
https://www.ncs.go.kr/unity/th03/ncsSearchMain.do
공개문제 아님
능력단위의 전반적인 내용 전체를 볼 수 있는 자료 사이트
해당 내용을 기준으로 요약본을 작성함
- [ 분야별 검색 : 20. 정보통신 ] ⇒ [01. 정보기술] ⇒ [02. 정보기술개발] ⇒ [하단 NCS학습모듈]
- 원하는 능력단위의 PDF 다운로드
노란색 : 출제될 확률이 높음. 개인적인 의견이니 믿지는 마세요
빨간색 : 실제 출제된 적이 있음
노션글을 가져오니까 내용이 엉망이 되어서 재정리하는데 좀 힘들었다ㅡㅡ..
02. 애플리케이션 테스트 관리
▶ 응용 소프트웨어의 유형
상용 소프트웨어
불특정 일반인에게 필요한 공통의 기능을 제공
- 산업 범용 소프트웨어
- 시스템 소프트웨어 : 운영체제, 데이터 통합, 프로그래밍 언어 등
- 미들웨어 : 웹 애플리케이션 서버, 실시간 데이터 처리, 네트워크 관리 등
- 응용 소프트웨어 : 영상 인식/분석, 영상 코덱/스트리밍, 영상 저작/편집/합성 등
- 산업 특화 소프트웨어
- 특정한 산업 분야에서 요구하는 기능만을 구현하기 위한 목적의 소프트웨어
서비스 제공 소프트웨어
특정 사용자의 요구사항 구현
- 신규 개발 소프트웨어 : 새로운 서비스 제공을 목적으로 개발
- 기능 개선 소프트웨어 : 사용자 편의성 개선, 응답 속도 개선, 화면 UI 개선 등의 목적으로 개발
- 추가 개발 소프트웨어 : 기존 시스템에 업무 환경 변화, 산업 환경 변화 등으로 새 기능을 추가로 개발
- 시스템 통합 소프트웨어 : 각 별도로 서비스되는 시스템을 원스톱 서비스 제공을 위해 통합하여 개발
▶ 소프트웨어 테스트의 기본 원칙
소프트웨어 테스트의 원리
1. 테스팅은 결함이 존재함을 밝히는 활동
- 테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수는 없음
2. 완벽한 테스팅은 불가능
- 리스크 분석과 우선순위를 토대로 테스트에 집중할 것
3. 테스팅은 개발 초기에 시작
- 개발 단계에 테스트를 계획하고 SDLC(Software Development Life Cycle) 의 각 단계에 맞춰 접근
4. 결함 집중
- 결함의 대부분은 소수 특정 모듈에 집중되어 존재
5. 살충제 패러독스
- 동일한 테스트 케이스로 반복 실행하면 결함 발견 X
- 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다
6. 테스팅은 정황(Context)에 의존
- 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행
7. 오류-부재의 궤변
- 사용자 요구사항을 만족 못하는 오류를 발견하고 제거하였다 해도, 해당 어플의 품질이 높다고 할 수 없다.
▶ 테스트 프로세스
[ 계획 ] ⇒ [ 분석 및 디자인 ] ⇒ [ 테스트 케이스 및 시나리오 작성 ] ⇒ [ 테스트 수행 ] ⇒ [ 결과 평가 및 리포팅 ]
- 테스트 계획
- 테스트 목적과 범위 정의
- 대상 시스템 구조 파악
- 테스트 일정 정의
- 테스트 분석 및 디자인
- 테스트 목적과 원칙 검토
- 요구사항 분석
- 리스크 분석 및 우선순위 결정
- 테스트 데이터 준비
- 테스트 케이스 및 시나리오 작성
- 테스트 케이스 작성
- 테스트용 스크립트 작성
- 케이스 검토 및 확인
- 테스트 수행
- 초기 데이터 로딩
- 테스트 수행
- 결함 리포팅
- 테스트 결과 평가 및 리포팅
- 테스트 결과 정리
- 테스트 프로세스 리뷰
- 테스트 결과 평가
▶ 소프트웨어 테스트 산출물
- 테스트 계획서
테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 일정, 테스트 수행 절차 등 테스트 수행을 계획한 문서 - 테스트 케이스
사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력 값/실행조건/기대 결과로 구성된 테스트 항목의 명세서, 테스트를 위한 설계 산출물 - 테스트 시나리오
테스트 케이스의 동작 순서를 기술한 문서, 테스트 수행을 위한 여러 개의 테스트 케이스의 집합 - 테스트 결과서
테스트 프로세스를 리뷰하고 결과를 평가하고 리포팅하는 문서
▶ 테스트 오라클
테스트 결과가 참인지 거짓인지 판단을 위해 정의된 참값을 입력하여 비교하는 기법
테스트 오라클 유형
- 참 오라클
- 모든 입력값에 대하여 기대하는 결과 생성
- 샘플링 오라클
- 특정 몇 개 입력 값에 대해서만 기대하는 결과를 제공
- 휴리스틱 오라클
- 샘플링을 개선한 오라클 + 나머지 값들은 휴리스틱으로 처리
- 일관성 검사 오라클
- 어플 변경이 있을 때 수행 전 후의 결과 값이 동일한지 확인
▶ 소프트웨어 테스트 유형
프로그램 실행 여부
- 정적 테스트
프로그램 실행 없이 소스 코드의 구조를 분석하여 논리적으로 검증하는 테스트- 인스펙션, 코드검사, 워크스루 등
- 동적 테스트
프로그램의 실행을 요구하는 테스트
- 화이트박스 테스트, 블랙박스 테스트
테스트 기법
- 화이트박스 테스트
내부 로직을 보면서 테스트를 수행 - 블랙박스 테스트
외부 사용자 요구사항 명세를 보면서 테스트
테스트에 대한 시각
- 검증
제품의 생산 과정을 테스트
올바른 제품을 생산하고 있는지 검증
- 확인
생산된 제품의 결과를 테스트
생산된 제품이 정상적으로 동작하는지 확인
테스트 목적
- 회복 테스트
시스템에 고의로 실패를 유도 → 정상적으로 복귀하는지 테스트 - 안전 테스트
불법 소프트웨어가 시스템을 파괴하지 못하도록 소스코드 내 보안적 결함을 미리 점검 - 강도 테스트
시스템 과부하 시에도 시스템이 정상적으로 작동되는지 테스트 - 성능 테스트
시스템 응답시간, 특정 시간내 처리 업무량, 사용자 요구에 시스템 반응 속도 등을 테스트 - 구조 테스트
시스템 내부 논리 경로, 소스코드 복잡도 평가 - 회귀 테스트
변경/수정 코드 새로운 결함 발견 여부 평가 - 병행 테스트
변경된 시스템과 기존 시스템에 동일한 데이터를 입력후 결과 비교
테스트 종류
- 명세 기반 테스트
주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지? - 구조 기반 테스트
SW 내부 논리 흐틈에 따라 케이스를 작성하고 확인 - 경험 기반 테스트
▶ 통합 테스트
통합 테스트
소프트웨어 각 모듈간 인터페이스 관련 오류&결함을 찾기 위한 테스트 기법
- 목적
단위 테스트가 끝난 모듈(컴포넌트)이설계와 동일한 구조와 기능으로 구현된 것인지 확인 - 수행 방법 분류
- 점증적인 방법 : 상향식 통합/하향식 통합
- 비점증적인 방법: 빅뱅 방식 ( 모든 컨포넌트를 통합 → 전체를 한번에 테스트 )
하향식 통합 (Top Down)
- 메인 모듈로부터 아래 방향으로 제어 경로를 따라 이동하며 하향식으로 통합하며 테스트 진행
- 테스트 스텁
- 제어 모듈이 호출하는 타 모듈의 기능을 수행
상향식 통합 (Botton Up)
- 최하위 모듈로부터 위쪽 방향으로 제어 경로를 따라 이동하며 상향식으로 테스트
- 테스트 드라이버
- 테스트 대상인 하위 모듈을 호출, 파라미터 전달
- 클러스터로 결합
회귀 테스팅
- 통합 테스트가 완료된 후 변경 모듈/컴포넌트가 있으면 의도하지 않은 오류가 생기지 않았음을 보증하기 위해 반복 테스트 하는 것
▶ 테스트 자동화
정의
테스트 도구를 활용하여 반복 테스트 작업을 스크립트 형태로 구현
→ 테스트 시간 단축& 인력 투입 비용 최소화, 쉽고 효율적인 테스트
유형
1. 정적 분석 도구
어플을 실행하지 않고 분석하는 방법
2. 테스트 실행 도구
테스트를 위해 작성된 스크립트 실행
- 데이터 주도 접근 방식
테스트 데이터를 스프레드시트에 젖아하고 이 데이터를 읽고 실행할 수 있도록 한다. - 키워드 주도 접근 방식
이 방식에서는 키워드를 이용하여 테스트 수행 동작을 정의할 수 있다. 테일러링을 수행할 수 있다,
3. 성능 테스트 도구
성능 테스트를 위해 가상의 사용자를 생성하고 테스트를 수행해서 성능 목표를 달성하였는지 확인하는 도구
4. 테스트 통제 도구
테스트 통제 도구에는 테스트 관리 도구, 형상 관리 도구, 결함 추적/관리 도구 등이 있다. 또한 스프레드시트 등 다른 도구들과 연계하여 사용할 수도 있다.
5. 테스트 장치
어플 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터
- 구성요소
- 테스트 드라이버
- 테스트 대상 하위모듈을 호출, 파라미터 전달, 상향식 테스트에 필요
- 테스트 스텁
- 타 모듈의 기능을 단순히 수행하는 도구, 하향식 테스트에 필요
- 테스트 슈트
- 테스트 케이스의 집합
- 테스트 케이스
- 입력 값, 실행 조건, 기대 결과 등의 집합
- 테스트 스크립트
- 테스트 실행 절차에 대한 명세
- 목 오브젝트
- 사용자 행위를 조건부로 입력해두면 그 상황에 예정된 행위를 수행하는 객체
- 테스트 드라이버
6. 테스트 자동화 도구
▶ 소프트웨어 결함
소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 현상
- 에러 (Error) : 결함의 원인, 일반적으로 사람에 의해 생성된 실수
- 결점 ( Fault ) : 시스템 고장을 일으키게 하며, 오류가 있는 경우 발생하는 현상
- 버그 (Bug) : 프로그램 오류로 인해 예상치 못한 결과가 나타나는 현상
- 실패 (Failure)/문제 ( Problem ) : 제품에 포함된 결함이 실행될 때 발생하는 현상
- 결함 (Defect)
----------------------------- 여기까지 노션 -> 티스토리 재정리 완료 --------------
▶ 테스트 커버리지
- 개요
- 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준
- 프로그램의 테스트 수행 정도를 나타내는 값으로 테스트 수행의 완벽성을 측정하는 도구
- 유형
- 기능 기반 커버리지
- 모수 : 전체기능
- 측정 : 실제 수행된 기능의 수
- 100% 달성을 목표로 한다.
- 라인 커버리지
- 모수 : 전체 소스코드의 라인 수
- 측정 : 실제 수행된 라인 수
- 코드 커버리지
- 소스코드의 구문, 조건, 결정 등 구조 코드 자체가 얼마나 테스트 되었는지를 측정
- 구문 커버리지
- 코드 구조 내 모든 구문에 대해 한 번 이상 수행
- 조건 커버리지
- 결정 포인트 내 모든 개별 조건식에 대해 수행
- 결정 커버리지
- 결정 포인트 내의 모든 분기문에 대해 수행
- 변형 조건/결정 커버리지
- 조건과 결정을 복합적으로 고려한 측정 방법
- 다중 조건 커버리지
- 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장
- 경로 커버리지
- 수행 가능한 모든 경로 테스트 ( 간선(맥케이브) 복잡도 : Edge - Node + 2 )
- 소스코드의 구문, 조건, 결정 등 구조 코드 자체가 얼마나 테스트 되었는지를 측정
- 기능 기반 커버리지
▶ 애플리케이션 성능 측정 지표
- 처리량 ( Throughput ) : 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수
- 응답 시간 ( Response Time ) : 사용자 입력이 끝난 후, APP의 응답 출력이 개시될 때까지의 시간
- 경과 시간 ( Turnaround Time ) : 사용자가 요구를 입력한 시점부터 트랜잭션을 처리한 후 결과를 출력할 때 까지 걸리는 시간
- 자원 사용률 ( Resource usage ) : 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량
▶ 애플리케이션 성능 저하 원인 분석
- DB 연결 및 실행시 발생
- DB Lock
- 불필요한 DB 패치 (DB Fetch)
- 연결 누수
▶ 클린코드 작성 원칙
- 가독성 : 이해하기 쉬운 용어 사용
- 단순성 : 한 번에 한 가지 처리만 수행
- 의존성 최소 : 영향도를 최소화
- 중복성 제거 : 중복된 코드를 제거
- 추상화 : 클래스/메소드/함수에 대한 동일한 수준의 추상화 구현
▶ 리팩토링
기능을 변경하지 않고, 복잡한 소스코드를 수정, 보완하여 가용성 및 가독성을 높이는 기법
'자격증 > 일학습병행 외부평가 : SW개발_L5_20V1' 카테고리의 다른 글
| [일학습병행 외부평가 요약정리][지필] 01. 제품소프트웨어 패키징 (1) | 2024.01.27 |
|---|---|
| [후기] 일학습병행 외부평가 후기 : SW개발_L5_20V1 (2) | 2023.02.23 |
