Business Whitepaper. Agile Performance- Tests. Schneller eine höhere Qualität erzielen

Transkript

1 Business Whitepaper Agile Performance- Tests Schneller eine höhere Qualität erzielen

2 Inhaltsverzeichnis 3 Performance-Tests 3 Warum agile Entwicklung? Warum zum jetzigen Zeitpunkt? 3 Integration von Performance-Tests 4 Integration von agilen Performance-Tests 7 Unterstützung von Performance-Tests in agilen Umgebungen durch HP 8 Weitere Informationen

3 Performance-Tests Performance-Tests sind in allen Softwareentwicklungsprojekten wichtig, auch in agilen Projekten. Von den ersten Pla nungsschritten bis hin zur Produktionsanalyse bewirkt die Anwendungsleistung die Entwicklung besserer Softwareiterationen und -Releases. Die Leistung darf nicht erst am Ende berücksichtigt werden. Für die Applikations-Verantwortlichen, Stakeholder, Entwickler und Tester einer Anwendung sollte die Leistung bei der agilen Entwicklung in jedem Sprint oder jeder Iteration ein zentraler Faktor sein. In diesem Dokument wird erläutert, wie Sie Performance-Tests in Ihre agilen Prozesse integrieren können. Darüber hinaus werden Konzepte und Best Practices zusammengefasst, Software-Tools für die Performance-Validierung in agilen Umgebungen beschrieben und praktische Tipps für Sie bereitgestellt. Abbildung 1 Mit agilen Prozessen (blaue Linie) erzielen Sie schneller einen ROI als mit dem Wasserfall-Ansatz (graue Linie) Agile brings ROI back Warum agile Entwicklung? Warum zum jetzigen Zeitpunkt? Weltweit versuchen Unternehmen, Software mit höherer Qualität in kürzerer Zeit zu entwickeln. Viele Unternehmen wenden Prozesse für die agile Softwareentwicklung an, um dieses Ziel zu erreichen. Dieser Ansatz kann dazu beitragen, die Markteinführungszeit zu verkürzen, die Softwarequalität zu erhöhen, die Produktivität zu steigern und die Ausrichtung der Technologie an den Geschäftszielen zu verbessern. Dies sind nur einige der zahlreichen Vorteile, die die agile Softwareentwicklung bietet. Mit dem agilen Ansatz überwinden Sie die Grenzen herkömmlicher Wasserfall-Ansätze für die Softwareentwicklung. Sie schaffen früher einen geschäftlichen Mehrwert und beschleunigen die Erzielung eines Investitionsertrags (Return on Investment ROI). Eine agile Umgebung besteht nicht aus isolierten Teams, die verschiedene Bausteine nacheinander entwickeln, sondern aus funktionsübergreifenden Teams, die Software gemeinsam in einer inkrementellen, iterativen und adaptiven Weise entwickeln. Agile Methoden fördern die Teamarbeit, häufige Überprüfungen, mehrere Iterationen, Selbstorganisation und Verantwortlichkeit. Diese Best Practices können nicht nur die schnelle Bereitstellung hochwertiger Software, sondern außerdem einen geschäftlichen Ansatz, der die Softwareentwicklung an den Kundenanforderungen und Unternehmenszielen ausrichtet, ermöglichen. $ Release 1 Release 2 Release 3 ROI Time Integration von Performance-Tests Performance-Tests sind ein integraler Bestandteil von agilen Prozessen. Sie unterstützen Ihr Unternehmen bei der schnellen und kostengünstigen Entwicklung von hochwertiger Software. Das Ziel ist, Performance-Tests früh und häufig in der Entwicklungsphase auszuführen und Funktionalität und Leistung in demselben Sprint zu testen. Warum? Weil die Einarbeitung von Änderungen immer teurer wird, je später Performance-Tests ausgeführt werden. Go live Performance-Tests werden für Web 2.0-Anwendungen noch wichtiger, da Mashups, die Inhalte aus mehreren Websites und Datenbanken auf angepassten Webseiten kombinieren, ganz neue Leistungsanforderungen mit sich bringen. Web 2.0-Anwendungen sind nicht nur dynamischer, sondern bestehen auch aus vielen kleinen Komponenten, die sich auf die Leistung und die Endbenutzererfahrung auswirken können. In Web 2.0-Anwendungen gibt es viel mehr Bestandteile, die alle miteinander verbunden sind von Client-Scripts bis hin zum Netzwerkverkehr, von Web-Diensten bis hin zu Server-Scripts. Aber wie können Sie vorgehen, um Performance-Tests in Ihre agilen Entwicklungsprozesse zu integrieren? Zunächst müssen Sie sich eine neue, agile Denkweise für Performance-Tests aneignen. Sie kommen nicht erst ins Spiel, wenn die Entwicklung zu großen Teilen abgeschlossen ist. Die Performance-Tests, die in einem Wasserfall-Prozess am Ende des Lebenszyklus der Softwareentwicklung (Software Development Lifecycle SDLC) ausgeführt werden, verschieben sich an den Anfang des agilen Prozesses und finden parallel zu Analyse, Design und Codierung statt. 3

