chapter7. 애플리케이션 테스트 관리

Yeppi's 개발 일기·2022년 5월 9일
1

정보처리기사

목록 보기
4/7

😳혹시 요약집 복사하실 분들은 댓글이나 공감 눌러주세요😳

애플리케이션 테스트

애플리케이션에 잠재되어있는 결함을 찾아내는 일련의 행위 또는 절차

Verification 검증 → 개발자 입장, 소프트웨어 명세서 만족
Validation 확인 → 사용자 입장, 고객 요구사항 만족

애플리케이션 테스트 기본 원리

완벽한 테스팅은 불가능

잠재적 결함, 줄, 없, 증명 불가

잠재적인 결함일 수 있지만, 결함이 없다증명할 수는


파레토 법칙 Pareto Principle)

20%, 전체 결함, 80%

애플리케이션의 20% 코드에서 전체 결함의 80%가 발견

살충제 패러독스(Pesticide Paradox)

동일한 테스트 케이스, 반복, 결함X

동일한 테스트 케이스로 테스트를 반복하면, 더 이상 결함발견되지 않음


테스팅은 정황(Context)에 의존적

정황, 결과X, 다른 테스트

정황에 따라 테스트 결과달라질 수 있기에, 정황에 따라 다른 테스트를 수행


오류-부재의 궤변 Absence of Errors Fallacy

결함, 제거, 사용자 요구사항, 만족X, 품질X

결함모두 제거해도 사용자 요구사항만족시키지 하면,
소프트웨어 품질높다고 말할 수 없음


테스트와 위험은 반비례

테스트 많이 할수록, 미래 발생할 위험은 줄어듬


테스트는 점진적 확대

테스트는 적은 부분부터 시작해서 점점 확대


테스트는 별도 팀 수행

테스트는 개발자와는 관계 없는 별도 팀에서 수행


애플리케이션 테스트 분류

실행 여부 따라

정적 테스트 → 실행X

  • 워크스루(검토회의) → 전문가 직접 검토, 미리 준비된 자료로 정해진 절차따라, 오류 조기 검출

  • 인스펙션 → 워크스루 발전, 산출된 결과물 품질 평가 및 개선 방법 제시


동적 테스트 → 실행 O, 모든 단계

화이트박스 테스트
블랙박스 테스트

테스트 기반에 따라

명세 기반 테스트 → 사용자 요구사항 명세

구조 기반 테스트 → sw 내부 논리 흐름

경험 기반 테스트 → 테스터의 경험, 체크리스트

시각에 따라

Verification 검증 테스트 → 개발자 시각, 제품 명세서

Validation 확인 테스트 → 사용자 시각, 사용자 요구사항

목적에 따라

Recovery 회복 테스트 → 실패시키고 올바르게 복구되는가

Security 안전 테스트 → 보호 도구가 불법 침임으로부터 보호하는 가

Stress 강도 테스트 → 과부하 시 정상적으로 실행되는 가

Performance 성능 테스트 → 실시간 성능, 전체 효율성응답시간처리량, 모든 단계

Structure 구조 테스트 → 내부 논리적 경로, 소스코드 복잡도

Regression 회귀 테스트 → 변경/수정된 코드에 새로운 결함이 없는 가. 반복 테스트

Parallel 병행 테스트 → 변경된 sw 와 기존 sw에 동일한 데이터 입력하여 결과 비교


테스트 기법에 따라

화이트박스 테스트**(White Box Test)

내부, 논리적 경로

모듈 안의 내용을 볼 수 있어서, 내부논리적인 모든 경로를 테스트


종류

기초 경로 검사대표적. 절차적 설계의 논리적 복잡성을 측정

제어 구조 검사조건 검사 : 논리적 조건

                   루프 검사 : 반복(loop) 구조

              데이터 흐름 검사 :  변수의 정의, 사용 위치 

검증 기준

문장 검증 기준모든 구문 한 번 이상

분기 검증 기준 → 모든 조건문의 조건식 결과가 (True, False) 한 번 이상

조건 검증 기준 → 조건문의 개별 조건식 결과가 (True, False) 한 번 이상

분기/조건 기준 → 분기 검증 기준, 조건 검증 기준 모두 만족
조건문 결과 따라 조건 검증 기준의 입력 데이터를 구분

⇒ 동적 테스트, 구조 기반 테스트에 해당



블랙박스 테스트**(Black Box Test) = 기능 테스트

기능, 완전 작동, 입증

기능완전히 작동되는 것을 입증하는 테스트


종류

