728x90

블랙박스 테스트 기법

1. 동등 분할 : 특정 파티션의 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션에 데이터를 분할한다. 유효한 값과 비유효한 값 모두에 대해 동등 분할을 구성할 수 있다.

  • 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.
  • 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(masked) 즉, 가려지는 것을 방지하기 위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다. 동시에 여러 장애가 발생할 때 겉으로 드러나는 하나의 장애 때문에 나머지가 인식되지 않아 장애가 가려지는 경우가 발생한다.

2. 경곗값 분석 : 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다. 분할의 최솟값과 최댓값(또는 첫 번째 값과 마지막 값)은 해당 분할의 경곗값이 된다.

  • 경곗값 분석은 모든 테스트 레벨에 적용할 수 있다. 이 기법은 일반적으로 숫자의 범위(날짜, 시간 포함)와 연관된 요구사항을 테스트하는 데 적용된다. 경곗값 분석 커버리지는 보통 백분율로 표기하며, 테스트한 경곗값의 수를 식별한 모든 경곗값의 수로 나눠서 계산한다.

3. 결정 테이블 테스팅 : 결정 테이블을 작성할 때 테스터는 시스템의 조건과 예상 동작을 식별한다. 이것들은 테이블의 행(rows)을 형성하며 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다. 각 열(column)은 하나의 결정 규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의한다.

4. 상태 전이 테스팅 : 컴포넌트나 시스템은 현재 조건이나 기존 이력에 따라 이벤트에 대해 다르게 반응할 수 있다. 기존 이력은 상태라는 개념을 활용해서 요약할 수 있다. 상태 전이 다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여준다. 전이는 이벤트에 의해 시작된다. 이 이벤트는 전이라는 결과를 가져온다. 하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생할 수 있다. 상태 변화로 소프트웨어가 특정 행동을 할 수도 있다.

5. 유스케이스 테스팅 : 유스케이스는 소프트웨어 기능에 대한 요구사항을 통합한다. 유스케이스는 액터와 대상 간의 관계이다. 각 유스케이스는 대상이 하나 이상의 액터와 협력하여 수행할 수 있는 동작들을 명시하고 있다. 유스케이스를 상호작용과 활동으로 설명하기도 하고, 적절한 경우 사전 조건, 사후 조건 및 자연어로 설명할 수도 있다. 액터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다. 상호작용은 워크플로우, 활동 다이어그램, 비즈니스 프로세스 모델로 시각화할 수 있다.

화이트박스 테스트 기법

  1. 구문 테스팅과 커버리지 : 구문 테스팅은 코드의 잠재적으로 실행 가능한 구문을 실행한다. 커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행한 구문의 수를 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산한다.
  2. 결정 테스팅과 커버리지 : 결정 테스팅은 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다. 이것을 달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다. 커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행된 결정문 결과의 수를 테스트 대상의 가능한 모든 결정문 결과의 수로 나눠서 계산한다.

경험 기반 테스트 기법

  1. 오류 추정 : 오류 추정 기법에 대한 체계적인 접근법은 발생 가능한 오류, 결함, 장애 목록을 작성하고 이런 장애와 그것의 원인이 되는 결함을 노출하는 테스트를 설계하는 것이다. 이러한 오류, 결함, 장애 목록은 경험, 결함 및 장애 데이터 또는 소프트웨어가 실패한 이유에 대한 일반적인 지식을 기반으로 작성할 수 있다.
  2. 탐색적 테스팅 : 탐색적 테스팅에서는 비공식(사전에 정의되지 않은) 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가한다. 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한 테스트를 작성하는 데 활용된다.
  3. 체크리스트 기반 테스팅 : 체크리스트 기반 테스팅에서는 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있지만, 기존 체크리스트를 수정하지 않고 그대로 사용하는 경우도 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다.

