[소프트웨어 공학] 소프트웨어 테스트 - 2

테스트 프로세스

ISO/IEC/IEEE 29119 테스트 프로세스

• 조직 테스트 프로세스
  • 조직 수준의 테스트 정책 및 전략 수립
  • 테스트 목표, 원칙, 접근 방식

1년 동안 심각도 레벨1 오류 수를 5% 줄인다.

• 테스트 관리 프로세스
  • 테스트 계획에 따른 수행여부 모니터링, 대응
  • 진행 상태 측정/통제, 자원 재분배, 우선순위 조정
• 동적 테스트 프로세스
  • 테스트 케이스 설계, 테스트 환경 구축하여 테스트
  • 이슈 발생 시 레포팅

 

개발 단계에 따른 테스트 분류

• 단위 테스트(JUnit, 구글테스트, Python)
  • 모의(Mock) 객체 사용(클래스의 객체 의존성 배제)
• 통합 테스트
  • 모듈 간 상호 작용 테스트
  • 빅뱅 통합 전략
    • 단위 테스트 후에 한꺼번에 모듈의 통합 테스트
    • 오류 원인 찾기 곤란
  • 점진적 통합 전략
    • 하향식(스텁 모듈), 상향식(테스트 드라이버)
  • 지속적 통합 전략
• 시스템 테스트
  • 시스템의 기능, 비기능(신뢰도, 성능 등) 테스트
• 인수 테스트
  • 사용자/수요자
  • 알파 테스트(개발자 환경)
  • 베타 테스트(사용자 환경)

 

위험 기반 테스트

위험(risk) 분류

• 프로젝트 위험
  • 프로젝트 성공에 영향을 줄 수 있는 문제: 인력 부족, 예산 및 일정, 기술력 등
• 제품 위험
  • 제품의 기능, 품질에 영향을 줄 수 있는 문제

위험 기반 테스트

• 위험(➡️우선순위)을 고려한 테스트 수행 방법
• 테스트 항목 선택 기준, 테스트 방법 선정 기준, 테스트 자원 할당 기준, 테스트 케이스 설계

위험 기반 테스트 프로세스

위험 분석

• 위험 발생 가능성이 높은 컴포넌트
  • 복잡한 컴포넌트, 새로운 컴포넌트
  • 자주 변경되는 컴포넌트
  • 도구, 기법이 처음 사용된 컴포넌트
  • 전체 개발기간 동안 한 명의 개발자로부터 다른 개발자로 전환된 컴포넌트
  • 극심한 시간 압력 하에 개발된 컴포넌트
  • 조기에 많은 결함이 발견된 컴포넌트
  • 많은 인터페이스를 가지는 컴포넌트

위험 평가와 보고

• 개발 계획 단계부터 위험 식별, 위험 발생 예방 준비
  • 개발 과정 동안 제거, 잔여 위험 모니터링 및 보고
• 위험 제거여부를 알기 위해 위험 항목 테스트
  • 테스트 수행 전에는 위험 존재 간주
  • 테스트가 통과되면 해당 위험 항목 제거 간주
• 개발 과정 동안 지속적인 위험 평가

 

테스트 공리

공리1

• 완전한 테스트는 불가능

공리2

• 테스트 노력 대비 얻을 수 있는 이익 판단

공리3

• 테스트 종료 기준 필요

"테스트는 오류로부터 완전무결함을 보여줄 수 없다."

공리4

• 결함 집중 원칙(defect clustering priciple)
  • 어떤 부분에 오류가 남아 있을 확률은 이미 발견된 오류의 수에 비례한다.

공리5

• 테스트 케이스의 지속적인 갱신 및 관리
  • 동일한 테스트를 반복하면 새로운 결함 검출 불가능
  • 새로운 테스트 개발 필요

공리6

• 발견된 오류가 모두 수정되는 것은 아니다.
  • 시간이 없을 때 (우선 순위가 높은 오류만 수정)
  • 오류 수정에 너무나 많은 위험이 있을 경우(시스템 전반에 영향을 주거나 엄청난 비용 소모)
  • 발견된 오류가 진짜 오류가 아닌 경우

 

Vilfredo Pareto 원칙

• 시스템의 20% 모듈에서 전체 오류의 80% 검출
• 시스템의 20% 모듈이 전 자원의 80% 소비
• 시스템의 20% 모듈이 실행시간의 80% 소비
• 오류의 20%가 전체 오류 수정 비용의 80% 차지
• 사용 도구의 20% 기능만 도구 사용의 80% 차지

Amland 제의

• 어떤 기능과 품질 특성이 중요한지 고객과 함께 추출
• 결함이 많이 발견되는 영역 식별(shallow test)
  중요 영역과 오류 밀집 지역 추가 테스트(deep test)