QA - Testing

테스트 유형

확인/리그레션 테스팅

1. 정의
   결함 수정 후 제거 확인을 위해 재확인 하는것
2. 목적
   테스트 된 프로그램 테스팅 반복
   결함 해결로 새로운 결함이 발생한지 확인
   
   버그가 수정되었는지 확인 = 확인 테스트
   수정 확인 후 다시 테스트 = 리그레이션 테스트(테스트 성공 후 다시 테스트를 하는 것)

유지 보수 테스팅

1. 이미 사용되고 운영되고 있는 시스템에서 수행되는 테스트
2. 변경, 단종, 마이그레이션 될 때 발생
   변경 = 개선 활동에 의한 변경, 요구사항, 환경 등등
   마이그레이션 = 다른 플렛폼으로 옮겨가는것

 

테스트 수행 방법에 따른 분류

동적 테스팅

• 실제 구현된 시스템 테스팅

정적 테스팅

• 소스코드 레벨의 시스템 테스팅

 

도구에 의한 정적 분석

1. 정적 분석의 목적
   1. 소프트웨어의 소스코드와 모델에서 결함을 발견
2. 정적 분석의 특징
   1. 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견
   2. 장애 보다는 결함을 반결하기 위함
      (장애(결함으로 일어난 무언가)와 결함(문제 그 자체)은 다른것)
   3. 도구의 도움을 받아 수행
   4. 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 간이 결과물도 분석
3. 정적 분석의 가치
   1. 테스트 실행 전에 조기 결함 발견
   2. 높은 복잡도 측정치와 같은 메트릭을 계산하여 코드와 설계의 의심스러운 부분에 대한 조기 경보
   3. 동적 테스팅으로는 발견하기 힘든 결함 발견
   4. 소프트웨어 모델상의 의존도와 불일치성 발견
   5. 코드와 설계의 유지보수성 향상
   6. 결함 예방 가능
      
      동적으로 찾기 어려운 결함을 발견
4. 정적 분석 도구를 통해 발견되는 전형적인 결함
   1. 정의되지 않은 값, 사용되지 않은 변수, 사용되지 않는 코드
   2. 모듈과 컴포넌트 간에 일관되지 않은 인터페이스
   3. 코드와 소프트웨어 모델의 구문 규칙 위반
   4. 코딩 표준 위반, 보안 취약성

정적 기법

• 소프트웨어를 실행하지 않고 테스팅 하는 기법
• 리뷰와 같은 수동기법과 정적 분석 자동화 도구를 활용한 정적 분석이 있음

리뷰

• 소프트웨어 작업 산출물을 테스팅하는 한 가지 방법
• 동적 테스트 실행 전에 수행할 수 있음
• 개발 프로세스의 초기에 결함을 발견
• 전체 수명주기의 효율 향상
• 개발 비용을 낮춤

리뷰의 이점

• 조기 결함 발견 및 수정
• 개발 생산성 향상
• 개발 기간 단축
• 테스트 비용 감소 및 시간 단축
• 개발 수명 주기 전체에 걸친 비용 감소
• 결함 감소
• 커뮤니케이션 향상
  
  리뷰와 정적 분석, 동적 테스팅은 모두 결함 발견이라는 목적을 가짐

동적 테스팅 보다 리뷰를 통해 발견하기 쉬운 결함

• 표준 위반
• 요구사항 결함
• 개발 설계 결함
• 불충분한 유지보수성
• 부정확한 인터페이스 명세

리뷰 프로세스

1. 활동 계획
   무엇을 할것인가
   
   
2. 시작
   문서를 배표
   목적, 절차를 설명
   
   
3. 개별 준비
   참석자 별로 준비
4. 리뷰 미팅
   토의 및 결과를 문서로 기록
   결함 기록, 처리 방안 등 결정을 내림
   
   
5. 재 작업
   발견된 결함을 대상 문서의 작서앚가 수정
   
   
6. 추가 작업
   처리완 결점을 확인, 측정 기준틀을 수정

 