4 Die Leistung einer Anwendung ist direkt von ihrem Design abhängig und sollte daher in ein frühes Stadium des Entwicklungslebenszyklus integriert werden. Performance-Tests werden über den gesamten agilen SDLC hinweg berücksichtigt bereits ab dem Release-Planungsstadium. Eine Möglichkeit, um sicherzustellen, dass Performance-Tests in ein frühes Stadium des SDLC-Prozesses integriert werden, besteht darin, den Begriff Done (Erledigt) klar zu definieren und bei der agilen Implementierung zugrunde zu legen. Auf diese Weise wird die Anwendung am Ende jedes Sprints im Hinblick auf Funktionalität, Leistung und Sicherheit getestet und steht bei Bedarf für die inkrementelle Bereitstellung zur Verfügung. Abbildung 2 Aufeinanderfolgende Aktivitäten werden im agilen SDLC zu gleichzeitigen Aktivitäten. Analyse Analyse Integration von agilen Performance- Tests Lassen Sie uns nun einige wichtige Aspekte von Performance- Tests betrachten, um besser zu verstehen, wie Performance-Tests in agile Prozesse integriert werden. Service-Level-Ziele Service-Level-Ziele (Service-Level Objectives SLOs) steuern die Planung von Leistungsanforderungen in agilen Umgebungen. In Form von SLOs vereinbaren die Führungskräfte in den Geschäftsbereichen und in der IT die Anforderungen in Bezug auf Anwendungsdurchsatz, Antwortzeiten, Anzahl der gleichzeitig unterstützten Benutzer und andere Faktoren, die sich auf die Endbenutzererfahrung auswirken. Diese Anforderungen werden in das Anwendungs-Backlog aufgenommen und müssen erfüllt sein, bevor eine Anwendung in eine Produktionsumgebung implementiert werden kann. Design Design Diese Beispiele legen die Anforderungen für die Anwendung fest, welche wiederum die Akzeptanzkriterien definieren und die Test- Scripts steuern. Codierung Test Zeit Codierung Test Zeit Performance-Tests in einem agilen Lebenszyklus Eine gute Anwendungsleistung wird zwar erst am Ende jedes Release erwartet; die Grundlage dafür wird jedoch bereits im Release-Planungsstadium gelegt. Zu beachten sind dabei User Storys, die Leistungsanforderungen beschreiben, und funktionale User Storys, die sich potenziell auf die Leistung einer Anwendung auswirken können. Mithilfe von Performance-Tests können Sie Fragen wie die folgenden beantworten: Muss die Anwendungsarchitektur geändert werden, um die Leistungsrichtlinien zu erfüllen? Wirken sich neuere Technologien wie AJAX negativ auf die Leistung der Anwendung aus? Muss die IT-Infrastruktur der Test- und Produktionsstandorte aktualisiert werden? Wirkt sich das Design der Benutzerschnittstelle negativ auf die Leistung der Anwendung aus? Kann sich eine erwartete höhere Last negativ auf die Anwendungsleistung auswirken? Reduziert sich die Leistung, wenn die Anwendung in anderen Regionen zur Verfügung gestellt wird? Die Anwendungseigner und Stakeholder müssten von Anfang an ein Interesse an den Leistungsaspekten der Anwendung haben. Sie legen die Prioritäten für die SLO-Anforderungen fest. Beispielsweise wird den Anforderungen, die sich am stärksten auf die Anwendung und damit letztendlich auch auf das Unternehmen auswirken, die höchste Priorität im Entwicklungsprozess zugeordnet. Ein Beispiel: Ein Anwendungseigner bietet die folgende User Story an: Als Benutzer möchte ich, dass alle Seiten auf unserer Website innerhalb von zwei Sekunden aktualisiert werden, damit ich auf unserer Website produktiver arbeiten kann. Und ein weiteres Beispiel für eine Story: Als Anwendungseigner möchte ich, dass die Anwendung bis zu Benutzer gleichzeitig unterstützen kann, ohne dass die Leistung der Anwendung sich verschlechtert, damit ich die Anwendung allen Mitarbeitern meines Unternehmens weltweit zur Verfügung stellen kann. Fokussierte Performance-Tests SLOs definieren das erwartete Verhalten von Anwendungen. Jedoch in der Praxis kennen Entwickler, Testteams und Geschäftsbereiche die genauen Anforderungen an eine Anwendung meistens erst, wenn sie ihre Leistung in der Produktionsumgebung kennen. Aus diesem Grund wird bei agilen Prozessen der sogenannte PAL (Production Availability Lifecycle) verwendet, um die tatsächliche Leistung einer Anwendung in der realen Welt zu ermitteln. Das Feedback aus der Produktionsumgebung hilft Entwicklern und Testern dabei, sich auf bestimmte Problembereiche der Anwendung zu konzentrieren und dadurch die Ressourcen in den kurzen Sprint-Zyklen zu erhöhen. Dies ist eine wichtige kontinuierliche Maßnahme im agilen Entwicklungsprozess. Sie stellt Entwicklern und Testern genaue Messwerte und Nutzungstrends zur Verfügung. Diese können diese Ergebnisse zugrunde legen, wenn sie an der nächsten Version der Anwendung arbeiten. Messwerte aus der realen Welt können zu besseren Tests und besserer Software führen. 4