테스트 전략과 테스트 접근법

  1. 분석적 : 특정 요소에 대한 분석을 기반으로 한 테스트 전략. 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법의 예이다.
  2. 모델 기반 : 이러한 유형의 테스트 전략에서 테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어진다. 특정 측면에는 기능, 비즈니스 프로세스, 내부 구조, 비기능 특성 등이 있다. 모델에는 비즈니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델 등이 있다.
  3. 방법론적 : 이 테스트 전략은 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존한다. 예를 들어, 보편적이고 발생 가능성이 높은 장애 분류, 주요 품질 특성 목록, 모바일 애플리케이션이나 웹페이지에 대한 전사 룩앤필 표준 등이 있다.
  4. 프로세스 준수 : 이 테스트 전략은 외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현한다. 예를 들어, 특정 산업 표준에서 제시하는 규정이나 표준, 프로세스의 문서화, 테스트 베이시스의 엄격한 식별과 사용, 조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반으로 한다.
  5. 전문가 조언 : 이 테스트 전략은 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어진다. 이 사람들은 외부 테스트팀이나 외부 조직 소속일 수 있다.
  6. 리그레션-기피 : 기존 기능에 대한 리그레션 테스트 기피를 목표로 한다. 이 테스트 전략에는 기존 테스트웨어의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
  7. 반응적 : 지금까지 소개한 사전 계획에 따라 실행하는 테스트 전략과는 달리 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법이다. 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 탐색적 테스팅이 반응적 전략에서 일반적으로 사용하는 기법이다.

형상 관리

  1. 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
  2. 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 한다.
  3. 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

결함관리 : 테스팅의 목적 중 하나가 결함을 찾는 것이기 때문에 테스팅 중 발견한 결함은 반드시 기록해야 한다. 결함을 기록하는 방법은 테스트 대상 컴포넌트나 시스템의 정황, 테스트 레벨, 소프트웨어 개발 수명주기 모델에 따라 달라진다. 찾아낸 모든 결함은 조사하고, 발견에서 결함 분류까지 추적해야 한다. 모든 결함을 해결까지 관리하기 위해 조직은 결함 관리 프로세스를 수립해야 한다. 아키텍처, 설계자, 개발자, 테스터, 제품 책임자 등 결함 관리에 참여하는 모든 사람이 프로세스에 동의해야 한다. 일부 조직에서는 결함 로깅과 추적이 매우 비공식적일 수 있다.

테스트 도구의 분류

  1. 테스팅 및 테스트웨어 관리 지원 도구
  2. 정적 테스팅 지원 도구
  3. 테스트 설계 및 구현 지원 도구
  4. 테스팅 실행 및 로깅 지원 도구
  5. 성능 측정과 동적 분석 지원 도구
  6. 특수 목적 테스팅 지원 도구

테스트 실행 도구

  1. 캡처 기반 테스트 접근법 : 테스터의 수동적인 조작을 녹화해 테스트를 캡처하는 것은 매력적으로 보일 수 있지만 이러한 접근 방식은 테스트 스크립트의 수가 많을 경우 적절하지 않다. 캡처한 스크립트마다 특정 데이터와 행위를 1 차원적으로 표현하고 있기 때문에 미처 예상하지 못한 이벤트가 발생하면 취약할 수 있으며, 시스템의 사용자 인터페이스가 시간이 지남에 따라 바뀌게 되면 스크립트도 그에 맞게 계속해서 유지보수를 해 줄 필요가 있다.
  2. 데이터 주도 테스트 접근법 : 이 접근법은 테스트 입력값과 기대 결과값을 보통 스프레드시트에 저장하고 더 많은 공통 스크립트를 활용해 해당 테스트 데이터를 읽어 들여 동일한 테스트 스크립트를 매번 다른 데이터로 반복적으로 실행한다.
  3. 키워드 주도 테스트 접근법 : 이 접근법은 해야 할 행동을 설명하는 키워드를 공통 스크립트가 처리해 키워드 스크립트를 호출한다. 키워드 스크립트는 연관된 테스트 데이터를 처리한다.
728x90

'테스팅' 카테고리의 다른 글

ISTQB CTFL 실라바스1  (0) 2024.03.22
애플리케이션 테스트 관리  (2) 2024.03.22
728x90

