SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Software Engineering 2 Software Testing Claire Lohr pp 413

adem avatar
adem
23 diapositives · 495 Views · Aug 26, 2012

Software Engineering 2 Software Testing Claire Lohr pp 413. Presented By: Feras Batarseh. Definition. IEEE 610.12 An activity in which a system or component under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or

#performance testing #acceptance test #black box testing #automated testing #talk aloud protocol #software engineer #bridge pattern #case
Software Engineering 2 Software Testing Claire Lohr pp 413 - slide 1
01 / 23Software Engineering 2 Software Testing Claire Lohr pp 413
1 / 17

Télécharger la présentation

Software Engineering 2 Software Testing Claire Lohr pp 413
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Software Engineering 2Software TestingClaire Lohrpp 413 Presented By:Feras Batarseh

  2. Definition IEEE 610.12 An activity in which a system or component under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component.

  3. Attributes Software engineer intuition and experience. Specification. Code. Dataflow. Fault. Usage. Nature of the application.

  4. Types of Testing Equivalence class partitioning. Boundary value. Decision table. Exploratory. Operational profile.

  5. Equivalence class partitioning According to two attributes: Valid. Invalid. Example: age 0-120 (valid) age <0 and >120 (Invalid)

  6. Steps for ECP Define valid and invalid values. Test as many valid classes together. Do one test for each invalid class.

  7. Boundary value Must test the following: Legally defined minimum. Legally defined maximum. The first possible value below the legally min. The first possible value above the legally max. Age ex: 0, 120, -1, 121

  8. Decision table Lists all conditions and all resultant outputs. Y :yes N: no 1:yes and no.

  9. Exploratory testing Emphasizing planning the focus of the testing process. Doesn’t require pre-planning. When test begins, modifications are still allowed. Test results modify the plan accordingly.

  10. Operational profile Number of tests to be done follows the model of how much it is used during operation. Test more for features that are used more.

  11. Testing Levels Levels vary from organization to organization, and from project to project. Some parameters: Size. Complexity. Safety criticality. Experience of staff. Desire for certification(ISO, CMMI)

  12. Testing Levels (cont.) Operational testing: Software units, DB, integrated components, requirements and integration. Maintenance process: modified and un-modified parts, migration verification, parallel testing, all development levels for improvements. Supporting process: Verification and validation.

  13. Testing strategies Testing all combinations is impossible! Macro: Time to market Amount of functionality to be delivered Quality of product Micro: More automation to speed process Better selection of test cases Less turnovers in testing staff.

  14. Testing strategies (cont.) For functionality changes: Tracing requirements to see cases affected by changes. Modular testing. For quality of product: More variety in types. Better tools. Better unit test tools for developers

  15. Testing strategies (cont.2) To control test effort cost: PM tool for estimations. Add root cause analysis.

  16. Test Design Art and science. Structured: Boundary value Decision table Equivalence class partitioning Un structured: Random Ad hoc Exploratory

  17. Test Coverage of code Impossible to cover all the code. Depends on the definition of ”covering”! Does it mean executing, reading, testing? Use Tom McCabe’s basis technique.

  18. Tom McCabe’s basis technique. 1-Draw a flow graph.(nodes and edges) 2-Compute the metric cyclomatic complexity (nodes). No.edges-no.Nodes+2=cc 3-Choose paths. (cover all nodes and edges)

  19. Test Execution Defined in a test plan (Pseudo code and flow graph) Cover all specifications is important.(categorize according to testable or not) Define components: hardware, software, personnel, data, automated tools.

  20. Testing documentation Media vary depending on level of detail: Word doc. Spread sheets. Databases. Within automated test tools.

  21. IEEE Testing documentation Test plan Test design Test cases Test procedures Test logos Incident reports Test summary report Test item transmittal report

  22. Test management Estimating schedules. Planning for staffing and training. Identifying and planning tasks. Monitoring the execution of the plans and re-planning based on results.

  23. Any questions? Thank You for your attention.