블랙 박스 또는 화이트 박스 테스트가 테스터에게 강조되어야합니까?

블랙 박스 또는 화이트 박스 테스트가 테스터에게 강조되어야합니까?

---

(테스터 / QA의 경우) 어떤 유형의 테스트를 강조해야하며 그 이유는 무엇입니까?

wikipedia의 빠른 정의 집합 :

블랙 박스 테스트

• 테스트 케이스를 도출하기 위해 테스트 개체의 외부 관점을 취합니다. 이러한 테스트는 일반적으로 작동하지만 작동하거나 작동하지 않을 수 있습니다. 테스트 디자이너는 유효하고 잘못된 입력을 선택하고 올바른 출력을 결정합니다. 테스트 개체의 내부 구조에 대한 지식이 없습니다.

화이트 박스 테스트

• 시스템의 내부 관점을 사용하여 내부 구조를 기반으로 테스트 케이스를 설계합니다. 소프트웨어를 통한 모든 경로를 식별하려면 프로그래밍 기술이 필요합니다. 테스터는 테스트 케이스 입력을 선택하여 코드를 통해 경로를 실행하고 적절한 출력을 결정합니다. 전기 하드웨어 테스트에서 회로의 모든 노드를 조사하고 측정 할 수 있습니다. 예를 들어 회로 내 테스트 (ICT)가 있습니다.

좀 더 명확히하기 위해 둘 다 중요하다는 것을 알고 있지만 일반적으로 개발과 QA간에 분리되어 있습니다.

테스터 / QA에 내부 지식이 중요합니까? 이 지식을 염두에두고 테스트하면 문제를 더 잘 테스트 할 수 있다는 주장을 들었지만,이 지식이 기능적 요구에서 산만 해지고 의도 된 솔루션이 아닌 "코드 테스트"를 촉진 할 수 있다는 주장도 들었습니다.

---

• 블랙 박스 테스트는 테스터 / QA에 중점을 두어야합니다.
• 화이트 박스 테스트는 개발자에게 강조되어야합니다 (즉, 단위 테스트).
• 이 질문에 답한 다른 사람들은 질문을 화이트 박스 테스트 또는 블랙 박스 테스트 중 어느 것이 더 중요한지 로 해석 한 것 같습니다 . 나도 둘 다 중요하다고 생각하지만 화이트 박스 테스트가 더 중요하다고 주장하는 이 IEEE 기사 를 확인하는 것이 좋습니다.

---

화이트 박스 테스트는 소프트웨어 단위 테스트와 동일합니다. 개발자 또는 개발 수준 테스터 (예 : 다른 개발자)는 작성한 코드가 시스템에 통합하기 전에 세부 수준 요구 사항에 따라 올바르게 작동하는지 확인합니다.

블랙 박스 테스트는 통합 테스트와 동일합니다. 테스터는 시스템이 기능 수준의 요구 사항에 따라 작동하는지 확인합니다.

두 가지 테스트 접근 방식 모두 제 생각 에는 똑같이 중요 합니다.

철저한 단위 테스트는 소프트웨어가 시스템에 통합 된 이후가 아니라 개발 단계에서 결함을 포착합니다. 시스템 레벨 블랙 박스 테스트는 함께 통합 될 때 모든 소프트웨어 모듈이 올바르게 작동하는지 확인합니다. 모듈은 일반적으로 서로 독립적으로 개발되기 때문에 개발 단계의 단위 테스트에서는 이러한 결함을 포착하지 못합니다.

---

블랙 박스

1 시스템의 기능에 중점을 둡니다. 시스템의 구조 (프로그램)에 중점을 둡니다.

2 사용 된 기술은 다음과 같습니다.

· 등가 분할

· 경계 값 분석

· 오류 추측

· 경쟁 조건

· 원인-결과 그래프

· 구문 테스트

· 상태 전환 테스트

· 그래프 매트릭스

테스터는 비 기술적 일 수 있습니다.

기능 사양의 모호함과 모순을 식별하는 데 도움이됩니다.

화이트 박스

사용 된 기술은 다음과 같습니다.

· 기본 경로 테스트

· 흐름 그래프 표기법

· 제어 구조 테스트

1. 상태 테스트

2. 데이터 흐름 테스트

· 루프 테스트

1. 단순 루프

2. 중첩 루프

3. 연결된 루프