테스팅의 목적

  1. 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
  2. 명시된 모든 요구사항이 충족됐는지 검증
  3. 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
  4. 테스트 대상의 품질 수준에 대한 자신감 획득
  5. 부적절한 소프트웨어 품질의 리스크 레벨 감소로 장애와 결함을 발견
  6. 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
  7. 계약 / 법률 / 규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인

테스트 활동과 작업

  1. 테스트 계획
  2. 테스트 모니터링과 제어
  3. 테스트 분석
  4. 테스트 설계
  5. 테스트 구현
  6. 테스트 실행
  7. 테스트 완료

테스트 베이시스와 테스트 작업 산출물 간의 추적성의 장점

  1. 수정으로 인한 영향 평가를 가능하게 한다.
  2. 테스팅에 대한 감사를 가능하게 한다.
  3. IT 통제조건을 충족할 수 있게 한다.
  4. 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행 상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있게 한다.
  5. 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달한다.
  6. 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.

반복적 개발의 예

  1. 래셔널 통합 프로세스 : 각 반복주기가 상당히 긴 경우가 많으며 따라서 기능 증분도 상당히 큼
  2. 스크럼 : 각 반복주기가 짧은 성향을 가지며 따라서 기능 증분도 작음
  3. 칸반 : 반복주기 기간이 고정된 경우와 고정되지 않은 경우가 있으며, 각 반복주기는 완료 후 하나의 개선 사항이나 기능을 전달하거나 몇 개의 기능을 묶어 한 번에 전달할 수도 있음
  4. 나선형 : 실험적인 증분을 생성, 일부는 차후 개발 과정에서 상당 부분 수정되거나 심한 경우 폐기되기도 함

유지보수가 필요한 상황

  1. 개선을 위한 변경, 계획된 확장, 수정 혹은 긴급 변경, 운영 환경 변경, 상용 소프트웨어 업그레이드, 결함 및 취약성을 위한 패치 등
  2. 이관을 위한 변경, 하나의 플랫폼에서 다른 플랫폼으로 이관할 때, 변경된 소프트웨어뿐만 아니라 신규 환경에 대한 운영 테스트가 필요할 수 있거나 또는 유지보수하고 있는 시스템에 이관하는 다른 애플리케이션의 데이터를 위한 데이터 전환 테스트 등
  • 단종, 애플리케이션의 수명이 다할 때 등, 애플리케이션이나 시스템이 단종될 때 데이터 이관이나 장시간의 데이터 유지가 필요하면 보관처리에 대한 테스팅이 필요할 수 있다.
  • 장시간의 보관이 필요한 경우 차후 복원/회수 절차에 대한 테스팅이 필요할 수 있다.
  • 여전히 서비스하고 있는 기능이 있다면, 해당 기능이 정상 동작할거라는 확신을 얻기 위한 리그레션 테스팅이 필요할 수 있다.

정적 테스팅으로 검토할 수 있는 작업 산출물

  1. 비즈니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
  2. 에픽, 사용자 스토리, 인수 기준
  3. 아키텍처 및 설계 명세
  4. 코드
  5. 테스트 계획, 테스트 케이스, 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어
  6. 사용자 가이드
  7. 웹 페이지
  8. 계약, 프로젝트 계획, 일정, 예산 기획
  9. 형상 및 인프라 셋업
  10. 액티비티 다이어그램과 같은 모델 기반 테스팅에 사용되는 모델

