OrgaMon-FS: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(8 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Die OrgaMon-FS (FS= Funktions Sicherstellung) hat die Aufgabe sicherzustellen dass eine neue OrgaMon-Version allen Anforderungen genügt, die an sie gestellt werden. Durch den release-Fortschritt müssen Regressionen verhindert werden. Dies gelingt durch automatisierte Tests. Dazu sollten sich OrgaMon-Bereiche beim CareTaker registrieren, beim OrgaMon-Selbsttest werden Tests dieser Bereiche initiert. Die Registrierfunktion und der Registirieprotoyp lauten
Die OrgaMon-FS (FS= Funktions Sicherstellung) hat die Aufgabe sicherzustellen, dass eine neue OrgaMon-Version allen Anforderungen genügt, die an sie gestellt werden. Dies ist eine Massnahme, um der Regressions-Gefahr entgegenzuwirken. Dies gelingt durch automatisierte Tests. Bei den OrgaMon-Selbsttest werden Tests der Bereiche (Oc,zip,html,eMail,Hash,Index) initiert. Die Registrierfunktion und der Registrieprotoyp lauten


  // Prototypen, Test-Bereiche können "fsTest" oder "fsSelfTest" implementieren
  // Prototypen, Test-Bereiche können "fsTest" oder "fsSelfTest" implementieren
  type
  type
  tTestProc = procedure of object fsTest (Path: string);
  tTestProc = procedure (Path: string) of object;
  tSelfTestProc = function of object fsSelfTest : TStringList;
  tSelfTestProc = function : TStringList of object; // noch nicht implementiert
 
//
   
   
// Registration beim CareTaker
== Vorbereitungen ==
//
  procedure addTest(NameSpace:string; test: tTestProc);
  procedure addTest(NameSpace:string; test: tSelfTestProc);


// Hilfs-Funktionen, Damit können sich fsTest-Implementierungen
# starte einen beliebigen OrgaMon-Mandanten und setze System->FunktionsSicherstellungsPfad= auf deinen ausgecheckten Pfadnamen (Slash am Ende nicht vergessen!)
// unabhängig von Datei-Operationen machen
# gehe nach Ticket->Funktions Sicherstellung->Tests starten
function getQuestion(Path:string):TStringList;
procedure setAnswer(sAnswer:TStringList);


-> wenn keine Fehler kommen ist alles in Butter!


== Verzeichnis-Struktur der Tests ==
== Verzeichnis-Struktur der Tests ==


  -~NameSpace~-
  -~NameSpace~-
   -test-nnnnn
  {
    -Rohstoffe
   -~AussagekräftigerTestname~
    -Ergebnis-Soll
    -Soll-Ergebnis
    -Ergebnis-Ist
  }
   
 
==
 
* <b>Namespace</b>: Jede Unit oder Teilfunktionalität inerhlab des OrgaMon registriert seine Test-Fähigkeit beim Test-Agenten unter einem Namespace. "Oc" (Orientation-Convert) war der erste Namespace der in die Testsuite aufgenommen wurde. Innerhalb eines Name-Space werden so auch thematisch die gleichen Tests durchgeführt - z.B. Finanz-Mathematik oder OLAP.
* <b>AussagekräftigerTestname</b>: Name eine Unterverzeichnisses des NameSpace. Ein Test benötigt 1 Unterverzeichnis. In diesem Verzeichnis liegen alle Rohstoffe, die zum Ablauf des Testes notwendig sind. Wie diese Verarbeitet werden ist Sache des Tests. Auch werden die Testergebnisse in dieses Verzeichnis gespeichert.
* <b>Soll-Ergebnis</b> Hier liegt eine oder mehrere Dateien, die nach einer erfolgreichen Durchführung eines Testes (in der regel im Rahmen der Einfühtrung eines neuen TEstes) gesichert wurde. Das "Soll-Ergebnis" legt offen wie genau die Ergebnis-Datei aussehen muss, so dass der Test als Erfolg gilt. "Soll-Ergebnis" spiegelt die Erwartungshaltung des Testsausganges wider.
 
== Determinismus ==
 
Um Testresulte vergleichen zu können dürfen Testergebnisse nicht von aktueller Zeit, vom Zufall, oder vom aktuellen Ausführungsort abhängen. Dieses Meeresrauschen muss ausgeblendet werden. Deshalb wird anfix32 in Rahmen des Testes in den "TestMode" verstetzt, der eigentlich einen Determinismusmodus ist. Release und Zeitfunktionen geben im "TestMode" die immer gleichen Angaben zurück ...
 
Datum  = 31.12.9999
Uhr    = 12:00
Version = 9.999
 
der CareServer setzt dieses Flag selbst vor der Ausführung von Tests.

Aktuelle Version vom 12. Februar 2021, 16:00 Uhr

Die OrgaMon-FS (FS= Funktions Sicherstellung) hat die Aufgabe sicherzustellen, dass eine neue OrgaMon-Version allen Anforderungen genügt, die an sie gestellt werden. Dies ist eine Massnahme, um der Regressions-Gefahr entgegenzuwirken. Dies gelingt durch automatisierte Tests. Bei den OrgaMon-Selbsttest werden Tests der Bereiche (Oc,zip,html,eMail,Hash,Index) initiert. Die Registrierfunktion und der Registrieprotoyp lauten

// Prototypen, Test-Bereiche können "fsTest" oder "fsSelfTest" implementieren
type
 tTestProc = procedure (Path: string) of object;
 tSelfTestProc = function : TStringList of object; // noch nicht implementiert
// 

Vorbereitungen

  1. starte einen beliebigen OrgaMon-Mandanten und setze System->FunktionsSicherstellungsPfad= auf deinen ausgecheckten Pfadnamen (Slash am Ende nicht vergessen!)
  2. gehe nach Ticket->Funktions Sicherstellung->Tests starten

-> wenn keine Fehler kommen ist alles in Butter!

Verzeichnis-Struktur der Tests

-~NameSpace~-
 {
 -~AussagekräftigerTestname~
   -Soll-Ergebnis
 }


  • Namespace: Jede Unit oder Teilfunktionalität inerhlab des OrgaMon registriert seine Test-Fähigkeit beim Test-Agenten unter einem Namespace. "Oc" (Orientation-Convert) war der erste Namespace der in die Testsuite aufgenommen wurde. Innerhalb eines Name-Space werden so auch thematisch die gleichen Tests durchgeführt - z.B. Finanz-Mathematik oder OLAP.
  • AussagekräftigerTestname: Name eine Unterverzeichnisses des NameSpace. Ein Test benötigt 1 Unterverzeichnis. In diesem Verzeichnis liegen alle Rohstoffe, die zum Ablauf des Testes notwendig sind. Wie diese Verarbeitet werden ist Sache des Tests. Auch werden die Testergebnisse in dieses Verzeichnis gespeichert.
  • Soll-Ergebnis Hier liegt eine oder mehrere Dateien, die nach einer erfolgreichen Durchführung eines Testes (in der regel im Rahmen der Einfühtrung eines neuen TEstes) gesichert wurde. Das "Soll-Ergebnis" legt offen wie genau die Ergebnis-Datei aussehen muss, so dass der Test als Erfolg gilt. "Soll-Ergebnis" spiegelt die Erwartungshaltung des Testsausganges wider.

Determinismus

Um Testresulte vergleichen zu können dürfen Testergebnisse nicht von aktueller Zeit, vom Zufall, oder vom aktuellen Ausführungsort abhängen. Dieses Meeresrauschen muss ausgeblendet werden. Deshalb wird anfix32 in Rahmen des Testes in den "TestMode" verstetzt, der eigentlich einen Determinismusmodus ist. Release und Zeitfunktionen geben im "TestMode" die immer gleichen Angaben zurück ...

Datum   = 31.12.9999
Uhr     = 12:00
Version = 9.999

der CareServer setzt dieses Flag selbst vor der Ausführung von Tests.