Das neue Konzept für Last- und Performancetestsdaniel.cqit.de/Publikationen_files/20111019 Das neue...
Transcript of 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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 |
Ü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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 |
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 |
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 7
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 8
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 9
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.
Traditionelles Last und Performance Testen
startet auf der System- und Systemintegration Stufe
Traditionelles Last und Performance Testen
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 11
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 12
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 13
+
Drei Methoden/Möglichkeiten für die Qualitätssicherung in
den frühen Phasen des SDLC.
Performance Analyse
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 14
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)
…
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 15
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)
…
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 16
Additive Methode: Model Based Performance Analyse
Etablierte
Spezifikation UML
PA MSC PN
AT
…
Stochastische
und Quantitative Erweiterung
Prima-UML
PEPA PCM
SPE
…
+
Simulation
+
Vorgehensweise zur Ermittlung des Lastmodells
Additive Methode: Model Based Performance Analyse
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 17
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
Additive Methode: Model Based Performance Analyse
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 18
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
Additive Methode: Model Based Performance Analyse
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 20
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 21
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
Additive Methode: ATAM
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
Sensitivity PointsSensitivity Points
TradeoffsTradeoffs
Non-RisksNon-Risks
RisksRisks
Sensitivity PointsSensitivity Points
TradeoffsTradeoffs
Non-RisksNon-Risks
RisksRisks
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 22
Die Erfassung der Qualitätsziele ist ganzheitlich und
betrachtet auch Performance.
Quality Attribute Utillity Tree
Additive Methode: ATAM
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 23
Umfassende Betrachtung aller Stakeholder: Wer hat
Interesse an dem System?
Additive Methode: ATAM
Kunde
Endanwender
Administrator
Wartungspersonal
Betrieb
(externe) Prüfer
Architekten
Entwickler Tester
Marketing
Manager
Fachseite
Projektleitung
…
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 24
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.
Additive Methode: ATAM
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 25
Systematische Erfassung der Szenarien
Erfassung der Szenarien durch Interviews mit Stakeholdern
Klassifizierung der Szenarienparameter durch SQS
Additive Methode: ATAM
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?
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 26
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.
Additive Methode: ATAM
Reaktions-
prüfung: im
Durchschnitt
innerhalb von
2 Sekunden
Stimulus: Initiale
Transaktionen
Reaktion: Transaktionen werden
ausgeführt
Quelle: Anwender
Artefakt:
System
Umgebung: im Normalbetrieb
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 27
„Analyse der Architektur“ mit Hilfe von Szenarien und
Architekturentscheidungen
Additive Methode: ATAM
Tradeoffs Non-Risks Risks Sensitivity Points
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 28
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 33
Definition von Qualitätseigenschaften
Detaillierung des Qualitätsbegriffs in mehrere Qualitätseigenschaften
der ISO 9126
Additive Methode: Statische Code Analyse
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 34
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.)
Additive Methode: Statische Code Analyse
Quell-
code
Q-Metrik
Q-Metrik
Q-Metrik
Q-
Merkmal
Q-
Merkmal
Q-
Merkmal
String
Operationen
URL
Verwendung
Source
Source
Beispiel:
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 35
Beispielindikator „Risikocode“
Nutzung eines bidirektionalen Qualitätsmodell
Additive Methode: Statische Code Analyse
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 36
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
Additive Methode: Statische Code Analyse
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 37
Fokussierung des Qualitätsmodells auf Performance-
Indikatoren
Das allgemeine Qualitätsmodell für Code lässt sich mit Performance spezifischen Indikatoren ergänzen
Additive Methode: Statische Code Analyse
Allgemeine
Indikatoren
Performance
Indikatoren …
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 38
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)
Additive Methode: Statische Code Analyse
Q-Eigenschaft
Analysierbarkeit
Austauschbarkeit
Modifizierbarkeit
Prüfbarkeit
Stabilität
Verbrauch
Zeitverhalten
Einfluss Ineffiziente Stringkonkatenation mit + in Schleifen
0 25 50 75 100
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 39
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
Additive Methode: Statische Code Analyse
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 40
Beispiel Ergebnisse: Überblick statische Analyse
Übersicht: Bewertung der codebasierten Performanceindikatoren
(statisch sichtbares Risikopotential)
Sourcecodes des Projekts
Additive Methode: Statische Code Analyse
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
gering mittel hoch sehr hoch
Impact
An
zah
l In
dik
ato
ren
(ohne Impact : 5
Indikatoren)
(ohne Impact: 3
Indikatoren)
Farblegende: überdurchschnittliches / durchschnittliches / unterdurchschnittliches Risikopotential
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 42
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)
Additive Methode: Statische Code Analyse
Risikopotentiale bzgl. Verbrauchsverhalten
2 10 0
3
0 10
3
1 12
0
3
6
9
12
15
gering mittel hoch sehr hoch
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
gering mittel hoch sehr hoch
Impact
An
zah
l In
dik
ato
ren
(ohne Impact : 2 Indikatoren) (ohne Impact : 2 Indikatoren)
Farblegende: überdurchschnittliches / durchschnittliches / unterdurchschnittliches Risikopotential
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 43
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 44
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 46
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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 47
… 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
© SQS Software Quality Systems AG | Konzept LuP Analyse | Oktober 2011 | 48
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