백 Box 테스트 - 정의, 기술, 예 및 유형

백 Box 지원

백 Box 지원 소프트웨어의 내부 구조, 디자인, 코딩을 테스트하여 입출력 흐름을 검증하고 디자인, 사용성, 보안을 개선하는 테스트 기법입니다. 화이트 박스 테스트에서는 테스터가 코드를 볼 수 있으므로 클리어 박스 테스트, 오픈 박스 테스트, 투명 박스 테스트, 코드 기반 테스트, 글래스 박스 테스트라고도 합니다.

이는 두 부분 중 하나입니다. Box 소프트웨어 테스팅에 대한 테스팅 접근 방식. 이와 대조적으로, 블랙박스 테스팅은 외부 또는 최종 사용자 관점에서 테스팅을 포함합니다. 반면, 소프트웨어 엔지니어링의 화이트박스 테스팅은 애플리케이션의 내부 작동을 기반으로 하며 내부 테스팅을 중심으로 진행됩니다.

"백인"이라는 용어는Box”는 투명한 상자 개념 때문에 사용되었습니다. 투명 상자 또는 흰색Box 이름은 소프트웨어의 외부 껍질(또는 "상자")을 통해 내부 작동을 볼 수 있는 능력을 상징합니다. 마찬가지로 "검정 Box 지원"는 소프트웨어의 내부 작동을 볼 수 없어 최종 사용자 경험만 테스트할 수 있음을 상징합니다.

백 Box 비디오 테스트

LINK 비디오에 접근할 수 없는 경우

화이트에서 무엇을 확인하나요? Box 테스트?

화이트 박스 테스트는 다음 사항에 대한 소프트웨어 코드 테스트를 포함합니다.

  • 내부 보안 허점
  • 코딩 프로세스의 경로가 끊어지거나 구조가 잘못됨
  • 코드를 통한 특정 입력의 흐름
  • 예상 출력
  • 조건부 루프의 기능
  • 각 문, 개체 및 기능을 개별적으로 테스트합니다.

테스트는 소프트웨어 개발의 시스템, 통합 및 단위 수준에서 수행할 수 있습니다. 화이트박스 테스트의 기본 목표 중 하나는 애플리케이션의 작업 흐름을 검증하는 것입니다. 여기에는 미리 정의된 일련의 입력을 예상 또는 원하는 출력과 비교하여 테스트하는 것이 포함되므로 특정 입력이 예상 출력으로 이어지지 않으면 버그가 발생한 것입니다.

화이트를 어떻게 수행합니까? Box 테스트?

화이트 박스 테스트에 대한 간단한 설명을 제공하기 위해 두 가지 기본 단계로 나누었습니다. 테스터가 화이트 박스 테스트 기술을 사용하여 애플리케이션을 테스트할 때 하는 일은 다음과 같습니다.

1단계) 소스 코드 이해

테스터가 가장 먼저 하는 일은 애플리케이션의 소스 코드를 배우고 이해하는 것입니다. 화이트 박스 테스트는 애플리케이션의 내부 작동을 테스트하는 것이므로 테스터는 테스트하는 애플리케이션에서 사용하는 프로그래밍 언어에 대해 매우 잘 알고 있어야 합니다. 또한 테스트하는 사람은 보안 코딩 관행을 잘 알고 있어야 합니다. 보안은 종종 소프트웨어 테스트의 주요 목표 중 하나입니다. 테스터는 보안 문제를 찾아내고 의도적으로든 무의식적으로든 애플리케이션에 악성 코드를 삽입할 수 있는 해커와 순진한 사용자의 공격을 방지할 수 있어야 합니다.

2단계) 테스트 케이스 생성 및 실행

화이트 박스 테스트의 두 번째 기본 단계는 적절한 흐름과 구조를 위해 애플리케이션의 소스 코드를 테스트하는 것입니다. 한 가지 방법은 애플리케이션의 소스 코드를 테스트하기 위해 더 많은 코드를 작성하는 것입니다. 테스터는 애플리케이션의 각 프로세스 또는 일련의 프로세스에 대한 작은 테스트를 개발합니다. 이 방법은 테스터가 코드에 대한 심층적인 지식을 가져야 하며 종종 개발자가 수행합니다. 다른 방법은 다음과 같습니다. 수동 테스트, 시행착오 테스트 및 테스트 도구 사용에 대해서는 이 문서에서 자세히 설명하겠습니다.

백Box 지원

백Box 테스트 예

다음 코드를 고려해보세요.

Printme (int a, int b) {                       ------------  Printme is a function 
    int result = a+ b; 
    If (result> 0)
    	Print ("Positive", result)
    Else
    	Print ("Negative", result)
    }                                        -----------   End of the source code

백의 목표Box 소프트웨어 엔지니어링에서 테스트는 코드의 모든 결정 분기, 루프 및 명령문을 확인하는 것입니다.

위의 화이트 박스 테스트 예제의 진술을 실행하려면 WhiteBox 테스트 케이스는

  • A = 1, B = 1
  • A = -1, B = -3

백 Box 테스트 기법

주요 화이트 박스 테스트 기술은 코드 커버리지 분석입니다. 코드 커버리지 분석은 코드 커버리지의 갭을 제거합니다. 테스트 케이스 모음곡. 이는 일련의 테스트 케이스에 의해 실행되지 않는 프로그램 영역을 식별합니다. 격차가 식별되면 테스트 사례를 만들어 코드의 테스트되지 않은 부분을 확인함으로써 소프트웨어 제품의 품질을 향상시킵니다.

