메뉴

소프트웨어 테스트 유형 : 세부 정보가있는 다양한 테스트 유형

types software testing

문제를 제거하기 위해 도구를 사용해보십시오

소프트웨어 테스트에는 어떤 유형이 있습니까?

테스터로서 우리는 기능 테스트, 비 기능 테스트, 자동화 테스트, 애자일 테스트 및 해당 하위 유형 등과 같은 다양한 유형의 소프트웨어 테스트를 알고 있습니다.

우리 각자는 테스트 여정에서 여러 유형의 테스트를 접했을 것입니다. 우리는 일부를 듣고 일부 작업을했을 수도 있지만 모든 사람이 모든 테스트 유형에 대해 알고있는 것은 아닙니다.

다양한 유형의 소프트웨어 테스트

각 테스트 유형에는 고유 한 기능, 장점 및 단점도 있습니다. 그러나이 기사에서는 일상적인 테스트 생활에서 일반적으로 사용하는 모든 유형의 소프트웨어 테스트를 대부분 다루었습니다.

가서 한 번 봅시다.

학습 내용 :

다양한 유형의 소프트웨어 테스트

다음은 몇 가지 일반적인 유형의 소프트웨어 테스트 목록입니다.

기능 테스트 유형은 다음과 같습니다.

  • 단위 테스트
  • 통합 테스트
  • 시스템 테스트
  • 온 전성 테스트
  • 연기 테스트
  • 인터페이스 테스트
  • 회귀 테스트
  • 베타 / 수락 테스트

비 기능 테스트 유형은 다음과 같습니다.

  • 성능 시험
  • 부하 테스트
  • 스트레스 테스트
  • 볼륨 테스트
  • 보안 테스트
  • 호환성 테스트
  • 테스트 설치
  • 복구 테스트
  • 신뢰성 테스트
  • 사용성 테스트
  • 적합성 테스트
  • 현지화 테스트

이러한 테스트 유형에 대한 자세한 내용을 살펴 보겠습니다.

소프트웨어 테스트 유형

# 1) 알파 테스트

소프트웨어 산업에서 사용되는 가장 일반적인 유형의 테스트입니다. 이 테스트의 목적은 시장 또는 사용자에게 출시하기 전에 가능한 모든 문제 또는 결함을 식별하는 것입니다.

알파 테스트는 소프트웨어 개발 단계의 마지막 단계에서 베타 테스트 전에 수행됩니다. 그러나 그러한 테스트의 결과로 사소한 설계 변경이 이루어질 수 있습니다.

알파 테스트 개발자 사이트에서 수행됩니다. 이러한 유형의 테스트를 위해 사내 가상 사용자 환경을 만들 수 있습니다.

# 2) 수락 테스트

안 승인 테스트 클라이언트에 의해 수행되며 시스템의 종단 간 흐름이 비즈니스 요구 사항에 따른 것인지 최종 사용자의 요구 사항에 따른 것인지 여부를 확인합니다. 클라이언트는 모든 기능이 예상대로 작동하는 경우에만 소프트웨어를 수락합니다.

테스트의 마지막 단계로 소프트웨어가 생산에 들어갑니다. 이를 UAT (User Acceptance Testing)라고도합니다.

# 3) 임시 테스트

이름 자체는이 테스트가 임시 즉, 테스트 케이스에 대한 참조가없고 이러한 유형의 테스트에 대한 계획이나 문서가 없습니다.

이 테스트의 목적은 응용 프로그램의 흐름이나 임의의 기능을 실행하여 결함을 찾고 응용 프로그램을 중단하는 것입니다.

임시 테스트는 결함을 찾는 비공식적 인 방법이며 프로젝트의 모든 사람이 수행 할 수 있습니다. 테스트 케이스없이 결함을 식별하는 것은 어렵지만 때로는 임시 테스트 중에 발견 된 결함이 기존 테스트 케이스를 사용하여 식별되지 않았을 수 있습니다.

# 4) 접근성 테스트

목표 접근성 테스트 장애인이 소프트웨어 또는 응용 프로그램에 액세스 할 수 있는지 여부를 결정하는 것입니다.

여기서 장애는 청각 장애, 색맹, 정신 장애, 시각 장애, 노령 및 기타 장애 그룹을 의미합니다. 시각 장애인 용 폰트 크기, 색맹 인 경우 색상 및 대비 등 다양한 검사를 수행합니다.

# 5) 베타 테스트