Equivalence Partitioning Testing
동치 분할 검사(동등 분할 검사)

타당한, 타당하지 않은 입력 자료 개수 균등하게 맞추고 입력 자료에 맞는 결과가 출력하는 지 확인


Boundary Value Analysis **경계값 분석**

중간값보다 경계값에서 오류 발생 확률 높음, 경계값을 테스트 케이스로


Cause-Effect Graphing Testing **원인-효과 그래프 검사**

입력 데이터간 관계와 출력에 영향 미치는 상황을 분석한 후, 효용성 높은 테스트 케이스 선정


Error Guessing **오류 예측 검사**

과거경험, 확인자 감각으로 테스트


Comparsion Testing **비교 검사**

여러 버전동일한 테스트 자료 제공하여, 동일한 결과 출력되는 지 테스트




⇒ 동적 테스트, 명세 기반 테스트, 경험 기반 테스트에 해당


V-모델

소프트웨어 개발 단계와 애플리케이션 테스트를 연결하여 표현

[ 소프트웨어 개발 단계 ] 요구사항 → 분석 → 설계 → 구현

⇒ [ 애플리케이션 테스트 단계 ] 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트

개발 단계에 따라

단위 테스트 Unit Test

최소 단위 모듈 또는 컴포넌트 테스트


⇒ 구조 기반 테스트 시행



통합 테스트 Integration Test

모듈 결합하여 시스템으로 완성시키는 과정

모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트

종류

비점진적 통합 방식 → 절차 없이, 모든 모듈이 미리 결합된 프로그램 전체 테스트

  • 빅뱅 통합 테스트 : 모듈 한꺼번에 결합. 소규모/일부분

점진적 통합 방식 → 모듈 단위로 단계적 통합

  • 하향식 통합 테스트 : 스텁 / 상위 → 하위 / 깊이 우선 통합법, 넓이 우선 통합법

  • 상향식 통합 테스트 : 테스트 드라이버 / 하위 → 상위 / 클러스터로 결합

    *Stub : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구

    *Test Driver : 테스트 대상의 하위 모듈을 호출

    *Driver : 상위 모듈에서 데이터 입출력을 확인하기 위한 더미 모듈

    *Cluster : 하나의 주요 제어 모듈과 관련된 종속 모듈의 집합

  • 혼합식 통합 테스트 : 하위 수준에서 상향식 통합, 상위 수준에서 하향식 통합
    (= 샌드위치식 통합 테스트)


⇒ 회귀 테스트


시스템 테스트 System Test

개발된 SW가 완벽하게 수행되는 지 점검

기능적 요구사항
비기능적 요구사항


인수 테스트 Acceptence Test

사용자 요구사항 충족하는 지 테스트. 사용자가 직접 테스트

사용자 인수 테스트 → 사용자가

운영상의 인수 테스트 → 시스템 관리자가

계약 인수 테스트

규정 인수 테스트


알파 테스트 → 사용자가 개발자 앞에서

베타 테스트 → 선정된 최종 사용자가 여러 사용자 앞에서


애플리케이션 테스트 프로세스

  1. 테스트 계획
  2. 테스트 분석 및 디자인 : 사용자 요구사항 분석
  3. 테스트 케이스 및 테스트 시나리오 작성
  4. 테스트 수행
  5. 테스트 결과 평가 및 리포팅
  6. 결함 추적 관리

결함 관리 프로세스

  1. 에러 발견
  2. 에러 등록
  3. 에러 분석
  4. 결함 확정
  5. 결함 할당
  6. 결함 조치
  7. 결함 조치 검토 및 승인

⇒ 결함인지 아닌지 판별하는 것에 초점

테스트 케이스(Test Case)

사용자 요구사항, 정확 준수, 확인, 테스트항목 명세서

사용자의 요구사항정확하게 준수하는 지 확인하기 위해 설계된 테스트 항목의 명세서

테스트 시나라오(Test Scenario)

테스트 케이스, 적용 순서, 묶은 집합

테스트 케이스적용하는 순서(동작하는 순서)에 따라 여러개의 테스트 케이스를 묶은 집합

테스트 오라클(Test Oracle)

테스트 결과, 올바른, 사전, 참 값, 비교

테스트 결과올바른지 판단하기 위해, 사전에 정의된 참 값을 대입하여 비교하는 기법

테스트 오라클 종류

참 오라클 True

모든 테스트 케이스의 입력 값에 대해 기대하는 결과 제공
모든 오류 검출


샘플링 오라클 Sampling