4. 구조화되지 않은 루프

   테스터는 기술적이어야합니다.

   논리 및 코딩 문제를 식별하는 데 도움이됩니다.

---

QA는 블랙 박스 테스트 에 중점을 두어야합니다 . QA의 주요 목표는 시스템이 수행하는 방식이 아니라 시스템이 수행하는 작업 (기능이 요구 사항을 충족합니까?)을 테스트하는 것입니다.

어쨌든 대부분의 QA 담당자는 기술 담당자가 아니기 때문에 QA가 화이트 박스 테스트를 수행하는 것이 어려울 것이므로 일반적으로 사용자와 같은 UI를 통해 기능을 테스트합니다.

한 단계 더 나아가 개발자 도 블랙 박스 테스트 에 집중해야 한다고 생각 합니다 . 나는 단위 테스팅과 화이트 박스 테스팅 사이의 광범위한 연관에 동의하지 않지만 어휘 / 스케일에 대한 질문 일 수 있습니다. 단위 테스트의 규모 에서 테스트 중인 시스템 은 계약 (서명을 통해)이있는 클래스 / 메서드이며 중요한 점은 방법이 아니라 수행하는 작업을 테스트하는 것입니다. 또한 화이트 박스 테스트는 방법이 계약을 어떻게 채우는 지 알고 있음을 의미합니다. 이는 나에게 TDD와 호환되지 않는 것처럼 보입니다.

IMHO SUT가 너무 복잡해서 화이트 박스 테스트를 수행해야하는 경우 일반적으로 리팩토링 할 때입니다.

---

"둘 다"가 위에서 언급되었으며 분명한 대답입니다 ... 그러나 IMO, 화이트 박스 테스트는 개발자 단위 테스트를 훨씬 뛰어 넘습니다 (흰색과 검은 색 사이의 선을 그리는 위치에 따라 달라질 수 있다고 생각합니다). 예를 들어, 코드 커버리지 분석은 일반적인 화이트 박스 접근 방식입니다. 즉, 일부 시나리오 또는 테스트를 실행하고 테스트에서 허점을 찾는 결과를 조사합니다. 단위 테스트가 100 % cc를 가지고 있더라도 일반적인 사용자 시나리오에서 cc를 측정하면 잠재적으로 더 많은 테스트가 필요할 수있는 코드를 나타낼 수 있습니다.

화이트 박스 테스트가 도움이되는 또 다른 곳은 데이터 유형, 상수 및 기타 정보를 검사하여 경계, 특수 값 등을 찾는 것입니다. 예를 들어, 애플리케이션에 숫자 입력을받는 입력이있는 경우 bb 전용 접근 방식은 테스터가 어떤 값이 테스트에 좋을지 "추측"하는 반면, wb 접근 방식은 1-256 사이의 모든 값이 한 방향으로 처리되는 반면 더 큰 값은 다른 방식으로 처리된다는 것을 나타낼 수 있습니다. 그리고 아마도 숫자 42에는 또 다른 코드 경로가 있습니다. .

따라서 원래 질문에 답하려면 bb와 wb가 모두 좋은 테스트에 필수적입니다.

---

내 경험상 대부분의 개발자는 자연스럽게 화이트 박스 테스트로 마이그레이션합니다. 기본 알고리즘이 "올바른"지 확인해야하므로 내부에 더 집중하는 경향이 있습니다. 그러나 지적했듯이 화이트 박스와 블랙 박스 테스트가 모두 중요합니다.

따라서 대부분의 개발자가 실제로 수행하지 않고 종종 잘하지 않는다는 사실을 커버하기 위해 테스터가 블랙 박스 테스트에 더 집중하도록하는 것을 선호합니다.

그것은 테스터가 시스템 작동 방식에 대해 어둠 속에 두어야한다는 말이 아니라 SomeMethod (int x) 함수가 아닌 문제 영역과 실제 사용자가 시스템과 상호 작용하는 방식에 더 집중하는 것을 선호한다는 것입니다. x가 5이면 예외가 올바르게 발생합니다.

---

약간 열린 문이지만 결국 둘 다 거의 똑같이 중요합니다.

더 나쁜 것은 무엇입니까?

1. software that does what it needs to do, but internally has problems?

2. software that is supposed to work if you look at the sources, but doesn't?

