Software testing


Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software testing

  1. 1. Software testing is a formal process carried out by aspecialized testing team in which a softwareunit, several integrated software units or anentiresoftware package are examined by running theprograms on a computer. All the associated tests areperformed according to approved test procedures onapproved test cases.
  2. 2. Software testing (or “testing”) was the first softwarequality assurance tool applied to control the softwareproduct’s quality before its shipment or installation atthe customer’s premises.
  3. 3. 0 At first, testing was confined to the final stage of development, after the entire package had been completed.0 Later, as the importance of early detection of software defects penetrated quality assurance concepts, SQA professionals were encouraged to extend testing to the partial in-process products of coding, which led to software module (unit) testing and integration testing.0 Common to all testing activities is their application through the direct running of code, free of review of development documents. Some authors tend to broaden the scope of testing even further and consider all software life cycle quality assurance activities as types of testing activities.
  4. 4. Software Testing Strategies0 Big bang testing : test the software in its entirety, once the completed package is available;0 Unit Test : test the software piecemeal, in modules, as they are completed0 Integration tests : test groups of tested modules integrated with newly completed modules ().0 Incremental testing : This process continues until all the package modules have been tested. Once this phase is completed, the entire package is tested as a whole (system test).
  5. 5. Incremental Testing0 In top-down testing, the first module tested is the main module, the highest level module in the software structure; the last modules to be tested are the lowest level modules.0 In bottom-up testing, the order of testing is reversed: the lowest level modules are tested first, with the main module tested last.
  6. 6. Software Test ClasificationsClassification according to testing concept:0 Black box (functionality) testing. Identifies bugs only according to software malfunctioning as they are revealed in its erroneous outputs. In cases that the outputs are found to be correct, black box testing disregards the internal path of calculations and processing performed.0 White box (structural) testing. Examines internal calculation paths in order to identify bugs. Although the term “white” is meant to emphasize the contrast between this method and black box testing, the method’s other name – “glass box testing” – better expresses its basic characteristic, that of investigating the correctness of code structure.
  7. 7. Classification according torequirements: 0 Correctness 0 Portability 0 Reliability 0 Reusability 0 Efficiency 0 Interoperability 0 Integrity 0 Usability 0 Maintability 0 Flexibility 0 Testability
  8. 8. WHITE BOX TESTING0 White box testing enables performance of data processing and calculations correctness tests, software qualification tests, maintainability tests and reusability tests.0 In order to perform data processing and calculation correctness tests (“white box correctness test”), every computational operation in the sequence of operations created by each test case (“path”) must be examined.
  9. 9. Data processing andcalculation correctness testsApplying the concept of white box testing, which is based onchecking the data processing for each test case, immediatelyraises the question of coverage of a vast number of possibleprocessing paths and the multitudes of lines of code. Twoalternative approaches have emerged:0 “Path coverage” – to plan our test to cover all the possible paths, where coverage is measured by percentage of paths covered.0 “Line coverage” – to plan our tests to cover all the program code lines, where coverage is measured by percentage of lines covered.
  10. 10. Correctness tests and path coverageDifferent paths in a software module are created by thechoice in conditional statements, such as IF–THEN–ELSE or DO WHILE or DO UNTIL. Path testing ismotivated by the aspiration to achieve completecoverage of a program by testing all its possible paths.
  11. 11. Correctness tests and line coverageThe line coverage concept requires that, for full linecoverage, every line of code be executed at least onceduring the process of testing. The line coverage metricsfor completeness of a line-testing (“basic path testing”)plan are defined as the percentage of lines indeedexecuted – that is, covered – during the tests.
  12. 12. Black Box Testing0 Black box testing allows us to perform output correctness tests and most classes of tests. Apart from output correctness tests (if you are prepared to pay the extra costs, these could be performed by white box data processing and calculation correctness tests) and maintainability tests (that could be performed by white box tests), most of the other testing classes are unique to black box testing.