Das neue Konzept für Last- und Performancetestsdaniel.cqit.de/Publikationen_files/20111019 Das neue...

SQS Software Quality Systems AG

Dr. Daniel Simon, SQS Research

19. Oktober 2011, Wolfsburg

Das neue Konzept für Last-

und Performancetests

Agenda

© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 2

Über SQS und SQS Research

Traditionelle Last und Performance Tests

Aufwandsbetrachtung und typische Ausgangslage

Test vs. Analyse

Alternative/additive Methoden – Performance Analysen

Model Based Performance Analysis

Architecture Tradeoff Analysis Method (ATAM) für Performance Risiken

Statische Analysen des Quellcodes

Zusammenführung der Methoden

Auf einen Blick: SQS ist der führende unabhängige

Anbieter von QM- und Test-Dienstleistungen.

Die SQS-Gruppe

3

Fast 30 Jahre erfolgreiche Beratungs-aktivität

Über 5.000 abgeschlossene Projekte

Zur starken Kundenbasis gehören 20 FTSE-100-Unternehmen, die Hälfte der DAX-30-Unternehmen und nahezu ein Drittel der STOXX-50-Unternehmen

Die SQS-Philosophie ist es, den Erfolg und die Effizienz von IT-Projekten zu erhöhen durch effiziente Lösungen

SQS ist am AIM in London gelistet

»

«

Der weltweit führende unabhängige

Anbieter von Test- und Qualitäts-

management-Dienstleistungen –

mit überwiegendem Teil seiner

Geschäftsaktivitäten in Europa

Financial Times, 21 August 2007

© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 |

163134143

121

795549

1.9001)

1.450

430 468733

1.012

1.450

Die Zahlen sprechen für sich: SQS befindet sich

auf einem soliden Wachstumskurs.

Die SQS-Gruppe

4

Mitarbeiter

Umsatz-

erlöse

in € Mio.

1) Stand Januar 2011, davon ca. 600 offshore

2004 2005 2006 2007 2008 2009 2010


Überall da, wo unsere Kunden sind.

SQS ist international vertreten

5

Standorte

Ägypten

Deutschland

Finnland

Großbritannien

Indien

Irland

Niederlande

Norwegen

Österreich

„Folge den Kunden“ ist unser Motto

für Offshore arbeiten wir an einer „Multi-language Customer-related Sourcing“ (MLCS) Strategie

Südafrika

Ägypten

Indien

USA

Portugal

Schweden

Schweiz

Südafrika

USA

Partnerschaft

Spanien


Das SQS-Serviceportfolio umfasst alle Bereiche des

Software-Qualitätsmanagements und -Testens.

Was wir für Sie tun

6

Quality Assurance & Testing

Quality Management

Business & Strategic Consulting

Process Improvement

Training & Conferences

Supporting Services

Tools & Tool-related Services

Technologies

Industries

Quality


Mission statement and benefits

SQS Research entwickelt die SQS Assets und

demonstriert unsere inhaltliche Vorreiterrolle

durch

Förderung innovativer Ideen der SQS Berater

Bewertung der Auswirkungen der Innovationen auf das Q-Business

Verbesserung und Entwicklung spezifischer SQS Assets

Vorstellung der SQS-Fähigkeiten am Markt

Ziele der SQS

Weiterentwicklung des Service Portfolio

Schärfung der Marktwahrnehmung als Vorreiter und Marktführer

Wissensaustausch innerhalb und außerhalb

Mitgestaltung in Forschung-Netzwerken

SQS Research & Development


Wie die Aufwände verteilt werden: reales anonymisiertes

Projekt

Aufwand für Last und Performance Tests

Projectmanagmement

Analysis Design Coding & Unit Testing IT-QS (Bugfixing) Test

Project X 21,90% 2,20% 1,10% 18,40% 24,50% 31,90%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

Effo

rt (

%)

Aufwandsverteilung je Projektphase


Projectmanagmement

Analysis DesignCoding & Unit

TestingIT-QS (Bugfixing) Test

