10-1. 애플리케이션 테스트 케이스 설계

1-1. 요구사항 분석 https://minjh1126.tistory.com/44

1-2. 현행시스템 분석 https://minjh1126.tistory.com/45

1-3. 요구사항 확인 https://minjh1126.tistory.com/46

2-1. UI 요구사항 확인 https://minjh1126.tistory.com/47

2-2. UI 설계 https://minjh1126.tistory.com/48

3-1. 논리 데이터 저장소 확인 https://minjh1126.tistory.com/54

7-1. 데이터베이스 기본 https://minjh1126.tistory.com/49

7-2. 응용 SQL 작성하기 https://minjh1126.tistory.com/50

8-1. 개발환경 구축 https://minjh1126.tistory.com/51

8-2. 공통 모듈 구현 https://minjh1126.tistory.com/52

9-1. 소프트웨어 개발 보안 설계 https://minjh1126.tistory.com/53

9-2. 소프트웨어 보안 개발 구현 https://minjh1126.tistory.com/55

 

1. 애플리케이션 테스트 케이스 작성

• 소프트웨어 테스트
  • 필요성: 오류 발견, 오류 예방, 품질 향상
  • 기본 원칙
    • 결함 존재 증명: 결함이 존재함을 밝힘으로써 결함을 줄임. 결함이 없다는 건 증명할 수 없음.
    • 완벽한 테스팅은 불가능: 무한 경로와 무한 입력값으로 인해 완벽한 테스트는 어려움.
    • 초기 집중: 조기 테스트 시 결과를 단시간에 알 수 있고 재작업을 줄임. 제대로 설계 및 분석이 수행되지 않으면 후반에 영향을 미친다는 요르돈의 법칙이 적용됨.
    • 결함 집중: 적은 수의 모듈에서 대다수의 결함이 발견됨. 오류의 80%는 전체 모듈 중 20%에서만 발견된다는 파레토 법칙 적용됨.
    • 살충제 패러독스: 동일한 테스트 케이스 반복은 새로운 버그를 못 찾음. 테스트 케이스의 정기적 리뷰와 개선 및 다른 시각의 접근 필요.
    • 정황 의존성: 스포트웨어 성격에 맞게 테스트를 실시하고 정황과 비즈니스 도메인에 따라 테스트 수행.
    • 오류-부재의 궤변: 요구사항을 충족시키지 않으면 품질이 낮음.
  • 유형
    • 정적 테스트: 테스트 대상을 실행하지 않고 구조를 분석해 논리성 검증.
    • 동적 테스트: 소프트웨어를 실행하는 방식으로 결함 검출.
      • 화이트박스 테스트: 응용 프로그램의 내부 구조와 동작을 검사. 코드 분석과 프로그램 지식으로 모듈 내부를 테스트함. 소스 코드의 모든 문장을 한 번 이상 수행하고, 제어 구조에 따라 선택 반복 등의 부분들을 수행함으로써 논리적 경로 점검. 동작의 유효성이나 실행 과정 확인 가능.
        • 유형
          • 구문 커버리지(문장 커버리지): 프로그램 내의 모든 명령문을 적어도 한 번씩 수행. 조건문과 관계 없이 구문 실행 개수 계산. 
            • 문장 커버리지 % = 테스트 케이스 집합에 의해 실행된 문장 수 / (전체 문장 수 * 100)
          • 결정 커버리지(선택, 분기 커버리지): 각 분기의 결정 포인트 내의 전체 조건식이 적어도 한 번은 T와 F의 결과를 수행. 구문 커버리지를 포함함.
            • 결정 커버리지 % = 테스트 케이스 집합에 의해 실행된 결정의 결과 수 / (전체 프로그램 결과 수 * 100)
          • 조건 커버리지: 각 분기의 결정 포인트 내의 개별 조건식이 적어도 한 번은 T와 F의 결과가 되도록 수행. 구문 커버리지를 포함.
            • 조건 커버리지 % = 테스트 케이스 집합에 의해 실행된 조건의 결과 수 / (전체 프로그램 조건의 결과 수 * 100)
          • 조건/결정 커버리지: 전체 조건식 뿐만 아니라 개별 조건식도 T와 F의 결과가 한번씩은 되어야 함.
          • 변경 조건/결정 커버리지: 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킴. 
          • 다중 조건 커버리지: 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 보장.
          • 기본 경로 커버리지(경로 커버리지): 수행 가능한 모든 경로 수행.
          • 제어 흐름 테스트: 프로그램 제어 구조를 그래프 형식으로 나타내 내부 로직 테스트.
          • 데이터 흐름 테스트: 제어 흐름 그래프에 데이터 사용 현황 추가.
          • 루프 테스트: 루프 구조에 초점을 맞춰 테스트
        • 맥케이브 회전 수 계산: 공백 수 계산(외부 1개 포함) or 간선 - 노드 + 2
        • 블랙박스 테스트: 요구사항 명세를 보면서 수행. 소프트웨어의 특징, 요구사항, 설계 명세서 등에 초점. 기능 및 동작 위주의 테스트를 진행하기 때문에 내부 구조나 작동원리를 몰라도 됨. 
          • 유형
            • 동등분할 테스트(동치분할, 균등 분할, 동치 클래스 분해 테스트): 입력 데이터의 영역을 유사한 도메인 별로 그룹핑해 대푯값 테스트 케이스를 도출해 테스트.
            • 경곗값 분석 테스트(한곗값 테스트): 경곗값을 포함해 극한 한계를 테스트하는 기법.
            • 결정 테이블 테스트: 요구사항 논리와 발생 조건을 테이블 형태로 나열해 조합.
            • 상태 전이 테스트: 테스트 대상 시스템이나 객체의 상태를 구분하고. 이벤트에 의해 다른 상태로 전이되는 경우의 수를 수행.
            • 유스케이스 테스트: 유스케이스로 모델링되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화해 수행.
            • 분류 트리 테스트: 소프트웨어의 일부나 전체를 트리구조로 분석 및 표현해 설계.
            • 페어와이즈 테스트: 테스트 데이터값들 간 한 번씩 조합하는 방식으로 모든 조합에 비해 상대적으로 적은 양을 테스트.
            • 원인-결과 그래프 테스트: 그래프를 활용해 입력 데이터의 관계 및 출력에 미치는 영향을 분석해 효용성이 높은 테스트 케이스 선정.
            • 비교 테스트: 여러 버전의 프로그램에 같은 값을 넣어 동일한 결과와 데이터가 나오는지 비교.
            • 오류 추정 테스트: 개발자의 실수를 추정하고 결함이 검출되도록 설계. 테스터의 경험과 직관을 바탕으로 결함 노출. 블랙박스 테스트 보완.
  • 분류
    • 테스트 시각에 따른 분류
      • 검증: 소프트웨어 개발 과정 테스트. 개발 규격과 요구를 충족하는지 판단. 개발자, 시험자의 시각으로 소프트웨어가 명세화한 기능을 올바르게 수행하는지 확인.
      • 확인: 소프트웨어 결과 테스트. 최종 사용자 요구나 소프트웨어 요구에 적합한지 판단. 사용자 시각으로 올바른 소프트웨어인지 판단.
    • 테스트 목적에 따른 분류
      • 회복 테스트: 고의로 실패를 유도하고 정상적 복귀 여부 테스트.
      • 안전 테스트: 불법적인 소프트웨어가 접근해 시스템을 파괴하지 못하다로고 보안적 결함을 미리 점검.
      • 성능 테스트: 시스템의 응답 시간, 처리량, 반응 속도 등 측정.
        • 유형
          • 부하 테스트: 부하를 계속 증가시키며 임계점을 찾고 병목 지점을 찾아 제거.
          • 강도 테스트: 시스템 처리 능력 이상의 부하를 가해 시스템 동작 테스트.
          • 스파이크 테스트: 짧은 시간에 사용자가 몰릴 때 반응 측정.
          • 내구성 테스트: 오랜 시간 동안 높은 부하를 가했을 때 반응 테스트.
      • 구조 테스트: 논리 경로, 복잡도 평가.
      • 회귀 테스트: 오류 제거나 수정한 시스템에서 새로 유입된 오류가 없는지 확인하는 반복 테스트 기법.
      • 병행 테스트: 변경된 시스템과 기존 시스템과 동일한 데이터 입력 후 동일한 데이터가 나오는지 비교.
    • 테스트 종류에 따른 분류
      • 명세 기반 테스트(블랙박스 테스트)
      • 구조 기반 테스트(화이트박스 테스트)
      • 경험 기반 테스트(블랙박스 테스트)
        • 유형
          • 탐색적 테스트: 문서로 작성하지 않고 경험을 토대로 기능을 수행. 테스트 대상에 대한 이해, 설계, 실행을 병행. 중대한 테스트 위주로 테스트 엔지니어의 경험이 필요. 테스트 차터, 회고, 노트, 시간 제한으로 구성.
          • 오류 추정: 개발자의 실수를 추정하고 결함이 검출되도록 케이스 설계. 예상되지 않는 상황이 사용자 입력값으로 적절히 처리되고 있는지 확인.