5 Abbildung 3 Die Definition von Done umfasst die Ausführung von Performance-Tests in einem Sprint. Planung Analyse Design Codierung Tests Vorbereitung der Testdaten Architektur, Infrastruktur Performance Benutzerakzeptanz Pilot Auslieferung In einer agilen Umgebung sind Sprints kurz. Sie dauern normalerweise nur zwei bis vier Wochen. Folglich ist auch die Zeit für Tests kurz. Umso wichtiger ist es, dass die Vorbereitung der Testdaten im Planungsstadium stattfindet, damit genügend Zeit für Performance-Tests zur Verfügung steht. Die Vorbereitung der Testdaten kann unter der Leitung eines Ge schäftsbereichs (Line of Business LOB) oder eines anderen Unternehmensbereichs ausgeführt werden, der ein Interesse am Schutz der Daten hat, die getestet werden. Beispielsweise möchte ein Stakeholder möglicherweise eine Datei verdecken, um vertrauliche Kunden- oder Mitarbeiterdaten zu schützen. Je früher die Testdaten vorbereitet werden, desto mehr Zeit steht für Tests zur Verfügung. D. h., die Performance-Tester sollten im Planungsstadium mit den Stakeholdern zusammenarbeiten, um die Tests und Testdaten vorzubereiten. Diese Art der Zusammenarbeit ist einer der Schlüssel, um in einem relativ kurzen Sprint ein großes Arbeitspensum zu schaffen. Verschiedene Tätigkeiten müssen gleichzeitig ausgeführt werden. In dieser Hinsicht entspricht die agile Softwareentwicklung der JIT-Fertigung. Die erforderlichen Ressourcen werden sorgfältig geplant und genau dann eingesetzt, wenn sie benötigt werden. Trendberichte In einer agilen Umgebung ist es für die Anwendungseigner maßgeblich, dass im Verlauf von aufeinanderfolgenden Sprints eine kontinuierliche Verbesserung sichtbar ist. Es muss erkennbar sein, dass jede Iteration der Anwendung besser ist als die vorherige. Daher ist es umso wichtiger, dass die Leistungstrends der Anwendung in Form von SLO-Anforderungen überwacht werden. Mit Trendberichten können Sie den Stakeholdern regelmäßige Snapshots der Leistung bereitstellen. Diese sollten im Idealfall zeigen, dass die Leistung sich stetig verbessert oder zumindest nicht verschlechtert. Darüber hinaus müssen Sie nicht notwendigerweise bei jeder Testausführung die Analyse auswerten, wenn Sie Trendberichte verwenden. Wiederverwendbare und gemeinsam genutzte Test- Assets Zur Beschleunigung der Test- und Entwicklungsarbeit sollte bei agilen Prozessen ein Repository mit wiederverwendbaren und gemeinsam genutzten Test-Assets verwendet werden. Durch dieses Repository der Test-Scripts können alle Mitglieder des virtuellen Entwicklungsteams einschließlich externer Lieferanten, die möglicherweise einen Teil der Arbeit erledigen auf dieselben Test-Assets zugreifen. Neben anderen Vorteilen, die das Repository bietet, ermöglicht es die Ausführung von Testaktivitäten durch verschiedene, weltweit verteilte Teams rund um die Uhr und erhöht damit die Effizienz. So können Test-Scripts im Lauf eines Tages in einer Region erstellt und anschließend Testern in einer anderen Region bereitgestellt werden, die die Tests dann im Lauf ihres Arbeitstages ausführen. Die Wiederverwendung und gemeinsame Nutzung von Test-Assets ist bei der agilen Entwicklung, bei der die Testzyklen kurz sind, noch kritischer. So kann innerhalb des verfügbaren Zeitfensters mehr Arbeit erledigt werden. Automatisierte Tests Die Verwendung von automatisierten Testtools kann den Performance-Testprozess erheblich beschleunigen. Mit der richtigen Software können Sie ein wiederverwendbares Test-Script erstellen und anschließend einen Zeitplan definieren, um den Test außerhalb der normalen Arbeitszeit auszuführen, wenn die Entwickler den zu testenden Code nicht bearbeiten. Auf diese Weise wird eine höhere Softwarequalität in kürzerer Zeit erreicht. Durch automatisierte Tests können Sie Ihre Ziele für Regression- Tests und Performance-Tests in dem knappen Zeitrahmen eines zwei- bis vierwöchigen Sprints erreichen. Angesichts der Tatsache, dass die Entwickler ihre Arbeit in Form eines Builds, der getestet werden kann, erst aus der Hand geben, wenn 60 % der Zeit in einem Sprint abgelaufen sind, ist dies umso wichtiger, da die Zeit für Tests dann sehr knapp ist. 5

