이 글은 이기적 정보처리기능사 실기 기본서를 기반으로 제작되었습니다.

소개

이번 시간엔 새로운 Part와 Chapter를 들어가봅시다!
애플리케이션 테스트 수행입니다!
비전공자이신 분들은 여기서 많이 갈려나가시겠지만, 이 고통을 이겨내시면 진정한 개발자가 되실겁니다.
자! 시작해봅시다!

1. 테스트

테스트의 개념

• 1) 개요

  • 테스트란? 개발된 응용 애플리케이션이나 시스템의 사용자가 요구하는 기능, 성능, 사용상, 안정성 등을 확인하고 노출되지 않은 숨어있는 결함을 찾아내는 활동이다.
    테스트 과정에 필요한 역할은 소포트웨어 아키텍트와 테스트 매니저이다.
    
  • 두 역할은 소포트웨어 생명 주기의 V모델에서 각각 좌측과 우측에 핵심 역할을 담당하고 서로 보완 관계에 있다.
  • 소포트웨어 생명 주기는 요구사항, 분석, 디자인, 구현 또는 개발순으로 진행된다.
  • 프로젝트의 특성과 방법론에 따라 반복적으로 수행 된다.
  • 테스트는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트의 순으로 진행된다.

• 2) 테스트의 7가지 원칙

  1. 테스트는 계획 단계부터 한다.

     • 테스트 활동은 소포트웨어 개발 주기에서 가능한 초기부터 시작해야 한다.

  2. 테스트는 결함을 밝히는 활동이다.

     • 테스트의 목적은 결함의 제거가 아닌, 결함의 발견이다.
     • 테스트는 결함이 있다는 것을 보여줄 수 있지만 결함이 없다는 것을 증명할 수는 없다.

  3. 완전한 테스트는 불가능하다.

     • 모든 것(입력값, 경로, 타이밍)에 대한 테스팅은 자원의 한계로 불가능하다.

  4. 테스트는 상황에 따라 다르다.

     • 애플리케이션 테스트에서도 동일한 테스트에 대한 비정상적인
       결함 검수가 이루어 질 수 있다.
     • 이러한 현상을 방지하기 위해서는 다양한 방법으로 테스트하는 것이 필요하다.

  5. 결함 집중을 고려한다.

     • 대부분 결함은 소수의 특정 모듈에 집중되어 발생하는 경향을 보인다.
     • 결함의 80%는 20% 코드에 집중되어 있다. 즉, 결함이 높은 곳에 자원이 집중되어 있다.
     • 이것을 파레토 법칙이라 한다.

  6. 살충제 페러독스를 고려한다.

     • 동일한 테스트 케이스에 의한 반복적 테스트로 새로운 버그를 찾지 못하는 내성 현상을 의미한다.

  7. 오류 부재의 궤변을 고려한다.

     • 개발한 제품이 사용자의 필요와 기대에 부응하지 못하고 쓸모가 없다면 결함을 찾는 활동은 의미가 없다.
     • 개발한 제품은 요구 사항과 일치하고 사용에 적합해야 한다.

2. 프로젝트 수행 단계에 따른 테스트의 분류

1. 단위 테스트

• 작은 소포트웨어 단위(컴포넌트 또는 모듈)을 테스트하는 것으로, 일반적으로 개발자 자신에 의해 진행된다.
• 과거에는 시간 부족을 이유로 단위 테스트가 생략되었으나, 최근에는 개발 도구의 발전으로 개발 과정 중에 자동으로 진행된다.
• 단위테스트는 아주 중요한 부분이므로 개발 도구에서 지원하지 않아도 반드시 수행해야 한다.
• 구조적 테스트, 기능성 테스트, 리소스 관련 테스트, 강건성 테스트 등 특정 비기능성 테스트 등이 포함되어 수행된다.
• 컴포넌트 명세, 소포트웨어 상세 설계, 데이터 모델 명세 등을 이용하여 테스트한다.
  