• 테스트 오라클: 테스트의 결과가 T인지 F인지 판단하기 위해 정의된 T값을 입력해 비교.
  • 종류
    • 참 오라클: 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출.
    • 샘플링 오라클: 특정한 몇 입력값에 대해서만 기대하는 결과를 제공.
    • 휴리스틱 오라클: 샘플링 오라클을 개선한 오라클로 특정 입력값에 올바른 결과를 제공하고 나머지 값은 추정 처리.
    • 일관성 검사: 애플리케이션 변경 시 수정 전후의 결과값이 동일한지 확인.

 

2. 애플리케이션 테스트 시나리오 작성

1. 테스트 레벨

• 종류
  • 단위 테스트: 사용자 요구사항에 대한 모듈 컴포넌트 초점 - 개발
  • 통합 테스트: 단위 테스트를 통과한 모듈 사이의 인터페이스, 컴포넌트 간 상호작용을 검증하는 테스트 - 설계
  • 시스템 테스트: 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지 검증 - 명세 분석
  • 인수 테스트: 요구사항이 만족되었는지 확인 - 요구사항 분석
    • 알파 테스트: 선택된 사용자가 개발자 환경에서 통제된 상태로 테스트.
    • 베타 테스트: 실제 환경에서 일정 수의 사용자에게 사용하게끔 함.