정보처리기사 - 7. 애플리케이션 테스트 관리

애플리케이션 테스트

테스트종류

• 애플리케이션 테스트 : 잠재되어 있는 결함 찾아내는 행위 또는 절차
•  기본원리
  • 파레토 법칙(Pareto Principle) : 20%에 해당하는 코드에서 전체결함80%발견 
  • 살충제 패러독스(Pesticide Paradox) : 동일한 TC로 여러번 테스트하다보면 결함이 더 이상 발견되지 않음
  • 오류-부재의 궤변(Absence of Errors Fallacy) : 결함이 없어도 요구사항 만족 못하면 품질 높은 것 아님
• 시각에 따른 테스트 
  • 검증(Verification) : 소프트웨어가 기능을 정확히 수행하는지(개발자입장)
  • 확인(Validation) : 고객의 요구사항을 만족시키는지(사용자입장)
• 프로그램 실행 여부에 따른 테스트
  • 정적테스트 : 프로그램을 실행하지 않고 명세서나 소스코드를 대상으로 분석하는 테스트
    • 종류 
      • 워크스루(Walkthrough, 검토회의) : 소프트웨어 검토를 위해 미리 준비된 자료를 바탕으로 정해진 절차에 따라 평가, 오류 조기검출 목적( 검토자료를 회의전에 배포해서 사전검토한 후 짧은 시간동안 회의 진행)
      • 인스펙션(Inspection, 인스펙션) : 워크스루를 발전시킨형태 (저작자 외의 다른전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법)
  • 동적테스트 : 프로그램을 실행하여 오류 찾는 테스트
    • 종류
      • 블랙박스 테스트 , 화이트박스테스트
• 테스트 기반에 따른 테스트
  • 명세 기반 테스트 : 동등 분할, 경계값 분석
  • 구조 기반 테스트 : 구문 기반, 결정 기반, 조건 기반
  • 경험 기반 테스트 : 에러 추정, 체크 리스트, 탐색정 테스팅
• 목적에 따른 테스트
  • 회복 테스트 : 여러가지 결함을 주고 복구되는지 확인
  • 안전 테스트 : 침입으로부터 보호하는지 확인
  • 강도 테스트 : 과부하
  • 성능 테스트 : 응답시간, 처리량 테스트
  • 구조 테스트 : 논리경로, 복잡도 평가
  • 회귀 테스트 : 변경 또는 수정시 결함 없는지 확인. 이미 테스트된 프로그램의 테스팅을 반복
  • 병행 테스트 : 변경 후와 변경 전 소프트웨어에 동일한 데이터 입력하고 비교

테스트 기법에 따른 애플리케이션 테스트

• 화이트박스테스트(White Box Test) 
  • 원시코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계
  • 모듈 안의 작동을 직접 관찰, 모든문장을 한번이상 수행
  • 화이트 박스 테스트 종류  
    • 기초 경로 검사(Base Path Testing) : 대표적인 화이트박스 테스트기법
    • 제어 구조 검사(Control Structure Testing) 
      • 조건검사(Condition Testing) : 논리적 조건을 테스트하는 
      • 루프검사(Loop Testing) : 반복구조에 초점을 맞춰 실시
      • 데이터 흐름 검사(Data Flow Testing) : 변수에 초점을 맞춰 실시
  • 화이트박스 테스트의 검증기준(=커버리지)
    • 분기검증기준(Branch Coverage) : 소스 코드의 모든 조건문이 한번이상 수행되도록 
    • 조건검증기준(Condition Coverage) : 모든조건문에 대해 true인경우 false인 경우 한번이상 수행되도록 테스트케이스 설계
• 블랙박스테스트(Black Box  Test)
  • 각 기능이 완전히 작동되는 것을 입증하는 테스트로 기능테스트라고도 한다.
  • 사용자의 요구사항 명세를 보면서 테스트
    • 블랙박스 테스트 종류
      • 동치분할검사(Equivalence Partitioning Testing) : 타당한 입력자료와 타당하지 않은 입력 자료 개수를 균등하게 입력(동등분할기법)
      • 경계값 분석(Boundary Value Analysis) : 조건의 경계값을 테스트
      • 원인-효과 그래프 검사(Cause-Effect Graphing Testing) : 입력과 출력을 모두를 체계적으로 분석해 효용성이 높은 TC를 선정해 검사 
      • 오류예측검사(Error Guessing) : 경험에 의한 검사
      • 비교 검사(Comparison Tesing) : 여러 버전의 프로그램에 동일한 TC를 제공

 

개발 단계에 따른 애플리케이션 테스트 