리뷰시 역발 분배

• 관리자
  리뷰 실행에 대한 결정권자
• 중재자
  리뷰 계획, 미팅 운영, 추가 사항을 포함하는 문서 혹은 문서 셋
• 작성자
  리뷰 된 문서에 대한 책임자
• 리뷰어
  특정 기술 혹은 비지니스 배경을 가진 개인
  발견된 결함을 정의, 설명
• 필기자
  리뷰에서 나온 것들을 문서화

리뷰의 유형

1. 비공식 리뷰
   • 공식적인 절차 없음
   • 설계, 코드를 리뷰 하는 것 일 수 있음
   • 선택적으로 문서화될 수 있음
   • 주요 목적 = 저렴한 방법으로 일정 수준의 성과 달성
2. 기술적 리뷰
   • 동료와 기술 전문가가 참여
   • 결함 발견을 위한 문서화되고 정의된 프로세스가 존재
   • 이상적으로는 저자가 아는 중재자가 미팅을 주도
   • 미팅 전 사전 준비 단계 필요
   • 실무에서는 공식적, 비공식적일 수 있음
   • 공식적인 경우 문서화 필수
   • 주요 목적 = 기술적 문제 해결, 토론, 의사결정, 대안평가, 결함 발견, 명세서 또는 표준과의 적합성 검토
   • 선택 => 체크리스트, 리뷰 리포트, 발견한 인시던트 리스트, 관리자 참여 활동
     
     인시던트란?
     갑작스럽게 일어난 무언가
3. 워크쓰루
   • 저자에 의한 진행 및 제어
   • 성격 = 시나리오 사용, 예행 연습, 동료 그룹 검토
   • 시간 및 인원 수 등에 저한이 없고, 상황에 따라 변경할 수 있는 세션
   • 선택 => 미팅 전 준비 과정 거침
   • 실무에서는 비공식, 공식적일 수 있음
   • 주요 목적 = 학습, 시스템에 대한 이해 향상, 결함 발견
4. 인스펙션
   • 저자가 아닌 훈련된 중재자에 의한 진행 및 제어
   • 주로 동료 검사
   • 역할이 정의되어 있음
   • 메트릭 = 수치화 된 것을 수집하고 활용
   • 체크 리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
   • 미팅 전 준비 과정 필요
   • 인스펙션 리포트와 발견사항 리스트 산출
   • 정식적인 후속 처리 확인 프로세스 존재
   • 선택 => 리뷰 프로세스 개선 활동 수행
   • 주요 목적 = 결함 발견

리뷰의 성공 요소

• 각각의 리뷰 활동에서 명확하게 정의된 목적이 있어야 함
• 리뷰 목적에 적합한 인력이 선택 되어야 함
• 결함이 객관적으로 표현되어야 함
• 사람 관련 이슈와 심리적인 측변이 고려되어야 함
• 리뷰 기법을 적절히 활용
• 효과적인 결함 발견을 위해 필요 시에 체크 리스트 및 역할 분담 활용
• 리뷰 기법에 대한 교육 제공
• 관리자가 적극적으로 비류 프로세스를 지원해야 함
• 학습과 프로세스 개선에 대한 강조
• 리뷰 결함과 효과를 내재화하여 지속적으로 적용하는 것이 필요

테스트 설계

테스트 조건

• 테스트 조건을 식별하기 위해 테스트 분석 과정에서 무엇을 테스트 할지 결정하기 위해 테스트 베이시스를 분석한다
• 테스트 조건은 하나 이상의 테스트 케이스로 확인 가능한 항목 또는 이벤트
  
  테이스 베이시스 = 테스트 케이스를 만드는 필요한 모든 자료

테스트 셜계 과정

• 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 한다
  • 테스트 케이스 설계
    • 목적 = 목표하는 보장성을 만족하는 최소한의 테스트 케이스로 가능한 많은 결함을 발견
    • 구성 = 입력 값의 묶음, 실행 사전 조건, 수행 절차, 기대 결과와 실행 사후 조건
    • 테스트 대상을 최대한 빠짐없이 테스트하여 원하는 수준의 테스트 보장성을 확보 할 수 있도록 설계 되어야 한다

