테스트

정보처리기사 필기 준비하며 정리한 내용입니다.

소프트웨어 테스트

기본 원칙

• 인간이 하기 때문에 완벽한 테스팅은 불가능하다.
• 결함 집중의 법칙
  • 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재
  • 파레토 법칙
• 살충제 패러독스
  • 동일한 테스트 케이스로 반복 실행하면 그 케이스에서는 결함을 발견할 수 없다
  • 그러나 다른 곳에서는 나타난다!
• 테스팅은 정황 context에 의존한다
• 오류-부재의 궤변
  • 사용자의 요구사항을 만족하지 못하는 오류를 고쳐봤자 품질이 높다고는 할 수 없다

테스트 프로세스

개발과 유사하다

• 테스트 계획
• 테스트 분석 및 디자인
• 테스트 케이스 및 시나리오작성
• 테스트 수행
• 테스트 결과 평가 및 리포팅

테스트 산출물

• 테스트 계획서
• **테스트 케이스 (**케이스란 하나의 단위)
  • 테스트를 위한 설계 산출물
  • ⭐입력값, 실행조건, 기대결과⭐로 구성됨
• 테스트 시나리오
  • 절차 명세
  • 여러 테스트 케이스의 집합
  • 테스트 케이스의 동작 순서를 기술한 문서
• 테스트 결과서

테스트 오라클 ⭐

테스트 결과 참/거짓을 판단하기 위해 미리(사전에) 정의한 참값을 입력하여 비교하는 기법 및 활동.

테스트 오라클의 4유형

1. 참 오라클
   • 모든 입력 값 결과 체크
   • 오류나면 큰일나는 곳에서 쓴다. 항공기, 임베디드, 발전소.
2. 샘플링 오라클
   • 아주 설렁설렁. 샘플링한(특정) 입력값만.
   • 일반적으로 많이 사용
3. 휴리스틱 오라클
   • 샘플링 +a (나머지 값들은 휴리스틱[추정]으로 처리)
4. 일관성 검사 오라클
   • 애플리케이션 변경/수정이 있을 때 확인.
   • 회귀 테스트와 비슷하다.

 

테스트 레벨 📌

V 모델 : 폭포수 → 테스트

1. 단위 테스트
   • 개발자가 진행. 코딩 표준을 준수했는지도 검증
   1. 정적 중심
   2. 동적도 수행
   3. 종류
      1. 화이트박스 테스트
      2. 메소드(함수) 기반 테스트 (파라미터 값 입력)
      3. 화면 기반 테스트
2. 통합 테스트
   • 각각의 모듈을 묶어서(통합해서) 인터페이스와 상호작용 오류 발견
     • 개발자가 진행.
   1. 하향
      • 하위 모듈 대체하는 스텁 사용
      • 깊이 우선 또는 너비 우선 방식으로 통합
   2. 상향
      • 상위 모듈 대체하는 드라이버 사용
   3. 빅뱅
      • 모든 구성 요소들을 한꺼번에 통합하여 테스트 → 소규모 시스템에 적합
   4. 백본
      • 상향, 하향 같이. 드라이버, 스텁 필요에 따라 둘 다 사용 → 대규모 프로젝트에 적합
3. 시스템 테스트
   • 실제 서버에 올리는 테스트
   1. 기능
      • 고객의 기능적 요구사항을 중점적으로 테스트
   2. 비기능
      • 성능 요구사항 중점적으로 테스트
        • 성능, 신뢰성, 안정성 등
4. 인수 테스트
   • 고객에게 인수
   1. 알파
      • 개발자&사용자
   2. 베타
      • 사용자 only (개발자 없음!)

 

소프트웨어 테스트 기법

🔻프로그램 실행 여부

1. 정적
   • 소프트웨어 실행 없이 소스 코드 내부 구조
   1. 코드검사
      • 동료검토. 소스코드 오류 여부
   2. 워크스루
      • 짧은 팀 회의 (개발자)
   3. 인스펙션
      • 전문가 회의
2. 동적
   • 프로그램 실행시킨 상태에서 값 입력해서 결과값 나오는지

🔻화이트/블랙 기법

