Functional testing

De Software testing
Ir para: navegação, pesquisa

Concepts

Facts

  • Functional testing was developed in the 70, in methods such as structured analysis and project, to validate systems regarding their functional requirements. <bib>delamaro:slides:2007</bib>
  • Functional testing treats the product under testing as a box which may only be visualized from its exterior. <bib>vincenzi-etal:2007</bib>, <bib>myers:1979</bib>
  • Functional testing main objective is to verify product functionalities without worrying about the details of their implementation. <bib>vincenzi-etal:2007</bib>
  • Functional testing requires no knowledge of the internal paths, structure, or implementation of the software. <bib>vincenzi-etal:2007:slides</bib>, <bib>delamaro:slides:2009</bib>
  • Functional testing approach remains the same regardless of the size and the input/output complexity of the software (unit, module, subsystem) under testing. <bib>vincenzi-etal:2007:slides</bib>
  • Functional testing is programming paradigm independent. <bib>vincenzi-etal:2007:slides</bib>, <bib>delamaro:slides:2009</bib>
  • Even though functional testing does not intend to cover specific parts of the product implementation, it is difficult not to relate input domains and their partitions with statement conditions of product implementation. In this sense, if the product implementation respects the product specification and if the functional testing is effectively performed, a high code coverage may be obtained, thus reducing the cost of structural testing and also ensuring that the product implementation satisfies its specification. <bib>vincenzi-etal:2007:slides</bib>
  • Functional testing is effective to detect missing functionality. <bib>delamaro:slides:2009</bib>
  • Functional testing is not suitable for testing complex processing that requires simple input data. <bib>delamaro:slides:2009</bib>
  • Functional testing does not assure that critical or essential parts of the software have been executed. <bib>delamaro:slides:2009</bib>

Procedure

  1. The software requirements are analyzed.
  2. Valid inputs are chosen based on the requirements to determine that the software processes them correctly.
  3. Invalid inputs must also be chosen to verify that the software detects them and handles them properly.
  4. Expected outputs for those inputs are determined.
  5. Test cases are constructed with the selected inputs.
  6. The test cases s are run.
  7. Actual outputs are compared with the expected outputs.
  8. A determination is made as to the proper functioning of the software. <bib>vincenzi-etal:2007:slides</bib>


  1. Identify the functionalities the product implementation should perform.
  2. Create test cases that are capable of verifying whether such functionalities are fulfilled correctly according to product specification. <bib>vincenzi-etal:2007</bib>, <bib>pressman:2005</bib>