• 소프트웨어 개발 단계에 따라 단위테스트, 통합테스트, 시스템테스트,인수테스트로 분류된다.(V-모델)
•  

• 단위테스트(Unit Test)
  • 모듈이나 컴포넌트에 초점을 맞춰 테스트
  • 구조기반테스트 시행(구문기반,결정기반,조건기반)
• 통합테스트(Integration Test)
  • 단위테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 테스트
  • 비점진적 통합 방식 : 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트(빅뱅통합테스트)
  • 점진적 통합 방식 : 모듈 단위로 단계적으로 통합
    • 하향식 통합 : 상위모듈에서 하위모듈방향으로 통합, 제어모듈의 종속모델은 스텁(Stub)으로 대체
      • 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구, 일시적으로 필요한 조건만을 가지고 있는 시험용모듈
      • 깊이 우선 통합법, 넓이 우선통합법 사용
      • 깊이 우선 또는 넓이 우선 등의 통합방식에 따라 하위 모듈인 스텁들이 한번에 하나씩 실제 모듈로 교체
      • 모듈이 통합될때마다 테스트 실시
      • 회귀테스트실시(새로운 오류 발생하지 않음 보장위해)
        • 회귀테스트(Regression Testing) : 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트 
    • 상향식통합 : 하위모듈에서 상위모듈방향으로 통합하면서 테스트
      • 절차 
        • 하위 모듈들을 클러스터(Cluster)로 결합
        • 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버(Driver)를 작성
          • 테스트 드라이버 : 테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈테스트 수행후의 결과를 도출하는 도구
        • 통합된 클러스터 단위로 테스트
        • 테스트가 완료 -> 클러스터는 프로그램 구조의 상위로 이동하여 결합, 드라이버는 실제 모듈로 대체
    • 혼합식 통합 테스트
      • 샌드위치식 통합테스트 , 하위수준에서는 상향 상위수준에서는 하향
• 시스템 테스트 : 개발된 소프트웨어가 완벽하게 수행되는가를 점검
• 인수테스트(Acceptance Test) : 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
  • 개발한 소프트웨어를 사용자가 직접 테스트
  • 알파테스트 : 사용자가 개발자 앞에서 행하는 테스트, 통제된 환경
  • 베타테스트 : 최종사용자가 여러명의 사용자 앞에서 행하는 테스트기법, 실업무를 가지고 테스트

 

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

• 개발된 소프트웨어가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차
• 테스트계획 -> 테스트 분석 및 디자인 -> 테스트케이스 및 시나리오 작성 -> 테스트 수행 -> 테스트 결과 평가 및 리포팅 -> 결함 추적 및 관리
• 결함 관리 프로세스
  • 에러발견 -> 에러등록 -> 에러분석 -> 결함 확정->결함할당->결함조치 -> 결함 조치 검토 및 승인

 

테스트케이스/테스트시나리오/테스트오라클

테스트케이스(Test Case)

• 사용자의 요구사항을 정확하게 준수 했는지를 확인하기 위해 설계된 테스트 항목에 대한 명세서
• 오류 방지, 인력, 시간 등 자원 낭비를 줄임

테스트시나리오(Test Scenario)

• 테스트 케이스 묶은 집합(테스트 케이스를 적용하는 순서에따라)
• 테스트 케이스를 적용하는 구체적인 절차를 명세

테스트오라클(Test Oracle)

• 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법
• 특징 
  • 제한된 검증, 수학적기법, 자동화기능
• 종류
  • 참(True) 오라클 : 모든테스트케이스의 입력값에 대해 기대하는 결과를 제공하는 오라클
  • 샘플링 오라클 : 특정 몇몇 테스트 케이스의 입력값들에 대해서만 기대하는 결과를 제공하는 오라클
  • 추정(Heuristic)오라클 : 특정 입력 값 기대 결과 제공, 나머지는 추정으로 처리하는 오라클
  • 일관성(Consistent)오라클 : 변경 있을 때 테스트 케이스 수행 전과 후의 결과 동일한지 확인하는 오라클

 

테스트 자동화 도구

