L9 Project Testing

pdf

School

The University of Sydney *

*We aren’t endorsed by this school

Course

5619

Subject

Electrical Engineering

Date

Oct 30, 2023

Type

pdf

Pages

Uploaded by MateCaribou3742

The University of Sydney Page 1 ELEC5619 – Object Oriented Application Frameworks Nan Yang School of Electrical and Information Engineering The University of Sydney

The University of Sydney Page 2 Contents Polymorphism

The University of Sydney Page 3 Polymorphism Basics – Inheritance allows you to define a base class and derive classes from the base class – Polymorphism allows you to make changes in the method definition for the derived classes and have those changes apply to methods written in the base class

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 4 Polymorphism – Consider an array of Person Person[] people = new Person[4]; – Since Student and Undergraduate are types of Person , we can assign them to Person variables people[0] = new Student("DeBanque, Robin", 8812); people[1] = new Undergraduate("Cotty, Manny", 8812, 1); people[2] = new Student("DeBanque, Robin", 8812); people[3] = new Undergraduate ("Bugg, June", 9901, 4);

The University of Sydney Page 5 Polymorphism – Given: Person[] people = new Person[4]; people[0] = new Student("DeBanque, Robin", 8812); – When invoking: people[0].writeOutput(); – Which writeOutput() is invoked, the one defined for Student or the one defined for Person ? – Answer: The one defined for Student

The University of Sydney Page 6 Polymorphism Example – View sample class class PolymorphismDemo – Output Listing 8.6

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 7 Contents Project Testing

The University of Sydney Page 8 Object-Oriented Testing – To discuss when testing takes place in the life cycle - Test-driven development advocates early testing! – To cover the strategies and tools associated with object oriented testing - Analysis and Design Testing - Class Tests - Integration Tests - Validation Tests - System Tests – To discuss test plans and execution for projects analysis design code test ?

The University of Sydney Page 9 Test-driven programming – When should testing begin? – Analysis and Design: - Testing begins by evaluating the OOA and OOD models - How do we test OOA models (requirements and use cases)? - How do we test OOD models (class and sequence diagrams)? - Structured walk-throughs, prototypes - Formal reviews of correctness, completeness and consistency – Programming: - How does OO make testing different from procedural programming? - Concept of a ‘unit’ broadens due to class encapsulation - Integration focuses on classes and their context of a use case scenario or their execution across a thread - Validation may still use conventional black box methods

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 10 Object-Oriented Testing – eXtreme Programming (XP) advocates writing tests for units before writing actual code for units – Why might this practice be a good idea? – Constrains code to design: How so? - Design -> Test -> Code … in small iterations – Promotes validation and reliability: Why? - Always rerun all tests (easier with automated testing) before integrating new code in a release – Increases confidence to change code: Why? - Changes shouldn’t break old code if you can test old code - Creed of XP: “embrace change”

The University of Sydney Page 11 Criteria for Completion of Testing – When are we done testing? (Are we there yet?) – How to answer this question is still a research question 1. One view: testing is never done… the burden simply shifts from the developer to the customer 2. Or: testing is done when you run out of time or money 3. Or use a statistical model: - Assume that errors decay logarithmically with testing time - Measure the number of errors in a unit period - Fit these measurements to a logarithmic curve - Can then say: “with our experimentally valid statistical model we have done sufficient testing to say that with 95% confidence the probability of 1000 CPU hours of failure free operation is at least 0.995”

The University of Sydney Page 12 Strategic Issues – Issues for a successful software testing strategy: - Specify product requirements long before testing commences For example: portability, maintainability, usability Do so in a manner that is unambiguous and quantifiable - Understand the users of the software, with use cases - Develop a testing plan that emphasizes “rapid cycle testing” Get quick feedback from a series of small incremental tests - Build robust software that is designed to test itself Use assertions, exception handling and automated testing tools (Junit). - Conduct formal technical reviews to assess test strategy and test cases - “Who watches the watchers?”

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 13 Testing OO Code Class tests Integration tests Validation tests System tests

