그레이 란? Box 테스트 중이신가요? 기술, 예

그레이 란? Box 테스트?

회색 Box 지원 (Gray라고도 표기됨) Box 그레이 테스팅(Grey Testing)은 소프트웨어 제품이나 애플리케이션을 내부 구조에 대한 부분적인 정보만을 가지고 테스트하는 소프트웨어 테스트 기법입니다. Box 테스팅이란 부적절한 코드 구조나 애플리케이션의 잘못된 사용으로 인해 발생하는 결함을 찾아내고 식별하는 것입니다.

이 과정에서 웹 시스템과 관련된 상황별 오류가 흔히 발견됩니다. 이 기법은 다음과 같은 이점을 제공합니다. 테스트 범위 복잡한 시스템의 특정 계층에만 집중하는 것이 아니라 모든 계층에 집중함으로써 가능합니다.

회색 Box 테스팅은 소프트웨어 테스트 방법으로, 다음과 같은 요소들을 결합합니다. 백 Box 지원 검정 Box 지원이 세 가지의 차이점은 테스트 담당자가 내부 구조를 얼마나 자세히 볼 수 있는지에 달려 있습니다.

• 화이트로 Box 내부 구조(코드) 테스트는 알려져 있습니다.
• 블랙 Box 내부 구조(코드) 테스트는 알려지지 않았습니다.
• 그레이로 Box 내부 구조(코드) 테스트는 부분적으로만 알려져 있습니다.

아래 그림은 세 가지 방법을 동일한 가시성 척도에 따라 나타낸 것입니다.

In 소프트웨어 공학, 그레이 Box 테스팅은 애플리케이션의 양면, 즉 프레젠테이션 레이어와 그 이면에 있는 코드 모두를 테스트할 수 있게 해줍니다. 주로 다음과 같은 경우에 유용합니다. 통합 테스트 침투 테스트.

회색의 예 Box 테스트 : 웹사이트 기능(예: 링크 또는 연결되지 않은 링크)을 테스트하는 동안 테스터가 해당 링크에서 문제를 발견하면 HTML 코드에서 즉시 변경하고 실시간으로 확인할 수 있습니다.

왜 회색인가 Box 지원

회색 Box 검사는 다음과 같은 이유로 실시됩니다.

• 이는 블랙박스 테스트와 화이트박스 테스트의 장점을 모두 제공합니다.
• 이는 개발자와 테스터의 의견을 종합하여 제품의 전반적인 품질을 향상시킵니다.
• 이는 기능적 및 비기능적 유형을 테스트하는 데 필요한 긴 프로세스의 오버헤드를 줄여줍니다.
• 이는 개발자에게 결함을 수정할 수 있는 충분한 자유 시간을 제공합니다.
• 테스트는 설계자의 관점이 아닌 사용자의 관점에서 진행됩니다.
• 테스터는 오류가 발생한 계층을 확인할 수 있으므로 단순히 오류를 보고하는 데 그치지 않고 오류를 설명할 수 있습니다.

회색 Box 테스트 vs 블랙 Box vs 화이트 Box 지원

이 세 가지 방법은 서로 경쟁하는 대안이라기보다는 접근 방식의 세 가지 수준이며, 각각 다른 유형의 질문에 답합니다. 이들을 나란히 놓고 보면 선택이 구체화됩니다.

대부분의 팀은 이 세 가지 방법을 모두 사용합니다. 소프트웨어 테스팅 수명주기그리고 회색 상자 계층은 사용자 인터페이스와 데이터 저장소 사이에 발생하는 결함이 일반적으로 포착되는 곳입니다.

회색 Box 테스트 전략

그레이를 공연하려면 Box 테스트를 수행할 때 테스터가 소스 코드에 접근할 필요는 없습니다. 테스트는 알고리즘, 아키텍처, 내부 상태 또는 프로그램 동작에 대한 기타 상위 수준 설명에 대한 지식을 기반으로 설계됩니다.

그레이를 공연하려면 Box 테스트 :

