Requirements basiertes Testen mit JUnit Architektur für eine Verbindung von Requirements Management und Test Management

Größe: px

Ab Seite anzeigen:

Download "Requirements basiertes Testen mit JUnit Architektur für eine Verbindung von Requirements Management und Test Management"

Ralf Geisler
vor 6 Jahren
Abrufe

1 Requirements basiertes Testen mit JUnit Architektur für eine Verbindung von Requirements Management und Test Management Oliver Böhm MKS GmbH

2 Agenda Architektur und Umsetzung MKS Integrity MKS Requirements MKS Test Management mit JUnit Verbindung zwischen Requirements und Test Management Reporting Live-Demo Folie 2

3 Architektur und Umsetzung MKS Integrity Folie 3

4 Herausforderung: Chaos durch voneinander losgelöste Tools Version Repository Process App Dev Process Process Requirements Repository Business Analyst QA Test Plan Repository Process Process Help Desk IT Operations Trouble Ticket Repository Configuration Repository Folie 4

5 Der MKS Ansatz One Product Business Analyst App Dev One Repository IT Operations QA Help Desk Folie 5

6 Folie 6 Die MKS Integrity Architektur

7 FSA (Federated Server Architecture) HQ Team Remote Team Folie 7

8 Architektur und Umsetzung MKS Requirements Folie 8

9 Domänenmodell Input Document Requirement Document Specification Document Test Document Change Request Input Requirement Specification Test Shared Input Shared Requirement Shared Specification Shared Test Input Change Order Requirement Change Order Specification Change Order Test Change Order Task Test Plan Test Case Folie 9

10 Domänenmodell: Umsetzung Input-Domäne Requirement-Domäne Specification-Domäne Test-Domäne Folie 10

11 Dokumenten-Workflow Jedes Dokument in jeder Domäne durchläuft Workflow Editierbarkeit eines Dokuments abhängig vom Workflow-Status Änderungen im Dokument ab bestimmtem Status nur noch über Change Request / Change Order möglich Berechtigungskonzept Folie 11

12 Arbeiten mit Projekten Project Folie 12 Jedem Requirementdokument ist ein Projekt zugeordnet

13 Projekt-Workflow Jedes Projekt durchläuft Workflow Projekt kann erst abgeschlossen werden, wenn alle zugehörigen Dokumente implementiert sind Berechtigungskonzept Folie 13

14 Domänenmodell mit Projekten (Matrixstruktur) Input Folie 14 Requirement Specification Test Beispiel für eine Projektstruktur: Kundenprojekte Audi BMW Daimler Volkswagen Toyota Vorhandene Module ABS V. 1.0 V. 1.1 V. 2.0 V. 2.1 Einspritzpumpe V. 1.0 V. 1.1 V. 1.2

15 Domänenmodell mit Projekten: Umsetzung Folie 15

16 Beziehungen zwischen Domänen Decomposes To Decomposes To Decomposed From Decomposed From Satisfied By Decomposes To Input Requirement Decomposed From Validates Validated By Satisfies Test Folie 16 Specification = Suspect

17 Beziehungen zwischen Domänen: Umsetzung Specification Input Requirement Test Folie 17

18 Traceability zum Source Code Folie 18

19 Architektur und Umsetzung MKS Test Management mit JUnit Folie 19

20 Verbindung zum Test Management Document Test Plan Requirements Ein Dokument enthält mehrere Requirements A utomatisierte Test Session Project Project Requirements Project Project Test Suite Sobald eine automatisierte T est Session in den Status In Progress gesetzt wird, erzeugt das automatische Test Execution Framework eine Verbindung mit JUnit, übergibt alle benötigten Informationen, holt die Ergebnisse ab und schreibt sie zurück in die Test Session. Test Plan Ein Test Plan enthält Spezifik ationen der einzelnen Test Cases, Pass/Fail Kriterien und Informationen zu den operativ e Abläufen der Test Cases. Project Project Test Case Test Suite Defect Project Project Test Session Eine logische Gruppierung mehrerer Test Cases. Z.B. als Gruppe mehrerer funk tionaler Requirements, eine Menge automatisierter Tests vom selben Ty p, usw. Test Suites werden durch einen Test Plan beschrieben. Test Session JUnit Execution Framework Test Result User Interface Um Testergebnisse der manuellen Tests einzugeben oder die Testergebnisse der automatischen Tests zu bewerten. Defect Defects werden durch das Test Result User Interface erzeugt und mit dem entsprechenden Test Case v erbunden. Folie 20 Eine Test Session wird pro Dok ument erwartungsgemäß mehrere Male ausgeführt, besonders bei automatisierten Tests (Regressions Tests). Eine Test Session umfasst alle Test Cases einer Test Suite, welche zusammen ablaufen. Test Case Die Testschritte, erwartete Testergebnisse und Pass/Fail Kriterien werden im Test Case dokumentiert. Ein Test Case k ann ein oder mehrere Requirements v erifizieren. Mehrere Test Cases k önnen für ein Requirement erzeugt werden.

21 Traceability zum Test Management (1) Folie 21

22 Traceability zum Test Management (2) Folie 22

23 Traceability zwischen Source Code und JUnit Test Folie 23 Datei1Test.java V1.1 Datei1.java V1.1 Datei2Test.java V1.1 Datei2.java V1.1

24 Traceability zu JUnit Status auf Execute setzen JUnit Ausführung der Tests Anzeige der Ergebnisse in der Test Result GUI Folie 24

25 Reporting Folie 25

26 MKS Test Requirements Test Coverage Folie 26

27 MKS Test Planung der Testausführung Folie 27

28 MKS Test Testresultate erfassen Folie 28

29 MKS Test Review der Testergebnisse Folie 29

30 LiveDemo Folie 30

31 Fragen????!? Stand 26? Folie 31? Besuchen Sie uns:!!?

Ähnliche Dokumente

Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006

Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006 Oliver Böhm MKS GmbH Agenda Überblick Der Entwicklungsprozess: Requirements