특정 몇몇 테스트 케이스의 입력 값들에 대해서 기대하는 결과 제공
전수 테스트 불가능


휴리스틱(추정) 오라클 Heuristic

특정 테스트 케이스의 입력 값에 대해 기대하는 결과 제공,
나머지 입력 값들에 대해서는 추정


일관성 검사 오라클 Consistent

애플리케이션 변경이 있을 때,
테스트 케이스의 수행 전수행 후결과 값동일한 지 확인


테스트 자동화 도구

정적 분석 도구

프로그램을 실행하지 고 분석하는 도구


테스트 실행 도구

스크립트 언어를 사용하여 테스트를 실행하는 도구

데이터 주도 접근 방식
키워드 주도 접근 방식


성능 테스트 도구

가상의 사용자를 만들어 테스트를 수행함으로써, 성능의 목표 달성 여부를 확인하는 도구

부하나 스트레스를 가하면서 애플리케이션 성능 측정 지표를 점검하는 도구


테스트 통제 도구

테스트 계획, 관리, 수행, 결함 관리 등 수행하는 도구


테스트 하네스 도구

테스트가 실행될 환경시뮬레이션하여,
모듈 및 컴포넌트가 정상적으로 테스트되도록 하는 도구


구성 요소

테스트 드라이버
테스트 스텁
테스트 슈트 → 테스트 케이스의 단순한 집합
테스트 케이스
테스트 스크립트 → 테스트 실행 절차
목 오브젝트 → 사전에 사용자 행위조건부로 입력해두면, 예정된 행위 수행하는 객체


결함 관리 프로세스

  1. 결함 관리 계획
  2. 결함 등록
  3. 결함 검토
  4. 결함 수정
  5. 결함 재확인
  6. 결함 상태 추적 및 모니터링 활동
  7. 최종 결함 분석 및 보고서 작성

⇒ 결함 처리 과정에 초점

결함 관리 측정 지표 3가지

결함 분포 → 결함 수

결함 추세 → 결함 수 추이

결함 에이징 → 지속 시간


애플리케이션 성능 측정 지표 4가지

처리량 Throughput → 일정 시간 내 애플리케이션이 처리하는 일의 양

응답시간 Response Time → 요청 전달 ~ 응답 도착까지 걸린 시간

경과시간 Turn Around Time → 작업 의뢰 ~ 처리 완료까지 걸린 시간

자원사용률 Resource Usage → CPU, 메모리, 네트워크 사용량 등

애플리케이션 성능 분석 도구

성능 테스트 도구 → 성능 측정 지표 점검

시스템 모니터링 도구 → 시스템 자원 사용량 확인


시간 복잡도

알고리즘, 프로세스, 연산 횟수, 수치화

알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수수치화한 것

시간이 아닌, 명령어의 실행 횟수를 표기 → 점근 표기법

접근 표기법 종류

빅오 표기법 Big-O Notation → 알고리즘 실행시간이 최악일 때를 표기. O(1) O(n)

세타 표기법 Big-Θ Notation → 알고리즘 실행시간이 평균일 때를 표기

오메가 표기법 Big-Ω Notation → 알고리즘 실행시간이 최상일 때를 표기

순환 복잡도(Cyclomatic Complexity)

논리적 복잡도, 측정, sw 척도
논리적인 복잡도측정하기위한 소프트웨어의 척도

= 맥케이브 순환도(McCabe’s Cyclomatic)
= 맥케이브 복잡도 메트릭(McCabe’s Complexity Metrics)

순환 복잡도 = 화살표 수 - 노드 수 + 2
V(G) = E - N + 2


소스 코드 최적화

나쁜 코드배제하고, 클린 코드작성하는 것

클린 코드(Clean Code)

누구나 쉽게 이해하고, 단순 명료한 코드

클린 코드 작성 원칙 5가지

가독성 → 누구든지 쉽게 읽도록

단순성 → 간단하게, 최소 단위

의존성 배제 → 다른 모듈에 미치는 영향 최소화

중복성 최소화 → 공통된 코드 사용

추상화 → 상위클래스에서는 간략한 기능만, 하위클래스에서 상세한 구현

나쁜 코드(Bad Code)

프로그램 로직이 복잡하고 이해하기 어려운 코드

스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀 있는 코드

외계인 코드 : 아주 오래되거나, 참고문서나 개발자가 어서 유지보수가 어려운 코드

profile
imaginative and free developer. 백엔드 / UX / DATA / 기획에 관심있지만 고양이는 없는 예비 개발자👋

0개의 댓글