Black & White Box testing

download Black & White Box testing

If you can't read please download the document

  • date post

  • Category


  • view

  • download


Embed Size (px)


Black & White Box testing

Transcript of Black & White Box testing

  • 1. Prepared by :1.Mohammed Siddig Ahmed.2.Mohammed Zeinelabdeen.3.Omer Salih Dawood.

2. Testing Overview and Black-BoxTesting Techniques 3. Introduction to Testing. Verification and validation. Black-box testing & White-box testing. Types of testing that involve bothblack- and white-box techniques. Strategies for writing test cases. Using a template for writingrepeatable, defined test cases. 3 4. Software testing is the process ofanalyzing a software item to detect thedifferences between existing and requiredconditions (that is, bugs) and to evaluatethe features of the software item. 4 5. Verification is the process of evaluating a system orcomponent to determine whether the products of agiven development phase satisfy the conditionsimposed at the start of that phase. Validation is the process of evaluating a system orcomponent during or at the end of the developmentprocess to determine whether it satisfies specifiedrequirements. Verification: Are we building the product right? Validation : Are we building the right product?5 6. Standard or specification to measure or identify correct results from incorrect results must define some terms: Mistake . Fault [or Defect] . Failure . Error . Specification.6 7. In software development, there are costsassociated with testing our programs. Quality is much more important forsafety- or mission critical software e.g.aviation software. Goal of testing covering many defects aspossible with a little testing.7 8. There are two basic classes of software testingdefinitions below: Black box testing (also called functionaltesting) is testing that ignores the internalmechanism of a system or component andfocuses solely on the outputs generated inresponse to selected inputs and executionconditions. White box testing (also called structuraltesting and glass box testing) is testing thattakes into account the internal mechanism of asystem or component. 8 9. 1. Unit Testing Opacity: White box testing. Specification: Low-level design and/or code structure. (Unit testing is the testing of individual hardware or software units or groups of related units).2. Integration testingOpacity: Black- and white-box testing.Specification: Low- and high-level design.(Integration test is testing in which software components,hardware components, or both are combined and tested toevaluate the interaction between them). 9 10. 3. Functional and system testingOpacity: Black-box testing Specification: high-level design, requirements specification.( Functional testing involves ensuring that the functionalityspecified in the requirement specification works,& Systemtesting is testing conducted on a complete, integrated systemto evaluate the system compliance with its specifiedrequirements). Stress testing Performance testing Usability testing 10 11. 4. Acceptance testing Opacity: Black-box testingSpecification: requirements specification. (Acceptance testing is formal testing conducted todetermine whether or not a system satisfies itsacceptance criteria (the criteria the system must satisfyto be accepted by a customer) and to enable thecustomer to determine whether or not to accept thesystem). 11 12. 5. Regression testing Opacity: Black- and white-box testing Specification: Any changed documentation, high-level design (Regression testing is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified Requirements).A subset of the regression test cases can be set asideas smoke tests.12 13. 6. Beta testingOpacity: Black-box testing.Specification: None.The advantages of beta test: Identification of unexpected errors A wider population search for errors Low costsThe disadvantages Lack of systematic testing Low quality error reports Much effort is necessary to examine error reports 13 14. 14 15. ( Document describing the scope, approach, resources,and schedule of intended test activities. It identifiestest items, the features to be tested, the testing tasks,who will do each task, and any risks requiringcontingency plans). Test case ( set of test inputs, executionconditions, and expected results developed fora particular objective, such as to exercise aparticular program path or to verify compliancewith a specific requirement).15 16. The earlier testing is planned at all levels, the better. Very important to consider test planning and testexecution as iterative processes. It is best to begin to write functional and system testcases. When requirements change, revise the test cases. When code changes, run the test cases again. All in all, testing should be considered an iterative andessential part of the entire development process.16 17. Called : functional testing behavioral testing focuses on: whether or not a program does what it issupposed to do based on its functionalrequirements. 17 18. 1. incorrect or missing functionality.2. interface errors .3.errors in data structures used by interfaces.4. behavior or performance errors.5. initialization and termination errors.But: no amount of testing candemonstrate the absence of errors.18 19. blackbox tester is not the programmer of the code (it is best). Programmer: If the program does what they programmedit to do?. Needed: If The program does what the customerwants it to do?.19 20. Focus on input and output of thesoftware without regard to the internalcode of the program20 21. 1. test case a unique identifier.2. describe the set of steps and/or input for the particular condition.3. the expected results for an input/output oracle.4. the actual results.21 22. 22 23. Why test Strategies?:- test every possible thing (Cost). find many defects in few test cases . avoid writing redundant test cases. design the simplest test cases .23 24. 1. Tests of Customer Requirements.2. Equivalence Partitioning.3. Boundary Value Analysis.4. Decision Table Testing.5. Failure (Dirty) Test Cases. 24 25. Black box test cases are based oncustomer requirements Have two paths: success path. failure path. risky requirements should tested first.25 26. dont want to write several test casesthat test the same aspect of ourprogram(cost). A good test case uncovers a differentclass of errors. Equivalence partitioning is used toreduce the number of test cases t. divides the input of a program intoclasses26 27. For each of these classes :- the set of data should be treated the sameby the module under test . And should produce the same answer. 27 28. Bugs lurk in corners andcongregate at boundaries Boris Beizer need to focus testing at the boundaries. Boundary value:- a data value that corresponds to a minimumor maximum input, internal, or output valuespecified for a system or component.28 29. When creating BVA test cases, considerthe following : If input conditions have a range from a to b(such as a=100 to b=300), create test cases: immediately below a (99) at a (100) immediately above a (101) immediately below b (299) at b (300) immediately above b (301) 29 30. If input conditions specify a number ofvalues that are allowed, test these limits.30 31. record complex business rules that must beimplemented in the program, and thereforetested. conditions represent possible input. actions are the events that should trigger. Each column in the table is a uniquecombination of input conditions that resultin triggering the action(s) associated withthe rule.31 32. 32 33. every possible thing a user could possiblydo with your system to demolish thesoftware. 33