The University of Sydney Page 14 Class (Unit) Testing – Smallest testable unit is the encapsulated class – Test each operation as part of a class hierarchy because its class hierarchy defines its context of use – Approach: - Test each method (and constructor) within a class - Test the state behavior (attributes) of the class between methods – How is class testing different from conventional testing? – Conventional testing focuses on input-process-output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class – But white-box testing can still be applied

The University of Sydney Page 15 Class Testing Process class to be tested test cases results software engineer How to test? Why a loop?

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 16 Class Test Case Design 1. Identify each test case uniquely - Associate test case explicitly with the class and/or method to be tested 2. State the purpose of the test 3. Each test case should contain: a. A list of messages and operations that will be exercised as a consequence of the test b. A list of exceptions that may occur as the object is tested c. A list of external conditions for setup (i.e., changes in the environment external to the software that must exist in order to properly conduct the test) d. Supplementary information that will aid in understanding or implementing the test - Automated unit testing tools facilitate these requirements

The University of Sydney Page 17 Challenges of Class Testing – Encapsulation: - Difficult to obtain a snapshot of a class without building extra methods which display the classes’ state – Inheritance and polymorphism: - Each new context of use (subclass) requires re-testing because a method may be implemented differently (polymorphism). - Other unaltered methods within the subclass may use the redefined method and need to be tested – White box tests: - Basis path, condition, data flow and loop tests can all apply to individual methods, but don’t test interactions between methods

The University of Sydney Page 18 Random Class Testing 1. Identify methods applicable to a class 2. Define constraints on their use – e.g. the class must always be initialized first 3. Identify a minimum test sequence – an operation sequence that defines the minimum life history of the class 4. Generate a variety of random (but valid) test sequences – this exercises more complex class instance life histories – Example: 1. An account class in a banking application has open , setup , deposit , withdraw , balance , summarize and close methods 2. The account must be opened first and closed on completion 3. Open – setup – deposit – withdraw – close 4. Open – setup – deposit –* [deposit | withdraw | balance | summarize] – withdraw – close . Generate random test sequences using this template

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 19 Integration Testing – OO does not have a hierarchical control structure so conventional top-down and bottom-up integration tests have little meaning – Integration applied three different incremental strategies: - Thread-based testing: integrates classes required to respond to one input or event - Use-based testing: integrates classes required by one use case - Cluster testing: integrates classes required to demonstrate one collaboration • What integration testing strategies will you use?

The University of Sydney Page 20 Random Integration Testing – Multiple Class Random Testing 1. For each client class, use the list of class methods to generate a series of random test sequences. Methods will send messages to other server classes. 2. For each message that is generated, determine the collaborating class and the corresponding method in the server object. 3. For each method in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits 4. For each of the messages, determine the next level of methods that are invoked and incorporate these into the test sequence

The University of Sydney Page 21 Validation Testing – Are we building the right product? – Validation succeeds when software functions in a manner that can be reasonably expected by the customer. – Focus on user-visible actions and user-recognizable outputs – Details of class connections disappear at this level – Apply: - Use-case scenarios from the software requirements spec - Black-box testing to create a deficiency list - Acceptance tests through alpha (at developer’s site) and beta (at customer’s site) testing with actual customers – How will you validate your term product?

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 22 System Testing – Software may be part of a larger system. This often leads to “finger pointing” by other system dev teams – Finger pointing defence: 1. Design error-handling paths that test external information 2. Conduct a series of tests that simulate bad data 3. Record the results of tests to use as evidence – Types of System Testing: - Recovery testing: how well and quickly does the system recover from faults - Security testing: verify that protection mechanisms built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters) - Stress testing: place abnormal load on the system - Performance testing: investigate the run-time performance within the context of an integrated system

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

The University of Sydney Page 23 Testing Summary – Testing affects all stages of software engineering cycle – One strategy is a bottom-up approach – class, integration, validation and system level testing – XP advocates test-driven development: plan tests before you write any code, then test any changes – Other techniques: - white box (look into technical internal details) - black box (view the external behaviour) - debugging (systematic cause elimination approach is best)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version