1. 화이트박스 테스트
   • 정적, 동적 둘다
   • 개발자 관점 - 소스 코드
   • 기법
     • 문장 검증
     • 선택 검증
     • 경로 검증
     • 조건 검증
   • 기초 경로 검사
     • MaCabe가 제안한 대표적 화이트박스 테스트 기법
     • 계산식 : Edge - Node + 2
2. 블랙박스 테스트
   • 사용자 관점 - 기능, 프로그램 실행
   • 기법
     • 동등 분할 기법 : 입력 자료에 초점을 맞춘다. 90~100이라면 95정도
     • 경계값 분석 : 90~100이라면 89,90,91, 99,100,101을 넣는다
     • 원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석
     • 오류 예측 검사 : 경험
     • 비교 검사 : 동일
     • 상태전이 검사 : 상태

🔻테스트에 대한 시간에 따른 분류

1. 검증
   • 개발 과정 테스트
2. 확인
   • 개발 끝난 후 완성된 소프트웨어를 테스트

🔻테스트 목적에 따른 분류

1. 회복 : 고의로 실패 유도
2. 안전
3. 강도 : 과다 정보량 부과
4. 성능
5. 구조
6. 회귀 : 변경 또는 수정된 코드
7. 병행

🔻테스트 종류

1. 명세 기반 테스트
   • 문서보면서 - 블랙박스 기법 사용
2. 구조 기반 테스트
   • 소스코드 - 화이트박스 기법 사용
3. 경험 기반 테스트
   • 위 둘은 시간이 꽤 걸려서 하기 힘들다.

 

테스트 자동화 도구

반복적인 테스트 작업을 스크립트 형태로 구현함

→ 태스크 시간 단축, 인력 최소화, 쉽고 효율적

유형

1. 정적 분석 도구
   • 소스 코드
   • pmd, SonarQube appcheck, checkstyle 등
2. 테스트 실행 도구
   • 작성된 스크립트 실행
3. 성능 테스트 도구
   • 부하 주는 것
4. 테스트 통제 도구
5. 테스트 장치 Test Harness
   • 구성요소
     • ⭐테스트 드라이버 : 하위 모듈 호출, 파라미터 전달 → 상향식 테스트에 필요 (상위 모듈 대체)
     • ⭐테스트 스텁 : 타 모듈 기능 단순히 수행하는 임시 모듈 → 하향식 테스트에 필요 (하위 모듈 대체)
     • 테스트 슈트 : 테스트 케이스의 집합
     • 테스트 케이스 : 입력 값, 실행 조건, 기대 결과
     • 테스트 스크립트 : 명세. 설명서
     • 목 오브젝트 Mock Object : 사용자 행위를 조건부로 사전에 만들어두면 그 상황에 예정된 행위를 수행하는 객체

 

테스트 커버리지

테스트를 얼마나 수행했는지 측정하는 기준

🔻테스트 커버리지 유형

1. 기능 기반 커버리지
   • 테스트한 수 / 전체 기능
   • 100퍼 달성이 목표!
2. 라인 커버리지
   • 테스트한 소스코드 라인 수 / 전체 소스 코드 라인 수
3. 코드 커버리지
   • 구문, 조건, 결정 등의 구조 코드자체가 얼마나 테스트되었는지 측정하는 방법
   • 아래로 내려갈 수록 열심히 테스트하는 것
   1. 결정, 구문, 조건 커버리지
      • 구문 커버리지
        • 라인과 비슷하다
      • 조건 커버리지
        • 결정 포인트 내의 모든 개별 조건식 T F
          • 결정 포인트는 상관 없다
      • 결정 커버리지
        • 결정 포인트 내의 모든 분기문 (결정포인트 T F)
          • 개별 조건식은 상관없다
   2. 조건 결정 커버리지
      • 결정포인트, 개별조건식이 TF를 가져야 한다
   3. 변경 조건 결정 커버리지
      • 모든 결정 포인트 내의 개별 조건식은 적어도 한번 TF를 가져야 한다
   4. 다중 조건 커버리지
      • 결정 포인트 내 모든 개별 조건식의 가능한 조합을 100퍼 보장해야