• 정적 분석 도구(Static Analysis Tools) : 프로그램을 실행하지 않고 분석하는 도구
• 테스트 실행 도구(Test Execution Tools) : 스크립트 언어를 사용하여 테스트를 실행하는 도구
• 성능 테스트 도구(Performance Test Tools) : 처리량, 응답시간, 경과시간 등을 가상의 사용자를 만들어 목표달성 여부 확인하는 도구 
• 테스트 통제 도구(Test Control Tools) : 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
• 테스트 하네스 도구(Test Harness Tools) : 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구
  • 테스트하네스(Test Harness) : 테스트하는 환경의 일부분, 테스트를 지원하기 위해 생성된 코드 데이터 
  • 테스트 하네스 구성요소
    • 테스트 드라이버 : 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행후의 결과를 도출
    • 테스트 스텁 : 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
    • 테스트 슈트 : 테스트 케이스의 집합
    • 테스트 케이스 : 입력값,실행조건,기대 결과 등으로 만들어진 테스트 항목의 명세서
    • 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서
    • 목 오브젝트 : 사전에 행위를 조건부로 입력해두면 상황에 맞는 예정된 행위를 수행하는 객체

 

결함(Fault)

• 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것
• 결함 상태 추적
  • 결함은 지속적으로 상태변화를 추적하고 관리
  • 결함 관리 측정 지표
    • 결함 분포 : 결함 수 측정
    • 결함 추세 : 결함 수의 추이 분석
    • 결함 에이징 : 특정 결함 상태로 지속되는 시간 측정
• 결함 분류
  • 시스템 결함 : 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함
  • 기능 결함 : 애플리케이션 기획,설계,업무 시나리오 등에 단계에서 유입된 결함
  • GUI 결함 : 사용자 화면 설계에서 발생된 결함
  • 문서 결함 : 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함
• 결함 심각도/우선순위
  • 결함 심각도 : 결함이 전체 시스템에 미치는 치명도를 나타내는 척도
    • High, Medium, Low, 치명적(Critical), 주요(Magor), 보통(Normal), 경미(Minor), 단순(Simple)
  • 결함 우선순위 : 결함 처리에 신속성을 나타내는 척도
    • 결정적(Critical), 높음(High), 보통(Medium), 낮음(Low), 즉시해결, 주의요망, 대기,개선 권고

 

 

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

• 처리량(Throughput) : 일정 시간 내 애플리케이션이 처리하는 일의 양
• 응답시간(Response Time) : 요청을 전달한 시간부터 응답이 도착할 때 까지 걸린 시간
• 경과시간(Turn Around Time) : 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때 까지 걸린 시간
• 자원 사용률(Resource Usage): 작업 처리 동안 CPU 사용량, 메모리 사용량 등 자원 사용률

 

 

성능 테스트 도구

• 애플리케이션 성능을 테스트 하기 위해 성능 측정 지표를 점검하는 도구
• JMeter : HTTP, FTP 등 다양한 프로토콜 지원하는 부하 테스트 도구
• LoadUI : 서버 모니터링, Drag&Drop 등 사용자 편리성이 강화된 부하 테스트 도구
• OpenSTA : HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구 

 

시스템 모니터링 도구

• 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
• Scouter : 단일 뷰 통합/ 실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구
• Zabbix : 웹 기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

 

복잡도(Complexity)

• 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말
• 시간 복잡도 : 알고리즘 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화 한것
• 순환 복잡도(Cyclomatic Complexity) 
  • 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
  • 맥케이브 순환도(McCabe's Cyclomatic) 또는 맥케이브 복잡도 메트릭(McCabe's Complexity Metrics)라고도함
  • V(G) = E - N +2 ( E: 화살표수 , N: 노드수)

 

소스코드최적화

• 나쁜코드(Bad Code)를 배제하고, 클린코드(Clean Code)로 작성하는 것
  • 클린코드(Clean Code):누구나 이해하고 수정 및 추가할 수 있는 단순,명료한 코드
  • 나쁜코드(Bad Code) : 로직이 복잡, 이해하기 어려운 코드
    • 스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀있는
    • 외계인 코드 : 아주 오래되거나, 유지보수 작업이 어려운 코드
  • 클린 코드 작성 원칙 
    • 단순성 : 코드를 간단하게 작성, 한번에 한가지를 처리하도록 작성
    • 가독성 : 누구나 쉽게 읽을 수 있게, 이해하기 쉬운 용어 사용
    • 의존성 배제 : 코드가 다른 모듈에 미치는 영향 최소화
    • 중복성 최소화 : 중복 최소화, 공동 코드 사용
    • 추상화 : 클래스,메소드,함수에서 간략하게 특성을 나타내고 상세내용은 하위구현

 

소스코드품질분석도구

• 정적분석도구 : 코드 실행없이 결함 확인하는 분석도구
  • pmd, cppcheck, checkstyle, ccm, cobertura, SonarQube
• 동적분석도구 : 코드를 실행하여 결함을 분석하는 도구
  • Avalanche, Valgrind