수행할 수 있는 자동화된 도구가 있습니다. 코드 커버리지 분석. 아래는 박스 테스터가 사용할 수 있는 몇 가지 커버리지 분석 기술입니다.

명세서 범위:- 이 기술을 사용하려면 코드의 가능한 모든 명령문을 테스트 프로세스 중에 최소한 한 번 테스트해야 합니다. 소프트웨어 공학.

지점 적용 – 이 기술은 소프트웨어 애플리케이션의 가능한 모든 경로(if-else 및 기타 조건부 루프)를 확인합니다.

위에서 언급한 것 외에도 조건 커버리지, 다중 조건 커버리지, 경로 커버리지, 함수 커버리지 등과 같은 다양한 커버리지 유형이 있습니다. 각 기술에는 소프트웨어 코드의 모든 부분을 테스트(커버)하려는 자체 장점과 시도가 있습니다. 명령문 및 분기 적용 범위를 사용하면 일반적으로 충분한 80-90% 코드 적용 범위를 얻을 수 있습니다.

다음은 중요한 흰색입니다Box 테스트 기술:

  • 명세서 범위
  • 의사결정 범위
  • 지점 적용 범위
  • 조건 적용 범위
  • 다중 조건 적용 범위
  • 유한 상태 머신 적용 범위
  • 경로 적용 범위
  • 제어 흐름 테스트
  • 데이터 흐름 테스트

흰색의 종류 Box 지원

화이트 박스 테스트 애플리케이션, 코드 블록 또는 특정 소프트웨어 패키지의 유용성을 평가하는 데 사용되는 여러 테스트 유형을 포함합니다. 아래에 나열되어 있습니다 —

  • 단위 테스트: 이는 애플리케이션에서 수행되는 첫 번째 테스트 유형인 경우가 많습니다. 단위 테스트 개발되는 각 코드 단위 또는 블록에 대해 수행됩니다. 단위 테스트는 기본적으로 프로그래머가 수행합니다. 소프트웨어 개발자는 몇 줄의 코드, 단일 기능 또는 개체를 개발하고 테스트를 통해 작동하는지 확인한 후 계속해서 단위 테스트를 수행하면 소프트웨어 개발 수명 주기 초기에 대부분의 버그를 식별하는 데 도움이 됩니다. 이 단계에서 식별된 버그는 더 저렴하고 수정하기 쉽습니다.
  • 메모리 누수 테스트: 메모리 누수는 애플리케이션 실행 속도를 저하시키는 주요 원인입니다. 느리게 실행되는 소프트웨어 애플리케이션이 있는 경우 메모리 누수 감지 경험이 있는 QA 전문가가 필수적입니다.

위의 것 외에도 몇 가지 테스트 유형은 블랙박스와 화이트박스 테스트의 일부입니다. 아래에 나열되어 있습니다.

  • 백 Box 침투 테스트: 이 테스트에서 테스터/개발자는 응용 프로그램의 소스 코드에 대한 전체 정보, 자세한 네트워크 정보, 관련 IP 주소 및 응용 프로그램이 실행되는 모든 서버 정보를 가지고 있습니다. 목표는 보안 위협을 노출시키기 위해 여러 각도에서 코드를 공격하는 것입니다.
  • 백 Box 돌연변이 테스트: 돌연변이 테스트 소프트웨어 솔루션을 확장하는 데 사용할 최고의 코딩 기술을 찾는 데 자주 사용됩니다.

백 Box 테스트 도구

아래는 최고의 화이트박스 테스팅 도구 목록입니다.

화이트의 장점 Box 지원

  • 숨겨진 오류를 찾아 코드를 최적화합니다.
  • 화이트박스 테스트 사례는 쉽게 자동화할 수 있습니다.
  • 일반적으로 모든 코드 경로가 포함되므로 테스트가 더욱 철저해집니다.
  • 테스트는 조기에 시작될 수 있습니다. SDLC GUI를 사용할 수 없는 경우에도 마찬가지입니다.

흰색의 단점Box 지원

  • 화이트 박스 테스트는 매우 복잡하고 비용이 많이 들 수 있습니다.
  • 일반적으로 화이트 박스 테스트 사례를 실행하는 개발자들은 그것을 싫어합니다. 개발자의 화이트 박스 테스트는 세부적이지 않으며 프로덕션 오류로 이어질 수 있습니다.
  • 화이트 박스 테스트에는 프로그래밍과 구현에 대한 세부적인 이해를 갖춘 전문적인 리소스가 필요합니다.
  • 화이트박스 테스트는 시간이 많이 걸리고, 규모가 큰 프로그래밍 애플리케이션의 경우 전체 테스트를 수행하는 데 시간이 걸립니다.

결론

  • 화이트 박스 테스트는 매우 복잡할 수 있습니다. 관련된 복잡성은 테스트되는 애플리케이션과 많은 관련이 있습니다. 단일 간단한 작업을 수행하는 작은 애플리케이션은 몇 분 안에 화이트 박스 테스트를 거칠 수 있지만, 더 큰 프로그래밍 애플리케이션은 완전히 테스트하는 데 며칠, 몇 주, 심지어 더 오랜 시간이 걸립니다.
  • 소프트웨어 테스팅에서 화이트 박스 테스팅은 소프트웨어 애플리케이션을 작성한 후 개발 중에 수행해야 하며, 각 수정 후에도 다시 수행해야 합니다.