동적 테스팅에 비해 쉽고 비용도 적은 정적 테스팅의 일반적 결함 유형

  1. 요구사항 결함 (ex. 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
  2. 설계 결함 (ex. 비효율적인 알고리즘이나 데이터베이스 구조, 높은 결합도, 낮은 응집도 등)
  3. 코딩 결함 (ex. 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
  4. 표준과의 차이 (ex. 코딩 표준 미준수 등)
  5. 잘못된 인타페이스 명세 (ex. 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
  6. 보안 취약점 (ex. 버퍼 오버플로우에 대한 취약성)
  7. 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성 (ex. 특정 인수 조건에 대한 테스트 누락)

리뷰의 단계

  1. 계획
  2. 리뷰 착수
  3. 개별 리뷰
  4. 이슈 논의 및 분석
  5. 수정 및 보고

공식 리뷰에서의 역할

  1. 저자
  2. 관리자
  3. 촉진자
  4. 리뷰 리더
  5. 검토자
  6. 서기

리뷰 유형

  1. 비공식 리뷰 : 잠재적 결함 발견
  2. 워크쓰루 : 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가
  3. 기술 리뷰 : 합의 도출, 잠재적 결함 발견
  4. 인스펙션 : 잠재적 결함 발견, 작업 산출물의 품질 평가 및 자신감 획득, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방

리뷰 기법 적용

1. 애드혹 : 검토자에게 리뷰 수행 방법에 대한 안내가 거의 또는 전혀 제공되지 않고 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록한다. 애드혹 리뷰는 특별한 준비 없이 일반적으로 사용되는 기법이다. 이 기법은 검토자의 능력에 크게 의존하며, 여러 검토자가 동일한 문제를 보고할 수 있다.

2. 체크리스트 기반 : 검토자는 리뷰 시작 시점에 배포된 체크리스트를 기반으로 이슈를 식별한다. 리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성된다. 체크리스트는 리뷰 대상 작업 산출물 유형별로 작성해야 하며 이전 리뷰에서 누락된 이슈 유형을 다루기 위해 주기적으로 개선할 필요가 있다. 체크리스트 기반 기법의 주요 장점은 일반적인 결함 유형에 대한 체계적인 커버리지를 갖는다는 점이다. 개별 리뷰를 수행할 때 검토자는 체크리스트를 단순히 실행하는 것 뿐만 아니라, 체크리스트로 식별할 수 없는 결함도 찾기 위해 특별한 주의를 기울여야 한다.

3. 시나리오 및 드라이 런 : 시나리오 기반 리뷰에서 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공받는다. 시나리오 기반 리뷰는 작업 산출물의 예상되는 용도를 기반으로 작업 산출물에 대해 드라이런을 수행할 수 있도록 검토자를 지원한다. 이러한 시나리오는 검토자에게 단순한 체크리스트 항목보다 특정 결함 유형을 식별하는 방법에 대한 좀 더 나은 지침을 제공한다. 체크리스트 기반 리뷰와 마찬가지로, 다른 결함 유형을 발견하기 위해 검토자는 기록된 시나리오에만 너무 얽매이지 않아야 한다.

4. 관점 기반 : 관점 기반 읽기)는 역할 기반 리뷰와 마찬가지로 검토자가 개별 리뷰 중 다양한 이해관계자의 관점을 사용하게 된다. 일반적으로 사용되는 이해관계자 관점에는 최종 사용자, 영업, 설계자, 테스터, 운영자 등이 있다. 서로 다른 이해관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행된다. 또한, 관점 기반 읽기에서는 검토자가 리뷰 대상 작업 산출물로부터 이해관계자의 관점을 기반으로 하는 산출물을 작성해야 한다. 예를 들어, 테스터가 필요한 모든 정보가 존재하는지 확인하기 위해 요구사항 명세에 대한 관점 기반 읽기를 수행하면서 인수 테스트 초안을 작성을 시도할 수 있다. 또한 관점 기반 읽기에서는 체크리스트도 활용한다.

5. 역할 기반 : 역할 기반 리뷰는 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법이다. 일반적인 역할에는 특정 최종 사용자 유형(경험 많은, 경험 적은, 노인, 아동 등)과 조직 내 특정 역할(사용자 관리자, 시스템 관리자, 성능 테스터 등)이 있다. 역할이 비슷하기 때문에 같은 원칙이 관점 기반 읽기에도 적용된다.

728x90

'테스팅' 카테고리의 다른 글

ISTQB CTFL 실라바스2  (0) 2024.03.22
애플리케이션 테스트 관리  (2) 2024.03.22
728x90

개발자는 코드를 쓰거나 소프트웨어나 시스템 또는 문서를 작성할 때 결함을 만드는 오류를 범할 수 있다. 코드에 존재하는 결함은 장애의 원인이 된다. 결함은 장애의 원인이 되지만, 모든 결함이 장애를 일으키는 것은 아니다. 테스팅은 결함이 존재함을 밝히는 활동이다.

애플리케이션 테스트는 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(validation) 하고 소프트웨어가 기능을 정확히 수행하는지 검증(verification) 한다. 이를 V&V 모델이라고 한다. 시각에 따른 테스트에 속한다.

검증 테스트는 개발자가 제품이 명세서대로 잘 완성됐는지 제품의 생산 과정을 테스트하는 것이다.

확인 테스트는 사용자가 요구한 대로 잘 됐는지 사용자 입장에서 동작하고 확인하는 테스트이다.

완벽한 테스팅은 불가능
소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어에 결함이 아예 없다고 증명할 수는 없다.
파레토 법칙(결함 집중)
테스트 개체의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다.
살충제 패러독스
동일한 테스트 케이스로 테스트를 반복하게 되면 결함이 더 이상 발견되지 않는다.
테스팅은 정황에 의존
소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라지므로 각각에 알맞게 수행해야 한다.
오류-부재의 궤변
결함을 모두 제거해도 결국 요구사항을 만족시키지 못하면 품질이 높다고 말할 수 없다.
테스트와 위험은 반비례
테스트를 많이 할수록 앞으로 발생할 결함을 줄일 수 있다.
테스트의 점진적 확대
테스트는 작은 단위부터 큰 단위로 점점 확대하며 진행해야 한다.
테스트의 별도 팀 수행
테스트는 개발자와 상관없는 팀으로 수행해야 한다.

정적 테스트는 프로그램을 실행하지 않고 명세서, 소스 코드를 대상으로 분석하는 테스트이다. 프로그램 실행 여부에 따른 테스트에 속한다. ex) 워크 스루, 인스펙션,코드검사

워크스루
소프트웨어 개발자가 모집한 전문가들이 개발자의 작업 내역을 검토하는 것
인스펙션
소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하고 이를 개선하기 위해 방법을 제시

동적 테스트는 프로그램을 실행시켜 진행하는 테스트이다. 프로그램 실행 여부에 따른 테스트에 속한다. ex) 블랙박스 테스트, 화이트박스 테스트

