1 / 22

CSC7302: Overview

CSC7302: Overview. Module Director : Jean-Luc Raffy. Joint Teaching : Paul Gibson Jean-Luc Raffy. Web Site: http://www-public.int-evry.fr/~gibson/Teaching/CSC7302/. Evaluation: single examination 3 hours (1st December ). CSC5021: calendar. My Sessions (all PBL- driven ).

bart
Download Presentation

CSC7302: Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSC7302: Overview Module Director: Jean-Luc Raffy • Joint Teaching: • Paul Gibson • Jean-Luc Raffy Web Site: http://www-public.int-evry.fr/~gibson/Teaching/CSC7302/ Evaluation: single examination 3 hours (1st December) CSC7302: Testing & Metrics

  2. CSC5021: calendar My Sessions (all PBL-driven) • Session 1: Tuesday 8th November – Introduction and Hangman PBL • Session 2: Thursday 10th November – Refactoring and Auto-restructuring (OO metrics) • Session 3: Tuesday 15th November – Integration Testing & Regression Testing (OO) • Session 4: Wednesday 16th November – Advanced Testing Techniques (Auto test generation) Thesewillbeinterdependent PBL will help us identifyholes in yourknowledge Jean-Luc • Metrics and Software Quality • How good are your tests (coverageetc…?) • Limits to Testing • Black box versus White box • Tests and Documentation • Tests and Maintenance • …? Wed 9th Nov(pm), Mon 14th (pm), Mon 21st (pm), Tue 22nd(pm) – to bedecided, Thur 1st Dec (am) – exam CSC7302: Testing & Metrics

  3. SomePreviousWork You (May) Need To Revisit Life Cycle: Chaos versus Organised versus Agile Test DrivenDevelopment UML & Tests JUnit MetricsExamples This module will examine all of thesethings in more detail CSC7302: Testing & Metrics

  4. CSC7302: Testing & Metrics

  5. CSC7302: Testing & Metrics

  6. CSC7302: Testing & Metrics

  7. Move To Agile? CSC7302: Testing & Metrics

  8. All of the most popular Agile methods place importance on testing, and are closely related to test-driven development (TDD): •Scrum •Lean Development •Extremeprogramming (XP) •Adaptive Software Development (ASD) •Agile Modeling • Crystal Methods • Dynamic System Development Methodology (DSDM) •FeatureDrivenDevelopment The (implicit) design places importance on refactoring, often in order to improve the software metrics CSC7302: Testing & Metrics

  9. Test DrivenDevelopment CSC7302: Testing & Metrics

  10. TestingConsistency • Tests are the main way of maintainingconsistency in the documentation/models: • Natural LanguageText (English/French) • (UML) models • (Java) Code • Comments in (Java) Code If you do not develop tests in parallelwith code youriskhavingwidespreadinconsistencythatisdifficult to fix (particularly in large projectswith lots of team membersworking on different phases of the development). NOTE: testingafter all the code isdevelopedisusually a badidea; but itisbetterthan no testingat all! CSC7302: Testing & Metrics

  11. UML & Tests • A keyprinciplewithtestingisthat the tests shouldbederivedfrom (and be consistent with) the requirementsspecification. • The UML diagramsshould help us because: • if our tests are consistent with the UML then – provided the UML isvalidatedagainst the informallyexpressedneeds of the client – we have a good chance of properlytesting the system againstwhatisreallyrequired by the client/customer • the structure of the UML should correspond to the structure of the developed code – itis a bridge betweenwhatisrequired and how itis to beimplemented – sowecanre-use this design structure to structure our tests. CSC7302: Testing & Metrics

  12. UML – the diagrams ValidationTests • Use Case Diagrams • Class Diagrams & Sequence/Communication Diagrams • test associations/aggregations • multiplicity • creation, destruction • sequencing • Flow control / threads • exceptions • Class diagrams (detailed) • State Machine Diagrams Integration Tests Unit Tests CSC7302: Testing & Metrics

  13. Validation Use Case Diagrams – for each use case examine possible scenarios, and choose a subset for testing. For example: Use case1 A1 Use case2 Use case3 A2 Use case4 A3 CSC7302: Testing & Metrics

  14. Big Bang– system validation – « if the system worksthenit must beproperlyintegrated? » Test at the system interface Integration: the most difficult • MAIN PROBLEMS: • Testing produces errors, but what caused them? • Testing misses bugs • Testing starts after all components are coded CSC7302: Testing & Metrics

  15. Top Down– test all interactions between components (from root to leaves). Integration Possible integration test sequence 1 3 4 2 8 7 5 6 • NOTES: • In reality, one will execute many different tests for each branch of the tree. • Top Down integration is usually performed breadth first or depth first. CSC7302: Testing & Metrics

  16. Top Down– the need for stubs In top down testing, wemaystart the tests before all components are coded. In such a case, wemay have to writestubs – pieces of dummy code thatsimulatebehaviourthatis not yetcoded. In OO, stubssimulatecalledmethods. NOTE: When code for other lower level components is completed, the relevant stubs are no longer needed. Integration To execute an integration test on branch1 we may have to simulate method calls between C and lower level components that are not yet implemented. For example, if SC2 is not yet coded we create a stub (dummy code) which simulates the method call between C and SC2 S 1 C 8 2 stub SC3 SC1 SC22 CSC7302: Testing & Metrics

  17. Bottom-Up– test all interactions between components (from leaves to root). Integration Possible integration test sequence 8 3 6 7 4 5 1 2 • NOTES: • In reality, one will execute many different tests for each branch of the tree. • Bottom Up integration is usually performed breadth first or depth first. CSC7302: Testing & Metrics

  18. Bottom-Up– the need for drivers In bottom up testing, we may start the tests before all components are coded. In such a case, we may have to write drivers– pieces of dummy code that simulate behaviour that is not yet coded. In OO, drivers simulate calling methods NOTE; When code for other higher level components is completed, the relevant drivers are replaced. Integration For example, to execute an integration test on branches 7 and 4 we may have to simulate method calls from C (which is not yet coded) to SC1 and SC2. So, we create a driver (dummy code) which simulates the sequence of method calls from C to SC1 and SC2. C 5 driver SC3 SC1 SC2 CSC7302: Testing & Metrics

  19. Unit Tests CSC7302: Testing & Metrics

  20. Unit Test Tool Support Always check if there unit test tool support for yourfavouritelanguages/IDEs, eg: Java/Eclipse CSC7302: Testing & Metrics

  21. MetricsTool Support Always check if thereis a metricstool support for yourfavouritelanguages/IDEs, eg: Java/Eclipse CSC7302: Testing & Metrics

  22. PBL Session – Hangman (Seenext set of slides) CSC7302: Testing & Metrics

More Related