베타 테스트 고객이 수행하는 공식적인 유형의 소프트웨어 테스트입니다. 그것은에서 수행됩니다 실제 환경 실제 최종 사용자를 위해 제품을 시장에 출시하기 전에

베타 테스트는 소프트웨어 또는 제품에 중대한 오류가 없는지 확인하고 최종 사용자 관점에서 비즈니스 요구 사항을 충족하는지 확인하기 위해 수행됩니다. 베타 테스트는 고객이 소프트웨어를 수락하면 성공적입니다.

일반적으로이 테스트는 일반적으로 최종 사용자 또는 다른 사용자가 수행합니다. 상업적 목적으로 애플리케이션을 출시하기 전에 수행되는 최종 테스트입니다. 일반적으로 출시 된 소프트웨어 또는 제품의 베타 버전은 특정 영역의 특정 사용자 수로 제한됩니다.

따라서 최종 사용자는 실제로 소프트웨어를 사용하고 피드백을 회사에 공유합니다. 그런 다음 회사는 소프트웨어를 전세계에 출시하기 전에 필요한 조치를 취합니다.

# 6) 백엔드 테스트

프런트 엔드 애플리케이션에 입력 또는 데이터를 입력 할 때마다 데이터베이스에 저장되며 이러한 데이터베이스의 테스트를 데이터베이스 테스트 또는 백엔드 테스트라고합니다.

SQL Server, MySQL, Oracle 등과 같은 다양한 데이터베이스가 있습니다. 데이터베이스 테스트에는 테이블 구조, 스키마, 저장 프로 시저, 데이터 구조 등의 테스트가 포함됩니다.

백엔드 테스트 GUI가 관련되지 않은 경우 테스터는 적절한 액세스 권한으로 데이터베이스에 직접 연결되며 테스터는 데이터베이스에서 몇 가지 쿼리를 실행하여 데이터를 쉽게 확인할 수 있습니다.

이 백엔드 테스트 중에 데이터 손실, 교착 상태, 데이터 손상 등과 같은 문제가 식별 될 수 있으며 이러한 문제는 시스템이 프로덕션 환경에 적용되기 전에 수정하는 데 중요합니다.

# 7) 브라우저 호환성 테스트

호환성 테스트의 하위 유형 (아래에 설명 됨)이며 테스트 팀에서 수행합니다.

브라우저 호환성 테스트 웹 애플리케이션에 대해 수행되며 소프트웨어가 다른 브라우저 및 운영 체제의 조합으로 실행될 수 있도록합니다. 이러한 유형의 테스트는 웹 애플리케이션이 모든 브라우저의 모든 버전에서 실행되는지 여부도 확인합니다.

# 8) 하위 호환성 테스트

새로 개발 된 소프트웨어 또는 업데이트 된 소프트웨어가 이전 버전의 환경에서 잘 작동하는지 여부를 확인하는 테스트 유형입니다.

이전 버전과의 호환성 테스트는 새 버전의 소프트웨어가 이전 버전의 소프트웨어에서 만든 파일 형식으로 제대로 작동하는지 확인합니다. 또한 해당 소프트웨어의 이전 버전에서 생성 된 데이터 테이블, 데이터 파일, 데이터 구조와도 잘 작동합니다.

소프트웨어가 업데이트 된 경우 해당 소프트웨어의 이전 버전 위에서 잘 작동합니다.

# 9) 블랙 박스 테스트

이러한 유형의 테스트에서는 내부 시스템 설계를 고려하지 않습니다. 테스트는 요구 사항과 기능을 기반으로합니다.

장점, 단점 및 블랙 박스 테스트 유형 볼 수있다 여기 .

# 10) 경계 값 테스트

이 유형의 테스트는 경계 수준에서 응용 프로그램의 동작을 확인합니다.

경계 값 테스트 경계 값에 결함이 있는지 확인하기 위해 수행됩니다. 경계 값 테스트는 다른 범위의 숫자를 테스트하는 데 사용됩니다. 각 범위에 대한 상한과 하한이 있으며 이러한 경계 값에 대해 테스트가 수행됩니다.

테스트에 1에서 500 사이의 숫자 테스트 범위가 필요한 경우 경계 값 테스트는 0, 1, 2, 499, 500 및 501의 값에 대해 수행됩니다.

# 11) 분기 테스트

White box Testing의 일종으로 Unit Testing 중에 수행됩니다. 브랜치 테스트라는 이름 자체는 모든 브랜치를 순회하여 코드가 철저하게 테스트된다는 것을 암시합니다.

# 12) 비교 테스트