블랙박스 테스트 : 각 기능이 완전히 작동되는가? 하는 기능 테스트이다. ex) 동치 분할, 경곗값 분석 등

원인 - 효과 그래프 검사
여러 입 출력 간에 높은 영향을 미치는 케이스를 분석 후 채택하여 효용성이 높은 테스트 케이스를 선정하여 검사한다.
동치 분할 검사(동등 분할 기법)
프로그램에 중간 값들을 대입하여 해당 입력 값들이 예상대로 나오는지 테스트하는 기법이다. 0 ~ 10 중의 숫자 중 입력 : 5
경곗값 분석
중간 값이 아닌 경곗값을 테스트 케이스로 선정하여 검사한다. 0 ~ 10 중의 숫자 중 입력 : 10
오류 예측 검사
확인자의 경험으로 예측하여 테스트한다.
비교 검사
여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 같은 결과가 출력되는지 테스트한다.

화이트박스 테스트 : 원시 코드를 오픈시키고 원시 코드의 논리적인 모든 경로를 테스트한다. ex) 기초 경로 검사, 제어 구조 검사

기초 경로 검사
테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 하는 기법
제어 구조 검사
조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트
루프 검사 : 프로그램의 반복 구조에 초점을 맞춰서 테스트
데이터 흐름 검사 : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰서 테스트
문장 검증 기준
소스 코드의 모든 구문이 한 번 이상 수행되나 하는 기준
분기 검증 기준(결정 검증 기준)
모든 조건문에 대한 결과가 True 혹은 False가 한 번 이상 수행되나 하는 기준
조건 검증 기준
모든 조건문에 포함된 개별 조건식의 결과가 True 혹은 False가 한 번 이상 수행되나 하는 기준
분기/조건 기준
분기 검증 기준과 조건 검증 기준을 합쳐 모든 조건식, 조건문이 True False가 한 번 이상 수행되나 하는 기준

테스트 기반에 따른 애플리케이션 테스트