6 Kontinuierliche Analyse In agilen Prozessen ist die kontinuierliche Analyse von zentraler Bedeutung. Sowohl aktive Projektteilnehmer (in der Scrum-Terminologie Pigs ) als auch Stakeholder (in der Scrum-Terminologie Chickens ) müssen den Fortschritt des Projekts sorgfältig überwachen, besonders in Bezug auf Anwendungsfunktionalität und -leistung. Damit sie die Ansicht erhalten, die sie benötigen, muss die Leistungsanalyse kontinuierlich und umfassend sein. Diese kontinuierliche Analyse hilft bei der Identifikation von Problembereichen in der Anwendung. Analysen finden in jeder Phase statt, bis hin zu den täglichen Besprechungen (Daily Scrums), an denen die Tester der IT-Infrastruktur und Leistung als aktive Projektteilnehmer sowie die Anwendungs-Stakeholder teilnehmen. Die aktiven Projektteilnehmer (Contributors) sind die Mitglieder des Sprint-Teams, die an den Daily Scrums teilnehmen. In diesen werden alle Stakeholder über den aktuellen Status der Entwicklungsarbeit informiert. Wenn alle interessierten Team-Mitglieder über die Leistung in jedem Sprint informiert sind, sind sie besser in der Lage, eine hohe Qualität der Anwendung sicherzustellen. Je früher Probleme gefunden werden, desto früher können sie behoben werden. Komponententests In einer agilen Umgebung steht nicht in jedem Sprint eine vollständige Anwendung zur Verfügung. Daher ist es wichtig, dass Performance-Tests nur für einen Teil oder eine Komponente einer Anwendung ausgeführt werden können. Stubbing stellt ein Verfahren zum Testen von Komponenten dar. Beim Stubbing werden die Teile einer Anwendung simuliert, die noch nicht geschrieben oder nicht verfügbar sind. Wenn eine Anwendung externe Datenquellen anderer Anbieter verwendet was in der Web 2.0-Welt häufig vorkommt, benötigen die Performance-Tester und Experten für Qualitätssicherung Stubs, da sie nicht die echten Produktionsserver dieser Anbieter verwenden können. Die Definition von Done In einem agilen Projekt sollte die Definition von Done die Ausführung von Performance-Tests in einem Sprint umfassen. Nur wenn Performance-Tests ausgeführt wurden, können Sie darauf vertrauen, dass sie den Endbenutzern eine erfolgreiche Anwendung bereitstellen. Die Best Practices für Performance-Tests innerhalb eines Sprints sehen wie folgt aus: Sammeln Sie alle leistungsbezogenen Anforderungen und berücksichtigen Sie diese bei der Besprechung und Planung der Systemarchitektur. Arbeiten Sie eng mit Endbenutzern und Stakeholdern zusammen, um Akzeptanzkriterien für jede Leistungs-Story zu definieren. Binden Sie Performance-Tester früh, d. h. in den Planungs- und Infrastrukturstadien, in das Projekt ein. Nehmen Sie Performance-Tester in das Entwicklungsteam (Sprint-Team) auf. Stellen Sie sicher, dass die Performance-Tester an den Testfällen und der Vorbereitung der Testdaten arbeiten, während die Entwickler den Code auf der Basis der User Storys erstellen. Lassen Sie die Performance-Tester Stubs für alle externen Web- Dienste erstellen. Stellen Sie den Performance-Testern jede relevante User Story bereit, sobald sie von den Funktionstestern freigegeben wurde. Liefern Sie kontinuierliches Feedback an Entwickler, Architekten und Systemanalysten. Nutzen Sie Assets für den Performance-Test über mehrere Projekte und Versionen hinweg. Führen Sie Performance-Test mithilfe von Zeitplänen außerhalb der normalen Arbeitszeit aus, um die Zeit innerhalb des Sprints besser zu nutzen. Durch Performance-Testkomponenten in jedem Sprint unterstützen Sie die Entwickler bei der Entwicklung einer Anwendung mit hoher Qualität, die eine durchgängig hohe Leistung liefert. Noch eine letzte Überprüfung Der sogenannte hardening Sprint ist ein optionaler letzter Schritt im agilen Prozess. In diesem Sprint werden letzte Prüfungen ausgeführt, z. B. eine letzte Testrunde, Prüfungen der Gesamtleistung und Tests in Bezug auf die Erfüllung der SLOs. Dabei können zwar auch Probleme aufgedeckt werden, die behoben werden müssen; hauptsächlich dient der hardening Sprint jedoch dazu, das Vertrauen in die Anwendung zu erhöhen, bevor sie in die Produktionsphase eintritt. Wenn Sie ordnungsgemäß vorgegangen sind und Performance-Tests im Verlauf des gesamten agilen SDLC ausgeführt haben dürften Sie keine Überraschungen erleben. Beim hardening Sprint sollten Performance- Tests jedoch nicht zum ersten Mal ausgeführt werden. 6