Project X 21,90% 2,20% 1,10% 18,40% 24,50% 31,90%

SQS Best Practices 20,00% 15,00% 10,00% 20,00% 15,00% 20,00%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

Effo

rt (

%)

Aufwandsvergleich: Projekt X vs. Best Practices

… und wie es sein sollte.

Aufwand für Last und Performance Tests


Traditionelles Last und Performance Testen

Typische Infrastruktur für einen End-to-End Performancetest

Database

MVS

Host

De-/ En-

coding

Applikation-

Server-Farm

Proxy Last

rechner

Firewall Firewall

Web-

Server-

Farm

Database-

Server

Load

Balancer

Load

Balancer

Last

rechner

Last

rechner

www

Typische Performance-Anforderungen

100.000 Transaktionen müssen pro Stunde

bearbeitet werden

90% der Anfragen sollen weniger als 3

Sekunden dauern

Die CPU Auslastung darf max. 80% sein

© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 10 = Messpunkt

Risiko: Performance Probleme werden zu spät im

Projektlebenszyklus erkannt.


startet auf der System- und Systemintegration Stufe



Reqs

Definition

Functional

Design

Technical

Design

Component

Spec

Implementation

Component

Test

Integration

Test

System

Test

Acceptance

Test

Performance Analyse als zusätzliche Methode für Last und

Performance Tests

Die Performance-Analyse (engl. analysis) wird in einer frühen Phase des Softwareentwicklungs-prozesses durchgeführt, wohingegen das Testen, bzw. die Messung (engl. measurement) der Performance in einer späteren Phase stattfindet. [Balsamo et al.]

Performance Analyse

Reqs

Definition

Functional

Design

Technical

Design

Component

Spec

Implementation

Component

Test

Integration

Test

System

Test

Acceptance

Test


Performance Analyse vs. Performance Testing

Im Vergleich

Projectmanagmement

Analysis DesignCoding & Unit

TestingIT-QS (Bugfixing) Test

Project X 21,90% 2,20% 1,10% 18,40% 24,50% 31,90%

Best Practices 20,00% 15,00% 10,00% 20,00% 15,00% 20,00%

0,00%

5,00%

10,00%

15,00%

20,00%

25,00%

30,00%

35,00%

Effo

rt (

%)

Effort Comparison : Project X vs. Best Practices Performance Analyse ist die Begutachtung oder Abschätzung der Performance,

und kann bereits in frühen Phasen des Entwicklungsprozesses durchgeführt werden.

Performance Testing bezeichnet die Messung der Performance nach der Erstellung der Software/des Systems.

Performance Analysis

Performance Testing


+

Drei Methoden/Möglichkeiten für die Qualitätssicherung in

den frühen Phasen des SDLC.

Performance Analyse


Reqs

Definition

Functional

Design

Technical

Design

Component

Spec

Implementation

Component

Test

Integration

Test

System

Test

Acceptance

Test

ATAM

MBPA

Statische Code Analyse

Die Model Based Performance Analyse baut auf bereits

bekannten Spezifikationstechniken auf.

Bereits im Einsatz: Unterschiedliche Techniken zur Modellierung und Spezifikation des dynamischen Verhaltens von Softwaresystemen

Automatentheorie (AT)

Petri-Netze (PN)

Prozess-Algebra (PA)

Message Sequence Charts (MSC)

Unified Modelling Language (UML)

…


Additive Methode: Model Based Performance Analyse

Etablierte

Spezifikation UML

PA MSC PN

AT

…

Zusätzlich werden erweiterte Methoden und Schätzverfahren

für eine Simulation eingebracht.

Verschiedene Ansätze, um bekannte Spezifikations- und Modellierungs-Techniken zu kombinieren, um Performance-Kennzahlen zu ermitteln.

Bekannte Verfahren:

Software Performance Engineering (SPE)

Performance Evaluation Process Algebra (PEPA)

Prima-UML

Performance From Unified Model Analysis (PUMA)

Palladio Component Model (PCM)

…



Etablierte

Spezifikation UML