명세 기반 테스트
사용자의 요구사항에 대한 명세를 다 갖췄나 확인하는 테스트 ex) 동등 분할, 경곗값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 유즈케이스 테스팅
구조 기반 테스트
프로그램에 대한 논리 흐름에 따라 작성하고 확인하는 테스트 ex) 구문 기반, 결정 기반, 조건 기반
경험 기반 테스트
테스트 관련 인력의 지식이나 경험으로 테스트 케이스를 도출 ex) 에러 추정, 체크 리스트, 탐색적 테스팅

목적에 따른 테스트

회복 테스트
시스템에 여러 가지 결함을 주어 실패하도록 한 뒤 올바르게 회복되는지 확인
안전 테스트
시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인
강도 테스트
시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지 확인
성능 테스트
소프트웨어의 실시간 성능이나 전체적인 효율성을 진단 (테스트 응답시간, 처리량 등)
구조 테스트
소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가
회귀 테스트
소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인
병행 테스트
변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교

V-모델(순차적 개발 모델) : 요구사항 정의 및 분석, 시스템 설계, 구현, 테스팅이라는 일련의 단계를 통해 소프트웨어(시스템)을 개발하는 폭포수 개발 모델(Waterfall model)에 근간을 두는 모델

단위 테스트(컴포넌트 테스트) : 테스트가 가능한 최소 단위로 나누어진 소프트웨어(모듈, 프로그램, 객체, 클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것

통합 테스트 : 컴포넌트간의 인터페이스, OS, 파일 시스템, 하드웨어, 시스템간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트하는 것

비점진적 통합 방식
단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트하는 방법 ex) 빅뱅 통합 테스트
점진적 통합 방식
모듈 단위로 단계적으로 통합하면서 테스트하는 방법 ex) 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트
하향식 통합 테스트
가장 상부의 모듈부터 통합해가면서 필요시 시험용 모듈인 스텁을 사용한다.
상향식 통합 테스트
가장 하부의 모듈부터 통합해가면서 하위 모듈을 클러스터로 결합한다. 하위 모듈을 호출하고 파라미터를 전달하는 테스트 드라이버를 작성하며 상위로 이동하며 결합시에 드라이버는 실제 모듈로 대체된다.
혼합식 통합 테스트
하위에서는 상향식 통합, 상위에서는 하향식 통합을 사용한다.
회귀 테스팅
통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인한다.

시스템 테스트 : 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트하는 것

인수 테스트 : 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 테스트이다. 다른 이해관계자도 참여가능

사용자 인수 테스팅
비즈니스 사용자가 시스템 사용의 적절성을 확인
운영상의 테스팅
시스템 관리자에 의한 테스팅이다. ex) 백업/복원 테스팅, 재난 복구, 사용자 관리, 유지보수, 보안 취약성에 대한 정기적 점검
계약 인수 테스팅
맞춤식 개발 소프트웨어가 계약상의 인수 통과 조건을 준수하는지 확인
규정 인수 테스팅
정부 지침, 법률 또는 안전 규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인
알파 테스팅
개발 조직 내에서 고객에 의해 수행되는 테스팅
베타 테스팅
실제 환경에서 사용자 혹은 잠재 고객에 의해 수행되는 테스팅

테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법

참 오라클
모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클
샘플링 오라클
특정한 몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
추정 오라클
특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
일관성 검사 오라클
애플리케이션에 변경이 있을 때, 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클

테스트 자동화 : 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적으로 테스트를 수행할수 있도록 한 것 ex) 정적 분석 도구, 테스트 실행 도구, 성능 테스트 도구, 테스트 통제 도구

정적 분석 도구
프로그램을 실행하지 않고 분석하는 도구
테스트 실행 도구
스크립트 언어를 사용하여 테스트를 실행하는 도구
성능 테스트 도구
가상의 사용자를 만들어 테스트를 수행하는 도구
테스트 통제 도구
테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구
테스트 하네스 도구
테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구

테스트 하네스의 구성 요소

