9 분 소요

애플리케이션 테스트 관리

  • 애플리케이션 테스트
    • 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
    • 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인하고 소프트웨어가 기능을 정확히 수행하는지 검증한다
  • 애플리케이션 테스트의 기본 원리
    • 파레토 법칙 - 애플리케이션 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
    • 살충제 패러독스 - 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
    • 오류-부재의 궤변 - 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것
  • 프로그램 실행 여부에 따른 테스트
    • 정적 테스트 - 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
      • 종류 - 워크스루, 인스펙션, 코드 검사 등
    • 동적 테스트 - 프로그램을 실행하여 오류를 찾는 테스트
      • 종류 - 블랙박스 테스트, 화이트박스 테스트
  • 테스트 기반에 따른 테스트
    • 명세 기반 테스트 - 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트
      • 종류 - 동등 분할, 경계 값 분석 등
    • 구조 기반 테스트 - 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트
      • 종류 - 구문 기반, 결정 기반, 조건 기반 등
    • 경험 기반 테스트 - 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트
      • 종류 - 에러 추정, 체크 리스트, 탐색적 테스팅
  • 시각에 따른 테스트
    • 검증 테스트 - 개발자의 시작에서 제품의 생산 과정을 테스트하는 것, 제품이 명세서대로 완성됐는지를 테스트
    • 확인 테스트 - 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것, 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트
  • 목적에 따른 테스트
    • 회복 테스트 - 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
    • 안전 테스트 - 시스템에 설치된 시스템 보호 도구가 불법적인 칩입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
    • 강도 테스트 - 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
    • 성능 테스트 - 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트
    • 구조 테스트 - 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
    • 회귀 테스트 - 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
    • 병행 테스트 - 변경된 소프트웨어의 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
  • 화이트박스 테스트
    • 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
  • 화이트박스 테스트의 종류
    • 기초 경로 검사 - 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
    • 제어 구조 검사
      • 조건 검사 - 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
      • 루프 검사 - 프로그램의 반복구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
      • 데이터 흐름 검사 - 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
  • 화이트박스 테스트의 검증 기준
    • 문장 검증 기준 - 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계한다
    • 분기 검증 기준 - 소스 코드의 모든 조건문에 대해 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계한다
    • 조건 검증 기준 - 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스를 설계한다
    • 분기/조건 기준 - 분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계로, 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계한다
  • 블랙박스 테스트
    • 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
  • 블랙박스 테스트의 종류
    • 동치 분할 검사 - 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법
    • 경계값 분석 - 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
    • 원인-효과 그래프 검사 - 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
    • 오류 예측 검사 - 과거의 경험이나 확인자의 감각으로 테스트하는 기법
    • 비교 검사 - 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트하는 기법
  • 개발 단계에 따른 애플리케이션 테스트
    • 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 분류
    • V-모델
      • 요구사항 - 인수 테스트
      • 분석 - 시스템 테스트
      • 설계 - 통합 테스트
      • 구현 - 단위 테스트
  • 단위 테스트
    • 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트하는 것
  • 통합 테스트
    • 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트
    • 비점진적 통합 방식 - 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법
      • 종류 - 빅뱅 통합 테스트 방식
    • 점진적 통합 방식 - 모듈 단위로 단계적으로 통합하면서 테스트하는 방법
      • 종류 - 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트
  • 시스템 테스트
    • 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
  • 인수 테스트
    • 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
    • 인수 테스트의 종류
      • 알파 테스트 - 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법
      • 베타 테스트 - 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법
  • 하향식 통합 테스트
    • 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
    • 하향식 통합 테스트 절차
      • 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈인 스텁으로 대체
      • 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
      • 모듈이 통합될 때마다 테스트를 실시
      • 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트를 실시
    • 스텁 - 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
  • 상향식 통합 테스트
    • 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
    • 상향식 통합 테스트 절차
      • 하위 모듈들을 클러스터로 결합한다
      • 상위 모듈에서 데이터의 입.출력을 확인하기 위해 더미 모듈인 드라이버를 작성
      • 통합된 클러스터 단위로 테스트
      • 테스트가 완료되면 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체
    • 테스트 드라이버 - 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
  • 혼합식 통합 테스트
    • 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식
    • 샌드위치식 통합 테스트 방법
  • 회귀 테스트
    • 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트
  • 테스트 케이스
    • 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서
  • 테스트 시나리오
    • 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스를 묶은 집합
  • 테스트 오라클
    • 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법 및 활동
    • 테스트 오라클의 특징 - 제한된 검증, 수학적 기법, 자동화 기능
  • 테스트 오라클의 종류
    • 참 오라클 - 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클, 발생된 모든 오류를 검출할 수 있음
    • 샘플링 오라클 - 특정한 몇몇 테스트 케이스의 입력 값에 대해서만 기대하는 결과를 제공하는 오라클, 전수 테스트가 불가능한 경우 사용하는 오라클
    • 추정 오라클 - 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
    • 일관성 검사 오라클 - 애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클
  • 테스트 자동화 도구
    • 정적 분석 도구 - 프로그램을 실행하지 않고 분석하는 도구, 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함 등을 발견하기 위해 사용
    • 테스트 실행 도구 - 스크립트 언러를 사용하여 테스트를 실행하는 도구, 테스트 데이터와 테스트 수행 방법 등이 포함된 스크립트를 작성한 후 실행
    • 성능 테스트 도구 - 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구
    • 테스트 통제 도구 - 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
    • 테스트 하네스 도구 - 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구
      • 테스트 하네스 - 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위해 생성된 코드와 데이터를 의미
  • 테스트 하네스의 구성 요소
    • 테스트 드라이버 - 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
    • 테스트 스텁 - 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
    • 테스트 슈트 - 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
    • 테스트 케이스 - 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서
    • 테스트 스크립트 - 자동화된 테스트 실행 절차에 대한 명세서
    • 목 오브젝트 - 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
  • 결함
    • 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
  • 결함 상태 추적
    • 결함 관리 측정 지표
      • 결함 분포 - 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
      • 결함 추세 - 테스트 진행 시간에 따른 결함 수의 추이 분석
      • 결함 에이징 - 특정 결함 상태로 지속되는 시간 측정
  • 결함 분류
    • 시스템 결함 - 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
    • 기능 결함 - 애플리케이션의 기획, 설계, 업무, 시나리오 등의 단계에서 유입된 결함
    • GUI 결함 - 사용자 화면 설계에서 발생된 결함
    • 문서 결함 - 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함
  • 결함 심각도/우선순위
    • 결함 심각도 - 애플리케이션에 발생한 결함이 전체 시스템에 미치는 치명도를 나타내는 척도
      • High, Medium, Low 또는 치명적, 주요, 보통, 경미, 단순 등으로 분류
    • 결함 우선순위 - 발견된 결함 처리에 신속성을 나타내는 척도
      • 결정적, 높음, 보통, 낮음, 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류
  • 애플리케이션 성능 측정 지표
    • 처리량 - 일정 시간 내에 애플리케이션이 처리하는 일의 양
    • 응답 시간 - 애플리케이션에 요청을 전달할 시간부터 응답이 도착할 때까지 걸린 시간
    • 경과 시간 - 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간
    • 자원 사용률 - 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률
  • 성능 테스트 도구
    • 애플리케이션의 성능을 테스트하기 위해 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션 성능 측정 지표를 점검하는 도구
    • JMeter - HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구
    • LoadUI - 서버 모니터링, Drag&Drop 등 사용자의 편리성이 강화된 부하 테스트 도구로, HTTP, JDBC 등 다양한 프로토콜을 지원함
    • OpenSTA - HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구
  • 시스템 모니터링 도구
    • 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
    • Scouter - 단일 뷰 통합/실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구, 애플리케이션의 성능을 모니터링/통제
    • Zabbix - 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구
  • 복잡도/시간 복잡도
    • 복잡도 - 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도
    • 시간 복잡도 - 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화 한것
      • 빅오 표기법 - 알고리즘의 실행시간이 최악일 때를 표기하는 방법
  • 빅오 표기법으로 표현한 최악의 시간 복잡도
    • O(1) - 입력값에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침, 스택의 삽입, 삭제
    • O(log₂n) - 문제 해결에 필요한 단계가 입력값 또는 조건에 의해 감소함, 이진 트리, 이진 검색
    • O(n) - 문제 해결에 필요한 단계가 입력값과 1:1관계를 가짐, for문
    • O(nlog₂n) -문제 해결에 필요한 단게가 nlog₂n번만큼 수행됨, 힙 정렬, 2-Way 합병 정렬
    • O(n²) - 문제 해결에 필요한 단계가 입력값의 제곱만큼 수행됨, 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬
    • O(2ⁿ) - 문제 해결에 필요한 단계가 2의 입력값 제곱만큼 수행됨, 피보나치 수열
  • 순환 복잡도
    • 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
  • 소스코드 최적화
    • 나쁜 코드를 배제하고, 클린 코드로 작성하는 것
    • 클린 코드 - 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉 잘 작성된 코드
    • 나쁜 코드 - 프로그램의 로직이 복잡하고 이해하기 어려운 코드
      • 스파게티 코드 - 코드의 로직이 서로 복잡하게 얽혀 있는 코드
      • 외계인 코드 - 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
  • 클린 코드 작성 원칙
    • 가독성 - 누구든지 코드를 쉽게 읽을 수 있도록 작성한다, 코드 작성 시 이해하기 쉬운 용어를 사용하거나 들여쓰기 기능 등을 사용
    • 단순성 - 코드를 간단하게 작성한다, 한 번에 한 가지를 처리하도록 코드를 작성하고 클래스/메소드/함수 등을 최소 단위로 분리
    • 의존성 배제 - 코드가 다른 모듈에 미치는 영향을 최소화한다, 코드 변경 시 다른 부분에 영향이 없도록 작성
    • 중복성 최소화 - 코드의 중복을 최소화한다, 중복된 코드는 삭제하고 공통된 코드를 사용
    • 추상화 - 상위 클래스/메소드/함수에서는 간략하게 애플리케이션의 특성을 나타내고, 상세 내용은 하위 클래스/메소드/함수에서 구현한다
  • 소스 코드 품질 분석 도구
    • 소스 코드 품질 분석 도구는 소스 코드의 코딩 스타일, 코드에 설정된 코딩 표준, 코드의 복잡도, 코드에 존재하는 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구
    • 정적 분석 도구 - 작성한 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
      • 종류 - pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
    • 동적 분석 도구 - 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
      • 종류 - Avalanche, Valgrind 등

댓글남기기