• 화이트박스 테스트 : 개발자 관점, 구조와 동작 기반의 테스트
  종류 : 기초 경로 테스트 , 제어 흐름 테스트, 조건 테스트, 루프 테스트, 데이터 흐름 테스트 등
• 블랙박스 테스트 : 사용자 관점, 명세 기반의 테스트
  종류 : 균등 분할 (등치분해), 한계값(경계값) 테스트, 원인 효과 그래프 테스트, 비교 테스트 등

2. 통합 테스트

• 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 테스트한다.
• 하나의 프로세스가 완성된 경우 부분적으로 통합 테스트를 수행하는 경우도 있다.
• 일반적으로 빅뱅 방식보다는 순차적 형태와 아키텍처에 대한 이해를 바탕으로 된다.
• 빅뱅, 상향식, 하향식, 샌드위치, Central, Collaboration, 레이어 통합 등의 테스트가 있다.
  
• 드라이버 : 상향식 테스트 방식의 존재하지 않는 상위 모듈 간의 인터페이스 역활
• 스텁 : 하향식 테스트 방식의 작성이 쉬운 시험용 모듈

3. 시스템 테스트

• 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지 테스트한다.
  성능 및 장애 테스트가 여기에 포함된다.
• 시스템 테스트는 개발 프로젝트 차원에서 정의된 전체 시스템의 동작과 관련된다.
• 환경 제한적 장애 관련 리스크를 최소화하기 위하여 실제의 최종 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능/비기능적인 요구사항 등이 완벽하게 수행되는지를 테스트한다.
• 요구사항 명세서, 비즈니스 절차, 유스케이스, 리스크 분석 결과 등을 이용한다.
• 유스케이스 : 시스템의 동작을 사용자의 입장에서 표현한 시나리오이다. 시스템에 관련된 요구사항을 알아내는 과정으로 생각하면 된다.

  업무 기반의 기능적 요구사항
  요구사항 명세서, 비즈니스 절차, 유스케이스 등 명세서 기반의 블랙박스 테스트
  시스템적인 비기능적 오구사항
  성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템의 메뉴 구조, 웹 페이지의 네비게이션 등의 구조적 요소에 대한 화이트박스 테스트

4. 인수 테스트

• 일반적으로 최종 사용자와 업무에 따른 이해관계자 등이 테스트를 수행한다.
• 개발된 제품에 대해 운영 여부를 결정하는 테스트로, 실제 업무 적용 전에 수행한다.
• 방법은 다음과 같다.
  1. 사용자 인수 테스트
     • 비즈니스 사용자가 시스템 사용의 적절성 여부를 확인하는 테스트 활동이다.
  2. 운영상의 인수 테스트
     • 시스템 관리자가 시스템 인수시 수행하는 테스트 활동이다.
     • 백업/복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인한다.
  3. 계약 인수 테스트
     • 계약상의 인수 / 검수 조건을 준수하는지 확인하는 테스트 활동이다.
  4. 규정 인수 테스트
     • 정부 지침, 법규, 규정 등 규정에 맞게 개발하였는지 확인하는 테스트 활동이다.
  5. 알파 테스트
     • 개발하는 조직 내 잠재 고객에 의해 수행하는 테스트 활동이다.
  6. 베타 테스트
     • 실제 환경에서 고객에 의해 수행하는 테스트 활동이다.

3. 테스트 케이스와 테스트 오라클

1. 테스트 케이스

• 명세 기반 테스트의 설계 산출물이다.
• 특정한 프로그램의 일부분 또는 경로에 따라 수행하거나, 특정한 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서를 말한다.
• 미리 설계하여 오류를 방지할 수 있고 테스트 수행에 필요한 인력, 시간 등의 낭비를 축소할 수 있다.
• 테스트 케이스 작성 절차는 아래에 나와있다.
  

2. 테스트 오라클

• 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여
  비교하는 기법 및 활동을 의미한다.