PA MSC PN

AT

…

Stochastische

und Quantitative Erweiterung

Prima-UML

PEPA PCM

SPE

…

+

Simulation

+

Vorgehensweise zur Ermittlung des Lastmodells


Input Performance Analyse Ergebnis

Informationen über:

Geschäftsprozesse

Testumgebung

Anforderungen

Expertisen zum Testvorgehen

Erfahrungswerte aus vergangenen Projekten

Teststrategie

Kunde

Testszenarien GP-Bewertungsmatrix

Rechenmodell zur Lastverteilung

GP-Modell Systemübersicht


Performance

Vorhersage

Vorgehensweise für eine simulationsunterstützte

Performance-Analyse

Entwurf des Modells

Iterative Verfeinerung anhand von Lasttestergebnissen und Auswertungen der Produktionsmessungen

Worst-Case Szenarios aus der Produktion werden ermittelt

Gemessenene Back-End Antwortzeiten wurden in das Model übernommen

End-to-End Antwortzeiten für das Modell schätzen

Durchführung von verschiedenen Simulationsreihen

Auswertung der Ergebnissen


Modellentwurf

Analyse von

Produktionslogs

Durchführung von

Lasttests

Optimierung

des Modells

Validierung durch

einzelne Simulationen

Ist das Modell

konsistent?

Nein

Definition und

Durchführung einer

Simulationsreihe

Ja

Beurteilung


Bisherige Erfahrungen

Ergebnisse zeigen, dass entworfene Performance-Modelle aussagefähig und für die Durchführung von Analysen geeignet sind

Während des Entwicklungsprozesses können Simulationsreihen wiederholt werden, um bei Designänderungen und Iterationen Impact-Analysen durchzuführen

Simulationsergebnisse können für die Selektion der Szenarien für spätere Tests verwendet werden, um den Aufwand für unnötige Testläufe zu vermeiden

Die Vorgehensweise für die Erstellung des Modells, der Adjustierung und der Auswertung können auch für komponenten-basierte Applikationen angewandt werden

Einschränkungen

Hardware-Verhalten bzgl. Swapping, Nebenläufigkeit, Exceptions

Notwendigkeit von im Vorfeld explizierter fachliche oder technischen Performance-Anforderungen

Abschätzungsverfahren anstelle eines Messverfahrens



Ganzheitliche Betrachtung der technischen und fachlichen

Anforderungen im Zusammenspiel mit der Architektur

Additive Methode: ATAM

Component A

Component B

Component C

Component D

Co

mp

on

en

tE

Markt-

anforderungen

Leistungen zur

Erfüllung der Anforderungen

Spezifisches System

zur Unterstützung der Leistung

Szenarien

Ve

rifikatio

n (P

QA

)

==

Evaluierung (ATAM)

Umsetzung

Geschäftsstrategie

SEI


Risiken identifizieren auf Grundlage von Szenarien und

Architekturen.

Evaluierung von Beziehungen zwischen der Geschäftsstrategie und den

architektonischen Entscheidungen

Ziel: Bewertung der Konsequenzen aus den architektonischen Entscheidungen im Hinblick auf die Qualitätsattribute basierend auf der Geschäftsstrategie

Primär ein Risikoidentifikations-Mechanismus


verdichtet

zu

bee

infl

us

st

Geschäfts-

Ziele

Geschäfts-

ZieleQualitäts-

Attribute

Qualitäts-

Attribute SzenarienSzenarien

Software

Architektur

Software

ArchitekturArchitektur-

Ansätze

Architektur-

AnsätzeArchitektur-

Entscheidung

Architektur-

Entscheidung

Maßnahmen

und Planung

Maßnahmen

und Planung

ATAM

Analyse

ATAM

Analyse

Sensitivity PointsSensitivity Points

TradeoffsTradeoffs

Non-RisksNon-Risks

RisksRisks

verdichtet

zu

bee

infl

us

st

Geschäfts-

Ziele

Geschäfts-

ZieleQualitäts-

Attribute

Qualitäts-

