[1차 필기] 애플리케이션 테스트 수행(과정평가형 정보처리산업기사)

테스트 수행

• 테스트는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 순으로 진행
• V-모델 : 요구사항 → 분석 → 디자인 → 구현 → 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트
• 단위 테스트 : 작은 소프트웨어 단위를 테스트하는 것, 아주 중요한 부분이므로 개발 도구에서 지원하지 않아도 반드시 수행
  1. 구조기반 : 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트 / 제어 흐름, 조건 결정
  2. 명세기반 : 목적 및 실행 코드 기반의 실행을 통한 블랙박스 테스트 / 동등 분할, 경계 값 분석
• 통합 테스트 : 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호 작용을 테스트하는 것
  1. 순차적 형태로 진행
  2. 빅뱅, 상향, 하향, 샌드위치, Central, Collaboration, 레이어 통합 등
• 시스템 테스트 : 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 테스트하는 것
  1. 기능적 요구사항 : 요구사항 명세서, 비즈니스 절차, 유스케이스 등 명세서 기반의 블랙박스 테스트
  2. 비기능적 요구사항 : 성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템 메뉴 구조, 웹 페이지의 네비게이션 등의 구조적 요소에 대한 화이트 박스 테스트
• 인수 테스트 : 일반적으로 최종 사용자와 업무에 따른 이해관계자 등이 테스트를 수행함으로써 개발된 제품에 대해 운영 여부를 결정하는 테스트
  1. 사용자 인수 테스트
  2. 운영상의 인수 테스트
  3. 계약 인수 테스트
  4. 규정 인수 테스트
  5. 알파 테스트
  6. 베타 테스트
• 테스트 기반에 따른 테스트의 종류
  1. 구조 기반 : 소프트웨어 내부의 논리 흐름에 따른 테스트 케이스 작성 및 결함 발견 활동
  2. 명세 기반 : 사용자의 요구사항 분석서에 주어진 명세를 빠뜨리지 않고 테스트 케이스화
  3. 경험 기반 : 유사 소프트웨어나 기술에서의 테스트의 경험, 직관, 기술 능력을 바탕으로 하는 테스트 기법

결함관리

• 결함은 프로그램과 명세서 간의 차이, 업무 내용 불일치
• 결함은 기대 결과와 실제 관찰 결과 간의 차이
• 시스템이 사용자가 기대하는 타당한 기대치를 만족시키지 못할 때 변경이 필요한 모든 것은 결함
• 결함관리 프로세스
  1. 결함관리 계획
  2. 결함 기록
  3. 결함 검토
  4. 결함 수정
  5. 결함 재확인
  6. 결함 상태 추적 및 모니터링 활동
  7. 최종 결함 분석 및 보고서 작성
• 결함 분류
  1. 시스템 결함 : 비정상적인 종료/중단, 응답 시간 지연, 데이터베이스 에러 등 주로 애플리케이션 환경과 데이터베이스 처리에서 발생하는 결함
  2. 기능 결함 : 사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러, 타 시스템 연동 시 오류 등 기획, 설계, 업무 시나리오 단계에서 발생된 결함을 말함
  3. GUI 결함 : 응용 프로그램의 UI 비일관성, 부정확한 커서/메시지, 데이터 타입의 표시 오류 등으로 사용자 화면 설계에서 발생된 결함을 말함
  4. 문서 결함 : 불완전한 상태의 문서의 경우
• 결함 심각도
  1. Hight : 시스템이 중단되어 더 이상 프로세스를 진행할 수 없게 만드는 결함
  2. Medium : 시스템의 흐름에 영향을 미치는 결함
  3. Low : 시스템의 흐름에는 영향을 미치지 않는 결함이나 상황에 맞지 않는 용도와 화면구성 결함

소프트웨어 테스트 기법

• 소프트웨어 테스트 기법
  1. 단위 테스트 기법
     • JUnit을 활용한 테스트 : java환경
     • Mock 테스트
  2. 통합 테스트 기법
  3. 시스템 테스트 기법
  4. 인수 테스트 기법
• 결함 관련 용어
  1. 에러(error)
  2. 오류(fault)
  3. 실패(failure)
  4. 결함(defect)
• 결함의 판단 기준
  1. 기능 명세서에 가능하다고 명시된 동작을 수행하지 않은 경우
  2. 기능 명세서에 불가능하다고 명시된 동작을 수행하는 경우
  3. 기능 명세서에 명시되어 있지 않은 동작을 수행하는 경우
  4. 기능 명세서에 명시되어 있지 않지만 수행해야 할 동작을 수행하지 않는 경우
  5. 테스터의 시각에서 볼 때 문제가 있다고 판단되는 경우

프로그램 코드 검토 기법

• 소프트웨어 인스펙션 : 코드 인스펙션 외에도 설계 및 설계 산출물까지 포괄하여 소프트웨어 인스펙션으로 부르기도 함

  1. 인스펙션 : 인스펙션은 개발 가이드에 따른 표준(체크리스트)을 준수하였는지를 파악하기 위함에 있으므로 기능적으로 이상이 없는 소스 코드를 대상으로 검증
  2. 인스펙션을 해야하는 비즈니스적인 이유
     • 결함을 빨리 찾을수록 수정 비용이 적게 듬
     • 인스펙션의 데이터를 통해 업무에 집중 할 수 있음
     • 인스펙션을 함으로써 교차 교육을 도움
     • 제품의 "re-engineering"이 가능한 영역을 식별하도록 도움
     • 소프웨어를 개발하고 유지하는 데 적은 비용이 듬
     • 스케줄에 긍정적인 효과를 줌
     • 품질을 향상 시킴

• 워크 스루 : 팀이나 관리자의 필요에 따라 집단 토의 통하여 프로그램 산출물 평가와 개선에 대하여 검증

형상 관리

• 형상관리(configuration management)는 형상항목을 식별하여 그 기능적, 물리적 특성을 문서화하고, 그러한 특성의 변경, 제어, 처리 상태를 기록 및 보고하면서 명시된 요구사항에 부합하는지 확인 및 감독하는 활동을 의미
• 형상 식별
• 버전 관리
• 변경 통제
• 형상 감사
• 상태 보고