테스트 구현 단계

1. 우선순위 선정, 배치
   • 테스트 프로시저 명세서를 작성
   • 테스트 프로시저 = 효율적인 테스트를 위한 테스트 실행 순서
   • 테스트 실행 도구를 사용할 경우 테스트 스크립트 프로시저로 기술
2. 테스트 실행 스케줄 구성
   • 작성된 테스트 프로시저와 자동화된 테스트 스크립트를 언제, 누가 수행할 것인지에 대한 구성
   • 리그레션 테스트 여부, 우선순위, 기술적/논리적 종속 관계 등을 고려하여 결정
3. 테스트 케이스 작성
   • 테스트 수행 절차를 얼마나 상세히 작성할지 결정
   • 테스터의 능력, 해당 시스템의 이해 등을 고려하여 테스트 케이스의 상세 정도를 조정

테스트 전략

1. 요구사항에 명시되어 있으나 구현되지 않은 경우
   테스트 케이스 만들어서 실행
2. 요구사항대로 구현되었으나 때에 따라 정상동작 하지 않는 경우
   테스트 케이스를 요구사항 기반으로 작성, 추가 테이스 케이스 작성
3. 요구사항에 명시되어 있지 않지만 구현된 경우
   비공식적 테스트 추가 실행, 요구사항 변경 및 해당 부분 제거
4. 요구사항에 명시 되어 있지 않지만 구현되었으며, 정상동작 하지 않는 경우
   비공식적 테스트 추가 실행

전통적인 기법 분류

• 블랙 박스 테스팅
  보이는 부분만 테스팅
• 화이트 박스 테스팅
  소프트웨어 내부를 보면서 컴포넌트, 코드 단위 테스팅

설계 기법 분류

1. 명세 기반 기법
   • 해결할 문제를 명세하기 위해 공식, 비공식적 모델을 사용
   • 모델에서 테스트 케이스를 시스템적으로 도출하는 것이 가능
   • 커버리지를 측정할 수 있으나 그 의미 구조 기반 기법의 커버리지에 비해 제한적
2. 구조 기반 기법
   • 코드와 개발 설계 등의 소프트웨어 구현 정보를 기반으로 테스트 케이스를 도출
   • 수행된 테스트케이스를 바탕으로 테스트 커버리지를 측정 가능
   • 커버리지를 높이기 위해 테스트 케이스를 시스템적으로 도출해 추가
3. 경험 기반 기법
   • 테스트 관련 인력의 지식이나 경험으로 테스트 케이스를 도출

명세 기반 기법

• 기능 명세 산출물을 분석하여 테스트 케이스를 선택하는 기법
• 시스템의 내부 구초를 참조하지 않음
• 문서 기반
• 모델로부터 테스트 케이스를 체계적으로 도출할 수 있음
• 블랙박스 테스팅임

명세 기반 기법의 종류

1. 동등 분할
   
   • 하나의 값이 정상적으로 동작한다면 다른 모든 값도 정상 적으로 동작한다는 가정 하에 진행
   • 전체에서 테스트하는 것 보다 각각의 부분에서 하니씩 테스트 하는 것이 효과적
   • 모든 테스트 레벨 및 모든 테스트 유형에서 적용이 가능
   • 유효, 비유효 입력 데이터도 포함할 수 있음
2. 경계 값 분석
   • 동등 분할의 경계 붑분에 해당되는 입력 값에서 결함이 발견될 확률이 경험적으로 높기 때문에 경계 값까지 포함하여 테스트 하는 기법
   • 해당 분할 영역의 최대값과 최소값은 그 영역의 경계 값이 됨
   • 유효한 부ㅡㄹ한 영역의 경계 값은 유효 경계 값이 되며, 비 유효한 분할 영역의 경계 값을 비 유효 경계 값이 됨
   • 경계 값 분석은 모든 테스트 레벨 및 모든 테스트 유형에서 적용이 가능 
