화이트 박스 테스트

White-box testing
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

화이트 박스 테스트(클리어 박스 테스트, 유리 박스 테스트, 투과 박스 테스트, 구조 테스트라고도 함)는 응용 프로그램의 기능(블랙 박스 테스트 등)이 아닌 내부 구조 또는 동작을 테스트하는 소프트웨어 테스트 방법입니다.화이트 박스 테스트에서는 테스트 케이스를 설계하기 위해 시스템의 내부 관점을 사용합니다.검사자는 코드를 통과하는 연습 경로를 위한 입력을 선택하고 예상 출력을 결정한다.이는 회로 내 노드 테스트(ICT)와 유사합니다.화이트 박스 테스트는 소프트웨어 테스트 프로세스의 유닛, 통합 및 시스템 수준에서 적용할 수 있습니다.기존 테스터들은 화이트박스 테스트가 유닛 수준에서 이루어지는 것으로 생각하는 경향이 있었지만 오늘날에는 통합 및 시스템 테스트에 더 자주 사용됩니다.장치 내 경로, 통합 중 장치 간 경로 및 시스템 수준 테스트 중 하위 시스템 간 경로를 테스트할 수 있습니다.이 테스트 설계 방법은 많은 오류나 문제를 발견할 수 있지만, 구현되지 않은 규격 부분이나 누락된 요구 사항을 놓칠 수 있습니다.화이트박스 테스트가 설계 [1]중심인 경우(DO-178C 및 ISO 26262 프로세스와 같이) 소프트웨어의 각 컴포넌트가 어떻게 동작해야 하는지에 대한 합의된 사양에 의해서만 실행되는 경우 화이트박스 테스트 기술은 구현되지 않았거나 누락된 요건에 대한 평가를 수행할 수 있습니다.

화이트 박스 테스트 설계 기술에는 다음과 같은 코드 적용 범위가 포함됩니다.

  • 흐름 테스트 제어
  • 데이터 흐름 테스트
  • 브런치 테스트
  • 스테이트먼트 커버리지
  • 의사결정 범위
  • 변경 조건/판단 범위 변경
  • 프라이머리 패스 테스트
  • 패스 테스트

개요

화이트 박스 테스트는 소스 코드 수준에서 애플리케이션을 테스트하는 방법입니다.이러한 테스트 케이스는 위의 설계 기술(컨트롤 플로우테스트, 데이터 플로우테스트, 브랜치테스트, 패스테스트, 스테이트먼트커버리지 및 의사결정커버리지) 및 변경된 조건/결정커버리지)를 사용하여 도출됩니다.화이트박스 테스트는 모든 코드를 검사하여 오류가 없는 환경을 구축하기 위한 지침으로 이러한 기술을 사용하는 것입니다.이러한 화이트 박스 테스트 기술은 화이트 박스 테스트의 구성 요소이며,[2] 그 본질은 숨겨진 오류를 나중에 줄이기 위해 애플리케이션을 소스 코드 수준에서 신중하게 테스트하는 것입니다.이러한 다양한 기술은 소스 코드의 가시적인 모든 경로를 연습하여 오류를 최소화하고 오류가 없는 환경을 만듭니다.화이트 박스 테스트의 요점은, 코드의 어느 행이 실행되고 있는지를 파악하고, 올바른 출력을 [2]특정할 수 있는 능력입니다.

레벨

  1. 유닛 테스트화이트 박스 테스트는 이전에 테스트한 코드와 통합하기 전에 코드가 의도한 대로 작동하는지 확인하기 위해 유닛 테스트 중에 수행됩니다.유닛 테스트 중의 화이트 박스 테스트는 많은 장애를 조기에 검출할 수 있으며, 코드가 어플리케이션의 나머지 부분과 통합된 후에 발생하는 장애에 대처하는 데 도움이 됩니다.따라서 개발 [2]후의 에러 영향을 줄입니다.
  2. 통합 테스트이 레벨에서의 화이트 박스 테스트는, 인터페이스간의 상호 작용을 테스트하기 위해서 작성됩니다.유닛 레벨 테스트에서는, 각 코드가 격리된 환경에서 테스트되어 적절히 동작하고 있는 것을 확인했습니다.통합은 프로그래머가 [2]알고 있는 인터페이스의 상호작용에 대해 화이트 박스 테스트를 사용하여 오픈 환경에서 동작의 정확성을 검사합니다.
  3. 회귀 테스트.회귀 테스트 중 화이트 박스 테스트는 유닛 및 통합 테스트 [2]수준에서 재활용 화이트 박스 테스트 케이스를 사용하는 것입니다.

기본 절차

화이트박스 테스트의 기본 절차에서는 테스트 대상 소스코드에 대한 자세한 지식이 필요합니다.프로그래머는 애플리케이션에 대해 깊이 이해하고 있어야 하며, 어떤 종류의 테스트 케이스를 작성해야 하는지 알아야 하며, 이를 통해 모든 가시 경로를 테스트에 사용할 수 있습니다.소스 코드를 이해하면 소스 코드를 분석하여 생성할 테스트 케이스를 만들 수 있습니다.화이트 박스 테스트가 테스트 케이스를 작성하기 위해 수행하는 3가지 기본적인 절차는 다음과 같습니다.

  1. 입력에는 다양한 유형의 요건, 기능 사양, 문서 상세 설계, 적절한 소스 코드 및 보안 [citation needed]사양이 포함됩니다.이것은 모든 기본 정보를 배치하기 위한 화이트 박스 테스트의 준비 단계입니다.
  2. 처리에는 리스크 분석을 실시하여 테스트 프로세스 전체의 가이드, 적절한 테스트 계획, 테스트 케이스의 실행 및 [citation needed]결과 전달이 포함됩니다.이 단계는 테스트 케이스를 구축하여 주어진 결과가 그에 따라 기록되도록 하는 단계입니다.
  3. 출력에는 상기의 모든 준비와 [citation needed]결과를 망라한 최종 보고서의 준비가 포함됩니다.

