. '''To Software''' '''[[Software|Software]]''' - '''To Software-Assessment - ''' '''[[Software/Assessment|Software/Assessment]]''' . '''To Software Current Tests - ''' '''[[Software/CurrentTest|Software/CurrentTest]]''' - '''To Software Testteam - ''' '''[[Software/TestTeam|Software/TestTeam]]''' . '''To Software Testers Welcome Pack (Intro) - ''' '''[[Software/TestTeam/WelcomePack/DE|Software/TestTeam/WelcomePack/DE]]''' ---- = Software Testers Welcome Pack = = 3. Arbeiten mit dem Testserver und dem Testserver-Management-System - [DE] = Hallo angehender Software-Tester, Nachdem du nun einen Ueberblick ueber die ganzen Bereiche und Tools mit denen du beim Software Testing in Beruehrung kommst erhalten hast, geht es nun etwas in die Details des Zusammenspiels Testserver und Testserver-Management-System. Auf der Tester Einstiegsseite [[Software/CurrentTest|Software/CurrentTest]] befinden sich daher auch beide Links, einmal zum Testserver selbst und zum zweiten zur Testserver-Management-System Seite: || [[http://cacert1.it-sls.de|Testserver Main Entry Page]] || [[http://cacert1.it-sls.de]] || || [[https://ca-mgr1.it-sls.de/login|Testserver Mgmt System Entry Page]] || [[https://ca-mgr1.it-sls.de/login]] || Die eigentlichen Tests der Software finden auf dem Testserver statt. Anmeldung am Testserver-Management-System funktioniert ausschliesslich mit Accounts, die zuvor auf dem Testserver angelegt worden sind, egal ob bestaetigt oder nicht. Nun werden aber beim Testen immer wieder Funktionen benoetigt, die unterschiedliche Einstellungen des Test Accounts erfordern. Sei es, das der Account Assurance Punkte braucht, sei es das der Test Account bestimmte Berechtigungen braucht. == Assurance Punkte vergeben == Die Theorie:<
> Im CAcert System werden Assurance Punkte folgendermassen eingetragen * Ein Assuree (demjenigen, dem die Punkte gutgeschrieben werden) erhaelt 0-35 Assurance Punkte, die auf das Konto des Assuree gutgeschrieben werden. Assurance Methode ist: "Face-2-Face Meeting" * Der Assurer erhaelt fuer jede durchgefuehrte Assurance 2 Experience Points auf sein Konto gutgeschrieben. Methode: Administrative Increase Beim Gutschreiben der Punkte wird ueberprueft, ob das Assuree Konto bereits 100 Punkte hat. Wenn nicht, wird die Differenz zwischen bisheriger Gesamtpunktzahl plus Anzahl vergebener Punkte addiert und bei Erreichen von 100 Punkten auf 100 Punkte limitiert.<
> . Beispiel: Account hat bislang 70 Punkte und ich addiere 35 Punkte, ergibt nach Adam Riese und Eva Zwerg 105 Punkte. Die werden nun auf 100 Punkte limitiert. Die Diffenz ergibt 5 Punkte, die nicht mehr gezaehlt werden. Also von den 35 vergebenen Punkten, werden nur 30 Punkte dem Account hinzugefuegt.<
> Das gleiche Prinzip wird angewendet auf die Experience Points. 25 mal koennen einem Account Experience Punkte (je 2) gutgeschrieben werden (25 mal 2 Punkte ergibt 50 maximale Experience Punkte). Danach werden keine Experience Punkte mehr gutgeschrieben. Assurance Punkte lassen sich prinzipiell mit 2 Methoden einem Account zuschreiben: a. Ich Assure einen Account mittels eines anderen Accounts innerhalb des Testsystems a. Ich fuege "Assurances" einem Account mit Hilfe des Testserver-Management-Systems einem Account hinzu Wenn ich nun fuer einen Test einen Account mit 100 Assurance Punkten benoetige, muesste ich mit der Methode a. 3 zusaetzliche Accounts haben, um diesen einen User auf 100 Punkte zu bringen (3 Assurances a 35 Punkte -> 105, Limitierung auf max 100 Punkte) Am Anfang habe ich aber noch gar keinen Testuser. Wie soll ich da diesem User 100 Assurance Punkte verpassen koennen ? Hier kommt das Testserver-Management-System ins Spiel. Melde dich mit dem Account der die 100 Assurance Punkte benoetigt am Testserver-Mgmt-System an. Gehe in die Account Administration und fuege diesem Account Assurance Punkte hinzu (Methode b.) (siehe Schritt [[Software/TestTeam/WelcomePack/02-CreateAccounts/DE|2. Account Erstellung - C. 3.]]) Nun kann es aber eine Test Situation geben, bei der der Prozess der Assurance im Online System getestet werden muss. Hierbei ist es wenig hilfreich die Punkte ueber das Testserver-Mgmt-System einem Account einzutragen. Hier muss man sich folglich eine Reihe von Accounts anlegen, die in der Lage sind Assurance Punkte vergeben zu koennen (Account hat 100 Assurance Punkte, die Assurer Challenge bestanden, und einige Experience Punkte). Auf dem Testserver melde ich mich nacheinander mit den verschiedenen Accounts an und fuehre dann eine "regulaere" Assurance fuer einen anderen Testaccount durch. . Beispiel: Testuser A hat 0 Assurance Punkte. Testuser B, C, D haben jeweils 100 Assurance Punkte, die Assurer Challenge bestanden, und jeweils 50 Experience Punkte. Nacheinander melde ich mich mit den Testusern B, C, D am Testserver an, um dann Assurances fuer den Testuser A durchzufuehren. Nach 3 x 35 Assurance Punkten hat nun Testuser A auch seine 100 Punkte (3x 35 = 105, limitiert auf 100 Punkte) wie unter Methode b. Hierbei wurde nun aber die Software des Webdb benutzt. Sprich, die Online Form um die Assurance Punkte eintragen zu koennen. Das Testserver-Mgmt-System ist also nur ein Hilfsmittel, mit dem bestimmte Szenarien "voreingestellt" werden koennen, waehrend die eigentlichen Tests nur innerhalb des Testservers ablaufen koennen. Weitere Funktionen, wofuer das Testserver-Mgmt-System benoetigt wird sind: == Assurer Challenge durchfuehren == Die Funktion Assurer Challenge ist im Produktiv System eine eigene Applikation, die mit der Webdb Applikation nicht direkt in Verbindung steht. Aber auf die gleiche Datenbank wie die Webdb zugreift. Da auf dem Testserver der CATS Server nicht zur Verfuegung steht, muessen um Assurer Challenges durchfuehren und bestehen zu koennen, diese Funktion nachgebildet werden. Das passiert mittels des Testserver-Mgmt-Systems. Melde dich mit dem Account, fuer den eine "bestandene Assurer Challenge" benoetigt wird am Testserver-Mgmt-System an. Gehe zur Account Administration und fuege dem Account eine "bestandene Assurer Challenge" hinzu (siehe Schritt [[Software/TestTeam/WelcomePack/02-CreateAccounts/DE|2. Account Erstellung - C. 6.]]) == Experience Punkte hinzufuegen == Wie bei der Vergabe von Assurance Punkten, habe ich als Tester 2 Moeglichkeiten einem Account Experience Punkte zukommen zu lassen. Entweder einmal mit einem Testaccount auf dem Testserver selbst. Und zum anderen mittels des Testserver-Mgmt-Systems. Fuer Testserien, bei der der Vorgang der Assurance getestet werden muss, kann ich als Tester auf voreingetragene Assuree's zurueckgreifen. Die im System vorhandenen Testuser haben ein Standard Format: * Name: John # Doe (wobei # eine Nummer zwischen 0 und 105 sein kann) * Email: john.doe-###@example.com (wobei ### eine Nummer zwischen 000 und 105 sein kann) Um zum Beispiel in Serie 20 Assurances durchzufuehren, kannst du nacheinander die User john.doe-001@example.com, john.doe-002@example.com, john.doe-003@example.com, usw. assuren und erhaelst dafuer auf deinem Testaccount jeweils 2 Experience Punkte, sofern du nicht bereits 50 Experience Punkte erreicht hast. Um aber initial einen User auf volle Punktzahl zu bringen und als Experienced Assurer zu generieren, empfiehlt sich hier auch wieder das Testserver-Mgmt-System zu Hilfe zu nehmen und die Experience Punkte mittels "Administrative Increase" in 2 Punkte Schritten eintragen zu lassen. == Emails == Es gibt in der Webdb Applikation eine Reihe von Funktionen, die eine Interaktion ueber Emails ausloesen. Beispielsweise die Bestaetigungsmail bei der Anmeldung. Da das gesamte Testsystem gekapselt ist, also keine Mail Interaktion mit dem Internet stattfindet, koennen auch keine Emails zu imaginaeren Test Email Addressen verschickt werden. Um aber dennoch an die Emails zu kommen, um beispielsweise den Bestaetigungslink zu erhalten, muss man zum Testserver-Mgmt-System wechseln und mit dem Account sich am Testserver-Mgmt-System anmelden, unter dem die Email erwartet wird. Ueber den Menuepunkt Mail erhaelt man eine einfache Postfach Ansicht, in der die empfangenen Mails gelesen werden koennen. == Erweiterte Berechtigungen == Wie in Abschnitt 2 (Anlegen von Accounts) beschrieben, sollte jeder Tester in der Zwischenzeit sich einen Admin-User angelegt haben. Mit diesem Admin-User koennen innerhalb des Testservers (Anmeldung als Admin-User) Aufgaben durchgefuehrt werden, die einem Support-Engineer mit der Admin Console zur Verfuegung stehen. * System Admin * Find User * Find Domain * Location DB Mit "Find User" (Suche nach der Email Adresse eines Benutzers) und "Find Domain" (Suche nach einer Domain eines Benutzers) kann sich der Account eines anderen Benutzers angezeigt und veraendert werden. Wenn die Aufgabenstellung fuer ein Testszenario beispielsweise heisst: "Fuehre den Test als Organisations-Assurer durch", dann habe ich folgende 2 Moeglichkeiten. 1. Ich erstelle mir einen neuen Testuser 1. Den Testuser bereite ich ueber das Testserver-Mgmt-System anhand der Vorlage 2. Account Erstellung vor oder aber ich habe bereits einen Standard Testuser, der volle Assurance Punkte hat, der die Assurer Challenge bestanden hat, der volle Experience Points hat, dem nur das O-Admin Flag fehlt: 1. Ich melde mich mit dem Admin-User am Testserver an 1. Ich suche unter "System Admin" - "Find User" nach dem User 1. setze das Flag "Organisations Assurer" fuer diesen Account Wenn ich mich nun am Testserver mit dem Testuser anmelde, dem das Organisations-Assurer Flag gesetzt wurde habe ich nun die Berechtigungen eines Organisations-Assurers == Verkuerzte Laufzeit von Zertifikaten auf Testserver == . Das Erstellen von User Client Zertifikaten, User Server Zertifikaten, Org Client Zertifikaten, Org Server Zertifikaten, GPG/PGP Key Signing ist nun bereits eine Weile auf dem Testserver aktiviert. . Aber es besteht ein entscheidender Unterschied gegenueber dem Produktionsbetrieb. Das betrifft die Zeitspanne ueber die Zertifikate gueltig sind (Expiry date) die auf dem Testserver von 3 Tagen bis 1 Monat reichen kann. . In der anhaengenden Liste sind die jeweiligen Zertifikat Typen, die jeweils notwendigen Assurance Punkte mit der dazugehoerigen Laufzeit einmal auf dem Testserver und zum Vergleich gegenueber dem Produktionssystem aufgelistet. ||<#a0a0a0> Zertifikats Typ ||<#d0d0d0> Laufzeit auf Testserver ||<#a0a0a0> Laufzeit auf Produktion || || User Client cert - 0-49 AP ||<#d0d0d0> 3 Tage || 6 Monate || || User Server cert - 0-49 AP ||<#d0d0d0> 3 Tage || 6 Monate || || User Client cert - GE 50 AP ||<#d0d0d0> 1 Monat || 2 Jahre || || User Server cert - GE 50 AP ||<#d0d0d0> 1 Monat || 2 Jahre || || Org Client cert ||<#d0d0d0> 7 Tage || 1 Jahr (? CPS sagt 24 Monate) || || Org Server cert ||<#d0d0d0> 1 Monat || 2 Jahre || || GPG/PGP signing - GE 50 AP ||<#d0d0d0> 1 Tag || ? || . Auf dem Testserver koennen Zertifikate mit anderen Laufzeiten existieren. Obige Liste sind nur die Standardwerte die derzeitig eingestellt sind. Das Software-Assessment Team kann anderweitig auch kurzfristig fuer bestimmte Tests entscheiden, das Laufzeiten von Zertifikaten fuer bestimmte Tests gekuerzt oder verlaengert werden kpennen. Das wird aber innerhalb der regulaeren Software-Assessment Projekt Team Meetings angekuendigt. == Probieren, Probieren, Probieren == Generell sollte man sich mit den verschiedenen Bereichen der Webdb Applikation vertraut machen.<
> Hierzu legt man sich am besten einen zweiten Admin User an, mit dem man herum experimentieren kann und sich die verschiedenen Bereiche einmal anschaut und auch ggf. mal ausprobiert. <
> Euer<
> Testteam Teamleader<
> <
> == Wie geht es weiter ? == * [[Software/TestTeam/WelcomePack/01-TestersEntryPage/DE|1. Die Einstiegsseite fuer Software Tester]] * [[Software/TestTeam/WelcomePack/02-CreateAccounts/DE|2. Anlegen von Accounts]] * [[Software/TestTeam/WelcomePack/03-WorkingWithTestserverAndMgmtSystem/DE|3. Arbeiten mit dem Testserver und dem Testserver-Management-System]] * '''[[Software/TestTeam/WelcomePack/04-Reporting/DE|4. Testing/Reporting]]''' == Software Testteam Welcome Pack == || Software Testteam Welcome Pack || [[Software/TestTeam/WelcomePack|English]] || [[Software/TestTeam/WelcomePack/DE|German]] || ---- . CategorySoftwareAssessment