• 이 방법은 블랙박스 테스트의 간단한 기법을 적용합니다.
• 요구사항 기반 테스트 케이스 생성 방식을 사용하기 때문에, 어설션 메서드를 통해 프로그램을 테스트하기 전에 모든 조건을 미리 설정합니다.

회색 염색에 사용되는 기법 Box 테스트는 다음과 같습니다.

• 매트릭스 테스트: 이 기법은 프로그램에 존재하는 모든 변수와 각 변수가 지닌 위험도를 정의하여 사용되지 않는 변수와 위험도가 높은 변수를 파악할 수 있도록 하는 것입니다.
• Regression Testing: 이전 버전의 변경 사항이 새 버전의 프로그램에서 다른 측면에 악영향을 미쳤는지 확인합니다. 이는 전체 재테스트, 위험 사용 사례 재테스트, 방화벽 내 재테스트와 같은 전략을 통해 수행됩니다.
• 직교 배열 테스트 또는 OAT: 최소한의 테스트 케이스로 최대한의 코드 커버리지를 제공합니다.
• 패턴 테스트: 이전 시스템 결함에 대한 과거 데이터를 기반으로 수행됩니다. 블랙박스 테스트와 달리 그레이 테스트는 Box 테스팅은 코드 내부를 자세히 살펴보고 오류가 발생한 원인을 파악하는 과정입니다.

회색 Box 이 방법론은 일반적으로 자동화된 방식을 사용합니다. 소프트웨어 테스트 도구 테스트를 수행하기 위해 스텁과 모듈 드라이버가 생성되므로 테스터는 코드를 수동으로 생성할 필요가 없습니다.

그레이를 실행하는 단계 Box 테스트는 다음과 같습니다.

• 1단계: 입력값을 식별합니다.
• 2단계: 출력값을 확인합니다.
• 3단계: 주요 경로를 파악합니다.
• 4단계: 하위 기능을 식별합니다.
• 5단계: 하위 함수에 대한 입력값을 개발합니다.
• 6단계: 하위 함수에 대한 출력 결과를 개발합니다.
• 7단계: 하위 함수에 대한 테스트 케이스를 실행합니다.
• 8단계: 하위 함수의 결과가 올바른지 확인합니다.
• 9단계: 나머지 하위 기능에 대해서도 4~8단계를 반복합니다.
• 10단계: 나머지 하위 기능에 대해서도 7단계와 8단계를 반복합니다.

Grey의 테스트 케이스 Box 테스트는 GUI, 보안, 데이터베이스, 브라우저 및 운영 체제 관련 문제를 포함하여 다양한 영역을 포괄할 수 있습니다. 생성된 각 테스트 케이스는 여전히 일반적인 절차를 따라야 합니다. 테스트 사례 속성이 중요한 이유는, 자체 설명만으로는 재현할 수 없는 사례는 회귀 분석에 거의 도움이 되지 않기 때문입니다.

회색이 있는 곳 Box 테스트가 사용됩니다

이 기법은 두 개의 레이어를 동시에 살펴봐야만 결함을 진단할 수 있는 모든 상황에서 유용하게 사용됩니다. 다음은 이 기법이 가장 자주 적용되는 시나리오입니다.

• 데이터베이스 기반 워크플로우: 사용자 인터페이스를 통해 작업이 수행되고, 그 결과로 생성된 행을 직접 조회하여 값, 유형 및 관계가 의도한 대로 저장되었는지 확인합니다.
• 웹 서비스 및 API: 요청이 전송되고 응답 상태, 헤더 및 페이로드가 게시된 조건과 비교하여 검사됩니다.tract는 일상적인 형태입니다. API 테스트.
• 통합 지점: 두 모듈 사이의 경계를 넘는 메시지는 두 모듈 모두 소스 파일이 아닌 실행 중인 시스템으로 취급되는 동안 검사됩니다.
• 보안 평가: 침투 테스터에게 일반 사용자 계정과 아키텍처 개요가 제공되면 내부자의 입장을 재현하게 되는데, 이것이 바로 표준적인 그레이 박스 참여 모델입니다.
• 웹 애플리케이션 및 GUI: 깨진 링크, 고립된 페이지, 세션 처리 및 클라이언트 측 유효성 검사는 모두 마크업과 요청 흐름에 대한 부분적인 가시성 하에서 검사됩니다.