7 Inkrementelle Auslieferung ermöglichen Die Performance-Validierung ist ein integraler Bestandteil jedes Softwareentwicklungsprojekts. In agilen Projekten kommt ihr jedoch eine größere Bedeutung zu. Sie ermöglicht die Bereitstellung eines potenziell auslieferbaren Produkts oder Anwendungs-Inkrements. Dies bedeutet Folgendes: Die in einer Iteration (einem Sprint) ausgeführte Arbeit wurde (einschließlich des Erreichens der Leistungsziele) so sorgfältig überprüft, dass die Anwendung bei Bedarf implementiert oder ausgeliefert werden kann, um Geschäftsanforderungen zu erfüllen. Die Entscheidung, ob ein Anwendungs-Inkrement tatsächlich implementiert oder ausgeliefert wird, ist von vielen weiteren Faktoren abhängig. Dazu gehören der Inkrement-Wert, der der Anwendung in einem Sprint hinzugefügt wurde, die Auswirkungen einer Aktualisierung auf die Betriebsabläufe des Unternehmens und die Auswirkungen häufiger Aktualisierungen auf Kunden oder Endbenutzer. Das heißt, die Leistung ist nicht der einzige Faktor aber ein sehr wichtiger. Könnten Sie ein Anwendungs-Inkrement möglicherweise ausliefern? Dies ist nur möglich, wenn Sie seine Leistung gründlich validiert haben. Unterstützung von Performance-Tests in agilen Umgebungen durch HP HP ist ein führender Anbieter von Software für Performance-Tests in agilen und Wasserfall-Umgebungen. Verschiedene HP Produkte für Performance-Management werden häufig in agilen Prozessen eingesetzt. Diese umfassen HP Performance Center Software, HP Diagnostics Software und HP Business Availability Center Software. Mit diesen Produkten kann Ihr Team die Leistung über den gesamten Anwendungslebenszyklus hinweg verwalten. HP Performance Center Software Die HP Performance Center Software kann im gesamten agilen SDLC verwendet werden, um die Leistung verschiedener Iterationen einer Anwendung zu validieren. Diese integrierte Lösung für Performance-Validierung emuliert Hunderte bis mehrere Zehntausend gleichzeitiger Benutzer, um simulierte Produktions- Workloads auf praktisch jede Clientplattform oder Umgebung anzuwenden. Im Einzelnen können Sie mit Performance Center auf einfache Weise Produktionsleistungsdaten bei der Erstellung von Performance-Tests integrieren und die Verwaltung und Bereitstellung von Performance-Test-Labs automatisieren. Mit seinen zukunftsweisenden Funktionen für Trendberichte, Zeitplanung, zentrales Repository und Webzugriff eignet HP Performance Center sich perfekt für Performance-Tests in einer agilen Umgebung. Mit Performance Center können Ihre Testteams über Zeitpläne Test-Labs automatisch bereitstellen und anschließend Lasttests für die gesamte Anwendung ausführen. Dabei werden konsistente, messbare und wiederholbare Lasten angewendet. Mit den so generierten Daten können Sie Skalierbarkeitsprobleme ermitteln, die sich negativ auf die Benutzer auswirken können. Tabelle 1 Eine agile User Story für die Leistung in der Praxis Anwendung Aktuelle Benutzerbasis Vision Roadmap-Anforderung Release- und Sprint- Anforderung Sprint-Ausführung Ergebnis Vertriebsanwendung zur Lead-Generierung als SaaS (Software as a Service) Abonnenten Definiert von den Geschäftsbereichen: Erhöhung der Abonnentenanzahl auf in den nächsten 12 Monaten durch Aktualisierung der Benutzerschnittstelle der Anwendung auf das modernere Web 2.0, sodass die Prozessabläufe und Benachrichtigungen interaktiver und interessanter werden. Eher allgemein, nicht sehr spezifisch: Als Anwendungseigner der Vertriebsanwendung für Leads möchte ich, dass die Anwendung bei guter Leistung auf Benutzer skaliert werden kann, sodass neue und vorhandene Abonnenten bei der Interaktion mit der Anwendung keine Verzögerungen bemerken. Spezifisch: Als Anwendungseigner der Vertriebsanwendung für Leads möchte ich, dass die Anwendung für gleichzeitige Benutzer eine gute Leistung bietet, sodass eine aktualisierte Anzahl der verfügbaren Leads innerhalb von zwei Sekunden angezeigt wird, wenn die Abonnenten die Suchkriterien ändern. Bei jedem Sprint wird überprüft, ob die Zwei-Sekunden-Anforderung für die Suche erfüllt wird. Bei mehreren Sprints wurde festgestellt, dass die zwei Sekunden überschritten wurden. Aber jedes Mal wurde das sofort behoben. Die Anwendung wird rechtzeitig ausgeliefert und die Zwei-Sekunden-Anforderung für die Suche ist erfüllt, da die Leistungsanforderung in jeden Sprint integriert wurde. Hätte man das Problem der Leistung in den Hardening Sprint verschoben, wäre das Produkt zu spät ausgeliefert worden oder es hätte die Anforderung nicht erfüllt. 7