• 테스트 오라클 유형은 다음과 같다.
  1. 참 오라클
     • 모든 입력값의 기대 결과를 생성, 발생한 오류를 모두 검출한다.
  2. 샘플링 오라클
     • 특정한 입력값들에 대해서만 기대하는 결과를 제공한다.
  3. 휴리스틱(추정) 오라클
     • 샘플링 오라클을 개선한 오라클이다.
     • 특정 입력값에 대해 올바른 결과를 제공하고 나머지 값들에 대해서는 휴리스틱으로 처리한다.
  4. 일관성 검사 오라클
     • 애플리케이션 병경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인한다.

4. 테스트 자동화

1. 배경

소포트웨어 테스트는 소포트웨어 개발에 소요되는 총 시간과 비용의 절반 이상을 차지할 정도로 많은 자원이 투입되는 프로세스이다.
따라서, 테스트의 정확성을 유지하면서 시간과 비용을 줄일 수 있는 도구가 필요하게 되었다.
그래서 나온것이 자동화 도구이다.

2. 테스트 자동화

• 테스트 자동화의 개념

  • 테스트 자동화란? 사람이 하던 반복적 테스트 절차를 자동화 도구를 활용하여 테스트하는 것이다.
  • 쉽게 예를 들자면.. 게임에 자동전투모드를 예로 들수있다.
    • 우리가 게임을 할 때 직접 전투를 하면 재밌지만.. 그것들을 반복한다고 생각해보라.. 노다가에 반복이 우리를 반겨줄 것이다.
    • 그래서 자동전투모드가 지금와서는 필요한 존재가 되었다.
      
  • 준비, 구현, 수행, 분석 등을 스크립트 형태로 구현함으로써 테스트 시간, 인력 투입의 부담을 최소화 할 수 있고, 휴먼에러(인간의 실수로 발생하는 에러)를 줄일 수 있다.

• 테스트 도구의 장점

  • 테스트 데이터의 재입력과 재구성같은 반복 작업의 자동화를 통하여 테스트 인력과 시간을 최소화 시킬 수 있다.
  • 향상된 요구사항 정의, 성능 및 스트레스 테스트, 품질 특정을 최적화 시킨다.
  • 빌드 확인, 회귀, 다중 플랫폼 호환성, 소포트웨어 구성, 기본 테스트 등의 향상된 테스트 품질을 보장한다.

• 테스트 도구의 단점

  • 도입 후 테스트 도구 전문가 양성 또는 고용이 필요하다.
  • 초기에 프로세스 적용에 대한 시간, 비용, 노력에 대한 추가 투자가 필요하다.
  • 비공개 상용 소프트웨어의 경우, 고가이며 인력과 교육에 대한 유지관리 비용이 높다.

• 테스트 자동화 수행 시 고려사항

  • 테스트 절차를 고려하여 재사용 및 측정이 불가능한 테스트 프로그램은 제외토록 하자.
  • 설계 기준을 고려하여 반복적인 빌드에서 스크립트 재사용성이 가능해야 한다.
  • 도구의 한계성으로 모든 수동 테스트 과정을 자동화 할 수 있는 도구는 없다.
    용도에 맞게 적절하게 도구를 사용토록 하자.
  • 도구 환경설정과 도구 습득 기간을 고려하여 프로젝트의 지연을 방지해야 한다.
  • 테스트 엔지니어의 늦은 투입은 프로젝트의 이해 부족으로 불완전한 테스트를 초래할 수 있다.
    따라서, 프로젝트 초기에 적절한 투입 시기와 계획을 수입해야 한다.

3. 테스트 도구의 평가 방법 및 요소

마치며

네! 오늘은 애플리케이션 테스트 수행에 대해 알아보았습니다!
위에 글을 보고 벌써 졸리시면 안되는데..

아무튼, 다음 시간엔 애플리케이션 결함 조치에 대해 알아봅시다!
그럼 다음시간에 다시 뵙도록 하죠!