Approach of boxes
Methods of software testing are traditionally divided into black box testing and white box testing. White box and black box both the approaches are used to explain the viewpoint that a test engineer takes when designing test cases.
1.Black box testing
Black box testing deals the software program as a "black box" — without any information of internal implementation. Black box testing manner contain: boundary value, equivalence partitioning, analysis, fuzz testing, all-pairs testing, traceability matrix, exploratory testing, model-based testing and specification-based testing.
Specification-based testing:
Testing based on Specification, targets to test the functionality of software system according to the applicable demands. Therefore, the software tester inputs information into, and only checks the result from the test object. This type of testing normally requires thorough test cases to be offered to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Specification-based testing is essential, but it is not sufficient to defend against certain risks.
Advantages and disadvantages:
The testers of black box have no "bonds" with the codes, and a tester's perception is very simple: a code must have errors. Applying the principle, "Ask and you shall receive," testers of black box get errors (bugs) where software programmers do not find these bugs. But, on the other side, black box testing is said to be "like a walk in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed. As a result, there are conditions when
(1) A tester writes many test cases to check something that could have been tested by only one test case
(2) Some parts of the back-end are not tested at all.
2.White box testing
White box testing is required when the tester has access to the inner algorithms and data structures adding the code that implement these.
3. Grey Box Testing
Grey box testing involves taking access to internal algorithms plus data structures for uses of designing the check events, but testing at the user, or black-box level. Manipulating input information plus formatting output do not alter as grey box, because the output plus input are clearly outside of the "black-box" that we are addressing the process under check. This differentiation is important when dealing with integration testing between two modules of code written by two different developers, where only the user interfaces are open for check. However, alteration in a data repository does alter as grey box, as the finish user would not usually be able to fine-tune the data outside of the process under check. Grey box testing may also involve reverse engineering to assess, for instance, boundary values or error messages.
4. Integration Testing
Integration testing is any type of software testing which seeks to ensure the interfaces between the elements against a software design. Software elements can be combined iteratively or all together ( "big bang"). Normally, the former is considered a best practice because it permits interface issues to be located and fixed more quickly.
5. Regression Testing
Regression testing is any type of program testing that searches to reveal program regressions. Such regression happen whenever program functionality, that was previously working right, ends working as intended. Typically, regressions take place as an unintended outcome of program changes, when the freshly developed part of the program clashes with the previously existing. General methods of regression testing include re-working previously run tests and checking whether previously resolved faults have re-emerged. The deepness of testing depends on the stage in the release procedure and the risk of the added features. They can either be complete, for changes added late in the release or viewed as to be unsafe, to very shallow, consisting of positive tests on each characteristic, if the changes are early in the release or viewed as to be of small risk.
6. Acceptance testing
Acceptance testing can mean one of two things:
(1) A smoke test is applied as an acceptance check prior to introduce a new build to the main testing scheme, i.e. before integration or regression.
(2) Acceptance testing done by the customer, often in their lab environment on their own hardware, is known as user acceptance testing.
7. Destructive testing
Destructive software testing attempts to reason the software or a sub-system to fail, in order to test its robustness.
nice
ReplyDelete