이점

  1. 소스코드를 아는 것의 부작용은 철저한 [citation needed]테스트에 도움이 됩니다.
  2. 눈에 띄지 않는 보틀 넥이 [citation needed]노출되어 코드의 최적화가 쉬워집니다.
  3. 개발자가 새로운 [citation needed]구현을 신중하게 설명하므로 프로그래머에게 자기성찰을 제공합니다.
  4. 소스로부터의 테스트의 트레이서빌리티를 제공하므로 새로 추가 또는 [3]변경된 테스트에서 소스로의 향후 변경을 쉽게 캡처할 수 있습니다.
  5. 자동화하기 [4]쉽다.
  6. 테스트를 [5][4]중단하는 시점에 대한 명확한 엔지니어링 기반 규칙을 제공합니다.

단점들

  1. 화이트 박스 테스트는 특정 구현의 세부 사항을 테스트하기 위해 작성됩니다.즉, 테스트가 구현과 밀접하게 연계되어 있기 때문에 구현이 변경되면 테스트가 실패합니다.따라서 테스트를 업데이트하기 위해 추가 작업을 수행해야 하며, 구현이 변경되었을 때 다시 구현과 일치해야 합니다.한편 블랙박스 테스트의 경우 구현과는 독립적이기 때문에 구현이 변경되지만 구현의 결과나 부작용이 변경되지 않는 경우에도 테스트는 정상적으로 실행됩니다.
  2. 테스트 대상 코드는 테스트에 포함된 가정을 무효화하는 다른 방법으로 동일한 기능을 구현하도록 다시 작성될 수 있습니다.이로 인해 테스트에 불필요하게 실패하거나 최악의 경우 false positive가 발생하여 코드에 오류가 마스크될 수 있습니다.화이트 박스 테스트는 테스트 대상 코드의 의도된 동작을 테스트하도록 작성된 것이 아니라 특정 구현이 수행하는 동작을 테스트하도록 작성되었기 때문입니다.
  3. 화이트박스 테스트는 테스터가 프로그램에 대한 지식을 갖추거나 테스트 팀이 코드 수준에서 프로그램을 이해할 수 있는 우수한 프로그래머를 적어도 한 명 이상 보유해야 하므로 테스트가 복잡해집니다.화이트박스 테스트에서는 [citation needed]테스트 레벨이 복잡하기 때문에 고도의 지식을 가진 프로그래머가 필요합니다.
  4. 경우에 따라서는 애플리케이션의 모든 기존 조건을 테스트할 수 없고 [citation needed]테스트되지 않는 조건도 있습니다.
  5. 이 테스트는 존재하는 소프트웨어에 초점을 맞추고 기능이 상실된 [citation needed]경우 발견되지 않을 수 있습니다.

모던 뷰

좀 더 현대적인 시각은 화이트 박스 테스트와 블랙 박스 테스트 사이의 이분법이 모호해지고 관련성이 줄어들고 있다는 것입니다.원래 "화이트 박스"는 소스 코드를 사용하고 블랙 박스는 요구 사항을 사용하는 것을 의미했지만, 이제 테스트는 다양한 추상화 수준의 많은 문서에서 파생되었습니다.요점은 테스트는 보통 입력 공간, 그래프 또는 논리 술어와 같은 추상적 구조에서 설계된다는 것입니다. 문제는 우리가 추상적 구조를 [4]어느 수준에서 도출하느냐입니다.소스 코드, 요건, 입력 공간 설명 또는 수십 가지 유형의 설계 모델 중 하나가 될 수 있습니다.따라서 "화이트 박스/블랙 박스" 구분이 덜 중요하며 용어의 연관성도 [citation needed]덜하다.

해킹

침입 테스트에서 화이트 박스 테스트는 화이트 햇 해커가 공격받는 시스템에 대해 완전히 알고 있는 방법을 말합니다.화이트 박스 침입 테스트의 목적은 타깃 시스템의 기본 자격 정보를 알고 있는 악의적인 내부자를 시뮬레이션하는 것입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Stacy Nelson (June 2003), NASA/CR–2003-212806 Certification Processes for Safety-Critical and Mission-Critical Aerospace Software (PDF), Ames Research Center, p. 25, [Glossary] White Box Testing: Design-driven testing where engineers examine internal workings of code
  2. ^ a b c d e Williams, Laurie. "White-Box Testing" (PDF): 60–61, 69. Retrieved 13 February 2013. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)[검증 필요]
  3. ^ Binder, Bob (2000). Testing Object-oriented Systems. Addison-Wesley Publishing Company Inc. ISBN 9780201809381.
  4. ^ a b c Ammann, Paul; Offutt, Jeff (2008). Introduction to Software Testing. Cambridge University Press. ISBN 978-0-521-88038-1.
  5. ^ Myers, Glenford (1979). The Art of Software Testing. John Wiley and Sons. ISBN 9780471043287.

외부 링크

  • BCS SIGIST(British Computer Society Specialist Interest Group in Software Testing):http://www.testingstandards.co.uk/Component%20Testing.pdf 소프트웨어 컴포넌트 테스트의 표준], 작업 드래프트 3.4, 27.2001년 4월
  • http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf 에서는 제어 흐름테스트 및 데이터 흐름테스트에 대한 자세한 내용을 보실 수 있습니다.
  • http://research.microsoft.com/en-us/projects/pex/ Pex –화이트박스 자동 테스트그물