수테크📱⌚️👀

1.3. 테스팅의 일반적인 원리

• 원리 1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)
  • 잠재적으로 존재하는 결함 줄임
  • But, 결함이 없다고 증명할 수는 없음
• 원리 2. 완벽한 테스팅 (Exhaustive testing)은 불가능 (Exhaustive testing is impossible)
  • 한 프로그램 내에 내부 조건이 많음
  • 입력이 가질 수 있는 모든 값의 조합이 무수히 많음
  • 이벤트 발생시 발생 순서에 대한 조합도 무수히 많음
  • 리스크에 따라 테스트 강도 높게 수행 -> 실제 완벽은 불가
• 원리 3. 개발 초기에 테스팅 시작 (Early testing)
  • 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근
  • 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출
  • 다 만들고 테스트 결과가 엉망이 나오면 유지보수 비용이 장난 아니겠쥐~
• 원리 4. 결함 집중 (Defect clustering)
  • 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임
  • 결함의 집중은 운영상의 장애를 초래
    • 복잡한 구조의 모듈
    • 다른 모듈과 다량의 상호작용을 하는 모듈 (자꾸 호출하다 보면 결함 나오기 쉬움)
    • 개발 난이도가 높거나 최신 기술을 사용한 모듈
    • 크기가 큰 모듈
    • 경험이 미흡한 팀에서 개발한 모듈
    • 새롭게 개발한 모듈
• 원리 5. 살충제 패러독스 (Pesticide paradox)
  • 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함으로 찾기 어려워짐
  • 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선
• 원리 6. 테스팅은 정황(Context)에 의존적 (Testing is context dependent)
  • 테스팅은 정황(context)과 도메인에 따라 다르게 진행
  • 모든 테스트에 적용되어야 하는 것
    • 테스트 프로젝트 기획
    • 표준적인 기법적용
    • 독립적인 테스트 환경
    • 효율적/효과적 테스트 팀 조직
    • 정식 리포팅 등
• 원리 7. 오류-부재의 궤변 (Absence-of-errors fallacy)
  • 개발된 소프트웨어가 사용자 요구수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음

1.2 테스팅이란 무엇인가?

• 테스팅
  • 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘
    • 정상 동작 여부 확인
    • 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인
    • 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달
  • 초기 개발 산출물 -> 리뷰
  • 테스트 케이스 작성 과정(결함 예방 활동)
  • 다양한 테스팅 활동

• 테스팅의 일반적인 목적
  • 남아있는 결함 발견
  • 명세 충족 확인
  • 사용자 및 비즈니스의 요구 충족
  • 결함 예방
  • 품질 수준에 대한 자신감 획득과 정보 제공
  • 비즈니스 리스크를 감소시키는 정보에 근간한 조언 제공
  • 개발 프로세스 점검, 이슈 제기
  • 논리적 설계의 구현 검증
  • 시스템과 소프트웨어가 적절히 동작함을 확인

• 관점에 따른 테스팅의 목적
  • 개발 과정 - 결함을 찾고 수정하기 위해 가능한 많은 장애 상황 재연
  • 인수 테스팅 - 예상대로 시스템이 동작하는지 확인, 요구사항 확인
  • 소프트웨어 품질 - 출시하는 것의 리스크를 관련자에게 전달
  • 유지보수 테스팅 - 변경에 대해 새로운 결함의 유입을 확인(반복 테스트)
  • 운영 테스팅 - 신뢰성 또는 가용성 같은 시스템 특성을 평가
  • 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함