Attribute SzenarienSzenarien

Software

Architektur

Software

ArchitekturArchitektur-

Ansätze

Architektur-

AnsätzeArchitektur-

Entscheidung

Architektur-

Entscheidung

Maßnahmen

und Planung

Maßnahmen

und Planung

ATAM

Analyse

ATAM

Analyse


TradeoffsTradeoffs

Non-RisksNon-Risks

RisksRisks


TradeoffsTradeoffs

Non-RisksNon-Risks

RisksRisks


Die Erfassung der Qualitätsziele ist ganzheitlich und

betrachtet auch Performance.

Quality Attribute Utillity Tree



Umfassende Betrachtung aller Stakeholder: Wer hat

Interesse an dem System?


Kunde

Endanwender

Administrator

Wartungspersonal

Betrieb

(externe) Prüfer

Architekten

Entwickler Tester

Marketing

Manager

Fachseite

Projektleitung

…


Welche Use-Cases kommen auf das System zu?

ATAM betrachtet drei unterschiedliche Szenariotypen:

Use-Case-Szenarien

beschreiben eine vom Stakeholder ausgelöste Interaktion auf dem vollständigen laufenden System.

Entwicklungsszenarien

repräsentieren typische in der Zukunft zu erwartende Änderungen am System

Explorative Szenarien

reizen die Architektur aus und sollen Stress im System verursachen. Das Ziel dieser Szenarien ist die Einschränkungen und Grenzbedingungen und mögliche implizite Ausnahmen aufzudecken.



Systematische Erfassung der Szenarien

Erfassung der Szenarien durch Interviews mit Stakeholdern

Klassifizierung der Szenarienparameter durch SQS


Quelle:

Wer muss

etwas tun?

Artefakt:

Was ist

betroffen?

Umgebung: Wo muss es getan

werden? Reaktions-

prüfung: Wie kann die

Reaktion

geprüft oder

gemessen

werden?

Stimulus: Was muss

getan werden?

Reaktion: Was wird vom System

erwartet?


Beispiel-Szenario aus Sicht der Performance

Ein Anwender muss 1.000 Transaktionen pro Minute im normalen Betrieb initialisieren. Die Transaktionen müssen durchschnittlich innerhalb von 2 Sekunden abgeschlossen sein.


Reaktions-

prüfung: im

Durchschnitt

innerhalb von

2 Sekunden

Stimulus: Initiale

Transaktionen

Reaktion: Transaktionen werden

ausgeführt

Quelle: Anwender

Artefakt:

System

Umgebung: im Normalbetrieb


„Analyse der Architektur“ mit Hilfe von Szenarien und

Architekturentscheidungen


Tradeoffs Non-Risks Risks Sensitivity Points


Statische Code-Analyse zur Identifikation von Performance

Risiken

Additive Methode: Statische Code Analyse

SQS-

Repository

(DB) Bestimmung der

Q-Indikatoren

Industrie-

projekte

> 200

25%

25%

25%

25%

Verletzungen

pro Q-Indikator

Maximum

Minimum

Benchmark

Industriestandard

schlechter als

Industriestandard

besser als

Industriestandard

Projekt X

Stand der Technik/

Industriestandard

schlechter

besser

Expertise


Definition von Qualitätseigenschaften

Detaillierung des Qualitätsbegriffs in mehrere Qualitätseigenschaften

der ISO 9126


Effizienz

Änder-

barkeit

Übertrag-

barkeit

Analysier-

barkeit

Qualität

Verbrauchs-

verhalten

Zeit-

verhalten

Modifizier-

barkeit

Stabilität

Prüfbarkeit

Austausch-

barkeit

Qualitätseigen-

schaften der

ISO 9126


Definition von Qualitätsmetriken

Qualitätsmetriken erheben Kennzahlen über den Quellcode

Dazu werden bestimmte Qualitätsmerkmale des Codes ausgewertet

Diese Auswertung findet durch statische Analysewerkzeuge statt (CAST, Bauhaus, Sotograph, PC Lint, Checkstyle etc.)


Quell-