8 Abbildung 4 Eine User Story für die Leistung beginnt als Idee und wird zu einer anerkannten Entität, die den Softwareentwicklungsprozess beeinflusst. Produktvision Produkt-Roadmap Release-Plan Sprint-Plan Daily Standup- Meeting HP Diagnostics Software HP Diagnostics erweitert die HP LoadRunner und HP Performance Center Software für die Herausforderungen, die das Testen von komplexen Web 2.0-Anwendungsarchitekturen und Unternehmensanwendungen über den gesamten Anwendungslebenszyklus hinweg mit sich bringt. HP Diagnostics stellt Ihren Testern die Tools bereit, mit denen der Problembereich für Leistungsengpässe, der mit der HP Performance Center Software ermittelt wurde, präzise identifiziert werden kann eine Funktion, die in einem kurzen Entwicklungs-Sprint viel wertvolle Zeit spart. Neben anderen Merkmalen unterstützt die Software Sie dabei, Probleme früher im Lebenszyklus zu finden und zu beheben, die Qualität durch Erkennung der häufigsten Anwendungsprobleme vor der Auslieferung zu erhöhen und konkrete Daten zu erfassen, auf deren Basis Sie entscheiden können, ob Sie eine Anwendung ausliefern. HP Application Performance Management Software HP Application Performance Management (APM) ist eine umfassende Lösung für Performance-Management, die Ihnen dabei hilft, Leistungs- und Verfügbarkeitsprobleme von Anwendungen schnell und effizient zu identifizieren und zu beheben, bevor sie sich auf die Geschäftstätigkeit auswirken. Sie ermöglicht die lückenlose Überwachung von Geschäftsservices und des Anwendungsstatus aus der Perspektive der wichtigsten Stakeholder des Unternehmens, seiner Kunden und seiner Partner. In agilen Umgebungen stellt HP APM mit seinen Diagnosefunktionen (Transaktionsverfolgung) Ihren Entwicklern und Testern Informationen zur Anwendungsleistung aus der realen Welt bereit. Auf der Basis dieser Informationen kann Ihr Team sich auf bestimmte Problembereiche der Anwendung, z. B. die Java-Thread-Analyse, konzentrieren und einzelne Komponenten der Anwendung identifizieren, deren Leistung schlecht ist. Weitere Informationen Weitere Informationen zu HP Lösungen für Performance-Tests in agilen Umgebungen finden Sie auf diesen Internetseiten: HP Performance-Validierung: hp.com/go/performancevalidation HP LoadRunner und Performance Center Blog: communities.hp.com/online/blogs/loadrunner/default.aspx Get connected hp.com/go/getconnected Informationen zu technischen Trends, Support-Hinweisen und HP Lösungen. Copyright Hewlett-Packard Development Company, L.P. Änderungen vorbehalten. Die Garantien für HP Produkte und Services werden ausschließlich in der entsprechenden, zum Produkt oder Service gehörigen Garantieerklärung beschrieben. Aus dem vorliegenden Dokument sind keine weiterreichenden Garantieansprüche abzuleiten. HP übernimmt keine Verantwortung für die Richtigkeit und Vollständigkeit der Angaben in diesem Dokument. Java ist eine eingetragene Marke der Oracle Corporation und/oder ihrer Tochterunternehmen. 4AA1-5263DEE, erstellt im Januar 2010; aktualisiert im Juli 2012, Rev. 2 This is an HP Indigo digital print.