My answer: Neither is totally acceptable, but software cannot be proven to be 100% bugfree. So you're going to have to make some trade-offs. Option two is more directly noticable to clients, so you're going to get problems with that sooner. On the long run, option one is going to be problematic.

---

Black Box Testing: Black Box testing is just observation no need Internal Knowledge or structure of software product. just putting valid and Invalid data input and expecting the correct result. here tester find the defect but unable to Find the Location of defect.black box testing done in all testing level.

Black box testing tecniques are: 1. Equivalance partition 2. Boundary Value Analysis 3. Decision table 4. State Transition Diagram 4. Use case diagram

White Box Testing: White box is testing it requires the knowledge of internal logic and structure of software product. here we will check the loop, condition and branch. here we find not only the defect but also and location of defect.

White box Testing Techniques: 1. Statement Coverage 2. Decision Coverage 3. Branch Coverage 4. Path Coverage.

---

• Usually the white-box testing is not possible for testers. Thus the only viable answer for testers is to emphasize black-box approach.

• However, with aspect-oriented-programming and design-by-contract methodology, when the testing goals are programmed into the target code as contracts (seen from the static view of a program), and/or when the testing temporal logic is programmed into the code as cross-cuts (dynamic view of the test logic), white-box testing would become not only possible but also a preferred take for testers. Given that said, it will need be an expertise-demanding take, the testers need to be not only good testers, but also good programmers or more than good programmers.

---

Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester. White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.

---

What constitutes, "internal knowledge?" Does knowing that such-and-such algorithm was used to solve a problem qualify or does the tester have to see every line of code for it to be "internal?"

I think in any test case, there should be expected results given by the specification used and not determined by how the tester decides to interpret the specification as this can lead to issues where each thinks they are right and blaming the other for the problem.

---

• *Black box testing: Is the test at system level to check the functionality of the system, to ensure that the system performs all the functions that it was designed for, Its mainly to uncover defects found at the user point. Its better to hire a professional tester to black box your system, 'coz the developer usually tests with a perspective that the codes he had written is good and meets the functional requirements of the clients so he could miss out a lot of things (I don't mean to offend anybody)
• Whitebox is the first test that is done in the SDLC.This is to uncover bugs like runtime errors and compilation errrors It can be done either by testers or by Developer himself, But I think its always better that the person who wrote the code tests it.He understands them more than another person.*

---

Here is my 5 cents:

As a developer, I mostly write tests for methods (in a class) as white box tests, simple because I do not want my test to break just because I change the inner works of my code.

I only want to my tests to break if my method behavior changes (e.g. returns a different result than before).

Over the last 20 years of development, I simple got tired of doing up-to double work just because my unit tests was strongly tied to the code and I need to maintain both application code and test code.

I think making decoupling code (also when you code tests) is a very good practice.

Another 5 cents: I hardly never use mocking frameworks, because when I find it necessarily to mock something I prefer to decouple my code instead - and yes in many cases that is very possible (especially if you are not working in legacy code) :-)

---

*Black-Box testing: If the source code is not available then test data is based on the function of the software without regard to how it was implemented. -strong textExamples of black-box testing are: boundary value testing and equivalence partitioning.

*White-Box testing: If the source code of the system under test is available then the test data is based on the structure of this source code. -Examples of white-box testing are: path testing and data flow testing.

---

Simple...Blackbox testing is otherwise known as Integration testing or smoke-screen testing . This is mostly applied in a distributed environment which rely on event-driven architecture. You test a service based on another service to see all possible scenarios. Here you cannot completely forecast all possible output because each component of the SOA/Enterprise app are meant to function autonomously. This can be referred to as High-Level testing

while

White box testing refers to unit-testing. where all expected scenarios and output can be effectively forecasted. i.e Input and expected output.This can be referred to as Low-level testing

---

I only partially agree with the top rated answer for this question. Which type of testing would you say should be the emphasis (for testers/QAs), and why?

1. I agree that: "Black box testing should be the emphasis for testers/QA."
2. I agree that White box testing should be the emphasis for developers, but I don't agree that White Box testing is just unit tests.

I agree with the definition here which states that White Box Testing method is applicable to the following levels of software testing:

• Unit Testing: For testing paths within a unit
• Integration Testing:For testing paths between units
• System Testing: For testing paths between subsystems

ReferenceURL : https://stackoverflow.com/questions/402161/should-black-box-or-white-box-testing-be-the-emphasis-for-testers