이 모든 과정을 통해 시스템 결함으로 인한 전체 비용이 절감됩니다. 문제가 파이프라인의 다음 단계로 넘어가기 전에 발견하고 설명할 수 있기 때문입니다. 시스템 테스트 또는 생산.

회색 Box 테스트 도구

어떤 도구도 그레이 기능을 수행하지 않습니다. Box 테스트 자체만으로는 충분하지 않습니다. 이 범주에 필요한 것은 인터페이스 드라이버, 하위 레이어 검사 도구, 그리고 이 둘을 함께 스크립트로 묶는 방법의 조합입니다.

• API 및 웹 서비스 클라이언트 등 Postman SoapUI요청을 발행하고 상태 코드 및 응답 본문을 검증하는 데 사용됩니다.
• 데이터베이스 클라이언트 및 SQL 쿼리 도구인터페이스 작업 후 유지된 상태를 확인하는 데 사용됩니다.
• 브라우저 개발자 도구 및 HTTP 프록시 등 Burp Suite보안 관련 세션 중에 요청을 검사하고 수정하는 데 사용됩니다.
• UI 자동화 프레임워크 등 Selenium는 내부의 프레젠테이션 레이어를 구동하는 데 사용됩니다. 자동화 테스트 모음곡.
• 로그 및 모니터링 도구관찰된 오류와 해당 시점에 애플리케이션이 내부적으로 기록한 내용을 연관시키는 데 사용됩니다.

선택 자체보다 연결 방식이 더 중요합니다. 인터페이스 드라이버와 검사 단계가 동일한 스크립트 흐름에서 실행되지 않으면 하나의 그레이 박스 테스트가 아닌 두 번의 별도 수동 검사가 수행되기 때문입니다.

회색 Box 테스트 과제

부분적인 가시성은 순수 가시성 방식에는 없는 문제점을 야기하며, 팀들이 가장 자주 접하는 문제점은 다음과 같습니다.

• 테스트 대상 구성 요소에 오류가 발생하면 진행 중인 작업을 중단하고 나머지 시퀀스를 실행하지 않은 상태로 남겨둘 수 있습니다.
• 테스트는 결과 내용이 잘못되었더라도 완전히 실행될 수 있으므로, 검증 단계에서는 완료 여부가 아닌 값 자체를 확인해야 합니다.
• 테스터는 화이트 박스 테스트에서 도달할 수 있는 모든 분기를 볼 수 없기 때문에 전체 코드 경로 커버리지를 달성하는 것은 불가능합니다.
• 테스트가 의존하는 설계 문서가 오래되었을 수 있으며, 구식 스키마 또는 인터페이스 사양은 조용히 테스트 설계를 무효화할 수 있습니다.
• 테스터는 해당 분야에 대한 이해와 기술적 깊이를 모두 갖춰야 하는데, 이는 채용 과정에서 요구되는 역량 프로필이 더 좁다는 것을 의미합니다.
• 분포가 고르고 복근이 많음tracTED 아키텍처는 관찰된 오류를 특정 내부 구성 요소에 귀속시키기 어렵게 만듭니다.

이러한 한계점들은 그레이를 치료해야 한다는 주장을 뒷받침합니다. Box 테스트는 여러 단계 중 하나일 뿐, 다른 단계를 대체하는 것이 아니라는 점이 더 광범위한 맥락에서 강조되는 요점입니다. 소프트웨어 테스트 기법 소프트웨어 테스트 유형그것은 자연스럽게 옆에 자리 잡고 있습니다. 기능 테스트 그리고 명세 중심적 접근 방식과 같은 것들 모델 기반 테스트.

자주 묻는 질문