습관처럼

소프트웨어공학 - White-box testing & Black-box testing 본문

CS/SE

소프트웨어공학 - White-box testing & Black-box testing

dev.wookii 2020. 2. 26. 16:50

화이트 박스 테스트란~

화이트박스 검사(White Box Test) 기법은 소프트웨어 내부 소스 코드를 테스트하는 기법이다. 소프트웨어를 테스트하는 방법은 크게 블랙박스 검사(Black-Box Test) 기법과 화이트박스 검사(White-Box Test) 기법이 있다. 블랙박스 검사 기법은 소프트웨어의 내부를 보지 않고, 입력과 출력값을 확인하여,기능의 유효성을 판단하는 테스트 기법이며,

 

화이트박스 검사 기법은 소프트웨어 내부 소스코드를 확인하는 기법이다. 화이트박스 테스트를 하는 이유는 내부 소스코드의 동작을 개발자가 추적 할 수 있기 때문에, 동작의 유효성 뿐만아니라 실행 되는 과정을 살펴봄으로써, 코드가 어떤경로로 실행되며, 불필요한 코드 혹은 테스트 되지 못한 부분을 살펴볼 수 있다. 화이트박스 테스트을 하는 부분은 대개 코드의 실행 경로를 확인해야 하기때문에 시중에 나와 있는 커버리지 분석도구를 많이 활용한다.

 

화이트박스 검사 기법은 블랙박스 검사 기법에 비해 많은 시간과 분석을 필요로 하지만 오류가 발생 되는 결함의 위치 등을 파악하는데 매우 유용하게 사용 할 수 있다. 일반적으로 화이트박스 테스트를 수행하는 도구는 커버리지 분석 도구와 많이 연관되며, Junit과 같은 무료도구가 있는 반면에 크리티컬한 마켓에 사용되는 VectorCAST와 같은 상용 도구 또한 있습니다.

화이트박스 검사(클래스 상속, White-box testing)

  • 응용 프로그램의 내부 구조와 동작을 검사하는 테스팅 방식이다.
  • 소프트웨어 내부 소스 코드를 테스트 하는 기법이다.
  • 개발자 관점의 단위 테스팅 방법이라 볼 수 있다.
  • 구현 기반의 테스팅이다.
  • 동작의 유효성 뿐만 아니라 코드를 꼼꼼하게 검사할 수 있다.

테스트 종류

  • 제어 흐름 테스트 : 프로그램의 제어구조(if, case, loop)를 테스트 함

  • 데이터 흐름 테스트: 제어 흐름 그래프에 데이터 사용 현황(정의, 소멸, 사용)을 테스트 함

  • 분기 테스트

  • 경로 테스트

장점

  • 컴파일 시점에 정적으로 정의되고 프로그래밍 언어가 직접 지원하므로 그대로 사용
  • 부모 클래스의 속성 및 함수를 재사용, 자식 클래스에서 재정의로 수정이 쉽다.

단점

  • 런타임 시점에 상속받은 부모 클래스의 구현을 변경할 수 없다.
  • 부모 클래스에 종속되므로, 부모 클래스 구현에 변경이 생기면 자식 클래스도 변경해야 한다.
  • 상속 시 부모 클래스의 내부가 보이므로 캡슐화에 위반된다는 의견도 있다.

해결책

  • 추상 클래스를 상속받는다. 구현이 아닌 인터페이스를 상속받는 것이므로 유연하다.

 

블랙 박스 테스트란~ 

블랙박스 검사(Black-box testing)는 소프트웨어 검사 방법 중 하나로 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법을 이르는 말입니다.

 

주로 올바른 입력과 올바르지 않은 입력을 일일이 다 동원하여 올바른 출력을 판별하는 방식으로 검사가 이루어지기 때문에 검사의 진행에 있어 대상이 되는 소프트웨어의 코드나 내부 구조 및 개발 노하우에 대한 정보는 기본적으로 필요로 하지 않습니다.

 

필요한 것은 특징, 요구 사항, 검사를 위해 공개된 설계도 등 대외적으로 공개된 사항들이며 '이 소프트웨어는 무슨 역할을 수행해야 되는가'와 같이 대상이 되는 소프트웨어의 특징이나 요구 사항 등에 초점을 맞춰 검사가 이루어진다. 검사 자체는 기능에 관한 것일 수도 있고 기능 외의 것에 관한 것일 수도 있습니다.

블랙박스 재사용 (객체 합성, Black-box testing)

  • 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식
  • 올바른 입력과 올바르지 않은 입력을 입력하여 올바른 출력이 나오는지 검사한다.
  • 사용자 관점의 테스트 방법이라고 볼 수 있다. 명세 기반 테스트 방법이라 볼 수 있다.
  • 필요한 것은 특징, 요구사항, 설계도 등이다.
  • 한 객체가 다른 객체에 대한 참조자를 얻는 방식으로 런타임에 동적으로 정의됨
  • 인터페이스 정의에 주의
  • 객체는 인터페이스에서만 접근하므로 캡슐화 유지, 종속성 감소

테스트 종류

  • 동등 분할 기법 : 입력 데이터를 특성에 따라 클래스로 분류, 경험에 의존
    • ex) x값이 0~100인 경우 x<0, x=50, x>100
  • 경계값 분석 기법 : 경계값에서 에러가 발생될 확률이 높다는 점을 이용.
    • ex) x값이 0~100인 경우 x=0, x=100, x=-1, x=101
  • 오류 예측 기법 : 각 시험 기법들이 놓치기 쉬운 오류들을 감각, 경험으로 테스트
  • 원인 결과 그래프 기법 : 입력 데이터간 관계가 출력에 미치는 영향을 그래프로 표현
  • 요구사항 추적 매트릭스 : 고객의 요구사항 중 빠진 사항은 없는지 추적하는 매트릭스
  • 상태 전이 테스팅 : 시스템의 상태(모드)가 변화함에 따른 테스트
  • 의사결정 테이블 테스팅 : 논리적인 조건이나 상황을 구현하는 시스템 요구사항을 도출하거나

요약을 하자면, 블랙박스 테스트의 경우 보이는 부분만 보고 문제점을 찾는 방법이고 화이트박스 테스팅의경우 보이지 않는 소스의 내부적인 로직구조의 문제점까지 찾아내는 방법이다.

 

출처 : http://justin-log.blogspot.com/2016/02/blog-post.html