이 섹션에서는 소프트웨어 개발 수명 주기에 사용할 수 있는 다양한 유형의 소프트웨어 테스팅을 이해하겠습니다.
우리가 알고 있듯이, 소프트웨어 테스팅 고객 전제 조건에 따라 애플리케이션의 기능을 분석하는 프로세스입니다.
소프트웨어에 버그가 없거나 안정적인지 확인하려면 다양한 유형의 소프트웨어 테스트를 수행해야 합니다. 테스트는 애플리케이션에 버그가 없는 유일한 방법이기 때문입니다.
다양한 유형의 소프트웨어 테스팅
소프트웨어 테스팅의 분류는 다음과 같은 다양한 테스팅 활동의 일부입니다. 테스트 전략, 테스트 결과물, 정의된 테스트 목표 등 . 그리고 소프트웨어 테스팅은 결함을 찾기 위해 소프트웨어를 실행하는 것입니다.
테스트 유형을 갖는 목적은 다음을 확인하는 것입니다. AUT (테스트 중인 애플리케이션).
테스트를 시작하려면 요구사항, 애플리케이션 준비 완료, 필요한 리소스 사용 가능 . 책임을 유지하려면 각 모듈을 다른 테스트 엔지니어에게 할당해야 합니다.
소프트웨어 테스팅은 주로 다음과 같이 두 부분으로 나뉩니다.
수동 테스트란 무엇입니까?
자동화 도구를 사용하지 않고 고객의 요구에 따라 소프트웨어나 애플리케이션을 테스트하는 것을 테스트라고 합니다. 수동 테스트 .
즉, 절차라고 할 수 있다. 확인 및 검증 . 수동 테스트는 요구 사항 사양과 모순되는 애플리케이션이나 소프트웨어의 동작을 확인하는 데 사용됩니다.
수동 테스트 사례를 실행하기 위해 테스트 도구에 대한 정확한 지식이 필요하지 않습니다. 모든 애플리케이션에 대해 수동 테스트를 수행하면서 테스트 문서를 쉽게 준비할 수 있습니다.
수동 테스트에 대한 자세한 정보를 얻으려면 다음 링크를 클릭하십시오: https://www.javatpoint.com/manual-testing.
수동 테스트의 분류
소프트웨어 테스팅에서 수동 테스팅은 다음과 같이 더 분류될 수 있습니다. 세 가지 다른 유형의 테스트 , 이는 다음과 같습니다:
더 나은 이해를 위해 하나씩 살펴보겠습니다.
화이트 박스 테스트
화이트박스 테스트에서 개발자는 테스트 팀이나 관련 테스트 엔지니어에게 코드를 넘기기 전에 모든 코드 줄을 검사합니다.
결과적으로 코드는 테스트 전반에 걸쳐 개발자에게 눈에 띕니다. 이것이 바로 이 프로세스가 다음과 같이 알려진 이유입니다. WBT(화이트 박스 테스트) .
즉, 우리는 다음과 같이 말할 수 있습니다. 개발자 특정 소프트웨어에 대한 완전한 화이트박스 테스트를 실행하고 특정 애플리케이션을 테스트 팀에 보냅니다.
화이트박스 테스트를 구현하는 목적은 소프트웨어에 대한 입력 및 출력 흐름을 강조하고 애플리케이션의 보안을 강화하는 것입니다.
화이트박스 테스팅(White Box Testing)이라고도 한다. 오픈 박스 테스트, 유리 박스 테스트, 구조 테스트, 클리어 박스 테스트, 투명 박스 테스트 .
화이트 박스 테스트에 대한 심층적인 지식을 얻으려면 아래 링크를 참조하십시오: https://www.javatpoint.com/white-box-testing.
블랙박스 테스트
또 다른 유형의 수동 테스트는 다음과 같습니다. 블랙박스 테스트 . 이 테스트에서 테스트 엔지니어는 요구 사항에 따라 소프트웨어를 분석하고 결함이나 버그를 식별한 다음 이를 개발 팀에 다시 보냅니다.
그런 다음 개발자는 해당 결함을 수정하고 한 차례의 화이트박스 테스트를 수행한 후 테스트 팀에 보냅니다.
여기서 버그를 수정한다는 것은 결함이 해결되었으며 특정 기능이 주어진 요구 사항에 따라 작동한다는 것을 의미합니다.
블랙박스 테스트를 구현하는 주요 목적은 비즈니스 요구 사항이나 고객의 요구 사항을 지정하는 것입니다.
즉, 블랙박스 테스트는 고객 요구사항에 따라 애플리케이션의 기능을 확인하는 프로세스라고 할 수 있습니다. 이 테스트에서는 소스 코드가 표시되지 않습니다. 그래서 그것은 다음과 같이 알려져 있습니다. 블랙박스 테스트 .
블랙박스 테스트에 대한 자세한 내용은 아래 링크(https://www.javatpoint.com/black-box-testing)를 참조하세요.
블랙박스 테스트 유형
블랙박스 테스트는 아래에 설명된 대로 두 부분으로 더 분류됩니다.
기능 테스트
테스트 엔지니어는 요구 사항 사양을 기준으로 모든 구성 요소를 체계적으로 확인합니다. 기능 테스트 . 기능 테스트라고도 합니다. 구성 요소 테스트 .
기능 테스트에서는 값을 제공하고, 출력을 정의하고, 예상 값으로 실제 출력을 검증하여 모든 구성 요소를 테스트합니다.
기능 테스트는 실제 코드보다는 애플리케이션 요구 사항을 강조하는 블랙박스 테스트의 일부입니다. 테스트 엔지니어는 시스템이 아닌 프로그램만 테스트하면 됩니다.
기능 테스트에 대한 자세한 정보를 얻으려면 아래 링크를 참조하세요. https://www.javatpoint.com/function-testing .
기능 테스트 유형
다른 유형의 테스트가 여러 부분으로 나뉘는 것처럼 기능 테스트도 다양한 범주로 분류됩니다.
다양한 기능 테스트 유형 다음을 포함합니다:
이제 하나씩 이해해 봅시다.
1. 단위 테스트
단위 테스트는 모든 소프트웨어를 테스트하기 위한 기능 테스트의 첫 번째 수준입니다. 여기서 테스트 엔지니어는 애플리케이션의 모듈을 독립적으로 테스트하거나 모든 모듈 기능을 테스트합니다. 단위 테스트 .
단위 테스트를 실행하는 주요 목적은 단위 구성 요소의 성능을 확인하는 것입니다. 여기서 단위는 소프트웨어 또는 애플리케이션의 테스트 가능한 단일 기능으로 정의됩니다. 그리고 이는 지정된 애플리케이션 개발 단계 전반에 걸쳐 검증됩니다.
단위 테스트에 대한 전체 정보를 얻으려면 아래 링크를 클릭하십시오: https://www.javatpoint.com/unit-testing.
2. 통합 테스트
단위 테스트를 성공적으로 구현한 후에는 통합 테스트를 진행합니다. 이는 기능 테스트의 두 번째 수준으로, 종속 모듈 간의 데이터 흐름 또는 두 기능 간의 인터페이스를 테스트합니다. 통합 테스트 .
통합 테스트를 실행하는 목적은 각 모듈 간의 명령문의 정확성을 테스트하는 것입니다.
통합 테스트의 유형
통합 테스트는 다음과 같은 부분으로 더 나뉩니다.
증분 통합 테스트
모듈 사이에 명확한 관계가 있을 때마다 우리는 증분 통합 테스트를 진행합니다. 두 개의 모듈을 가져와서 모듈 간의 데이터 흐름이 제대로 작동하는지 분석한다고 가정해 보겠습니다.
역참조 포인터
이러한 모듈이 제대로 작동하면 모듈을 하나 더 추가하고 다시 테스트할 수 있습니다. 그리고 더 나은 결과를 얻기 위해 동일한 프로세스를 계속할 수 있습니다.
즉, 모듈을 점진적으로 추가하고 모듈 간의 데이터 흐름을 테스트하는 것을 다음과 같이 말할 수 있습니다. 증분 통합 테스트 .
증분 통합 테스트 유형
증분 통합 테스트는 다음과 같은 두 부분으로 더 분류될 수 있습니다.
이러한 유형의 통합 테스트에 대해 간략하게 소개하겠습니다.
1. 하향식 증분 통합 테스트
이 접근 방식에서는 모듈을 단계별로 또는 점진적으로 추가하고 모듈 간의 데이터 흐름을 테스트합니다. 우리가 추가하는 모듈이 올바른지 확인해야 합니다. 이전 것의 아이 .
2. 상향식 증분 통합 테스트
상향식 접근 방식에서는 모듈을 점진적으로 추가하고 모듈 간의 데이터 흐름을 확인합니다. 또한 우리가 추가하는 모듈이 다음과 같은지 확인하세요. 이전 것의 부모 .
비증분 통합 테스트/빅뱅 방법
데이터 흐름이 복잡하고 상위와 하위를 분류하기가 매우 어려울 때마다 우리는 비증분 통합 접근 방식을 사용할 것입니다. 비증분 방법이라고도 합니다. 빅뱅 방식 .
통합 테스트 및 해당 유형에 대한 전체 정보를 얻으려면 다음 링크를 참조하십시오: https://www.javatpoint.com/integration-testing.
3. 시스템 테스트
단위 및 통합 테스트가 완료될 때마다 시스템 테스트를 진행할 수 있습니다.
시스템 테스트에서 테스트 환경은 프로덕션 환경과 유사합니다. 그것은 또한로 알려져 있습니다 끝으로 종료 테스트.
이러한 유형의 테스트에서는 소프트웨어의 각 속성을 검토하고 최종 기능이 비즈니스 요구 사항에 따라 작동하는지 테스트합니다. 그리고 소프트웨어 제품을 완전한 시스템으로 분석합니다.
시스템 테스트에 대한 전체 정보를 얻으려면 아래 링크를 클릭하십시오: https://www.javatpoint.com/system-testing.
비기능 테스트
블랙박스 테스트의 다음 부분은 비기능 테스트 . 소프트웨어 제품 성능 및 사용 기술에 대한 자세한 정보를 제공합니다.
비기능 테스트는 소프트웨어의 생산 위험과 관련 비용을 최소화하는 데 도움이 됩니다.
비기능 테스트는 다음의 조합입니다. 성능, 부하, 스트레스, 유용성 및 호환성 테스트 .
비기능 테스트에 대한 자세한 내용은 다음 링크를 참조하세요: https://www.javatpoint.com/non-function-testing.
비기능 테스트 유형
비기능 테스트는 테스트의 여러 부분으로 분류되며 이에 대해 더 자세히 논의할 것입니다.
1. 성능 테스트
성능 테스트에서 테스트 엔지니어는 일부 부하를 적용하여 애플리케이션의 작동을 테스트합니다.
이러한 유형의 비기능 테스트에서 테스트 엔지니어는 다음과 같은 여러 측면에만 집중합니다. 응답 시간, 로드, 확장성 및 안정성 소프트웨어나 애플리케이션의.
성능 테스트의 분류
성능 테스트에는 다음과 같은 다양한 유형의 테스트가 포함됩니다.
성능 테스트를 실행하는 동안 특정 애플리케이션에 일부 로드를 적용하여 애플리케이션의 성능을 확인합니다. 부하 테스트 . 여기서 부하는 원하는 부하보다 작거나 같을 수 있습니다.
이는 소프트웨어의 최대 작동량과 병목 현상을 감지하는 데 도움이 됩니다.
부하 테스트와 관련된 전체 정보를 얻으려면 아래 링크를 참조하세요.
https://www.javatpoint.com/load-testing.
이는 일반적인 기능적 한계를 넘어서는 소프트웨어의 사용자 친화성과 견고성을 분석하는 데 사용됩니다.
주로 스트레스 테스트는 중요한 소프트웨어에 사용되지만 모든 유형의 소프트웨어 응용 프로그램에도 사용할 수 있습니다.
스트레스 테스트에 대한 자세한 내용은 아래 링크(https://www.javatpoint.com/stress-testing)를 참조하세요.
분석을 위해 특정 잔액의 부하를 강화하거나 감소시킴으로써 애플리케이션의 성능을 다음과 같이 알려져 있습니다. 확장성 테스트 .
확장성 테스트에서는 다음 사항도 확인할 수 있습니다. 시스템, 프로세스 또는 데이터베이스의 능력 상향적 요구를 충족시키기 위해. 그리고 이것에는 테스트 케이스 효율적으로 설계되고 구현됩니다.
확장성 테스트와 관련된 자세한 정보를 보려면 다음 링크를 클릭하세요.
https://www.javatpoint.com/scalability-testing.
안정성 테스트는 정확한 시간 동안 부하를 적용하여 애플리케이션의 성능을 평가하는 절차입니다.
주로 응용프로그램의 일관성 문제와 개발된 제품의 효율성을 확인합니다. 이러한 테스트를 통해 스트레스가 많은 상황에서도 시스템의 결함을 신속하게 찾아낼 수 있습니다.
안정성 테스트에 대한 자세한 내용을 보려면 아래 링크를 참조하세요.
https://www.javatpoint.com/stability-testing.
2. 사용성 테스트
또 다른 유형의 비기능 테스트 ~이다 유용성 테스트 . 유용성 테스트에서는 애플리케이션의 사용자 친화성을 분석하고 소프트웨어의 최종 사용자 인터페이스에서 버그를 감지합니다.
여기서 용어는 사용자 친근성 애플리케이션의 다음 측면을 정의합니다.
- 애플리케이션은 이해하기 쉬워야 합니다. 즉, 최종 사용자가 모든 기능을 볼 수 있어야 합니다.
- 애플리케이션의 모양과 느낌이 좋아야 합니다. 이는 애플리케이션이 보기에 좋고 최종 사용자가 사용하는 느낌을 주어야 함을 의미합니다.
사용성 테스트에 대한 자세한 내용은 다음 링크를 참조하세요.
https://www.javatpoint.com/usability-testing.
3. 호환성 테스트
호환성 테스트에서는 특정 하드웨어 및 소프트웨어 환경에서 애플리케이션의 기능을 확인합니다. 애플리케이션이 기능적으로 안정적이면 다음으로 이동합니다. 호환성 테스트 .
여기, 소프트웨어 이는 다양한 운영 체제와 다른 브라우저에서 애플리케이션을 테스트할 수 있음을 의미합니다. 하드웨어 이는 다양한 크기로 애플리케이션을 테스트할 수 있음을 의미합니다.
호환성 테스트에 대한 자세한 내용을 보려면 아래 링크를 참조하세요.
https://www.javatpoint.com/compatibility-testing .
삽입 파이썬
회색 상자 테스트
또 다른 부분 수동 테스트 ~이다 회색 상자 테스트 . 이것은 블랙박스와 화이트박스 테스트의 협업 .
이후 그레이박스 테스트에는 테스트 사례 설계를 위한 내부 코딩에 대한 액세스가 포함됩니다. 그레이박스 테스팅은 코딩은 물론 테스팅까지 잘 아는 사람이 수행한다.
즉, 1인 팀이 이 두 가지를 모두 수행했다면 화이트박스와 블랙박스 테스트 , 그것은 고려된다 회색 상자 테스트 .
그레이 박스 테스트에 대한 자세한 정보를 얻으려면 아래 링크를 참조하십시오.
https://www.javatpoint.com/grey-box-testing.
자동화 테스트
소프트웨어 테스트의 가장 중요한 부분은 자동화 테스트입니다. 특정 도구를 사용하여 사람의 간섭 없이 수동 설계 테스트 사례를 자동화합니다.
자동화 테스트는 소프트웨어 테스트의 효율성, 생산성 및 적용 범위를 향상시키는 가장 좋은 방법입니다.
수동으로, 신속하게, 반복적으로 실행했던 테스트 시나리오를 다시 실행하는 데 사용됩니다.
즉, 일부 도구를 사용하여 애플리케이션을 테스트할 때마다 다음과 같이 알려져 있다고 말할 수 있습니다. 자동화 테스트 .
애플리케이션이나 소프트웨어에 대해 다양한 릴리스나 여러 회귀 주기가 진행될 때 자동화 테스트를 진행합니다. 프로그래밍 언어를 이해하지 않으면 테스트 스크립트를 작성하거나 자동화 테스트를 수행할 수 없습니다.
자동화 테스트에 대한 자세한 내용은 아래 링크를 참조하세요.
https://www.javatpoint.com/automation-testing.
다른 유형의 소프트웨어 테스팅
소프트웨어 테스팅에는 위에서 논의한 테스팅의 일부가 아닌 다른 유형의 테스팅도 있지만 이러한 테스팅은 소프트웨어나 애플리케이션을 테스트하는 동안 필요합니다.
이러한 유형의 테스트를 하나씩 이해해 보겠습니다.
~ 안에 연기 테스트 , 심층적이고 엄격한 테스트를 한 번 수행하기 전에 애플리케이션의 기본적이고 중요한 기능을 테스트합니다.
또는 가능한 모든 양수 및 음수 값을 확인하기 전에 다음과 같이 알려져 있습니다. 연기 테스트 . 애플리케이션의 핵심 및 주요 기능의 워크플로우를 분석하는 것이 스모크 테스트 수행의 주요 목표입니다.
나무를 펴다
연기 테스트에 대한 자세한 내용은 다음 링크를 참조하세요.
https://www.javatpoint.com/smoke-testing.
온전성 테스트
모든 버그가 수정되었고 이러한 변경으로 인해 추가 문제가 발생하지 않았는지 확인하는 데 사용됩니다. 온전성 테스트는 스크립트가 없으므로 문서화할 수 없습니다. 새로 추가된 기능과 구성 요소의 정확성을 확인합니다.
온전성 테스트에 대한 자세한 정보를 얻으려면 아래 링크를 참조하십시오.
https://www.javatpoint.com/sanity-testing.
회귀 테스트
회귀 테스트는 가장 일반적으로 사용되는 소프트웨어 테스트 유형입니다. 여기서 용어는 회귀 이는 영향을 받지 않은 애플리케이션의 해당 부분을 다시 테스트해야 함을 의미합니다.
회귀 테스트는 자동화 도구에 가장 적합한 테스트입니다. 프로젝트 유형 및 리소스 접근성에 따라 회귀 테스트는 다음과 유사할 수 있습니다. 재테스트 중 .
개발자가 버그를 수정한 다음 버그 수정으로 인해 시뮬레이션할 수 있는 응용 프로그램의 다른 기능을 테스트하는 것을 다음과 같이 합니다. 회귀 테스트 .
즉, 일부 프로젝트에 대한 새 릴리스가 있을 때마다 회귀 테스트를 수행할 수 있으며 새로운 기능으로 인해 이전 릴리스의 이전 기능에 영향을 미칠 수 있다고 말할 수 있습니다.
회귀 테스트와 관련된 철저한 지식을 얻으려면 아래 링크를 참조하십시오.
https://www.javatpoint.com/regression-testing .
사용자 승인 테스트
UAT(사용자 승인 테스트)는 도메인 전문가/고객 또는 클라이언트로 알려진 개별 팀에 의해 수행됩니다. 그리고 최종 제품을 승인하기 전에 신청서를 아는 것을 다음과 같이 부릅니다. 사용자 승인 테스트 .
사용자 수용 테스트에서는 비즈니스 시나리오와 별도의 환경에 대한 실시간 시나리오를 분석합니다. UAT 환경 . 이번 테스트에서는 고객 승인을 위해 UAI 이전에 애플리케이션을 테스트합니다.
사용자 승인 테스트에 대한 자세한 내용을 보려면 아래 링크를 클릭하세요.
https://www.javatpoint.com/acceptance-testing.
탐색적 테스트
요구 사항이 누락될 때마다 초기 반복이 필요하며 테스트 팀은 중요한 애플리케이션이 있을 때 테스터를 경험했습니다. 새로운 테스트 엔지니어가 팀에 합류한 후 우리는 탐색적 테스트 .
탐색적 테스트를 실행하기 위해 먼저 가능한 모든 방법으로 애플리케이션을 살펴보고 테스트 문서를 작성하고 애플리케이션의 흐름을 이해한 다음 애플리케이션을 테스트합니다.
탐색적 테스트에 대한 전체 정보를 얻으려면 다음 링크를 클릭하십시오.
https://www.javatpoint.com/exploratory-testing.
임시 테스트
빌드가 확인된 순서에 들어가자마자 무작위로 애플리케이션을 테스트하는 것을 다음과 같이 합니다. 임시 테스트 .
그것은 또한 원숭이 테스트와 고릴라 테스트 . 임시 테스트에서는 고객의 요구 사항과 모순되는 애플리케이션을 확인합니다. 그렇기 때문에 ~로도 알려져 있습니다. 부정적인 테스트 .
최종 사용자가 애플리케이션을 아무렇게나 사용하다가 버그를 발견할 수도 있습니다. 그러나 전문 테스트 엔지니어는 소프트웨어를 철저히 사용하기 때문에 유사한 탐지를 식별하지 못할 수도 있습니다.
Adhoc 테스트에 대한 자세한 정보를 얻으려면 다음을 참조하십시오.
https://www.javatpoint.com/adhoc-testing.
보안 테스트
이는 소프트웨어 애플리케이션의 약점, 위험 또는 위협을 확인하는 데 사용되는 소프트웨어 테스트의 필수 부분입니다.
보안 테스트를 실행하면 외부인의 불쾌한 공격을 피하고 소프트웨어 애플리케이션의 보안을 보장하는 데 도움이 됩니다.
즉, 보안 테스트는 주로 데이터가 안전하고 소프트웨어의 작업 프로세스를 견딜 수 있는지 정의하는 데 사용된다고 말할 수 있습니다.
보안 테스트에 대한 자세한 내용을 보려면 아래 링크(https://www.javatpoint.com/security-testing)를 참조하세요.
세계화 테스트
또 다른 유형의 소프트웨어 테스팅은 세계화 테스트. 세계화 테스트는 개발된 소프트웨어가 여러 언어로 지원되는지 확인하는 데 사용됩니다. 여기서, 그 말은 세계화 다양한 언어에 대한 응용 프로그램이나 소프트웨어를 계몽하는 것을 의미합니다.
세계화 테스트는 응용 프로그램이 여러 언어와 여러 기능을 지원하는지 확인하는 데 사용됩니다.
현재 시나리오에서는 애플리케이션이 전 세계적으로 사용될 준비가 되면서 여러 기술이 향상되는 것을 볼 수 있습니다.
세계화 테스트와 관련된 완전한 정보를 얻으려면 다음 링크를 참조하십시오.
https://www.javatpoint.com/globalization-testing.
결론
튜토리얼에서는 다양한 유형의 소프트웨어 테스트에 대해 논의했습니다. 그러나 여전히 100개 이상의 테스트 범주 목록이 있습니다. 그러나 각 종류의 테스트가 모든 유형의 프로젝트에 사용되는 것은 아닙니다.
우리는 다음과 같이 가장 일반적으로 사용되는 소프트웨어 테스팅 유형에 대해 논의했습니다. 블랙박스 테스트, 화이트박스 테스트, 기능 테스트, 비기능 테스트, 회귀 테스트, 임시 테스트 등 .
또한 다양한 조직에서 사용되는 대체 분류나 프로세스가 있지만 일반적인 개념은 어디에서나 유사합니다.
이러한 테스트 유형, 프로세스 및 실행 접근 방식은 프로젝트, 요구 사항 및 범위가 변경되면 계속 변경됩니다.