| Current Path : /var/www/web-klick.de/dsh/90_akt/DEV1303/Documentation/ |
Linux ift1.ift-informatik.de 5.4.0-216-generic #236-Ubuntu SMP Fri Apr 11 19:53:21 UTC 2025 x86_64 |
| Current File : /var/www/web-klick.de/dsh/90_akt/DEV1303/Documentation/Aktuelle_Beschreibung.txt |
13.2.2012
---------
Version 0.83:
Änderungen gegenüber 0.82 (9.2.2012):
Der Code von AutoDB.pm wurde in AutoItem.pm übernommen,
da dort die spezifischen Eigenschaften der ObjProcess-Objekte
ihren Platz finden müssen. AutoDB.pm selbst ist daher jetzt überflüssig.
1. AutoTest installieren:
=========================
Perl muss installiert sein und im Verzeichnis C:\perl
vorliegen.
Ins Verzeichnis c:\perl\lib gehen und dort die Datei
autotest_0_83.zip (steht im Projektverzeichnis)
entpacken.
Dann ins Verzeichnis C:\perl\bin gehen und den Befehl ausführen:
perl -e "use DivBasicF::AutoServer; DivBasicF::AutoServer->make_batch()"
(Hiermit werden sieben Dateien erzeugt - ot, or, ox, ot.bat, or.bat, ox.bat
sowie howto.txt, von denen allerdings nur die .bat-Dateien unter
Windows wirklich benötigt werden).
Der Ort für die AutoTest-Dateien kann auch ein ander sein,
m,an muß dann aber den Pfad zu den Perl-Dateien mit der Umgebungsvariablen
PERL5LIB einstellen, damit der Perl-Interpreter diese Module findet.
Auf den virtuellen Maschinen 122 und 123 ist schon alles fertig installiert.
Die AutoTest-Dateien liegen in U:\ift\appserv\, und PERL5LIB ist
entsprechend eingestellt, wenn man die Shell shell_gen6000.bat aufruft.
2. Grundlegende Begriffe von AutoTest
=====================================
2.1. Was ist AutoTest?
----------------------
AutoTest ist ein Framework, mit dem es möglich ist, viele parallele
(auch langlaufende) Tests - automatische, halbautomatische und manuelle -
durchzuführen, zu bewerten und zu reportieren. Auch die Testfallgenerierung
über Test-Generatoren ist mit den gleichen Methoden möglich.
Die Bewertung der Tests geschieht hinsichtlich vorher definierten,
aus der Spezifikation nstammenden Requirements, und jeder Test
wird hinsichtlich seiner Relevanz für das jeweilige Requirement
qualifiziert.
AutoTest ist in Perl geschrieben, und auch die Tests werden in
Perl geschrieben. Das hat den Vorteil, daß zur Beschreibung der Tests
eine allgemein zur Verfügung stehende, ausgereifte Programmiersprache
verwendet wird, für die allerorten Experience zur Verfügung steht.
2.2. Tests, Testfälle, Testgeneratoren
---------------------------------------
Ein 'Testfall' ist eine Vorschrift, in der angegeben ist, in welcher Weise
bestimmte Aktionen mit dem zu testenden Target vorgenommen werden,
um dann über Checks eine Bewertung des Testfalls vorzunehmen. Damit
ist ein Testfall also nichts anderes als ein Programm, wobei man
sich meistens auf eine reinen Batch-Struktur beschränkt - d,h,
die Aktionen werden hintereinander ausgeführt, ohne daß es Schleifen
und Verzweigungen gibt.
Ein 'Test' selbst ist das Ergebnis einer Durchführung eines Testfalles.
Er enthält Informationen zum Testlauf, insbesondere die Bewertung
des Tests (OK, WARNING oder NOK), sowie weitere Angaben, die z.B.
im Bugtracking helfen können.
Ein Test-Generator ist wiederum ein Programm, das Testfälle erzeugt
(also ein Programm, das wieder Programme erzeugt).
Test, Testfälle und Test-Generatoren werden im Rahmen von AutoTest
unter dem Sammelbegriff 'Test-items' zusammengefaßt.
Wenn man auch einen Test als ein Programm auffaßt, das nichts
anderes tut, als die Logging-Information, die dieser Test enthält,
auszugeben, dann kann man allgemein sagen:
--> Ein Test-Item ist ein Programm, das wieder ein Programm erzeugt.
o Test-Generatoren erzeugen Testfälle.
o Testfälle erzeugen Tests
o Tests erzeugen Logs.
Ganz generell:
Ein Testitem erzeugt wieder ein Testitem.
2.6. Requirements, Fehlerfindewahrscheinlichkeiten, Relevanzen
---------------------------------------------------------------
Jedes Test-Item reagiert 'sensibel' auf Fehler im zu prüfenden Target,
aber jeder Test in spezifischer Weise. Genauer gesagt: Hat man Requirements
definiert, die erfüllt sein müssen, dann kann man für einen Test versuchen
abzuschätzen, wie groß die Wahrscheinlichkeit ist, daß der Test tatsächlich
fehlschlägt, wenn das jeweilige Requirement falsch implementiert ist
(Fehlerfindewahrscheinlichkeit, oder auch: Sensitivität). Eine Einschätzung
dafür kann man bekommen, wenn man eine Entscheidung darüber trifft, wieviele
Tests vom zugrundeliegenden Testfall man für nötig hält. Sind das beispielsweise
100 Tests, dann ist die Relevanz des Testfalls für dieses Requirement 0.01
(der einzelnen Testfall hat dann die Fehlerfindewahrfscheinlichkeit
0.01), bei 1000 erforderlichen Tests 0.001 (mit jeweils 0.001
Fehlerfindewahrscheinlichkeit).
In der klassischen Test-Theorie ist die 'Test-Abdeckung' der
Prozentsatz der Tests, die schon erfolgreich ausgeführt wurden.
Aber selbst bei einer 100% Testabdeckung kann man nicht
davon ausgehen, daß Fehler damit ausgeschlossen sind. Ist die
Fehlerfindewahrscheinlichkeit f, dann hat man eine Sicherheit von
1 - ( 1 - f)^n
daß man einen bestehenden Fehler tatsächlich findet mit n Testfällen.
D.h. bei 0.01 Fehlerfidnewahrscheinlichkeit und 100 Tests bleibt
ein Restunsicherheit von ca. 36%, erst bei fünfmal sovielen
Testfällen kann man die Restunsicherheit unter 1 Prozent drücken.
Das gilt allgemein: Bei n = 5/f ist die Restunsicherheit kleiner
als 1 Prozent.
2.6. Architekturen und User
----------------------------
Jeder Test wird in einem bestimmten Kontext ausgeführt. Zu diesem
Kontext gehört nicht nur die gerade getestete Software-Version,
sondern der gesamte Kontext, also z.B. auch Datenbankversionen,
weitere Hardware, Betriebssysteme usw. Getestet wird also stets
gegenüber Architekturen. Sie werden durch entsprechende
Kürzel der Form ARCH_<pattern> bezeichnet.
Ferner wird für jeden Lauf eines Test-Items festgehalten, wer
diesen Lauf gestartet hat, und zu welcher Zeit er losgelaufen ist.
Jeder Benutzer von AutoTest erhält ein Personenkürzel der
Form: USER_<pattern>.
3. AutoTest auf der Konsole
---------------------------
AutoTest kann auf der Konsole gesteuert werden. Hierfür gibt es die
drei Kommandos ot, ox, und or (die als Batch-Dateien bei der
Installation erzeugt wurden und nun in C:\perl\bin stehen).
Die einzelnen Kommandos werden im folgenden erlaütert.
3.1. Test-Items, Wurzel-Item und Test-Tree-Verzeichnis
-------------------------------------------------------
Die Basisklasse aller Test-Items ist DivBasicF::AutoItem.
Das einfachste aller Test-Items ist daher:
-------------------------------------------------------
package MyTestProject;
use vars qw(@ISA);
use DivBasic::AutoItem;
@ISA = qw(DivBasicF::AutoItem);
1;
-------------------------------------------------------
Mann kann diesem Modul natürlich weitere beliebige Methoden
hinzufügen. Insbesondere können die Methoden result, remark,
user, requ und run überladen werden. Deren Bedeutung wird
weiter untren erlaütert.
Ein Modul, das direkt von DivBasicF::AutoItem erbt, heißt
Wurzel-item, und das Verzeichnis, in dem es liegt, heißt
Test-Tree-Verzeichnis.
3.2. Die run-Methode
---------------------
Jedes Test-Item muss eine run-Methode besitzen. Sie erzeugt ein Child-Item.
Die run-Methode muss die folgende Struktur haben:
sub run {
my $self = shift;
$self->test_start(@_);
...
eigener Code
...
$self->test_end();
}
Der Aufruf geschieht dann mit den folgenden Parametern:
$self->run(<requ1>,<sensitivity1>,<requ2>,<sensitivity2>, ...)
wobei die <requxxx> Requirements sind und <sensitivityxxx> die
zugehörigen Fehlerfindewahrscheinlichkeiten (Sensitivitäten) für diesen
Test. Das Kommando test_start bewirkt, daß die Werte aus dem Array
$self->requ(), in dem die entsprechenden Relevanzen des Testfalls stehen,
als Sensitivitäten der entsprechenden Requirements mit übernommen werden.
Architektur und User werden in der gleichen Weise mit übergeben,
und zwar mit der formalen Sensitivität 1.
Beispiel:
sub requ { [ Req1, 0.05,
Req2, 0.01,
] }
$self->run('ARCH_001',1,'USER_cg',1,R3,0.1)
Damit wird dem Test für die Requirements Req1, Req2 bzw. R3 die
dioe Sensitivitäten 0.05, 0.01 bzw. 0.1 zugeordnet; die
Architektur ist ARCH_001, der User, der den Lauf gestartet hat: cg.
Das Kommando test_end bewirkt, daß in die Objektvariable
$self->{'program'} der Code des Perl-Moduls eingetragen wird,
das das Child-Item repröäsentiert. Hierbei werden die
Funktionen result, remark, user und requ mit den entsprechenden
Werten der Objektvariablen $self->{'result'}, $self->{'remark'},
$self->{'user'} und $self->{'requ'} belegt, sowie der Inhalt
von $self->{'log'} als Funktionsblock in den Modulcode eingefügt.
3.5. Einfrieren und Auftauen von Test-Item-Prozessen
----------------------------------------------------
DivBasicF::AutoItem stellt die Methode sleep(<time>,<func>,<par1>,<par2>,...)
zur Verfügung. Diese bewirkt, daß der laufende Prozess in einer Task-Datenbank
eingefroren wird, dort für die Zeit <time> schläft, und nach dem 'Auftauen'
die Methode <func> ausführt, mit den Parametern <par1>,<par2> ...
Ist <func> = "" , dann wird für <func> das jeweils nächste Element aus einer
Liste von Funktionen aus dem jeweiligen Perl-Modul gesetzt. Diese
Funktionen müssen mit r oder t beginnen und werden sortiert, so daß
man stets weiß, wewlche Funktion als nächstes angesteuert wird.
Damit das Auftauen funktioniert, muß ein weiterer Prozeß die Task-Datenbank
immer wieder durchsehen, ob evtl. ein eingefrorener Task seine
'Aufweck-Zeit' erreicht hat, um ihn dann wieder zu aktivieren.
Die Task-Datenbank enthält zusätzliche Spalten (in AutoDB definiert),
die bestimmte Objektvariablen des jeweils laufenden Prozesses in
den entsprechenden Spalten nochmals ablegt. Dies erleichtert das Finden
entsprechender Tasks bzw. stellt Informationen zur Verfügung, ohne
daß der Task explizit wieder aufgerufen werden muß.
Neben der Spalte program gibt es noch die Spalte package, die den
Package-Namen des erzeugten Child-Items enthält, sowie noch die Spalten
result und remark.
Nachdem die run-Methode durchgelaufen ist, bleibt der Task im Task-Manager
aktiv, also auch in der Datenbank, und stellt die Spalten result, remark,
program und package zur Verfügung. Indiesem Sinne ist ein Child-Item
eines Items eine laufende Instanz des Items, das in der Datenbank
eingefroren ist.
4. Testprojekte und Anwendung von AutoTest
===========================================
Ein Testprojekt beginnt man damit, indem man ein Test-Tree-Verzeichnis
festlegt, z.B. C:\sktest. Dorthinein muß das Wurzel-Item eingestellt werden,
d.h. ein Perl-Modul, das direkt von DivBasicF::AutoItem erbt. Weitere
statische Module können hinzigufügt werden, soweit im Wurzel-Item
benötigt, am besten in Unterverzeichnissen. Die zugehörige
Testtree-Datenbank wird on-the-fly erzeugt, oder kann, wenn sie vorhanden
ist, auch in das Wurzelverzeichnis gestellt werden.
Als allereinfachtes Wurzel-Item kann das Modul MyTestProject aus Abschnitt
3.1. gewählt werden, es enthält dann eben keine weiteren proprietären
Methoden.
Ein eiwas komplexeres Beispiel (Miele): Die zip-Datei gen6000_0_82.zip im
Test-Tree-Verzeichnis entpacken. Dort steht dann das Wurzel-Item Gen6000.pm sowie ein
Unterverzeichnis PPLTest, in dem weiter von Gen6000.pm benötigte
Module stehen. Die zugehörige Test-Datenbank findet sich ebenfalls im
Projektverzeichnis: die Datei testtree_manuell_0_82.db ebenfalls
ins Test-Tree-Verzeichnis kopieren, und zwar unter dem Namen:
testtree.db. Diese Umbenennung ist wichtig!
Zu den einzelnen Befehlen:
Exportieren aller Test-Items aus der testtree.db in das Test-Tree-Verzeichnis:
ot Gen6000 a(ll)
Exportieren eines einzelnen Test-Items aus der testtree.db in das Test-Tree-Verzeichnis:
ot Gen6000 x (export)
Löscht man jetzt die Testdatenbank testtree.db, dann kann man sie durch
ot Gen6000 m(ulti)
wieder erzeugen.
Editieren von Test-Items.
Entweder im Test-Treeverzeichnis editieren, und dann aufrufen:
ot <testitem> i(mport)
oder direkt editieren mit:
ot <testitem> e(dit)
Run eines Test-Items:
ot <testitem> r(un) <arch> 1 <user> 1
Dabei ist <arch> ein Achitektur-Kürzel, und <user eine User-Angabe
Die Einsen sind wichtig!
In einer zweiten Konsole muss dann ox laufen, damit die
schlafenden Prozesse wieder aufgeweckt werden.
Erstellung eines Excel-Reports für ein Test-Item:
ot <testitem> report <tiefe> <arch1> <arch2> ...
<tiefe>: Zahl der Unteritem-Ebenen, die verfolgt werden sollen.
5. Beschreibung der fünf Module ObjTask, ObjProcess, AutoItem, AutoServer und AutoDB
5.1. Der Task-Manager Obj-Task
Stichworte:
Kommunikation ueber die Datenbank,
Messages (auch zeitverzögerte)
Dump von Objekten mit der Methode push
Wiederauftauen von Objekten mit fetch, Schlüsselwort MESSAGE
(wenn eine Message für das LObjekt vorliegt, wird es
gehlot und aufgetaut)
Datenbank-Tabellen:
conn: Message-Tabelle
Wichtige Spalten:
replynr, msgid (20-stellige Message-Identifier)
msgtime (Zeitverzögertes Aktivieren der Message),
text: gedumpter Message-Inhalt
conn_store: Tabelle der gedumpten Objekte.
Wichtige Spalten:
text: Gedumptes Objekt
conn: damit verknüpfter Message-Identifier
Weitere Index-Spalten: program, package, result, remark
Die Index-Spalten werden in der Environment-Variable
procidx übergeben (kommaseparierte Liste).
Wenn man z.B. in $ENV{'procidx'} hat:
index1,index2
dann werden die Werte von $self->{'index1'} bzw.
$self->{'index2'} beim Dumpen des Objektes
$self in die entsprechenden Spalten index1 und
index2 geschrieben. Damit kann man Informationen
über das Objekt mit SQWL suchen und ausgeben, OHNE das
Objekt wieder auftauen zu müssen.
Ein zu dumpendes Objekt MUSS die Methode IDX haben,
die als letztes immer kurz vor dem Dumpen aufgerufen wird.
.....
5.2. AutoServer - Methode server:
Ist eine Endlosschleife, die dafür sorgt, daß Objekte, für die
eine Message vorliegt, wieder aufgetaut werden. Mehrere ObjServer-
Prozesse können gleichzeitig laufen, was die Performance erhöht
(abhängig von der Leistung des Host).
5.3. AutoServer - Methode client
Hier die Aktionen
1. run: Läßt ein Test-Item als Programm laufen
2. edit: Editiert ein test-Item
3. import: Importiert ein Test-Item aus dem Datei-Baum in die Datenbank
4. multi: Importiert einen ganzen Unterbaum
5. export: Exportiert ein Item mitsamt seinen Childs
6. all: Exportiert einen ganzen Unterbaum
7. report: Erstellt einen Excel-Report
5.4. AutoItem: Die Basisklasse für alle Test-Items.
Methoden test_start, test_end, sleep erlaütern.
Für die Objekt-Daten müssen die Indexe angelegt werden
(in der Environment-Variablen procidx):
package,program,result,remark,user,requirement
Die entsprechenden Objekt-Variablen werden in der Methode
IDX (wird aufgerufen kurz vor dem Dumpen) jeweils
aktualisiert:
package: Paketname = Test-Item-name
program: Eigentlicher Programmcode des Test-Items
result: Ergebnis
remark: Bemerkung
user: User-Angaben
Hier werden die konsolidierten Ergebnisse aus den Child-Items
berechnet und eingetragen.
5.5. ObjProcess: Basisklasse von AutoItem
5.6. AutoDB: Enhält für Testitems wichtige Spaltenindexe
sowie die Definition der Requirement-Relevance-Tabelle.
Wichtige Environment-Variablen:
procdb: Datenbank der Test-Items
procdir: Dateisystem-Repräsentation
procidx: Indexe der gedumpten Objekte (siehe oben)
Diese Environment-Variablen werden - wenn nichts anderes angegeben ist -
automatisch gesetzt:
procdir: dasjenige Verzeichnis, das das Wurzel-Item enthält
procdb: die darin enthaltene Datenbank testtree.db
procidx: Indexe sind gesetzt in AutoDB.pm
============================================================================================
============================================================================================
9.2.2012
--------
Version 0.82:
Änderungen gegenüber Version vom 6.2.2012:
o Fehler korrigiert bei 'AutoTest installieren':
AutoServer statt ObjClient->new()
o Dokumentation weitestgehend neu geschrieben.
1. AutoTest installieren:
=========================
Perl muss installiert sein und im Verzeichnis C:\perl
vorliegen.
Ins Verzeichnis c:\perl\lib gehen und dort die Datei
autotest_0_82.zip (steht im Projektverzeichnis)
entpacken.
Dann ins Verzeichnis C:\perl\bin gehen und den Befehl ausführen:
perl -e "use DivBasicF::AutoServer; DivBasicF::AutoServer->make_batch()"
(Hiermit werden sieben Dateien erzeugt - ot, or, ox, ot.bat, or.bat, ox.bat
sowie howto.txt, von denen allerdings nur die .bat-Dateien unter
Windows wirklich benötigt werden).
2. Grundlegende Begriffe von AutoTest
=====================================
2.1. Was ist AutoTest?
----------------------
AutoTest ist ein Framework, mit dem es möglich ist, viele parallele
(auch langlaufende) Tests - automatische, halbautomatische und manuelle -
durchzuführen, zu bewerten und zu reportieren. Auch die Testfallgenerierung
über Test-Generatoren ist mit den gleichen Methoden möglich.
Die Bewertung der Tests geschieht hinsichtlich vorher definierten,
aus der Spezifikation nstammenden Requirements, und jeder Test
wird hinsichtlich seiner Relevanz für das jeweilige Requirement
qualifiziert.
AutoTest ist in Perl geschrieben, und auch die Tests werden in
Perl geschrieben. Das hat den Vorteil, daß zur Beschreibung der Tests
eine allgemein zur Verfügung stehende, ausgereifte Programmiersprache
verwendet wird, für die allerorten Experience zur Verfügung steht.
2.2. Tests, Testfälle, Testgeneratoren
---------------------------------------
Ein 'Testfall' ist eine Vorschrift, in der angegeben ist, in welcher Weise
bestimmte Aktionen mit dem zu testenden Target vorgenommen werden,
um dann über Checks eine Bewertung des Testfalls vorzunehmen. Damit
ist ein Testfall also nichts anderes als ein Programm, wobei man
sich meistens auf eine reinen Batch-Struktur beschränkt - d,h,
die Aktionen werden hintereinander ausgeführt, ohne daß es Schleifen
und Verzweigungen gibt.
Ein 'Test' selbst ist das Ergebnis einer Durchführung eines Testfalles.
Er enthält Informationen zum Testlauf, insbesondere die Bewertung
des Tests (OK, WARNING oder NOK), sowie weitere Angaben, die z.B.
im Bugtracking helfen können.
Ein Test-Generator ist wiederum ein Programm, das Testfälle erzeugt
(also ein Programm, das wieder Programme erzeugt).
Test, Testfälle und Test-Generatoren werden im Rahmen von AutoTest
unter dem Sammelbegriff 'Test-items' zusammengefaßt.
Wenn man auch einen Test als ein Programm auffaßt, das nichts
anderes tut, als die Logging-Information, die dieser Test enthält,
auszugeben, dann kann man allgemein sagen:
--> Ein Test-Item ist ein Programm, das wieder ein Programm erzeugt.
o Test-Generatoren erzeugen Testfälle.
o Testfälle erzeugen Tests
o Tests erzeugen Logs.
Ganz generell:
Ein Testitem erzeugt wieder ein Testitem.
2.6. Requirements, Fehlerfindewahrscheinlichkeiten, Relevanzen
---------------------------------------------------------------
Jedes Test-Item reagiert 'sensibel' auf Fehler im zu prüfenden Target,
aber jeder Test in spezifischer Weise. Genauer gesagt: Hat man Requirements
definiert, die erfüllt sein müssen, dann kann man für einen Test versuchen
abzuschätzen, wie groß die Wahrscheinlichkeit ist, daß der Test tatsächlich
fehlschlägt, wenn das jeweilige Requirement falsch implementiert ist
(Fehlerfindewahrscheinlichkeit, oder auch: Sensitivität). Eine Einschätzung
dafür kann man bekommen, wenn man eine Entscheidung darüber trifft, wieviele
Tests vom zugrundeliegenden Testfall man für nötig hält. Sind das beispielsweise
100 Tests, dann ist die Relevanz des Testfalls für dieses Requirement 0.01
(der einzelnen Testfall hat dann die Fehlerfindewahrfscheinlichkeit
0.01), bei 1000 erforderlichen Tests 0.001 (mit jeweils 0.001
Fehlerfindewahrscheinlichkeit).
In der klassischen Test-Theorie ist die 'Test-Abdeckung' der
Prozentsatz der Tests, die schon erfolgreich ausgeführt wurden.
Aber selbst bei einer 100% Testabdeckung kann man nicht
davon ausgehen, daß Fehler damit ausgeschlossen sind. Ist die
Fehlerfindewahrscheinlichkeit f, dann hat man eine Sicherheit von
1 - ( 1 - f)^n
daß man einen bestehenden Fehler tatsächlich findet mit n Testfällen.
D.h. bei 0.01 Fehlerfidnewahrscheinlichkeit und 100 Tests bleibt
ein Restunsicherheit von ca. 36%, erst bei fünfmal sovielen
Testfällen kann man die Restunsicherheit unter 1 Prozent drücken.
Das gilt allgemein: Bei n = 5/f ist die Restunsicherheit kleiner
als 1 Prozent.
2.6. Architekturen und User
----------------------------
Jeder Test wird in einem bestimmten Kontext ausgeführt. Zu diesem
Kontext gehört nicht nur die gerade getestete Software-Version,
sondern der gesamte Kontext, also z.B. auch Datenbankversionen,
weitere Hardware, Betriebssysteme usw. Getestet wird also stets
gegenüber Architekturen. Sie werden durch entsprechende
Kürzel der Form ARCH_<pattern> bezeichnet.
Ferner wird für jeden Lauf eines Test-Items festgehalten, wer
diesen Lauf gestartet hat, und zu welcher Zeit er losgelaufen ist.
Jeder Benutzer von AutoTest erhält ein Personenkürzel der
Form: USER_<pattern>.
3. AutoTest auf der Konsole
---------------------------
AutoTest kann auf der Konsole gesteuert werden. Hierfür gibt es die
drei Kommandos ot, ox, und or (die als Batch-Dateien bei der
Installation erzeugt wurden und nun in C:\perl\bin stehen).
Die einzelnen Kommandos werden im folgenden erlaütert.
3.1. Test-Items, Wurzel-Item und Test-Tree-Verzeichnis
-------------------------------------------------------
Die Basisklasse aller Test-Items ist DivBasicF::AutoItem.
Das einfachste aller Test-Items ist daher:
-------------------------------------------------------
package MyTestProject;
use vars qw(@ISA);
use DivBasic::AutoItem;
@ISA = qw(DivBasicF::AutoItem);
1;
-------------------------------------------------------
Mann kann diesem Modul natürlich weitere beliebige Methoden
hinzufügen. Insbesondere können die Methoden result, remark,
user, requ und run überladen werden. Deren Bedeutung wird
weiter untren erlaütert.
Ein Modul, das direkt von DivBasicF::AutoItem erbt, heißt
Wurzel-item, und das Verzeichnis, in dem es liegt, heißt
Test-Tree-Verzeichnis.
3.2. Die run-Methode
---------------------
Jedes Test-Item muss eine run-Methode besitzen. Sie erzeugt ein Child-Item.
Die run-Methode muss die folgende Struktur haben:
sub run {
my $self = shift;
$self->test_start(@_);
...
eigener Code
...
$self->test_end();
}
Der Aufruf geschieht dann mit den folgenden Parametern:
$self->run(<requ1>,<sensitivity1>,<requ2>,<sensitivity2>, ...)
wobei die <requxxx> Requirements sind und <sensitivityxxx> die
zugehörigen Fehlerfindewahrscheinlichkeiten (Sensitivitäten) für diesen
Test. Das Kommando test_start bewirkt, daß die Werte aus dem Array
$self->requ(), in dem die entsprechenden Relevanzen des Testfalls stehen,
als Sensitivitäten der entsprechenden Requirements mit übernommen werden.
Architektur und User werden in der gleichen Weise mit übergeben,
und zwar mit der formalen Sensitivität 1.
Beispiel:
sub requ { [ Req1, 0.05,
Req2, 0.01,
] }
$self->run('ARCH_001',1,'USER_cg',1,R3,0.1)
Damit wird dem Test für die Requirements Req1, Req2 bzw. R3 die
dioe Sensitivitäten 0.05, 0.01 bzw. 0.1 zugeordnet; die
Architektur ist ARCH_001, der User, der den Lauf gestartet hat: cg.
Das Kommando test_end bewirkt, daß in die Objektvariable
$self->{'program'} der Code des Perl-Moduls eingetragen wird,
das das Child-Item repröäsentiert. Hierbei werden die
Funktionen result, remark, user und requ mit den entsprechenden
Werten der Objektvariablen $self->{'result'}, $self->{'remark'},
$self->{'user'} und $self->{'requ'} belegt, sowie der Inhalt
von $self->{'log'} als Funktionsblock in den Modulcode eingefügt.
3.5. Einfrieren und Auftauen von Test-Item-Prozessen
----------------------------------------------------
DivBasicF::AutoItem stellt die Methode sleep(<time>,<func>,<par1>,<par2>,...)
zur Verfügung. Diese bewirkt, daß der laufende Prozess in einer Task-Datenbank
eingefroren wird, dort für die Zeit <time> schläft, und nach dem 'Auftauen'
die Methode <func> ausführt, mit den Parametern <par1>,<par2> ...
Ist <func> = "" , dann wird für <func> das jeweils nächste Element aus einer
Liste von Funktionen aus dem jeweiligen Perl-Modul gesetzt. Diese
Funktionen müssen mit r oder t beginnen und werden sortiert, so daß
man stets weiß, wewlche Funktion als nächstes angesteuert wird.
Damit das Auftauen funktioniert, muß ein weiterer Prozeß die Task-Datenbank
immer wieder durchsehen, ob evtl. ein eingefrorener Task seine
'Aufweck-Zeit' erreicht hat, um ihn dann wieder zu aktivieren.
Die Task-Datenbank enthält zusätzliche Spalten (in AutoDB definiert),
die bestimmte Objektvariablen des jeweils laufenden Prozesses in
den entsprechenden Spalten nochmals ablegt. Dies erleichtert das Finden
entsprechender Tasks bzw. stellt Informationen zur Verfügung, ohne
daß der Task explizit wieder aufgerufen werden muß.
Neben der Spalte program gibt es noch die Spalte package, die den
Package-Namen des erzeugten Child-Items enthält, sowie noch die Spalten
result und remark.
Nachdem die run-Methode durchgelaufen ist, bleibt der Task im Task-Manager
aktiv, also auch in der Datenbank, und stellt die Spalten result, remark,
program und package zur Verfügung. Indiesem Sinne ist ein Child-Item
eines Items eine laufende Instanz des Items, das in der Datenbank
eingefroren ist.
4. Testprojekte und Anwendung von AutoTest
===========================================
Ein Testprojekt beginnt man damit, indem man ein Test-Tree-Verzeichnis
festlegt, z.B. C:\sktest. Dorthinein muß das Wurzel-Item eingestellt werden,
d.h. ein Perl-Modul, das direkt von DivBasicF::AutoItem erbt. Weitere
statische Module können hinzigufügt werden, soweit im Wurzel-Item
benötigt, am besten in Unterverzeichnissen. Die zugehörige
Testtree-Datenbank wird on-the-fly erzeugt, oder kann, wenn sie vorhanden
ist, auch in das Wurzelverzeichnis gestellt werden.
Als allereinfachtes Wurzel-Item kann das Modul MyTestProject aus Abschnitt
3.1. gewählt werden, es enthält dann eben keine weiteren proprietären
Methoden.
Ein eiwas komplexeres Beispiel (Miele): Die zip-Datei gen6000_0_82.zip im
Test-Tree-Verzeichnis entpacken. Dort steht dann das Wurzel-Item Gen6000.pm sowie ein
Unterverzeichnis PPLTest, in dem weiter von Gen6000.pm benötigte
Module stehen. Die zugehörige Test-Datenbank findet sich ebenfalls im
Projektverzeichnis: die Datei testtree_manuell_0_82.db ebenfalls
ins Test-Tree-Verzeichnis kopieren, und zwar unter dem Namen:
testtree.db. Diese Umbenennung ist wichtig!
Zu den einzelnen Befehlen:
Exportieren aller Test-Items aus der testtree.db in das Test-Tree-Verzeichnis:
ot Gen6000 a(ll)
Exportieren eines einzelnen Test-Items aus der testtree.db in das Test-Tree-Verzeichnis:
ot Gen6000 x (export)
Löscht man jetzt die Testdatenbank testtree.db, dann kann man sie durch
ot Gen6000 m(ulti)
wieder erzeugen.
Editieren von Test-Items.
Entweder im Test-Treeverzeichnis editieren, und dann aufrufen:
ot <testitem> i(mport)
oder direkt editieren mit:
ot <testitem> e(dit)
Run eines Test-Items:
ot <testitem> r(un) <arch> 1 <user> 1
Dabei ist <arch> ein Achitektur-Kürzel, und <user eine User-Angabe
Die Einsen sind wichtig!
In einer zweiten Konsole muss dann ox laufen, damit die
schlafenden Prozesse wieder aufgeweckt werden.
Erstellung eines Excel-Reports für ein Test-Item:
ot <testitem> report <tiefe> <arch1> <arch2> ...
<tiefe>: Zahl der Unteritem-Ebenen, die verfolgt werden sollen.
5. Beschreibung der fünf Module ObjTask, ObjProcess, AutoItem, AutoServer und AutoDB
5.1. Der Task-Manager Obj-Task
Stichworte:
Kommunikation ueber die Datenbank,
Messages (auch zeitverzögerte)
Dump von Objekten mit der Methode push
Wiederauftauen von Objekten mit fetch, Schlüsselwort MESSAGE
(wenn eine Message für das LObjekt vorliegt, wird es
gehlot und aufgetaut)
Datenbank-Tabellen:
conn: Message-Tabelle
Wichtige Spalten:
replynr, msgid (20-stellige Message-Identifier)
msgtime (Zeitverzögertes Aktivieren der Message),
text: gedumpter Message-Inhalt
conn_store: Tabelle der gedumpten Objekte.
Wichtige Spalten:
text: Gedumptes Objekt
conn: damit verknüpfter Message-Identifier
Weitere Index-Spalten: program, package, result, remark
Die Index-Spalten werden in der Environment-Variable
procidx übergeben (kommaseparierte Liste).
Wenn man z.B. in $ENV{'procidx'} hat:
index1,index2
dann werden die Werte von $self->{'index1'} bzw.
$self->{'index2'} beim Dumpen des Objektes
$self in die entsprechenden Spalten index1 und
index2 geschrieben. Damit kann man Informationen
über das Objekt mit SQWL suchen und ausgeben, OHNE das
Objekt wieder auftauen zu müssen.
Ein zu dumpendes Objekt MUSS die Methode IDX haben,
die als letztes immer kurz vor dem Dumpen aufgerufen wird.
.....
5.2. AutoServer - Methode server:
Ist eine Endlosschleife, die dafür sorgt, daß Objekte, für die
eine Message vorliegt, wieder aufgetaut werden. Mehrere ObjServer-
Prozesse können gleichzeitig laufen, was die Performance erhöht
(abhängig von der Leistung des Host).
5.3. AutoServer - Methode client
Hier die Aktionen
1. run: Läßt ein Test-Item als Programm laufen
2. edit: Editiert ein test-Item
3. import: Importiert ein Test-Item aus dem Datei-Baum in die Datenbank
4. multi: Importiert einen ganzen Unterbaum
5. export: Exportiert ein Item mitsamt seinen Childs
6. all: Exportiert einen ganzen Unterbaum
7. report: Erstellt einen Excel-Report
5.4. AutoItem: Die Basisklasse für alle Test-Items.
Methoden test_start, test_end, sleep erlaütern.
Für die Objekt-Daten müssen die Indexe angelegt werden
(in der Environment-Variablen procidx):
package,program,result,remark,user,requirement
Die entsprechenden Objekt-Variablen werden in der Methode
IDX (wird aufgerufen kurz vor dem Dumpen) jeweils
aktualisiert:
package: Paketname = Test-Item-name
program: Eigentlicher Programmcode des Test-Items
result: Ergebnis
remark: Bemerkung
user: User-Angaben
Hier werden die konsolidierten Ergebnisse aus den Child-Items
berechnet und eingetragen.
5.5. ObjProcess: Basisklasse von AutoItem
5.6. AutoDB: Enhält für Testitems wichtige Spaltenindexe
sowie die Definition der Requirement-Relevance-Tabelle.
Wichtige Environment-Variablen:
procdb: Datenbank der Test-Items
procdir: Dateisystem-Repräsentation
procidx: Indexe der gedumpten Objekte (siehe oben)
Diese Environment-Variablen werden - wenn nichts anderes angegeben ist -
automatisch gesetzt:
procdir: dasjenige Verzeichnis, das das Wurzel-Item enthält
procdb: die darin enthaltene Datenbank testtree.db
procidx: Indexe sind gesetzt in AutoDB.pm
==========================================================================
==========================================================================
6.2.2012
--------
Version 0.81:
Änderungen gegenüber Version vom 20.1.2012:
o Die Datei ObjServer heißt jetzt AutoServer.
o Die Datei ObjProcess wurde auf die beiden Dateien
ObjProcess.pm und AutoItem.pm aufgeteilt (enthält den
AutoTest-spezifischen Anteil).
AutoTest installieren:
======================
Perl muss installiert sein und im Verzeichnis C:\perl
vorliegen.
Ins Verzeichnis c:\perl\lib gehen und dort die Datei
autotest_0_81.zip (steht im Projektverzeichnis)
entpacken.
Dann ins Verzeichnis C:\perl\bin gehen und den Befehl ausführen:
perl -e "use DivBasicF::AutoServer; DivBasicF::AutoServer->make_batch()"
(Hiermit werden sieben Dateien erzeugt - ot, or, ox, ot.bat, or.bat, ox.bat
sowie howto.txt, von denen allerdings nur die .bat-Dateien unter
Windows wirklich benötigt werden).
AutoTest anwenden - Konsolen-GUI
================================
In ein beliebiges Verzeichnis gehen, z.B. C:\sktest. Das ist
das Test-Tree-Verzeichnis. Dorthinein das sogenannte Wurzel-Item des
jeweiligen Testprojektes hineinkopieren, sowie weitere Unterverzeichnisse
mit hierfür benötigen statischen Perl-Modulen.
Beispiel Miele: Die zip-Datei gen6000_0_81.zip im Test-Tree-Verzeichnis
entpacken. Dort steht dann das Wurzel-Item Gen6000.pm sowie ein
Unterverzeichnis PPLTest, in dem weiter von Gen6000.pm benötigte
Module stehen.
Die Test-Items sind alle in einer Obj-Task-Datenbank als Prozesse
gespeichert. Eine solche Test-Datenbank findet man ebenfalls im
Projektverzeichnis: die Datei testtree_manuell_0_81.db ebenfalls
ins Test-Tree-Verzeichnis kopieren, und zwar unter dem Namen:
testtree.db. Diese Umbenennung ist wichtig!
Exportieren aller Test-Items aus der testtree.db in das Test-Tree-Verzeichnis:
ot Gen6000 a(ll)
Exportieren eines einzelnen Test-Items aus der testtree.db in das Test-Tree-Verzeichnis:
ot Gen6000 x (export)
Löscht man jetzt die Testdatenbank testtree.db, dann kann man sie durch
ot Gen6000 m(ulti)
wieder erzeugen.
Editieren von Test-Items.
Entweder im Test-Treeverzeichnis editieren, und dann aufrufen:
ot <testitem> i(mport)
oder direkt editieren mit:
ot <testitem> e(dit)
Run eines Test-Items:
ot <testitem> r(un) <arch> 1 <user> 1
Dabei ist <arch> ein Achitektur-Kürzel, und <user eine User-Angabe
Die Einsen sind wichtig!
In einer zweiten Konsole muss dann ox laufen, damit die
schlafenden Prozesse wieder aufgeweckt werden.
Erstellung eines Excel-Reports für ein Test-Item:
ot <testitem> report <tiefe> <arch1> <arch2> ...
<tiefe>: Zahl der Unteritem-Ebenen, die verfolgt werden sollen.
1. Beschreibung der fünf Module ObjTask, ObjProcess, AutoItem, AutoServer und AutoDB
1.1. Der Task-Manager Obj-Task
Stichworte:
Kommunikation ueber die Datenbank,
Messages (auch zeitverzögerte)
Dump von Objekten mit der Methode push
Wiederauftauen von Objekten mit fetch, Schlüsselwort MESSAGE
(wenn eine Message für das LObjekt vorliegt, wird es
gehlot und aufgetaut)
Datenbank-Tabellen:
conn: Message-Tabelle
Wichtige Spalten:
replynr, msgid (20-stellige Message-Identifier)
msgtime (Zeitverzögertes Aktivieren der Message),
text: gedumpter Message-Inhalt
conn_store: Tabelle der gedumpten Objekte.
Wichtige Spalten:
text: Gedumptes Objekt
conn: damit verknüpfter Message-Identifier
Weitere Index-Spalten:
Die Index-Spalten werden in der Environment-Variable
procidx übergeben (kommaseparierte Liste).
Wenn man z.B. in $ENV{'procidx'} hat:
index1,index2
dann werden die Werte von $self->{'index1'} bzw.
$self->{'index2'} beim Dumpen des Objektes
$self in die entsprechenden Spalten index1 und
index2 geschrieben. Damit kann man Informationen
über das Objekt mit SQWL suchen und ausgeben, OHNE das
Objekt wieder auftauen zu müssen.
Ein zu dumpendes Objekt MUSS die Methode IDX haben,
die als letztes immer kurz vor dem Dumpen aufgerufen wird.
.....
1.2. AutoServer - Methode server:
Ist eine Endlosschleife, die dafür sorgt, daß Objekte, für die
eine Message vorliegt, wieder aufgetaut werden. Mehrere ObjServer-
Prozesse können gleichzeitig laufen, was die Performance erhöht
(abhängig von der Leistung des Host).
1.3. AutoServer - Methode client
Hier die Aktionen
1. run: Läßt ein Test-Item als Programm laufen
2. edit: Editiert ein test-Item
3. import: Importiert ein Test-Item aus dem Datei-Baum in die Datenbank
4. multi: Importiert einen ganzen Unterbaum
5. export: Exportiert ein Item mitsamt seinen Childs
6. all: Exportiert einen ganzen Unterbaum
7. report: Erstellt einen Excel-Report
1.4. AutoItem: Die Basisklasse für alle Test-Items.
Methoden test_start, test_end, sleep erlaütern.
Für die Objekt-Daten müssen die Indexe angelegt werden
(in der Environment-Variablen procidx):
package,program,result,remark,user,requirement
Die entsprechenden Objekt-Variablen werden in der Methode
IDX (wird aufgerufen kurz vor dem Dumpen) jeweils
aktualisiert:
package: Paketname = Test-Item-name
program: Eigentlicher Programmcode des Test-Items
result: Ergebis
remark: Bemerkung
user: User-Angaben
requirement: Liste von Requirement und deren Relevanzen:
[
requ1, wert1,
requ2, wert2,
....
maxresult]
Hier werden die konsolidierten Ergebnisse aus den Child-Items
berechnet und eingetragen, maxresult ist der Maximalwert
aller Results aller Child-Items (also der 'schlechteste'
vorgefundene Wert)
1.5. ObjProcess: Basisklasse von AutoItem
1.6. AutoDB: Enhält für Testitems wichtige Spaltenindexe
sowie die Definition der Requirement-Relevance-Tabelle.
Wichtige Environment-Variablen:
procdb: Datenbank der Test-Items
procdir: Dateisystem-Repräsentation
procidx: Indexe der gedumpten Objekte (siehe oben)
=======================================================================================================
20.1.2012
---------
Version 0.8
0. AutoTest beispielhaft zum Laufen bringen:
=============================================
a. Die Programmdateien unter svn+ssh://<user>@172.20.20.1/var/svnift/appserv
ins Verzeichnis C:\appserv auschecken.
b. Das Verzeichnis C:/ppl1 anlegen.
c. Die Datenbank test5.db aus U:/ift/projects/DEV.1302__AutoTest_Backend
nach C:/test5.db kopieren
d. Das Modul Gen6000.pm aus U:/ift/projects/DEV.1302__AutoTest_Backend
nach C:/ppl1 kopieren
e. Die Dateien ot.bat und ox.bat aus C:/appserv/DivBasicF kopieren nach
C:/perl/bin.
f. Die Datei sqlite3.exe aus U:/ift/projects/DEV.1302__AutoTest_Backend
kopieren nach C:/perl/bin.
g. Die Datei shell_gen6000.bat aus U:/ift/projects/DEV.1302__AutoTest_Backend
kopieren auf den Desktop.
Dann mit Doppelklick auf die shell_gen6000 auf dem Desktop eine Konsole
starten. Man ist nun automatisch im Verzeichnis C:\ppl1.
Jetzt Test-Items anschauen und editieren mit:
ot <test-item> edit (z.B. ot Gen6000::CVA::Einstellungen edit)
Test laufen lassen mit:
ot <test-item> run (z.B. ot Gen6000::CVA::Einstellungen run)
In einer zweiten Konsole muss im Verzeichnis C:/ppl1 ausserdem gestartet
werden: ox . In dieser zweiten Konsole laufen dann die wieder
aufgetauten Test-Items weiter.
Auflisten aller Test-Items:
Befehl: sqlite3 /test5.db
Dann eingeben:
select package from conn_store;
Weitere Spalten der Objekt-Tabelle conn_store:
conn,text,package,program,result,remark,user,maxresult,requirement
(man kann sich die Spalten per SQL anschauen):
select <spalte1>,<spalte2>,.... from conn_store
Ausserdem befinden sich Kopien der editierten Test-Items im Verzeichnisbaum
unter C:\ppl1.
1. Beschreibung der vier Module ObjTask, ObjClient, ObjServer und AutoTest
1.1. Der Task-Manager Obj-Task
Stichworte:
Kommunikation ueber die Datenbank,
Messages (auch zeitverzögerte)
Dump von Objekten mit der Methode push
Wiederauftauen von Objekten mit fetch, Schlüsselwort MESSAGE
(wenn eine Message für das LObjekt vorliegt, wird es
gehlot und aufgetaut)
Datenbank-Tabellen:
conn: Message-Tabelle
Wichtige Spalten:
replynr, msgid (20-stellige Message-Identifier)
msgtime (Zeitverzögertes Aktivieren der Message),
text: gedumpter Message-Inhalt
conn_store: Tabelle der gedumpten Objekte.
Wichtige Spalten:
text: Gedumptes Objekt
conn: damit verknüpfter Message-Identifier
Weitere Index-Spalten:
Die Index-Spalten werden in der Environment-Variable
procidx übergeben (kommaseparierte Liste).
Wenn man z.B. in $ENV{'procidx'} hat:
index1,index2
dann werden die Werte von $self->{'index1'} bzw.
$self->{'index2'} beim Dumpen des Objektes
$self in die entsprechenden Spalten index1 und
index2 geschrieben. Damit kann man Informationen
über das Objekt mit SQWL suchen und ausgeben, OHNE das
Objekt wieder auftauen zu müssen.
Ein zu dumpendes Objekt MUSS die Methode IDX haben,
die als letztes immer kurz vor dem Dumpen aufgerufen wird.
.....
1.2. ObjServer:
Ist eine Endlosschleife, die dafür sorgt, daß Objekte, für die
eine Message vorliegt, wieder aufgetaut werden. Mehrere ObjServer-
Prozesse können gleichzeitig laufen, was die Performance erhöht
(abhängig von der Leistung des Host).
1.3. ObjClient:
Methode run:
Hier die Aktionen
1. run: Läßt ein Test-Item als Programm laufen
2. edit: Editiert ein test-Item
3. import: Importiert ein Test-Item aus dem Datei-Baum in die
Datenbank
4. multi: Importiert einen ganzen Unterbaum
1.4. AutoProcess: Die Basisklasse für alle Test-Items.
Methoden test_start, test_end, sleep erlaütern.
Für die Objekt-Daten müssen die Indexe angelegt werden
(in der Environment-Variablen procidx):
package,program,result,remark,user,requirement
Die entsprechenden Objekt-Variablen werden in der Methode
IDX (wird aufgerufen kurz vor dem Dumpen) jeweils
aktualisiert:
package: Paketname = Test-Item-name
program: Eigentlicher Programmcode des Test-Items
result: Ergebis
remark: Bemerkung
user: User-Angaben
requirement: Liste von Requirement und deren Relevanzen:
[
requ1, wert1,
requ2, wert2,
....
maxresult]
Hier werden die konsolidierten Ergebnisse aus den Child-Items
berechnet und eingetragen, maxresult ist der Maximalwert
aller Results aller Child-Items (also der 'schlechteste'
vorgefundene Wert)
Wichtige Environment-Variablen:
procdb: Datenbank der Test-Items
procdir: Dateisystem-Repräsentation
procidx: Indexe der gedumpten Objekte (siehe oben)