code

Q-Metrik

Q-Metrik

Q-Metrik

Q-

Merkmal

Q-

Merkmal

Q-

Merkmal

String

Operationen

URL

Verwendung

Source

Source

Beispiel:


Beispielindikator „Risikocode“

Nutzung eines bidirektionalen Qualitätsmodell


Effizienz

Änder-

barkeit

Übertrag-

barkeit

Analysier-

barkeit

Qualität

Verbrauchs-

verhalten

String

Operationen

URL

Verwendung

Source

Source

Zeit-

verhalten

Modifizier-

barkeit

Stabilität

Prüfbarkeit

Austausch-

barkeit

Risikocode

Q-Eigenschaft

Analysierbarkeit

Austauschbarkeit

Modifizierbarkeit

Prüfbarkeit

Stabilität

Verbrauch

Zeitverhalten

Einfluss Loglevel insensitives Logging

0 25 50 75 100

Risikocode


Wie gut sind andere? – Nutzung des SQS Repository

Die SQS verfügt über eine Datenbank, die die Ergebnisse von anonym gespeicherten Industriesystemen enthält

Ein System kann gegen diese Datenbank bewertet werden


Risikocode

Quell-

code

Effizienz

Änder-

barkeit

Übertrag-

barkeit

Analysier-

barkeit

Qualität

Verbrauchs-

verhalten

Zeit-

verhalten

Modifizier-

barkeit

Stabilität

Prüfbarkeit

Austausch-

barkeit

SQS

Repository

Risikocde

String

Operationen

URL

Verwendung

Source

Source


Fokussierung des Qualitätsmodells auf Performance-

Indikatoren

Das allgemeine Qualitätsmodell für Code lässt sich mit Performance spezifischen Indikatoren ergänzen


Allgemeine

Indikatoren

Performance

Indikatoren …


Indikator Ineffiziente Stringkonkatenation mit + in Schleifen

Beschreibung (Risiko)

Aufbau eines Strings innerhalb von Schleifen mit + Operator erzeugt temporäre Objekte wachsender Größe

FindBugs Doku: „This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.“

Implementierung/Metriken

Konkatenation von Strings in Schleifen mittels + Operator statt mit StringBuffer (synchronized) oder StringBuilder (nicht synchronized)


Q-Eigenschaft

Analysierbarkeit

Austauschbarkeit

Modifizierbarkeit

Prüfbarkeit

Stabilität

Verbrauch

Zeitverhalten

Einfluss Ineffiziente Stringkonkatenation mit + in Schleifen

0 25 50 75 100


Indikator Loglevel insensitives Logging

Beschreibung (Risiko)

Der Zusammenbau komplexer, aber irrelevanter Logmeldungen kostet unnötigen Aufwand und kann signifikante Performanceeinbußen verursachen

Implementierung/Metriken

Aufbau und Absetzen von debug/trace-Logmeldungen über einen Logger ohne vorhergehende Prüfung, ob im gerade aktiven Loglevel debug-/trace-Meldungen überhaupt relevant sind


Log4j manual,

chapter „Performance“

(http://logging.apache.org/

log4j/1.2/manual.html )

Q-Eigenschaft

Analysierbarkeit

Austauschbarkeit

Modifizierbarkeit

Prüfbarkeit

Stabilität

Verbrauch

Zeitverhalten

Einfluss Loglevel insensitives Logging

0 25 50 75 100


Beispiel Ergebnisse: Überblick statische Analyse

Übersicht: Bewertung der codebasierten Performanceindikatoren

(statisch sichtbares Risikopotential)

Sourcecodes des Projekts


Risikopotentiale bzgl. Verbrauchsverhalten

5

1 10

5

20

0

4

2

1 3

0

3

6

9

12

15

gering mittel hoch sehr hoch

Impact

An

zah

l In

dik

ato

ren

Risikopotentiale bzgl. Zeitverhalten

4

1

4

0

4

2

0

0

4

2 1

4

0

3

6

9

12

15


Impact

An

zah

l In

dik

ato