제품의 강점과 약점을 이전 버전 또는 기타 유사한 제품과 비교하는 것을 비교 테스트라고합니다.

# 13) 호환성 테스트

소프트웨어가 다른 환경, 웹 서버, 하드웨어 및 네트워크 환경에서 어떻게 작동하고 실행되는지 검증하는 테스트 유형입니다.

호환성 테스트 소프트웨어가 다른 구성, 다른 데이터베이스, 다른 브라우저 및 해당 버전에서 실행될 수 있도록합니다. 호환성 테스트는 테스트 팀에서 수행합니다.

# 14) 구성 요소 테스트

단위 테스트 완료 후 대부분 개발자가 수행합니다. 구성 요소 테스트 여러 기능을 단일 코드로 테스트하는 작업이 포함되며 그 목적은 여러 기능을 서로 연결 한 후 결함이 있는지 확인하는 것입니다.

C ++에서 병합 정렬

# 15) 종단 간 테스트

시스템 테스트와 유사하게 종단 간 테스트 데이터베이스와 상호 작용하거나 네트워크 통신을 사용하거나 적절한 경우 다른 하드웨어, 응용 프로그램 또는 시스템과 상호 작용하는 것과 같이 실제 사용을 모방하는 상황에서 전체 응용 프로그램 환경을 테스트하는 작업이 포함됩니다.

# 16) 등가 분할

테스트 기법이자 블랙 박스 테스트의 한 유형입니다. 이 동안 등가 분할 , 그룹 집합이 선택되고 테스트를 위해 몇 가지 값 또는 숫자가 선택됩니다. 해당 그룹의 모든 값이 동일한 출력을 생성하는 것으로 이해됩니다.

이 테스트의 목적은 동일한 출력을 생성하지만 결함이없는 특정 그룹 내에서 중복 테스트 케이스를 제거하는 것입니다.

응용 프로그램이 -10에서 +10 사이의 값을 허용하므로 동등 분할을 사용하여 테스트를 위해 선택한 값이 0, 양수 1, 음수 1이라고 가정합니다. 따라서이 테스트의 등가 분할은 -10에서 -1, 0 및 1에서 10입니다.

# 17) 예제 테스트

실시간 테스트를 의미합니다. 예제 테스트에는 실시간 시나리오가 포함되며 테스터의 경험을 기반으로 한 시나리오도 포함됩니다.

# 18) 탐색 적 테스트

탐색 테스트는 테스트 팀이 수행하는 비공식 테스트입니다. 이 테스트의 목적은 애플리케이션을 탐색하고 애플리케이션에 존재하는 결함을 찾는 것입니다.

때때로이 테스트 중에 발견 된 주요 결함이 시스템 오류를 일으킬 수도 있습니다.

탐색 적 테스트 중에 테스트 한 흐름과 특정 흐름이 시작되기 전에 수행 한 활동을 추적하는 것이 좋습니다.

탐색 적 테스트 기법 문서 및 테스트 케이스없이 수행됩니다.

# 20) 기능 테스트

이 유형의 테스트는 내부 부품을 무시하고 요구 사항에 맞는지 여부를 확인하기 위해 출력에만 집중합니다. 애플리케이션의 기능적 요구 사항에 맞춘 블랙 박스 유형 테스트입니다. 기능 테스트에 대한 자세한 내용을 보려면 클릭하십시오 여기 .

# 21) 그래픽 사용자 인터페이스 (GUI) 테스트

이 GUI 테스트의 목적은 비즈니스 요구 사항에 따라 GUI를 검증하는 것입니다. 애플리케이션의 예상 GUI는 세부 설계 문서 및 GUI 모형 화면에 언급되어 있습니다.

GUI 테스트에는 화면에있는 버튼 및 입력 필드의 크기, 모든 텍스트, 테이블 및 테이블 내용의 정렬이 포함됩니다.

또한 다른 메뉴 및 메뉴 항목을 선택한 후 응용 프로그램의 메뉴를 확인하고 메뉴 또는 하위 메뉴에 마우스를 올려 놓은 후에도 페이지가 변동되지 않고 정렬이 동일하게 유지되는지 확인합니다.

# 22) 고릴라 테스트

Gorilla Testing은 테스터가 수행하고 때로는 개발자가 수행하는 테스트 유형입니다. Gorilla Testing에서는 하나의 모듈 또는 모듈의 기능이 철저하고 심하게 테스트됩니다. 이 테스트의 목적은 애플리케이션의 견고성을 확인하는 것입니다.

