답변:
가장 정확한 것은 무엇이든.
화이트 박스 테스트 (즉, 코드 내부 테스트)는 코드를 작성한 개발자가 단위 테스트를 수행하는 것이 이상적입니다. 단위 테스트는 시간이 지남에 따라 빌드되고 빌드 프로세스의 일부이므로 빌드되지 않은 테스터의 시간을 제대로 작동하지 않는 코드로 낭비하지 않습니다. 팀이 작을수록 단위 테스트가 더욱 중요해집니다. 특히 테스터 군대가 없어서 문제를 해결할 수 없기 때문입니다.
블랙 박스 테스트 (즉, 사용자 / 시스템 인터페이스를 통한 테스트)는 일반적으로 대부분의 테스터가하는 일입니다.
완제품에 기능이 얼마나 중요한지 모든 테스트를 우선시해야합니다. X를 수행 할 도구를 제공하고 제품이 X를 수행하지 않는 것이 큰 문제입니다.
기능을 검증하기위한 블랙 박스 테스트. 필요한 경우 화이트 박스 테스트. 모든 블랙 박스 테스트가 통과되고 적용 범위가 양호하면 화이트 박스 테스트가 필요하지 않습니다.
블랙 박스.
화이트 박스 구성 요소는 일반적 으로 블랙 박스 구성 요소에 의존하므로 블랙 박스를 먼저 테스트 한 다음 화이트 박스로 이동하고 싶습니다.
좋은 테스트주기를 원한다면 다른 사람들이 두 가지 모두를 수행해야합니다 .
화이트 박스 테스트에 중점을 둔 개발자는 최근 코드에서 변경된 사항, 더 복잡한 영역 (및 깨질 가능성이있는 영역) 등을 알고 있으며 새로운 결함이 발생할 가능성이 가장 높은 영역에 적절한 노력을 집중할 수 있습니다.
반면 블랙 박스 테스트에 중점을 둔 QA 테스터는 최종 사용자와 같은 테스트에보다 쉽게 접근 할 수 있습니다. 코드에 대한 내부 지식이 없으면 새로운 접근 방식을 취할 수 있으며 솔루션의 다른 부분이 어떻게 구현되는지에 대한 지식에 의해 편향되지 않습니다. 개발자가 간과했을 수있는 버그 나 실수로 응용 프로그램의 다른 영역을 손상시킨 코드 변경으로 인한 회귀를 포착합니다.
귀하의 질문에 대답하려면 먼저 화이트 박스 테스트를 수행해야합니다. 그러나 효과를 발휘하려면 블랙 박스 테스트를 수행하는 다른 사람이 필요합니다.
TDD의 지지자로서 코드 (또는 상자)가 존재하기 전에 테스트가 작성되기 때문에 블랙 박스 테스트를 먼저 말합니다. :)
화이트 박스 테스트 (내가 이해하는 한)는 디버깅 사고 방식에 더 유용합니다.
코드가 존재하기 전에 테스트를 작성하기 때문에 블랙 박스 테스트. 테스터는 소규모 팀에서 효율적으로 코드를 작성하는 개발자와 병행하여 시간 소모적 인 자동 테스트를 개발해야합니다.
코드가 이미 작성된 경우 블랙 박스 관점에서 테스트 범위를 스케치하여 실제 코드로 두뇌를 혼란시키기 전에 시간을 브레인 스토밍하는 데 시간을 할애하는 것이 좋습니다. 그러나 실제 테스트와 너무 멀어지기 전에 화이트 박스로 전환하고 코드를 살펴보고 위험한 영역에 대한 느낌을 얻거나 앞서 브레인 스토밍 한 테스트의 우선 순위를 정할 수 있습니다. 복잡하거나 의심스러워 보이는 코드 부분을 살펴보십시오).
둘 다. 내가 사용하는 좋은 테스트를 작성하려고 마우스 오른쪽 이두근을 염두에두고없고, 올바른 경계 조건 에 상관없이이 마음에 와서 차례를. 이것들은 Pragmatic Unit Testing 에서 제안 된 두문자어 입니다.
저의 목표는 좋은 테스트를 작성하는 데 중점을 두는 것입니다.
먼저 흰색 상자 테스트를 수행하십시오 .
두 번째는 블랙 박스 테스트입니다.
> 블랙 박스 테스트
I. 테스터는 텍스트 상자, 라디오 버튼, 목록 상자, 명령 버튼 등과 같은 응용 프로그램의 기능을 확인해야합니다.
II. 테스터는 로고, 이미지, 철자 등 응용 프로그램이 작동하지 않는지 확인해야합니다.
III. 테스터는 응용 프로그램의 전체 흐름을 확인해야합니다.
참고 : 긍정적 및 부정적 조건을 확인합니다.