ren

(ohne Impact : 5

Indikatoren)

(ohne Impact: 3

Indikatoren)

Farblegende: überdurchschnittliches / durchschnittliches / unterdurchschnittliches Risikopotential


Beispiel Ergebnisse: Überblick statische Analyse

Übersicht: Bewertung der codebasierten Performanceindikatoren

(statisch sichtbares Risikopotential)

auch für 3rd party Klassen (dort nicht für alle Indikatoren möglich, da z.T. kein Quellcode vorliegt)


Risikopotentiale bzgl. Verbrauchsverhalten

2 10 0

3

0 10

3

1 12

0

3

6

9

12

15


Impact

An

zah

l In

dik

ato

ren

Risikopotentiale bzgl. Zeitverhalten

2 1 0 0

2

0 3

0

2

1

1

20

3

6

9

12

15


Impact

An

zah

l In

dik

ato

ren

(ohne Impact : 2 Indikatoren) (ohne Impact : 2 Indikatoren)

Farblegende: überdurchschnittliches / durchschnittliches / unterdurchschnittliches Risikopotential


Zusammenführung der Methoden

Modell-, Architektur-, Code Analyse zur Risikoermittlung

Ableitung von Annahmen über auftretende Last und Systemverhalten

Ableitung von Testszenarien für den traditionellen L&P Test

Monitoring und Messungen über Teilstrecken im Systembetrieb

Nutzung der Erkenntnisse für die Festlegung der Messpunkte und Lastszenarien

Zusammenführung

ATAM-Analyse MB Performance

Analyse

Performance Test

& Monitoring

Risiken+

Messaufträge

Statische Code

Analyse


Last und Performance Analyse profitieren von agilen

Entwicklungsmethoden.

Zusammenführung

© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 45 http://dev2ops.org/blog/2010/2/22/what-is-devops.html

Test

Test

Test

Last und Performance Test agilisieren

User Story Performance Analyse:

Anhand der Architektur und des Codes sollen Performance Risiken identifiziert werden

Begleitender Architekt ist Co-Produkt-Owner

Methodenkoffer

Performance Risiko identifizieren als Sprint Task

Model Based Performance Analyse iterativ inkrementell

ATAM iterativ inkrementell

Code Analyse bzgl. Performance Risiken stark automatisierbar

Identifizierte Risiken werden in das Risikomanagement für traditionelles L&P am Releasepunkt integriert

Zusammenführung


Zusammenfassung

Performance Testing

ist üblicherweise kostenintensiv und spät im Entwicklungszyklus einsetzbar

sollte gesteuert werden von Ergebnissen der Performance Analyse

Performance Analyse

ergänzt und liefert Input für Performance Testing

identifiziert Performance Risiken

lässt sich in früheren Entwicklungsphasen einsetzen

lässt sich mit traditionellem Performance Testing verbinden

Einsatz in agilen Projekten

können iterativ und inkrementell auch im agilen Prozess eingesetzt werden

Iterationen ermöglichen sukzessive Verbesserung der Performance Analysen

Performance Testen auf erkannte HotSpots reduziert

Agile Konzepte unterstützen die vorgeschlagenen Ideen

Konzept Last und Performance Tests


… one more thing …

http://www.sqs-blog.com/de/author/dr-frank-simon/

http://www.qrm-framework.de/

IQNITE DE: http://www.iqnite-conferences.com/de/

Kontakt: [email protected]

Referenzen














http://www.iqnite-conferences.com/de/



mailto:[email protected]

Thank you for your attention

SQS Software Quality Systems AG

Stollwerckstraße 11 | 51149 Cologne, Germany

Phone: +49 22 03 91 54-0 | Fax: +49 22 03 91 54-15

E-Mail: [email protected]

Internet: www.sqs.com

Das neue Konzept für Last- und Performancetestsdaniel.cqit.de/Publikationen_files/20111019 Das neue...

Documents

Transcript of Das neue Konzept für Last- und Performancetestsdaniel.cqit.de/Publikationen_files/20111019 Das neue...