# 23) 행복한 경로 테스트

Happy Path Testing의 목적은 긍정적 인 흐름에서 애플리케이션을 성공적으로 테스트하는 것입니다. 부정적 또는 오류 조건을 찾지 않습니다. 초점은 응용 프로그램이 예상 출력을 생성하는 유효하고 긍정적 인 입력에만 있습니다.

# 24) 증분 통합 테스트

증분 통합 테스트 테스트를위한 상향식 접근 방식입니다. 즉, 새 기능이 추가 될 때 애플리케이션을 지속적으로 테스트합니다. 응용 프로그램 기능과 모듈은 별도로 테스트 할 수있을만큼 독립적이어야합니다. 이것은 프로그래머 또는 테스터가 수행합니다.

# 25) 테스트 설치 / 제거

설치 및 제거 테스트 다른 하드웨어 또는 소프트웨어 환경의 다른 운영 체제에서 전체, 부분 또는 업그레이드 설치 / 제거 프로세스에서 수행됩니다.

# 26) 통합 테스트

통합 후 결합 된 기능을 확인하기위한 모든 통합 모듈 테스트를 다음과 같이 지칭합니다. 통합 테스트 .

모듈은 일반적으로 코드 모듈, 개별 애플리케이션, 네트워크상의 클라이언트 및 서버 애플리케이션 등입니다. 이러한 유형의 테스트는 특히 클라이언트 / 서버 및 분산 시스템과 관련이 있습니다.

# 27) 부하 테스트

비 기능 테스트의 한 유형이며로드 테스트의 목적은 시스템이 성능 저하없이 처리 할 수있는로드 또는 최대 워크로드를 확인하는 것입니다.

부하 테스트는 도움이됩니다. 특정 부하 및 소프트웨어 성능 저하를 유발하는 문제에서 시스템의 최대 용량을 찾습니다. 부하 테스트는 다음과 같은 도구를 사용하여 수행됩니다. JMeter , LoadRunner, WebLoad, Silk 수행자 등

# 28) 원숭이 테스트

원숭이 테스트 원숭이가 응용 프로그램을 사용하는 경우 임의의 입력, 응용 프로그램에 대한 지식이나 이해없이 Monkey에 의해 값이 입력된다는 가정하에 테스터가 수행합니다.

Monkey Testing의 목적은 임의의 입력 값 / 데이터를 제공하여 애플리케이션 또는 시스템이 충돌하는지 확인하는 것입니다. Monkey Testing은 무작위로 수행되며 테스트 케이스가 스크립팅되지 않으며 필요하지 않습니다.

Monkey Testing은 무작위로 수행되며 테스트 케이스가 스크립팅되지 않으며 시스템의 전체 기능을 인식 할 필요가 없습니다.

# 29) 돌연변이 테스트

돌연변이 테스트 프로그램 중 하나의 소스 코드가 변경되고 기존 테스트 케이스가 시스템에서 이러한 결함을 식별 할 수 있는지 확인하는 화이트 박스 테스트 유형입니다.

프로그램 소스 코드의 변경은 매우 미미하여 전체 애플리케이션에 영향을 미치지 않으며 영향을받는 특정 영역과 관련 테스트 케이스 만 시스템에서 이러한 오류를 식별 할 수 있어야합니다.

# 30) 부정적인 테스트

'파괴하려는 태도'라는 사고 방식을 갖고 부정적인 테스트를 사용하는 테스터는 시스템 또는 애플리케이션이 중단되는지 확인합니다. 부정적인 테스트 기법 잘못된 데이터, 잘못된 데이터 또는 입력을 사용하여 수행됩니다. 시스템이 잘못된 입력 오류를 발생시키고 예상대로 작동하는지 확인합니다.

# 31) 비 기능 테스트

일반적으로 NFT (Non-Functional Test) 팀 또는 성능 팀이라고 부르는 별도의 팀이있는 모든 조직에 대한 테스트 유형입니다.

비 기능 테스트 부하 테스트, 스트레스 테스트, 보안, 볼륨, 복구 테스트 등과 같은 비 기능적 요구 사항의 테스트가 포함됩니다. NFT 테스트의 목적은 소프트웨어 또는 응용 프로그램의 응답 시간이 비즈니스 요구 사항에 따라 충분히 빠른지 확인하는 것입니다.

페이지 또는 시스템을로드하는 데 많은 시간이 걸리지 않아야하며 최대로드 동안 지속되어야합니다.

안드로이드를위한 최고의 음악 mp3 다운로드