3. 결정 테이블 테스팅
   • 논리적인 조건이나 상황을 구현하는 시스템에서 요구사항을 도출하거나 내부 시스템 설계를 문서화 하는 데 유용
   • 시스템이 구현하야 하는 비지니스 구칙을 문서화 하는데 사용
   • 결정 데이블에서 입력조건과 기대결과는 참과 거짓으로 표현
   • 결정 테이블의 각 컬럼 당 적어도 하나의 테스트 케이스를 생성
   • 결정 테이블은 조건부와 액션부로 구성
     조건 = 발생 가능한 모든 사항을 나열
     액션 = 발생 가능한 조건에 따라 처리해야 할 작업을 나열
   • 장점
     논리적으로 의존적인 가능한 모든 조건들의 조합을 생성
     요구사항 등 테스트 베이시스의 문제점을 발견하는데 효과적
     테스트 베이시스의 불완전성과 모호함 발견 가능
     테스트 케이스를 만들변서 명세의 결함을 발견하는 것이 가능
   • 단점
     작성에 많은 노력과 시간이 소요
     복잡한 시스템은 표현하기 어려울 수 있으며 작성 시 논리적 실수 가능성이 있음
4. 상태 전이 테스팅
   • 시스템은 현재 상황과 이전의 이력을 반영하는 상태 및 그 변화에 따라 다르게 동작할 수 있음
   • 상태전이 다이어그램으로 표현할 수 있으며 이 다이어그램을 바탕으로 테스트 케이스를 도출
   • 상태 전이 다이어그램을 바탕으로 테스트 케이스 토출하는 순서
     • 상태 이벤트 테이블 구성
     • 전이 트리 구성
     • 반응 테이스 케이스 구성
     • 무반응 테이트 케이스 구성
     • 가드 또는 조건 테이스 케이스 구성
     • 테스트 프로시저 구성
5. 유즈 케이스 테스팅
   • 유즈 케이스나 비지니스 시나리오를 기반으로 테스트 명세화
     • 유즈케이스란?
       사용자의 관점에서 시스템을 모델링 하는 역할 수행
       누가, 무엇을 할 수 있는지에 대해 상세히 기술해 놓은 집합
       사용자 시각에 맞춘 분석
   • 시스템이 유즈케이스로 모델링 되어 있을 때, 유즈케이스에서 테스트 케이스를 도출하는 테스트 설계 기법
   • 유즈케이스 명세서
     • 시스템이 제공하는 기본 단위 기능을 정의
     • 유즈케이스와 액터간의 상호작용

유즈케이스 테스팅 종류

1. 컴포넌트 레벨 유즈케이스 테스팅
2. 시스템 레벨 유즈 케이스 테스팅

상태전이와 유즈 케이스의 차이점

• 상태전이 테스팅은 시스템의 상태 변화에 중심을 두고 테스트
• 유즈 케이스는 사용자의 사용 시나리오에 따라 테스트를 수행하는 접근법

 

구조 기반 기법 = 화이트 박스

1. 컴포넌트 레벨
2. 통합 레벨
3. 시스템 레벨

커버리지

시스템 또는 소프트웨어의 구조가 테스트 스위트에 의해 테스트 된 정도

 

경험 기반 기법

유사 소프트웨어나 기술의 경험, 직관, 테스터의 기술능력으로 부터 테스트 케이스를 추출하는 기법

공식적인 기법을 적용한 후에 경험 기반 기법을 적용

공식적인 기법이 찾기 어려운 결함 발견이 가능

 

경험기반 기법 종류

1. 탐색적 테스팅
   경험에 의해 직관적으로 살펴보며 버그 탐색
2. 오류 추정
   유사 프로젝트 경험을 활용해 결함 예상
3. 체크 리스트
   과거 체크 리스트를 활용하여 소프트웨어를 검증
4. 스크립트 기반 테스팅
   과거 절차와 결과를 활용
5. 분류 트리 기법
   입력값을 카테고리 구분, 사용