Functional testing is sometimes called black-box testing because no knowledge of the internal logic of the system is used to develop test cases. For example, if a certain function key should produce a specific result when pressed, a functional test validates this expectation by pressing the function key and observing the result. When conducting functional tests, you’ll use validation techniques
almost exclusively.
Conversely, structural testing is sometimes called white-box testing because knowledge of the internal logic of the system is used to develop hypothetical test cases. Structural tests use verification predominantly. If a software development team creates a block of code that will allow a system to process information in a certain way, a test team would verify this structurally by reading the code, and given the system’s structure, see if the code would work reasonably. If they felt it could, they would plug the code into the system and run an application to structurally validate the code.
Each method has its pros and cons:
Functional Testing Advantages
1• Simulates actual system usage.
2• Makes no system structure assumptions
Functional Testing Disadvantages
1• Potential of missing logical errors in software
2• Possibility of redundant testing
Structural Testing Advantages
1• You can test the software’s structure logic
2• You test code that you wouldn’t use if you performed only functional testing
Structural Testing Disadvantages
1• Does not ensure that you’ve met user requirements
2• Its tests may not mimic real-world situations
A functional test case might be taken from the documentation description of how to perform a certain function, such as accepting bar code input. A structural test case might be taken from a technical documentation manual. To effectively test systems, you need to use both methods.
Related Posts
CONDITION TESTING
TESTING CONDITIONS PART ONE
TESTING CONDITIONS PART TWO
TESTING CONDITIONS PART THREE
TESTING CONDITIONS PART FOUR
SPECIFIC FIELD TESTING
USABILITY TESTING
INTEGRATION TESTING
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
almost exclusively.
Conversely, structural testing is sometimes called white-box testing because knowledge of the internal logic of the system is used to develop hypothetical test cases. Structural tests use verification predominantly. If a software development team creates a block of code that will allow a system to process information in a certain way, a test team would verify this structurally by reading the code, and given the system’s structure, see if the code would work reasonably. If they felt it could, they would plug the code into the system and run an application to structurally validate the code.
Each method has its pros and cons:
Functional Testing Advantages
1• Simulates actual system usage.
2• Makes no system structure assumptions
Functional Testing Disadvantages
1• Potential of missing logical errors in software
2• Possibility of redundant testing
Structural Testing Advantages
1• You can test the software’s structure logic
2• You test code that you wouldn’t use if you performed only functional testing
Structural Testing Disadvantages
1• Does not ensure that you’ve met user requirements
2• Its tests may not mimic real-world situations
A functional test case might be taken from the documentation description of how to perform a certain function, such as accepting bar code input. A structural test case might be taken from a technical documentation manual. To effectively test systems, you need to use both methods.
Related Posts CONDITION TESTING
TESTING CONDITIONS PART ONE
TESTING CONDITIONS PART TWO
TESTING CONDITIONS PART THREE
TESTING CONDITIONS PART FOUR
SPECIFIC FIELD TESTING
USABILITY TESTING
INTEGRATION TESTING
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
No comments:
Post a Comment