# 32) 성능 테스트

이 용어는 종종 '스트레스'및 '부하'테스트와 같은 의미로 사용됩니다. 성능 시험 시스템이 성능 요구 사항을 충족하는지 확인하기 위해 수행됩니다. 이 테스트를 수행하기 위해 다양한 성능 및로드 도구가 사용됩니다.

# 33) 복구 테스트

애플리케이션 또는 시스템이 충돌 또는 재해로부터 얼마나 잘 복구되는지 확인하는 테스트 유형입니다.

복구 테스트는 시스템이 재해 후 작업을 계속할 수 있는지 확인합니다. 애플리케이션이 네트워크 케이블을 통해 데이터를 수신하고 갑자기 네트워크 케이블이 분리되었다고 가정합니다.

나중에 네트워크 케이블을 연결하십시오. 그러면 시스템은 네트워크 케이블이 분리되어 연결이 끊어진 곳에서 데이터 수신을 시작해야합니다.

# 34) 회귀 테스트

모든 모듈 또는 기능의 수정을 위해 애플리케이션 전체를 테스트하는 것을 회귀 테스트라고합니다. 모든 시스템을 회귀 테스트 , 그래서 일반적으로 자동화 테스트 도구 이러한 유형의 테스트에 사용됩니다.

# 35) 위험 기반 테스트 (RBT)

에 위험 기반 테스트 , 기능 또는 요구 사항은 우선 순위에 따라 테스트됩니다. 위험 기반 테스트에는 비즈니스에 가장 큰 영향을 미치고 실패 가능성이 매우 높은 매우 중요한 기능에 대한 테스트가 포함됩니다.

우선 순위 결정은 비즈니스 요구 사항을 기반으로하므로 모든 기능에 대해 우선 순위가 설정되면 우선 순위가 높은 기능 또는 테스트 사례가 먼저 실행되고 그 다음 우선 순위가 낮은 기능이 실행됩니다.

우선 순위가 낮은 기능은 사용 가능한 시간을 기준으로 테스트하거나 테스트하지 않을 수 있습니다.

위험 기반 테스트는 전체 소프트웨어를 테스트하는 데 사용할 수있는 시간이 충분하지 않은 경우 수행되며 소프트웨어는 지체없이 적시에 구현되어야합니다. 이 접근 방식은 고객과 조직의 고위 경영진의 논의와 승인으로 만 이어집니다.

# 36) 온 전성 테스트

온 전성 테스트 새로운 소프트웨어 버전이 주요 테스트 노력을 받아 들일 수있을만큼 충분히 잘 작동하는지 확인하기 위해 수행됩니다. 응용 프로그램이 초기 사용을 위해 충돌하는 경우 시스템은 추가 테스트를 위해 충분히 안정적이지 않습니다. 따라서 빌드 또는 애플리케이션이이를 수정하도록 지정됩니다.

# 37) 보안 테스트

특수 테스터 팀이 수행하는 테스트 유형입니다. 어떤 해킹 방식 으로든 시스템에 침투 할 수 있습니다.

보안 테스트 소프트웨어, 애플리케이션 또는 웹 사이트가 내부 및 외부 위협으로부터 어떻게 안전한지 확인하기 위해 수행됩니다. 이 테스트에는 악성 프로그램, 바이러스로부터 얼마나 많은 소프트웨어가 안전한지, 권한 부여 및 인증 프로세스가 얼마나 안전하고 강력한 지 포함됩니다.

또한 소프트웨어가 해커 공격 및 악성 프로그램에 대해 어떻게 작동하는지, 그리고 그러한 해커 공격 후 데이터 보안을 위해 소프트웨어가 어떻게 유지되는지 확인합니다.

# 38) 연기 테스트

개발 팀에서 새 빌드를 제공 할 때마다 소프트웨어 테스트 팀은 빌드를 검증하고 주요 문제가 없는지 확인합니다.

테스트 팀은 빌드가 안정적인지 확인하고 세부 수준의 테스트가 추가로 수행되는지 확인합니다. 연기 테스트 테스트 팀이 애플리케이션을 자세히 테스트하지 못하게하는 빌드에 쇼 스토퍼 결함이 없는지 확인합니다.

테스터가 주요 중요 기능이 초기 단계에서 분해 된 것을 발견하면 테스트 팀은 빌드를 거부하고 그에 따라 개발 팀에 알릴 수 있습니다. 연기 테스트는 모든 기능 또는 회귀 테스트의 세부 수준으로 수행됩니다.

