0% found this document useful (0 votes)
27 views

03 Uml Testing

The document discusses UML diagrams and software testing. It describes different types of UML diagrams like class, sequence, state, and activity diagrams. It also covers different levels of testing like unit testing, component testing, and system testing.

Uploaded by

Daniel Bdkmv
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
27 views

03 Uml Testing

The document discusses UML diagrams and software testing. It describes different types of UML diagrams like class, sequence, state, and activity diagrams. It also covers different levels of testing like unit testing, component testing, and system testing.

Uploaded by

Daniel Bdkmv
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

Software Engineering

Lecture 03 – UML & Testing


© 2015-20 Dr. Florian Echtler
Bauhaus-Universität Weimar
<[email protected]>

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
UML & Testing

UML/Modelling (Recap)

(Unit) Testing

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 2


UML/Modelling (Recap)

UML: Unified Modelling Language

Used for visualization of system design

ISO standard since 2000 (currently v2.5)

Multiple diagram types (14!)
– Structure diagrams
– Behaviour diagrams

(Sometimes) used to auto-generate code

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 3


UML Diagram Types

Tools
– Violet: http://alexdp.free.fr/violetumleditor/
– UMLet: http://www.umlet.com/
– ArgoUML: http://argouml.tigris.org/

5 most common diagram types [ES2007]:
– Structure: Class
– Behaviour: Sequence, Use case, State, Activity

Common to all diagram types: comments

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 4


Class Diagram (1)

Show properties of classes
– Methods, attributes, visibility, scope
generics
parameter(s)

b: Boolean + = public
class name Window
# = protected
+ size: Area - = private
# visibility: Boolean = b
attributes - window: Pointer
+ display() italic = abstract
methods + show() underline = static
+ hide()

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 5


Class Diagram (2)
Image source (CC): https://en.wikipedia.org/wiki/Class_diagram


Show relations between classes
– Inheritance, implementation, …

Inheritance (“is a”) superclass


MoneyStorage

subclass

BankAccount Wallet

Interface (“implements”)
<<interface>>
Wallet Owner
implementation IWallet usage

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 6


Class Diagram (3)
Image source (CC): https://en.wikipedia.org/wiki/Class_diagram


Shows relations between classes:
Composition, Associations, Multiplicity, …
Composition (“contains”, Aggregation (“has”,
is destroyed with container) can exist separately)
Car Motor Pond Duck
1 1...2 1 0...*

“1 Car contains 1-2 Motors” “1 Pond has arbitrary # of Ducks”

NonProfit Donor
* *
“Every Donor gives to arbitrary # of
NonProfits, each NonProfit has
Donation arbitrary # of Donors, and each
Amount:money Donation has an individual Amount.”
20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 7
Use Case Diagram
Image source (CC): https://en.wikipedia.org/wiki/Use_Case_Diagram


Contains actors and actions

Useful for communication
with customers

Mimics real world

Less focus on system
internals

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 8


Sequence Diagram
Image source (CC): https://en.wikipedia.org/wiki/Sequence_diagram


Shows objects, lifelines and messages

Illustrates …
– runtime behavior
– object lifetimes
– (a)synchronous calls

download

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 9


State Diagram
Image source (CC): https://commons.wikimedia.org/wiki/File:UML_State_diagram.svg


Contains states and transistions

Transitions represent external events

Start transition shows initial state
[Start]

[Pause]
Simulator stopped Simulator running Simulator paused
[Continue]
[Request log]
[Stop]

Retrieve log data


[Continue]

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 10


Activity Diagram
Image source (CC): https://en.wikipedia.org/wiki/Activity_diagram


Shows actions, decisions
and concurrency (black
bars)

Similar to flowchart

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 11


UML best practices

Use for communication/documentation

Try to keep diagrams small

Code generation can be helpful …

… but usually only for “boilerplate” code (class structure etc.)

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 12


UML: alternatives?

If UML not strictly required: consider simpler “box-and-line”
diagrams

Most whiteboard sketches
fall into this category :-)

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 13


Testing

Abstract: process test cases, check results

However: tests can only show presence of errors, not absence.

Outputs revealing
presence of defects
Ie Oe

Input Output
Inputs causing test test
anomalous cases System results
behaviour

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 14


Testing (2)

Validation testing
– Show that software meets requirements
– Test cases modelled after typical use cases

Defect testing
– Obvious goal: find bugs/errors/design flaws!
– Test cases contain atypical/erroneous data

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 15


Testing (3)

Testing is possible at many levels/stages

Development testing
– unit testing
– component testing
– system testing

Release testing

Performance testing

User testing

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 16


Development Testing

Performed iteratively during development

Mostly performed by developers themselves (“white-box
testing”)

Independent test developers also possible (“black-box testing”)

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 17


Unit Testing

Core idea: test each unit of source code individually, e.g. each
class

Goal: test all methods, attributes, states

Often requires mock objects/test harnesses to simulate missing
system components

Testing all states may require internal knowledge of the class –
problem with black box testing

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 18


Component/System Testing

Test building blocks consisting of multiple units/classes
(or sub-blocks), also called integration tests

Focus on interface between sub-units “mystery booleans”

Possible types of interface error:
– Interface misuse, e.g. parameters in wrong order
– Interface misunderstanding – incorrect assumptions about
behaviour of callee, e.g. passing unsorted array to binary search
– Timing errors – components operate at different speeds → out-of- out-of-
date information is accessed

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 19


“2 Unit Tests, 0 Integration Tests”
Image source (FU): https://www.reddit.com/r/ProgrammerHumor

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 21


Testing automation

Tests should (usually) be automated

e.g. run tests directly after RCS commit

Test frameworks provide structural support

3 phases:
– Setup – initialize object/environment
– Call – execute method
– Assertion – check results

Often grouped in test suites

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 22


Testing: best practices

Use a test framework (JUnit, CPPUnit, …)

Automate your tests scripts executed after
RCS operations

Combine with RCS
– Commit/push hooks to trigger tests
– Bisection to find errors in large changesets

Use “extreme” test cases, e.g. NULL, NaN, -0, INT_MAX,
empty set, …

If at all possible: write tests first!

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 23


Testing: best practices (2)

Bisection: binary search in revision history
– Identify initial “good” and “bad” commit
– Test the one halfway between good and bad
– Repeat until only one commit left

Works best with small commits

Example: 4th test identifies commit with error
revision
history
+ -
Test passes Test fails
1. 3. 4. 2.
+ + - -
20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 24
General best practices: Teamwork

Follow the coding style guide
– Use a tool like indent

Use team tools
– RCS
– Issue tracker
– Discussion forums

Never, ever send code by e-mail.

Never, ever share code via remote folders.

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 25


Questions/suggestions?

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 26

You might also like