[정보처리기사 필기] 2과목 - 테스팅(1)

테스팅(Testing)

시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동/자동 방법을 동원하여 검사/평가 하는 일련의 과정

• 숨어있는 결함을 찾기 위해 소프트웨어를 작동시키는 행위와 절차
• 결함이 존재함을 보여주는 작업
• 분석, 설계 도중에 일어나는 검증, 검토 등 품질 보증을 위한 모든 행위
• 소프트웨어의 정확성을 확증하는 과정
  • 결함이나 원치 않는 동작을 찾음
  • 요구와 제약에 맞는지 검증

용어

• 오류(Error)
  • 프로그램 실행 결과가 예상한 결과와 다른 경우 그 차이
  • 결함 및 고장을 일으키게한 인간의 실수
• 결함(Fault/Bug/Defect)
  • 시스템이 요구된 기능을 수행하지 못하게 하는 조건
  • 소프트웨어 오작동의 원인
• 고장(Failure)
  • 명세로 작성된 요구와 기능을 제대로 수행할 수 없는 경우
  • 겷마은 고장을 유발하는 잠재성을 가지지만, 모든 결함이 고장을 발생하는 것은 아님
• 결함 집중(Defect Clustering)
  • 대부분의 결함이 소수의 특정 모듈에 집중해서 발생
• 파레토 법칙(Pareto Principle)
  • 상위 20% 고객이 매출의 80%를 창출 또는 상위 20% 사람들이 전체 부의 80%를 가지고 있다는 개념이 테스팅에도 적용됨
  • 80% 오류는 20%의 모듈에서 발견되므로 20%의 모듈을 집중적으로 테스트하여 효율적으로 오류 탐색
• 살충제 패러독스(Pesticide Paradox)
  • 살충제를 지속적으로 뿌리면 벌레가 내성이 생겨서 죽지 않는 현상
  • 테스트하면 할 수록 테스트에 면역이 됨(동일 테스트 케이스를 반복해서 사용하지 말것)
• 오류 - 부재의 궤변(Absence of Errors Fallacy)
  • 소프트웨어의 결함을 모두 제거해도 사용자의 요구 사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없음
• 테스트 케이스(Test case)
  • 소프트웨어 시스템에 포함된 결함을 발견하기 위하여 설계한 명령 또는 입력 값의 집합
    • 테스트에 필요한 입력 데이터, 테스트 조건, 예상 결과 등을 모아 테스트 케이스를 만듦
  • 테스트 케이스 선택은 테스팅에 정말로 중요함
  • 좋은 테스트 케이스는 효과적으로 결함을 드러낼 수 있어야 함
  • 구성요소(ISO/IEC/IEEE 29119-3 표준)
    • 식별자(Identifier) - 항목 식별자, 일련 번호
    • 테스트 항목(Test Item) - 테스트 대상(모듈 또는 기능)
    • 입력 명세(Input Specification) - 입력 데이터 또는 테스트 조건
    • 출력 명세(Output Specification) - 테스트 케이스 수행시 예상되는 출력 결과
    • 환경 설정(Environmental Needs) - 필요한 하드웨어나 소프트웨어의 환경
    • 특수 절차 요구(Special Procedure Requirement) - 테스트 케이스 수행 시 특별히 요구되는 절차
    • 의존성 기술(Inter-case Dependencies) - 테스트 케이스 간의 의존성

원리

• 오류를 발견하려고 프로그램 실행
• 완벽한 테스팅은 불가능
• 창조적이면서 어려움
• 오류의 유입을 방지
• 구현과 관계없는 독립된 팀에 의해 수행 되야 함
• 테스트의 의해 오류가 발견되지 않았다고 해서 프로그램에 오류가 반드시 없다는 것은 아님

과정

• 1. 테스트에 의하여 무엇을 점검할 것인지 정함
  • ex. 테스트의 목표 - 기능의 완벽성, 신뢰도
• 2. 테스트 방법을 결정
  • ex. 검사, 증명, 블랙박스 테스트, 화이트 박스 테스트, 자동화 도구
• 3. 테스트 케이스를 개발
  • ex. 테스트 자료, 시행 조건, 시험 계획서
• 4. 테스트의 예상되는 올바른 결과를 작성
  • 테스트 오라클 - 모든 테스트에 대한 예상 결과 모음
• 5. 테스트 케이스로 실행
  • 테스트 하니스(테스트를 위해 일부 기능을 변경하는 작업) 필요

 

테스트 종류

프로그램 실행 여부

정적 테스트	- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 - 소프트웨어 개발 초기에 결함을 발견할 수 있어 소프트웨어의 개발 비용을 낮추는데 도움이 됨 - 종류 : 워크스루, 인스펙션, 코드 검사 등
동적 테스트	- 프로그램을 실행하여 오류를 찾는 테스트 - 소프트웨어 개발의 모든 단계에서 테스트를 수행할 수 있음 - 종류 : 블랙박스 테스트, 화이트 박스 테스트

 

테스트 기반(Test Bases)

명세 기반 테스트	- 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 - 종류 : 동등 분할, 경계 값 분석 등
구조 기반 테스트	- 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 - 종류 : 구문 기반, 결정 기반, 조건 기반 등
경험 기반 테스트	- 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트 - 경험 기반 테스트는 사용자의 요구사항에 대한 명세가 불충분하거나 테스트 시간에 제약이 있는 경우 수행하면 효     과적 - 종류 : 에러 추정, 체크 리스트, 탐색적 테스팅

 

시각

검증 테스트 (Verification Test)	- 개발자의 시각에서 제품의 생산 과정을 테스트하는 것 - 제품이 명세서대로 완성됐는지를 테스트 함
확인 테스트 (Validation Test)	- 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것 - 사용자가 요구한대로 제품이 완성됐는지, 제품이 정상적으로 동작하는지를 테스트

 

목적

회복 테스트 (Recovery)	- 시스템에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인
안전 테스트 (Security)	- 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인
강도 테스트 (Stress)	- 시스템이 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지 확인
성능 테스트 (Performance)	- 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단 - 응답시간, 처리량 등
구조 테스트 (Structure)	- 소프트웨어 내부의 논리적인 경로, 소스코드의 복잡도 등을 평가
회귀 테스트 (Regression)	- 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
병행 테스트 (Parallel)	- 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교

 

개발 단계

• V-모델 : 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것