테스트 드라이버
테스트 대상의 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구
테스트 스텁
제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
테스트 슈트
테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
테스트 케이스
사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력값, 실행 조건 기내 결과 등으로 만들어진 테스트 항목의 명세서
테스트 스크립트
자동화된 테스트 실행 절차에 대한 명세서
목 오브젝트
사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체

결함 관리 도구

Mantis
결함 및 이슈 관리 도구로, 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적도 가능한 도구
Trac
결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구
Redmine
프로젝트 관리 및 결함 추적이 가능한 도구
Bugzilla
결함 신고, 확인, 처리 등 결함을 지속적으로 관리할 수 있는 도구
Jira
버그 및 문제 테스트에 소요되는 에너지, 시간, 비용을 절약할 수 있는 도구

결함 관리 측정 지표

결함 분포
모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
결함 추세
테스트 진행 시간에 따른 결함 수 의 추이 분석
결함 에이징
특정 결함 상태로 지속되는 시간 측정

성능 테스트 도구

JMeter
HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구
Cross-Platform
LoadUI
서버 모니터링이 가능한 편리성이 강화된 도구 HTTP, JDBC 등 다양한 프로토콜을 지원한다.
Cross-Platform
OpenSTA
HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구
Windows
처리량
일정 시간 내에 애플리케이션이 처리하는 일의 양
응답 시간
애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
경과 시간
애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때 까지 걸린 시간
자원 사용률
애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

클린 코드 : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순 명료한 코드

베드 코드 : 프로그램의 로직이 복잡하고 이해하기 어려운 코드

스파게티 코드
코드의 로직이 서로 복잡하게 얽혀 있는 코드
외계인 코드
아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드

정적 분석 도구

pmd
소스 코드에 대한 미사용 변수, 최적화되지 않은 코드 등 결함을 유발할 수 있는 코드를 검사
Linux, Windows
cppcheck
C/C++ 코드에 대한 메모리 누수, 오버플로우 등 분석
Windows
SonarQube
중복 코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼
Cross-Platform
checkstyle
자바 코드에 대해 소스 코드 표준을 따르고 있는지 검사
Cross-Platform
ccm
다양한 언어의 코드 복잡도를 분석함
Cross-Platform
cobertura
자바 언어의 소스 코드 복잡도 분석 및 테스트 커버리지를 측정함
Cross-Platform

동적 분석 도구

Avalanche
프로그램에 대한 결함 및 취약점 등을 분석함
Linux, Android
Valgrind
프로그램 내에 존재하는 메모리 및 쓰레드 결함등을 분석함
Cross-Platform

시간 복잡도 : 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화한 것 시간 복잡도가 낮을수록 알고리즘의 실행시간은 짧다.

점근 표기법

빅오 표기법(Big-O)
알고리즘의 실행시간이 최악일 때를 표기하는 방법
세타 표기법(Big-θ)
알고리즘의 실행시간이 평균일 때를 표기하는 방법
오메가 표기법(Big-Ω)
알고리즘의 실행시간이 최상일 때를 표기하는 방법

빅오 표기법의 시간 복잡도

O(1)
입력값에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침
ex) 스택의 Push, Pop
O(log₂n)
문제 해결에 필요한 단계가 입력값 또는 조건에 의해 감소함
ex) 이진 트리, 이진 검색
O(n)
문제 해결에 필요한 단계가 입력값과 1:1 관계를 가짐
ex) for문
O(nlog₂n)
문제 해결에 필요한 단계가 n(log₂n)번만큼 수행됨
ex) 힙 정렬, 2-Way 합병 정렬
O(n²)
문제 해결에 필요한 단계가 입력값의 제곱만큼 수행됨
ex) 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬
O(2ⁿ)
문제 해결에 필요한 단계가 2의 입력값 제곱만큼 수행됨
ex) 피보나치 수열

순환 복잡도 : 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도

순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산한다.

V(G) = E - N + 2 // E는 화살표의 수, N은 노드의 수

728x90

'테스팅' 카테고리의 다른 글

ISTQB CTFL 실라바스2  (0) 2024.03.22
ISTQB CTFL 실라바스1  (0) 2024.03.22

+ Recent posts