[IT 용어 풀이] 화이트 박스 테스트

[IT 용어 풀이]

화이트 박스 테스트

화이트 박스 시험(투명 박스 시험, 유리 박스 시험, 투명 박스 시험 및 구조 시험으로도 알려져 있음)은 기능성과 반대로 애플리케이션의 내부 구조나 작동을 시험하는 소프트웨어의 한 방법입니다. 화이트 박스 테스트에서는 프로그래밍 기술뿐만 아니라 시스템에 대한 내부적인 관점을 사용하여 테스트 사례를 설계합니다. 테스터는 입력을 선택하여 코드를 통과하는 경로를 측정하고 예상 출력을 결정합니다. 이는 회로 내 테스트(ICT)와 같은 회로의 테스트 노드와 유사합니다. 화이트 박스 테스트는 소프트웨어 테스트 프로세스의 유닛, 통합 및 시스템 레벨에 적용할 수 있습니다. 기존의 테스터들은 화이트 박스 테스트를 단위 레벨에서 수행하는 것으로 생각하는 경향이 있었지만, 통합 및 시스템 테스트에 더 자주 사용되고 있습니다. 시스템 수준 테스트 중에 장치 내 경로, 통합 중인 장치 간 경로 및 하위 시스템 간 경로를 테스트할 수 있습니다. 이 시험 설계 방법은 많은 오류나 문제를 발견할 수 있지만 규격의 구현되지 않은 부분이나 누락된 요구 사항이 있을 수 있습니다.

단계별

-유닛 테스트 : 유닛 테스트 중에 화이트 박스 테스트를 수행하여 코드가 의도한 대로 작동하는지 확인합니다. 이전에 테스트한 코드를 통합하기 전에. 장치 테스트 중에 화이트 박스 테스트를 수행하면 초기에 결함을 발견하고 코드가 나머지 응용 프로그램과 통합된 후 나중에 발생하는 모든 결함을 보완하여 나중에 발생할 수 있는 오류를 방지합니다.
-통합 시험 : 이 레벨에서의 화이트 박스 시험은 인터페이스 상호 작용을 시험하기 위한 것이다. 유닛 레벨 테스트는 각 코드가 격리된 환경에서 적절하게 작동하는지 확인하고 통합은 프로그래머에 알려진 인터페이스의 상호 작용에 대한 화이트 박스 테스트를 사용하여 개방 환경에서 동작의 정확성을 검사하게 합니다.
-회귀 시험 : 회귀 시험 중 화이트 박스 시험은 단위 및 통합 시험 수준에서 재활용된 화이트 박스 시험 케이스를 사용하는 것입니다.

기본절차

화이트 박스 시험의 기본 절차는 시험자가 시험하는 소스 코드에 대해 심층적인 지식을 가지고 있어야 합니다. 프로그래머는 어떤 종류의 시험 사례를 작성하여 시험을 위해 모든 가시적 경로를 연습할 것인지를 알기 위해 응용 프로그램에 대한 깊은 이해가 있어야 합니다. 소스 코드가 이해되면 소스 코드를 분석하여 테스트 사례를 생성할 수 있습니다. 다음은 화이트 박스 테스트가 테스트 사례를 생성하기 위해 수행하는 세가지 기본 단계입니다.
A. 입력에는 다양한 유형의 요구 사항, 기능 규격, 문서 상세 설계, 적절한 소스 코드 및 보안 규격이 포함된다. 이것은 모든 기본 정보를 배치하기 위한 화이트 박스 테스트의 준비 단계입니다.
B. 공정은 전체 시험 과정, 적절한 시험 계획, 시험 사례 실행 및 결과 전달을 위한 위험 분석 수행을 포함합니다. 이것은 주어진 결과가 적절히 기록되도록 애플리케이션을 철저하게 테스트하기 위한 테스트 사례 구축 단계입니다.
C. 출력은 위의 모든 준비와 결과를 포함하는 최종 보고서를 준비하는 것을 포함합니다.

장점

화이트 박스 테스트는 오늘날 사용되는 가장 큰 두가지 테스트 방법 중 하나입니다. 다음과 같은 몇가지 주요 이점이 있습니다. 소스 코드에 대한 지식이 있으면 철저한 테스트에 도움이 됩니다.
무분별한 병목 현상이 나타나면서 코드의 최적화가 쉬워 집니다.
개발자가 새로운 구현을 주의 깊게 설명하기 때문에 프로그래머에게 자기 성찰을 제공합니다.
소스의 테스트 추적성을 제공하여 새로 추가되거나 수정된 테스트에서 향후 소스 변경 사항을 쉽게 캡처할 수 있습니다. 쉽게 자동화할 수 있습니다.
테스트 중지 시기에 대한 명확한 엔지니어링 기반 규칙을 제공합니다.

단점

화이트 박스 테스트에는 큰 장점이 있지만 완벽하지 않고 단점도 있습니다.
화이트 박스 테스트는 테스터가 프로그래머가 되는 것을 포함하여 프로그램에 대한 지식을 가져야 하기 때문에 테스트가 복잡해집니다. 화이트 박스 시험은 필요한 시험 수준의 복잡성 때문에 높은 수준의 지식을 가진 프로그래머를 필요로 합니다. 어떤 경우에는 애플리케이션의 모든 기존 조건을 테스트할 수 없으며 일부 조건은 테스트되지 않습니다. 테스트는 존재하는 소프트웨어에 초점을 맞추며 누락된 기능이 발견되지 않을 수 있습니다. 결과적인 시험은 시험하는 물건의 특정한 실행과 밀접하게 결합되어 있기 때문에 깨지기 쉽습니다. 시험 중인 코드를 다시 작성하여 시험 중인 가정을 무효화하는 다른 방법으로 동일한 기능을 구현할 수 있습니다. 이로 인해 불필요하게 실패하는 테스트 또는 최악의 경우 잘못된 긍정을 제공하고 코드의 오류를 마스킹 하는 테스트가 발생할 수 있습니다.