# 39) 정적 테스트

정적 테스트는 코드없이 실행되는 테스트 유형입니다. 실행은 테스트 단계 동안 문서에서 수행됩니다.

여기에는 프로젝트 결과물의 검토, 연습 및 검사가 포함됩니다. 정적 테스트는 코드 구문 대신 코드를 실행하지 않으며 명명 규칙이 확인됩니다.

정적 테스트 테스트 케이스, 테스트 계획, 디자인 문서에도 적용됩니다. 이러한 유형의 테스트 중에 식별 된 결함은 프로젝트 관점에서 비용 효율적이므로 테스트 팀의 정적 테스트를 수행해야합니다.

# 40) 스트레스 테스트

이 테스트는 시스템이 어떻게 그리고 언제 실패하는지 확인하기 위해 사양 이상으로 스트레스를받을 때 수행됩니다. 이는 스토리지 용량을 초과하는 많은 수, 복잡한 데이터베이스 쿼리, 시스템에 대한 지속적인 입력 또는 데이터베이스로드와 같은 과부하 상태에서 수행됩니다.

# 41) 시스템 테스트

아래에 시스템 테스트 기술 , 전체 시스템은 요구 사항에 따라 테스트됩니다. 전체 요구 사항 사양을 기반으로하고 시스템의 모든 결합 된 부분을 포괄하는 블랙 박스 유형 테스트입니다.

# 42) 단위 테스트

개별 소프트웨어 구성 요소 또는 모듈의 테스트는 단위 테스트 . 내부 프로그램 디자인 및 코드에 대한 자세한 지식이 필요하므로 일반적으로 테스터가 아닌 프로그래머가 수행합니다. 또한 테스트 드라이버 모듈 또는 테스트 장치를 개발해야 할 수도 있습니다.

# 43) 사용성 테스트

아래에 사용성 테스트 , 사용자 친 화성 검사가 완료되었습니다. 응용 프로그램 흐름은 새로운 사용자가 응용 프로그램을 쉽게 이해할 수 있는지 여부를 확인하기 위해 테스트됩니다. 사용자가 어느 지점에서든 문제가 발생하면 적절한 도움말이 문서화됩니다. 기본적으로이 테스트에서는 시스템 탐색이 확인됩니다.

# 44) 취약점 테스트

소프트웨어, 하드웨어 및 네트워크의 약점을 식별하는 테스트를 취약점 테스트라고합니다. 이러한 종류의 공격, 바이러스 및 웜에 취약한 경우 악성 프로그램 인 해커가 시스템을 제어 할 수 있습니다.

따라서 이러한 시스템이 생산 전에 취약성 테스트를 거치는 지 확인해야합니다. 심각한 결함, 보안 결함을 식별 할 수 있습니다.

# 45) 볼륨 테스트

볼륨 테스트 성능 테스트 팀에서 수행하는 비 기능 테스트 유형입니다.

소프트웨어 또는 응용 프로그램은 엄청난 양의 데이터를 겪고 볼륨 테스트는 시스템이 그렇게 많은 양의 데이터를 발견했을 때 응용 프로그램의 시스템 동작과 응답 시간을 확인합니다. 이러한 대량의 데이터는 시스템의 성능과 처리 시간의 속도에 영향을 미칠 수 있습니다.

# 46) 화이트 박스 테스트

화이트 박스 테스트 응용 프로그램 코드의 내부 논리에 대한 지식을 기반으로합니다.

Glass box Testing이라고도합니다. 이러한 유형의 테스트를 수행하려면 내부 소프트웨어 및 코드 작업을 알아야합니다. 이러한 테스트는 코드 문, 분기, 경로, 조건 등의 범위를 기반으로합니다.

결론

위에서 언급 한 소프트웨어 테스트 유형은 테스트의 일부일뿐입니다. 그러나 여전히 100 개 이상의 테스트 유형 목록이 있지만 모든 유형의 프로젝트에서 모든 테스트 유형이 사용되는 것은 아닙니다. 그래서 저는 테스트 수명주기에서 주로 사용되는 몇 가지 일반적인 유형의 소프트웨어 테스트를 다루었습니다.

또한 다른 조직에서 사용되는 대체 정의 또는 프로세스가 있지만 기본 개념은 모든 곳에서 동일합니다. 이러한 테스트 유형, 프로세스 및 해당 구현 방법은 프로젝트, 요구 사항 및 범위가 변경 될 때마다 계속 변경됩니다.

추천 도서

^