Anfänge’der’Testautoma1on’ · Source$ Code$ Asseron$ Script$ SPL Compiler$ Asseron$...
Transcript of Anfänge’der’Testautoma1on’ · Source$ Code$ Asseron$ Script$ SPL Compiler$ Asseron$...
Anfänge der Testautoma1on
Die ersten Testwerkzeuge im deutschsprachigen Raum
1977-‐1982
Keynote Address by Harry Sneed zum 25. TAV Geburtstag Bremen am 23. Juno 2016
Anfänge der Testautoma1on (Die ersten Testwerkzeuge 1977-‐1982)
In der Zeit vom Herbst 1977 bis Ende 1982 entwickelte Harry Sneed mit Hilfe der ungarischen RecheninsTtute Szamok und SzKI sieben Testwerkzeuge für die deutsche Industrie. Vier davon werden hier vorgestellt.
• RXVP – Die MuXer aller Testwerkzeuge (1975)
• Prüfstand – das erste deutsche Testwerkzeug (1977) • QSTS – das Quelle SoZware Testsystem für IBM Assembler
• KSTDS – das Kienzle SoZware Testsystem für den Test von embedded SoZware in Geräten
• INTTEST – das allumfassende IntegraTonstestsystem für die Tornado Lagerhaltung
• ACM-‐QS-‐Konferenz an der Bundeswehrhochschule (1982)
SNEED-01 TAV-2016
RXVP –Die MuCer aller Testwerkzeuge
• RXVP wurde von der General Research CorporaTon in Santa Barbara CA in der Zeit von 1972-‐1978 entwickelt für den Test des BallisTc Missile Defense Systems.
• Projektleiter war Dr. Ed Miller, später Gründer der Firma SoZware Research Associates. Prof. Charles Ramamoorthy von der Uni California war Projektberater
• Später im Jahre 1977 hat Sabine Saib das Projekt übernommen und weiter geführt
• Es wurde umgetauZ in SQLAB und auf dem CDI Struktokongress 1979 in Frankfurt vorgestellt.
TAV-2016 SNEED-02
Sta1c Analysis
Dynamic Analysis
Program Verifica1on
Syntax Analysis
Syntax Errors
Semantic Errors
Execution Errors
Deviation Errors
Graph Checking +
Call Checking +
Units Consistency +
Mode Checking +
Asserted/Actual Use
+ Set/Use Checking
Test Results +
Execution Errors
+ Coverage
Report +
Assertion Exceptions
Annotated Listing
+ VC'S
+ Symbolic
Execution of Expressions
+ Simplified
VC'S
Indented Program Listing
+ Diagnostics
Detect Detect Detect Detect Original Program
Tester builds in Asserts
1976
Correct
Program Incorrect
Program with Asserts
Test Documentation
Die RXVP Testwerkzeugkette
Folie aus dem Jahr 1976
TAV-2016 SNEED-03
Store Measurement
Receive Message
Assert Check
Assert Check
Report Patient ok
Assert Check
Check Measurement
Range
Report Measurement
Error
Assert Check
Report Patient
in danger
Assert Check
Invalid Measure Valid Measure
Sets Validation Points
Patient Monitoring
System
Safe Range Danger Range
If Measurement valid?
Tester sitzt am TI Bildschirmterminal
und steuert den Test mit einem Lichtstift
System Tester
RXVP Assertion-based Testing System
RXVP Dynamic Analyzer verfolgt Testpfade TAV-2016 SNEED-04
Der SoOware Prüfstand zum Test von Siemens SPL und Assembler Module
• Harry Sneed hat die Entwicklung des Prüfstandes schon 1976 begonnen als er noch bei Siemens in der Datenbankentwicklung täTg war und erkannte wie aufwendig Testen ist.
• Im Jahre 1977 ist er als Testmanager zum I.T.S. Projekt rüber gewechselt. Seine Aufgabe war dort die SPL Module zu testen. Da es keine Tester gab, hat er allein mit dem Tool STchproben getestet.
• Im gleichen Jahr war er auf der NCC Kongress in Dallas Texas wo er Dr. Ed Miller kennenlernte. Sie haben entschieden zusammenzuarbeiten.
• Im Feb. 1978 lernt Sneed einen Mitarbeiter des Szamok InsTtuts aus Budapest auf der ersten europäischen Testkonferenz in London kennen. Dieser bot Testkapazität an.
• Im Mai 1978 beginnt der Test der I.T.S. Module mit Prüfstand auf dem Siemens Rechner in Budapest für DM 75 pro Tesfall und DM 150 pro nachgewiesener Fehler.
TAV-2016 SNEED-05
Ar1kel über den Test der Datenbank SoOware bei Siemens 1977
Systematisches Programmtesten – ein mühsames Geschäft
TAV-2016 SNEED-06
Online – Zeitschrift für Datenverarbeitung Sept. 1977
TesVall Extrak1on
aus dem Code
TesVall
Tabelle TesCreiber
Testobjekt Compile &
Einbinden
Source
Code
Pruefstand Modultestrahmen
Entwickler programmiert
Module
Tester testet
Module
Prüfstand testet Module gegen sich selbst
Siemens ITS Projekt 1978/79
Durch die Ablaufanalyse werden Tesfälle automaTsch abgeleitet aus dem Source-‐Code.
TAV-2016 SNEED-07
Prüfstand verwendet die Compile-Listing um die Moduldaten zu adressieren.
Source Code
AsserTon Script
SPL
Compiler
AsserTon
Compiler
Object Code
Testdata Tables
Test Execu1on
Vorzustände & Nachzustände
wird instrumentiert mit Durchlaufzähler
Daten Abweichung
Bericht
Prüfstand vergleicht die Sicht des Testers mit der Sicht des Entwicklers
Bei jeder Unterbrechung werden Vorzustände
gesetzt & Nachzustände geprüft
Entwickler Tester
Parallel Entwicklung & Test
Compile Adressen
TAV-2016 SNEED-08
SNEED-09 TAV-2016 Prüfstand BS2000 Testumgebung
• In einem Jahr sind 281 Module mit 134 K Anweisungen von 3864 TesVällen getestet worden. Bei einem Preis von DM 75,-‐ per TesVall kosteten die TesVälle DM 289.800
• Der Mindestzweigüberdeckungsgrad betrug 85%
• 403 Programmfehler wurden berichtet und bestä1gt. Bei einem Preis von DM 150,-‐ per Fehler, kamen noch DM 60.450 dazu.
• Später im Integra1onstest durch den Kunden wurden noch 386 Fehler gefunden.
• Der intensive Modultest haCe nur 51% aller im Test aufgedeckten Fehler gefunden, trotz einer Überdeckung von 85%.
• Dies warf einen SchaCen auf die Effek1vität von einem Modultest bei dem die Module nur gegen sich selbst getestet werden. Es brauchte ein unabhängiges Testorakel.
Ergebnisse aus dem Test mit Prüfstand TAV-2016 SNEED-10
Quelle SoOware Test System für Makro-‐Assembler Module
• Nach Abschluss des I.T.S. Projektes wurde Harry Sneed von Siemens an die Quelle AG in Nürnberg weiter vermiXelt. Quelle wollte ein Modultestsystem wie der Prüfstand haben, aber es sollte auf ihre IBM-‐Umgebung und ihre Programmiersprache QAL zugeschniXen sein.
• Sneed hat zusammen mit den Quelle Entwicklern das QSTS konzipiert und mit PseudoCode entworfen. Drei ungarische Mitarbeiterinnen haben das Tool selbst in QAL Assembler implemenTert.
• Im Gegensatz zum Prüfstand lief QSTS im Batchmodus. Für jeden Batchlauf wurde ein eigenes Testobjekt zusammengebaut. Die Testdaten und Sollergebnisse wurden in den generierten Treiber und Stubs fest zugewiesen.
• Programmunterbrechungen und abweichende Ergebnisse wurden in einem Testprotokoll berichtet.
• QSTS hat auch die Einhaltung der Quelle Programmierregel kontrolliert und Regelverletzungen dokumenTert. Damals wurde die Nichteinhaltung der Regel mit Strafmaßnahmen geahndet.
TAV-2016 SNEED-11
Quelle SoOware Testsystem 1979 Das Quelle SoOware Testsystem (QSTS) erfüllte drei HaupVunk1onen: • Programmanalyse • Testdatengenerierung • Testausführung Die Programmanalyse untersucht: • Datenstruktur • Ablaufstruktur • Programmverknüpfungen
Testdatengenera1on • Die TestdatengeneraTon ist ein interakTver Prozess. Der Tester kann Testdaten
am Sichtgerät über ROSCOE symbolisch zuweisen. Die Daten werden automaTsch geprüZ gegen die Datentabelle. Wenn sie falsch sind werden sie zurückgewiesen. Wenn alle Daten korrekt sind werden sie tesfallweise in PanValet Dateien abgelegt.
SNEED-12 TAV-2016
Quelle SoOware Testsystem 1979
Testausführung mit QSTS: • Für die Testausführung erstellt QSTS einen Testrahmen um die
Umgebung des zu testenden Moduls zu simulieren. Der Tester braucht keine zusätzliche Testprogramme zu schreiben. QSTS simuliert sowohl die – Übergeordnete, bzw. aufrufende Module als auch – Untergeordnete, bzw. aufgerufene Module und
– Alle Dateien und Datenbanken. • Mit QSTS ist man in der Lage, einzelne Module losgelöst von ihrer
Umgebung zu testen. Eingaben zu dem Test sind:
• QAL Assembler Code • Testdatenzuweisungen und • Testparameter
SNEED-13 TAV-2016
QSTS Testdatenzuweisung Testdatenzuweisung: • &TF 01 • &DB SH5102 200 F // Datenbankzuweisung • &P1 = X‘01‘ // Parameterwertzuweisung • &P2 = ‘C‘ • &P3 = 99 • R7 = (FELD1) // Registerbelegung • FELD1 = ‘KUSE‘ // FeldinTalisierung • &SD SB24502 // Satzbeschreibung • FELD2 (1) = 30 // Eingabewertzuweisung • FELD3 = ‘KIEL‘ • &TD SH5102 SH5102A // Testdatensatz • AFELD = ‘WUERSIG‘ // Sollergebnisvorgabe
SNEED-14 TAV-2016
DV51001 ($ANAL)
DV51002 (DATPAR)
DV51003 (EXPAR)
DV51004 (ASSZEI,OPNPAR
DV51005 (DATPAR)
DV51006 (EXPAR)
DV51007 (ABLFPA)
DVDBTIO (IOPARM)
DV54009 (CONVEIN)
DV51008 (GETELEM)
KERN SORT
DV51010 (CONVAUS)
DVPRINT (LISTE)
Datenbank Tabelle
Ablauf Struktur
Diagramm
Externe Referenzen-
Liste Daten
Verzeichnis
Quelle Software Testsystem Statischer Analysator
Linkage Chart
DATPAR EXPAR OPNPAR DATPAR EXPAR ABLPAR IOPARM
CONVPAR ONPAR DBTAB CONVPAR ZEILE
QSTS Sta1scher Analysator SNEED-15 TAV-2016
DV53001 (TESTDAT)
DVDBTIO (IOPARAM)
DVDTIO1 (IOPARAM)
DV53002 (PRÜFDAT)
DVPRINT (LISTE)
Fehler Protokoll Testdaten
Tabelle Datenbank
Tabelle
DV53004 (GETELEM)
ZEILE GNEPAR
RETCODE IOPARAM IOPARAM
PanValet Member
Quelle Software Testsystem Testdatenverfasser
Linkage Chart
QSTS Testdatenerfassung SNEED-16 TAV-2016
Test Daten
Test Object
Datenbank Tabelle
DVDBTIO DV54002 (LinkDat)
DV54004 (GetParm)
DVDTI02 (IOParam)
DV54005 (Zuweise)
DV54006 (SaveData)
DV54008 (Abgleich)
DV54001 (TESTMON)
$PUT
IOPARAM LNMODNAM IOPARAM
DV54003 (ReadLnkt)
TESTDRU DV54009 (CONVEIN)
DV53003 (FormDat)
DVINDPR
DV53004 (GetElem)
Test Params
DV54011 (PrtDiff)
DV54010 ConvAus
DVPRNT ConvAus
Abgleichs Liste
PARM
ZEILE CONPAR
PDPARM DSPPAR ARBTAB COVPAR NAME IOPARAM
GNEPAR
Quelle Software Testsystem Testmonitor
Linkage Chart
QSTS QAL Testmonitor SNEED-17 TAV-2016
Test Object DV54040
(INTERUPT)
DV54041 (PDUMP)
DV54020 ($STUB)
DV54025 ($GET)
DV54035 ($IMS)
DV54030 ($PUT)
DV54025 (ZUWEISE)
TESTDRU
AUSGABE DATEIEN
PDUMP LISTE
DV54009 (CONVEIN)
DV54007 (GETDAT)
DVINDRPR
FEHLER LISTE
COVPAR R4 DSPPAR
STUBNAME DATEINAME SEGNAME DATEINAME
Quelle Software Testsystem Testmonitor
Linkage Chart
QSTS QAL Dynamischer Analysator SNEED-18 TAV-2016
Kienzle Embedded SoOware Test System
• Die Kienzle Apparate GmbH in Villingen stand vor dem Problem ihre in den Geräten eingebauten SoZware zu testen.
• Die SoZware musste in einer simulierten Umgebung unter Echtzeitbedingungen getestet werden.
• Kienzle haXe von der TU Karlsruhe eine eigene Programmiersprache für embedded SoZware entwickeln lassen – SPM – strukturierte Programmierung für Mikroprozessoren.
• 1981 erteilte Kienzle einen AuZrag an die SES GmbH ein Mikro-‐Testsystem für sie zu bauen. Drei Mitarbeiter des Szamok InsTtuts wurden dem Projekt zugeteilt, das schon nach sechs Monaten abgeschlossen war.
• In diesem Tool war die Durchlaufzeit entscheidend. Der Code dürZe deshalb nicht instrumenTert werden. Die Testüberdeckung wurde auf anderer Weise gemessen, nämlich über die CPU.
• Die Ergebnisse wurden erst nach dem Test kontrolliert und Fehler registriert, auch Fehler im Laufzeitverhalten
TAV-2016 SNEED-19
INCOMING PARAMETER
Order
OUTGOING PARAMETER Confirmation
Error Message
GUI Output Panel
GLOBAL DATA Transaction
statistic
GUI Input Panel
GLOBAL DATA Transaction
statistic
DB- Retcode ArticleNr.
Article Attr.
DB- Function ArticleNr.
Article Attr.
Horizontal Data Flow
Input
Data Flow
Output
Persistent Data
Persistent Data
Results Arguments Verticle Data Flow
Test Object
Arguments Results
Transient Data Transient Data
Simulierten Embedded SoOware SchniCstellen SNEED-20 TAV-2016
KTDS Testdatenzuweisung SNEED-21 TAV-2016
KTDS Preprozessor SNEED-22 TAV-2016
KTDS Prozessor SNEED-23 TAV-2016
KTDS Postprozessor SNEED-24 TAV-2016
T e s t m o n i t o r
Output- Speicher
Input- Speicher
Gerät unter Test
Test- ergebnis-
Aggregator
Test- ergebnis-
Datenbank
Test- ergebnis- Validator
Test- zustands- Erzeuger
Test- Datenbank
Test- Compiler
Test- sprache
Ausgabe- protokoll
Validations- protokoll
SPEZIFIKATION INPUT Assertions PRE Assertions
Testplatz VERIFIKATION OUTPUT Assertions INPUT Assertions
Test der eingebeCete SoOware durch KTDS
Tester
SNEED-25 TAV-2016
MBB Integra1onstestsystem für die Tornado Lagerhaltung
• Die Firma Messerschmidit-‐Belkow-‐Blöhm – MBB – war Hauptlieferant der Bundeswehr, vor allem was Flugzeuge anbetraf.
• Seit 1980 war MBB an der Herstellung des neuen europäischen Jägerbomber – Tornado – beteiligt. Das Flugzeug wurde in dem Werk Augsburg zusammengebaut.
• In diesem Werk haXe MBB eine miXelgroße IBM Anlage mit dem Betriebssystem DOS-‐VSE. Sie haXe für die Lagerhaltung ein Bill of Materials Processing System entwickeln lassen. Dieses System bestand aus vielen Teilsysteme, die einzeln geliefert wurden. Das Personal in Augsburg musste jede neue Release wieder testen.
• Um den Test zu beschleunigen erteilte MBB einen AuZrag an die Firma SES einen IntegraTonstestsystem für die Lagerhaltung zu entwickeln.
• Die IntegraTonstest-‐Tools wurden in Ungarn entwickelt und in Augsburg getestet. Als es heraus kam dass ungarische Staatsbürger dort testen wurde das Projekt auf das IBM Rechenzentrum in München verlagert. Es wurde dort ferTggestellt aber Harry Sneed dürZe einen deutschen Rüstungsbetrieb nie wieder betreten.
TAV-2016 SNEED-26
Test- Monitor
System- Auditor Instrumentor
Programm- test
Datei/DB- Dokumen-
tator
Datei/DB- Validator
Datei/DB- Generator
Terminal- Simulator
Masken- Validator
Masken- Generator
DB-Test DC-Test
MBB INTTEST
Augau des MBB Integra1onstestsystems SNEED-27 TAV-2016
Batch- Terminal- Simulator
Test- monitor
Ausgabe- masken
Eingabe- masken
Masken- Validator
Masken- Validations-
protokoll Masken- generator
In/Out- Asserts
Trace- Tabellen
Instr.- Source
System- ablauf- Auditor
System- Deckungs-
bericht Instrumentor Source
Datei/DB- Validator
Datei/DB- Validations-
protokoll Datei/DB- Generator
In/Out- Asserts
Datei/DB- Dokumen-
tator
Datei/DB- Validations-
protokoll
Datei-DB
LOG
Im Test Vor dem Test Nach dem Test
Ablauf des MBB Integra1onstestsystems SNEED-28 TAV-2016
Testdaten- generierung Test Testergebnis-
validation Testdaten-
spezifikation Testjob-
erstellung
Testdaten- protokoll
Test- ergebnis- protokoll
Test- jobs
Test- fall-
Bank Test- DB
LOG- Datei
Include- LIB
Tester Tester
Dateien Sätze Felder
DOS-VSE
DOS Job Quelle VBOMP
VSAM
Integra1onstest der Batchjobs SNEED-29 TAV-2016
Entlade- dienst
Datei- komparator
Dateire- formator
Entlade- dienst
Dateire- formator
Abweichungs- bericht
Datenbank vorher
Datenbank nachher
Datei vorher
Datei nachher
Reformatierter Inhalt vorher
Reformatierter Inhalt nachher
Abgleich der Daten im Regressionstest SNEED-30 TAV-2016
Die ACM Konferenz an der Bundeswehr Hochschule im März 1982
• Am 25./26. März 1982 fand die erste wissenschaZliche Tagung zum Thema SoZwaretest in deutscher Sprache staX. Veranstalter waren die Bundeswehr Hochschule Neubiberg und die Firma SES.
• Keynote Speaker waren Prof. C. Ramamoorthy von der University California in Berkley und Les Belady von der IBM Watson Labor.
• Es gab Beiträge sowohl aus der WissenschaZ als auch aus der Praxis. Hier sind alle zu Wort gekommen die sich damals mit der jungen Disziplin „SoZware Test“ befasst haben, u.A – Heinz Bons und Rudolf van Megen zum Thema Qualitätsziele sowie zum
Thema TEST-‐COVER für die TeststaTsTk – Werner Schmied von Siemens zum Thema SoZware Prüffeld – P. Ehrensberger von MBB und N. Ramsperger von der IABG zum Thema
Qualitätssichung in großen SoZwareprojekten. – L. Gemeiner und U. Voges von der TU Karlsruhe zum Thema Erfahrung
mit dem Einsatz des automaTschen TestTools SADAT – M. Majoros vom Szamok InsTtut zum Thema SoZTest
TAV-2016 SNEED-31
Test Cover zur Messung der Testüberdeckung SNEED-32
TAV-2016
Das Testsystem SADAT von der TU Karlsruhe SNEED-33
TAV-2016
Das Testsystem SoOTest vom Szamok Ins1tut SNEED-34
TAV-2016
Test Bed
Test Auditor
Coverage reports
Test DeviaTons
Test Paths
Instru- mentor
Program Source
Assertion Compiler
AsserTon Procedures
Test data
Protocol
Drivers & Stubs
COBOL PL/1
SoftTest testet Module gegen eine formale Testspezifikation
Instrumented Sources
Test Procedures
Stand der Testautomation Im Jahre 1982
If (x > y) assert pre a = 2; assert pre b = 3; assert post c = 5; End,
Auf Statement Branch or Path Stufe
SNEED-35 TAV-2016
Eine neue Technologie ist entstanden
• Die ACM Tagung an der Bundeswehr Hochschule markierte das Ende der Pionierzeit und den Beginn einer neuen Technologie.
• Die deutschen Hochschulen begannen sich mit dem Thema SoZwaretest zu befassen. Professionelle Schulungsanstalten wie das Control Data insTtute, die Integrata und die GES nahm Kurse über SoZwaretest in ihr Programm auf. Immer mehr Beratungsfirmen fingen an Testberatung an zu bieten. Es gab sogar Firmen, wie die SQS GmbH in Köln, die sich ganz auf der Qualitätssicherung von SoZware spezialisiert haben. Es würde aber noch 9 Jahre vergehen bis die GI-‐Fachgruppe TAV ins Leben gerufen wurde.
• Mit diesem Vortrag wollte ich belegen, dass SoZwaretest vom Anfang an eng mit der TestautomaTon verstrickt war. TestautomaTon in aller ihrer Ausprägungen von der Testüberdeckungsmessung bis zu selbst testenden Programmen ist das Fundament auf dem die TesXechnologie aufgebaut ist. Ohne AutomaTon sind Testverfahren weder durchsetzbar noch kontrollierbar.
TAV-2016 SNEED-36