SilkCentralÂ® Test Managerâ¢ 2009 SP1

SilkCentral® Test 

Manager 2009 SP1 

Datenbankmodell

Borland Software Corporation 

4 Hutton Centre Dr., Suite 900 

Santa Ana, CA 92707 

Copyright 2009 Micro Focus (IP) Limited. All Rights Reserved. SilkCentral Test Manager contains derivative works of 

Borland Software Corporation, Copyright 2004-2009 Borland Software Corporation (a Micro Focus company). 

MICRO FOCUS and the Micro Focus logo, among others, are trademarks or registered trademarks of Micro Focus (IP) Limited 

or its subsidiaries or affiliated companies in the United States, United Kingdom and other countries. 

BORLAND, the Borland logo and SilkCentral Test Manager are trademarks or registered trademarks of Borland Software 

Corporation or its subsidiaries or affiliated companies in the United States, United Kingdom and other countries. 

All other marks are the property of their respective owners. 

ii

Inhalt 

Test Manager-Datenbankmodell.............................................................................4 

Anforderungsmanagement.....................................................................................5 

Grundlegende Tabellen für das Anforderungsmanagement.......................................................6 

Tabellen für Anforderungsdokumente........................................................................................8 

Tabellen für externe Anforderungen...........................................................................................8 

Tabellen für Anforderungsbenachrichtigungen...........................................................................9 

Testmanagement....................................................................................................11 

Grundlegende Tabellen für das Testmanagement....................................................................12 

Tabellen für Container..............................................................................................................13 

Tabellen für Testspezifikationen................................................................................................15 

Tabellen für manuelle Testspezifikationen.....................................................................16 

Tabellen für Fehler....................................................................................................................18 

Tabellen für Attribute................................................................................................................19 

Integrierte Attribute...................................................................................................................20 

Tabellen für integrierte Attribute....................................................................................21 

Tabellen für Parameter.............................................................................................................23 

Tabellen für die tägliche Fehlerstatistik....................................................................................24 

Tabellen für die LQM-Berichtserstellung..................................................................................25 

Testausführungsmanagement..............................................................................28 

Tabellen für die Testsuitehierarchie..........................................................................................28 

Tabellen für die Ausführungsergebnisse..................................................................................30 

Codeanalyse...........................................................................................................33 

Tabellen für die Codeanalyse...................................................................................................33 

Berichte...................................................................................................................36 

Datenbankansichten..............................................................................................38 

Allgemeine Ansichten...............................................................................................................38 

Anforderungsansichten............................................................................................................39 

Ansichten zum Anforderungsfortschritt....................................................................................40 

Testplanansichten.....................................................................................................................44 

Ansichten zum Testplanfortschritt.............................................................................................47 

Fehleransichten........................................................................................................................49 

Inhalt | 3

Test Manager-Datenbankmodell 

Diese Hilfe enthält eine detaillierte Beschreibung des Datenbankschemas von SilkCentral Test Manager. Das 

Datenbankschema unterstützt Sie beim Erstellen von Berichten. 

Tipp: Wenn Sie diese Hilfe im PDF-Format anzeigen, können Sie die Abbildungen mit den Zoomfunktionen 

von Acrobat Reader vergrößern. Wenn Sie diese Hilfe im Eclipse-Format anzeigen, klicken Sie mit der 

rechten Maustaste auf ein Bild und wählen Bild anzeigen. 

SilkCentral ® Test Manager (Test Manager) ist ein leistungsstarkes, umfassendes Managementsystem für 

den Software-Test. Test Manager optimiert Qualität und Produktivität Ihres Testprozesses und beschleunigt 

die Auslieferung erfolgreicher Software-Projekte bei gleichzeitiger Minimierung von Anwendungsfehlern. Es 

führt alle kritischen Phasen des Software-Tests in einem einzigen, Web-basierten Testsystem zusammen und 

ermöglicht es, lokalen und verteilten Software-Entwicklungsteams Erfahrungen, Ressourcen und wichtige 

Informationen gemeinsam zu nutzen. 

4 | Test Manager-Datenbankmodell

Anforderungsmanagement 

Dieser Abschnitt gibt einen Überblick über den Teil des Datenbankschemas von Test Manager, der für das 

Anforderungsmanagement relevant ist und beschreibt, wie anhand des Schemas Anforderungen verwaltet 

werden. 

Hinweis: Dieses Bild wird am besten im PDF-Format angezeigt. Um dieses Bild in der Eclipse-Hilfe 

anzuzeigen, klicken Sie mit der rechten Maustaste und wählen Bild anzeigen. 

Anforderungsmanagement | 5

Verwandte Themen 

Grundlegende Tabellen für das Anforderungsmanagement auf Seite 6 

Tabellen für Anforderungsdokumente auf Seite 8 

Tabellen für externe Anforderungen auf Seite 8 

Tabellen für Anforderungsbenachrichtigungen auf Seite 9 

Grundlegende Tabellen für das Anforderungsmanagement 

Dieses Thema beschreibt die grundlegenden Tabellen im Bereich "Anforderungsmanagement" des 

Datenbankschemas. 



6 | Anforderungsmanagement

TM_RequirementTreeNodes 

Dies ist die Basistabelle für Anforderungshierarchien. Jeder Knoten in 

der Hierarchie wird durch eine Zeile dargestellt, die folgende Attribute 

enthält: 

• Die Knoten-ID des übergeordneten Knotens, ParentNodeID_fk. 

• Grundlegende Informationen zum Knoten (PropertyName, 

Beschreibung). 

• Daten für Integrationen von Fremdherstellern. 

• Informationen zu zugeordneten Dokumenten, die mit der 

Anwendung Office Import Tool von Test Manager importiert wurden. 

TM_ReqTestCoverages 

TM_RequirementsCoverages 

TM_ReqTreePaths 

TM_RequirementsHistories 

TM_CustomRequirementProperties 

TM_CustomPropertyValues 

TM_ReqDocsCustomMapping 

Eine Zuordnungstabelle, die Paare von Anforderungs- und 

Testspezifikations-IDs enthält. 

Diese Tabelle enthält ausführliche Zuordnungsinformationen zu 

Anforderungen und Testspezifikationen. Sie wird für die Erstellung von 

Berichten verwendet. Die Tabelle enthält zusätzlich zu den 

Informationen in TM_ReqTestCoverages Einträge für 

Anforderungs-IDs, deren Testspezifikations-ID den Wert NULL hat. 

Diese Einträge beschreiben untergeordnete Anforderungsknoten, die 

bei der Erstellung von Abdeckungsstatistiken berücksichtigt werden. 

NULL bedeutet, dass eine Anforderung den Status "Nicht abgedeckt" 

hat. 

Diese Tabelle enthält für alle Knoten Paare aus der Anforderungs-ID 

und der ID des übergeordneten Knotens, die den vollständigen Pfad 

einer Anforderung bis zum Stamm beschreiben. 

In dieser Tabelle werden die Änderungen gespeichert, die ein Benutzer 

an einer Anforderung vornimmt. Auf diese Weise lassen sich 

Änderungen an Anforderungen nachverfolgen. 

Diese Tabelle enthält die Definitionsdaten von benutzerdefinierten 

Eigenschaften, wie z.B. Typ, Name, Ersteller und eine eindeutige ID. 

Diese Tabelle enthält Instanzen von benutzerdefinierten 

Eigenschaftswerten, die Anforderungen zugeordnet sind. Jeder Eintrag 

besteht aus der eindeutigen ID für die benutzerdefinierte Eigenschaft 

und dem Wert der Instanz. 

Diese Tabelle enthält die Daten für die Zuordnung einer 

benutzerdefinierten Eigenschaft zu einer aus Microsoft Office 

importierten benutzerdefinierten Eigenschaft. In Microsoft 

Office-Dokumenten werden für die IDs benutzerdefinierter 

Eigenschaften Textmarken verwendet. 



Anforderungsmanagement auf Seite 5 

Tabellen für Anforderungsdokumente 

Dieses Thema beschreibt die Tabellen, die für den Import von Anforderungen aus Office-Dokumenten verwendet 

werden. 



TM_Projects_RequirementsDocs Diese Tabelle enthält die Daten für die Zuordnung eines Microsoft 

Office-Dokuments für den Import von Anforderungen zu dem 

entsprechenden Test Manager-Projekt, in das die Anforderungen importiert 

wurden. 

TM_RequirementsDocs 

Diese Tabelle enthält Daten für alle importierten Microsoft 

Office-Dokumente. 



Tabellen für externe Anforderungen 

Dieses Thema beschreibt die Tabellen, die für Integration von Fremdherstellerwerkzeugen für das 

Anforderungsmanagement zur Verfügung stehen. 




TM_ReqExternalAssociation 

TM_ReqExtMappingRules 

TM_ReqExtAssociationReqTypes 

Diese Tabelle enthält die Zuordnungsdaten, die zur Integration von 

Fremdherstellerwerkzeugen für das Anforderungsmanagement benötigt 

werden. Hierzu gehören Anmeldedaten, Anforderungstypen, Projektname 

und Synchronisierungsstatus. 

Diese Tabelle enthält Daten für die Zuordnung benutzerdefinierter 

Eigenschaften von Test Manager und den Anforderungseigenschaften 

von Fremdherstellern. 

Diese Tabelle enthält eine Liste der verfügbaren externen 

Anforderungstypen. 



Tabellen für Anforderungsbenachrichtigungen 

Dieses Thema beschreibt die Tabellen, die für Benachrichtigungen bei Anforderungsänderungen relevant 

sind. 




TM_NotifyEvents 

Diese Tabelle enthält die ID und den Namen aller Ereignisse, für die eine 

Änderungsbenachrichtigung auslösen können. 

TM_ChangeNotificationRegister Diese Tabelle enthält die Benachrichtigungsregistrierungsdaten für alle 

Benutzer und Benachrichtigungsereignisse. Wenn seit der letzten 

Bestätigung eine Änderungsbenachrichtigung gesendet wurde, hat 

Notified den Wert True. Ist für das Ereignis und den Benutzer die 

Benutzerbenachrichtigung aktiviert, hat NotifyActive den Wert True. 




Testmanagement 


Testmanagement relevant ist und beschreibt, wie anhand des Schemas Testpläne verwaltet werden. 




Grundlegende Tabellen für das Testmanagement auf Seite 12 

Tabellen für Container auf Seite 13 

Tabellen für Testspezifikationen auf Seite 15 

Tabellen für Fehler auf Seite 18 

Tabellen für Attribute auf Seite 19 

Integrierte Attribute auf Seite 20 

Tabellen für Parameter auf Seite 23 

Tabellen für die tägliche Fehlerstatistik auf Seite 24 

Tabellen für die LQM-Berichtserstellung auf Seite 25 

Testmanagement | 11

Grundlegende Tabellen für das Testmanagement 

Dieses Thema beschreibt die grundlegenden Tabellen im Bereich "Testmanagement" des Datenbankschemas. 



TM_TestPlanNodes 

TM_PlanTreePaths 

Dies ist die Basistabelle für Testhierarchien. Jeder Knoten der Hierarchie wird 

durch eine Zeile dargestellt, die folgende Attribute enthält: 

• Die Knoten-ID des übergeordneten Knotens (ParentNodeID_fk). 

• Grundlegende Informationen zum Knoten, wie der Name und die Beschreibung. 

• Die allgemeine Knoten-ID, mit der im Modell auf Knoten Bezug genommen 

wird (z.B. zur Bereitstellung von Detailinformationen zu bestimmten Knotentypen 

wie Containern, Testspezifikationen und Ordnern). 

Diese Tabelle enthält alle der Hierarchie möglichen Pfadangaben. Mit Hilfe dieser 

Informationen können alle übergeordneten Knoten eines Hierarchieknotens 

lokalisiert werden (NodeID_pk_fk). Der Knoten selbst ist in der Liste der 

übergeordneten Knoten in der Spalte ParentNodeID_pk_fk enthalten. 

12 | Testmanagement

TM_TestContainers 

Unter einem Container versteht man den Stammknoten einer Testhierarchie. 

TM_TestContainers enthält die Informationen für jeden Container in 

TM_TestPlanNodes mit einer 1:1-Beziehung und weitere Informationen über 

den Container. 

TM_TestDefAttachments Hier werden Hierarchieknoten einer gemeinsam genutzten Tabelle 

(TM_Attachments) zugeordnet, in der Anlagen binär oder als Verknüpfungen 

gespeichert sind. Anlagen können jedem Knoten in der Testhierarchie zugeordnet 

werden, auch Ordnern und Containern. 

TM_TestDefinitions 

TM_TestDefStatuses 

TM_PlanHistory 

TM_PlanHistoryParams 

Dies ist die Basistabelle für Testspezifikationen. Sie ist über eine 1:1-Beziehung 

mit der Tabelle TM_TestPlanNodes verknüpft. Die Tabelle speichert den aktuellen 

Testausführungsstatus und Informationen zur letzten Testausführung, den Testyp 

und die geplante Dauer. 

Hier wird der aktuelle Testausführungsstatus der Testspezifikationen gespeichert. 

Diese Tabelle enthält die Änderungshistorie jedes Knotens in der Testhierarchie. 

Hier werden detaillierte Informationen zu den Änderungen gespeichert. 


Testmanagement auf Seite 11 

Tabellen für Container 

Dieses Thema beschreibt die Tabellen, die im Datenbankmodell für Container relevant sind. 






Unter einem Container versteht man den Stammknoten einer Testhierarchie. 

TM_TestContainers enthält die Informationen für jeden Container in 

TM_TestPlanNodes mit einer 1:1-Beziehung und weitere Informationen 

über den Container. 

Dies ist die Basistabelle für Testhierarchien. Jeder Knoten der Hierarchie 

wird durch eine Zeile dargestellt, die folgende Attribute enthält: 


• Grundlegende Informationen zum Knoten, wie der Name und die 

Beschreibung. 


wird (z.B. zur Bereitstellung von Detailinformationen zu bestimmten 

Knotentypen wie Containern, Testspezifikationen und Ordnern). 

TM_HiddenTestDefProperties 

TM_ExecutionDefinitions 

Diese Tabelle speichert die verborgenen Eigenschaften aller Container. 

Diese Tabelle zeigt alle Testsuiten in der Testsuitehierarchie. Jede Testsuite 

ist ein Knoten in der Hierarchie, d.h. es besteht eine 1:1-Beziehung zu 

TM_ExecTreeNodes. 


SCC_Projects 

SCC_Products 

SCC_SourceControlProfiles 

Speichert Informationen über Projekte. 

Speichert Informationen über Produkte. 

Speichert Informationen über Versionsverwaltungsprofile. 



Tabellen für Testspezifikationen 

Dieses Thema beschreibt die Tabellen, die im Datenbankmodell für das Testmanagement relevant sind. 





mit der Tabelle TM_TestPlanNodes verknüpft. Die Tabelle speichert den aktuellen 

Testausführungsstatus und Informationen zur letzten Testausführung, den Testyp 

und die geplante Dauer. 






• Grundlegende Informationen zum Knoten, wie der Name und die Beschreibung. 

• Die allgemeine Knoten-ID, mit der im Modell auf Knoten Bezug genommen wird 

(z.B. zur Bereitstellung von Detailinformationen zu bestimmten Knotentypen 

wie Containern, Testspezifikationen und Ordnern). 

TM_TestDefStatuses 

TM_TestDefExecutions 

TM_ExecDefs_TestDefs 

Hier wird der aktuelle Testausführungsstatus der Testspezifikationen gespeichert. 

Diese Tabelle speichert Informationen zu Testspezifikationsausführungen. 

Diese Tabelle zeigt, welche Testspezifikationen zu welchen Testsuiten zugeordnet 

sind. Eine Testspezifikation kann mehreren Testsuiten zugeordnet sein, und eine 

Testsuite kann mehrere Testspezifikationen haben. 



Tabellen für manuelle Testspezifikationen auf Seite 16 

Tabellen für manuelle Testspezifikationen 

Dieser Abschnitt beschreibt die Tabellen, die für manuelle Testspezifikationen relevant sind. 





TM_ManualSteps 

TM_ManualTestStepResults 

TM_ManualStepAttachments 


mit der Tabelle TM_TestPlanNodes verknüpft. Die Tabelle speichert den 

aktuellen Testausführungsstatus und Informationen zur letzten Testausführung, 

den Testyp und die geplante Dauer. 

Jede Zeile entspricht einem Schritt einer manuellen Testspezifikation. Die 

Schritte verfügen über einen sequenziellen Wert, der die beabsichtigte 

Ausführungsreihenfolge festlegt. 

Diese Tabelle speichert Ergebnisbeschreibungen oder -kommentare, die von 

einer Testperson während der Durchführung eines manuellen Tests 

eingegeben wurden. 

Neben der Zuordnung von Anlagen zu Testspezifikationen besteht die 

Möglichkeit, jedem Schritt eines manuellen Tests beliebig viele Anlagen 

zuzuordnen. 

TM_CustomStepProperties Diese Tabelle enthält zusätzliche Eigenschaften, die zusammen mit manuellen 

Schritten gespeichert werden sollten. Jede Zeile entspricht einer 

benutzerdefinierten Eigenschaft, die für alle manuellen Testschritte eines 

Projekts zur Verfügung steht. 

TM_CustomStepValues 

Hier werden die Werte der benutzerdefinierten Eigenschaften für manuelle 

Testschritte gespeichert. 



Tabellen für Testspezifikationen auf Seite 15 

Tabellen für Fehler 

Dieses Thema beschreibt die Tabellen, die im Datenbankmodell für Fehler relevant sind. 



TM_Issues 


TM_IssuesHistory 

SCC_IssueTrackingProfiles 

SCC_IssueStates 

Testspezifikationen können mit Fehlern verknüpft werden, die mit einem 

externen System zur Fehlerverfolgung verwaltet werden. Die Zuordnung eines 

Fehlers zu einer Testspezifikation wird mit Hilfe eines Verweises auf den 

Testplanknoten gespeichert. 




• Grundlegende Informationen zum Knoten, wie der Name und die 

Beschreibung. 


wird (z.B. zur Bereitstellung von Detailinformationen zu bestimmten 

Knotentypen wie Containern, Testspezifikationen und Ordnern). 

Diese Tabelle speichert die Änderungshistorie für jeden Fehler. 

Speichert Informationen über Fehlerverfolgungsprofile. 

Speichert Informationen über den jeweiligen Status der Fehler. 




Tabellen für Attribute 

Dieses Thema beschreibt die Tabellen, die im Datenbankmodell für Attribute relevant sind. 

Attribute werden verwendet, um benutzerdefinierte Eigenschaften zu erstellen und den Knoten der Testhierarchie 

benutzerdefinierte Eigenschaftswerte zuzuweisen. Attribute werden innerhalb der Hierarchie vererbt. 

Untergeordnete Knoten erben alle Attribute ihres übergeordneten Knotens. Ausgenommen davon sind Attribute, 

die durch den untergeordnete Knoten selbst definiert werden. 

Es gibt zwei grundlegende Attributtypen: 

Attributwerte 

Attributoptionen 

Hierbei handelt es sich um Name/Wert-Paare. Der Benutzer gibt den Wert in Form 

eines Strings ein und ordnet ihn einem Knoten der Testhierarchie zu. Der Name des 

Attributs identifiziert den Wert. 

Dieser Attributtyp verfügt über eine vordefinierte Gruppe von Optionen (das 

Optionsset) mit mindestens einem Optionswert. Sie können den Knoten der 

Testhierarchie eine oder mehrere Optionen zuordnen. 




TM_Attributes 

TM_AttributeOptions 

TM_AttributeValues 

TM_NodeAttributeOptions 

TM_NodeAttributeValues 

Jede Zeile definiert ein Attribut über seinen Namen (ein eindeutiger Bezeichner) 

und seinen Typ (Wert oder Option). 

Hier werden die vordefinierten Optionssets für Attribute der Typs option 

gespeichert. 

Hier werden die benutzerdefinierten Werte für Attribute des Typs value als 

String gespeichert. 

In jeder Zeile wird einem Knoten der Testhierarchie (NodeID_pk_fk) eine 

Attributoption zugeordnet. In der Spalte InheritedFromNodeID_pk_fk ist 

der Knoten angegeben, von dem die Option geerbt wird. Der Wert NULL 

bedeutet, dass die Option dem Knoten explizit zugeordnet ist. 

In jeder Zeile wird einem Knoten der Testhierarchie ein Attributwert zugeordnet. 

Ansonsten entspricht TM_NodeAttributeValues der Tabelle 

TM_NodeAttributeOptions. 



Integrierte Attribute 

Dieses Thema erläutert die integrierten Eigenschaften, die Knoten der Testhierarchie zugeordnet werden 

können. 

Neben den benutzerdefinierten Attributen gibt es zwei Typen von integrierten Eigenschaften, die den Knoten 

der Testhierarchie zugeordnet werden können. 

Typ I 

Bei diesem Eigenschaftstyp handelt es sich um vordefinierte Attribute, die auf die gleiche Weise wie 

benutzerdefinierte Attribute gespeichert und verarbeitet werden. Anhand der Spalte IsBuiltin der Tabelle 

TM_Attributes können die Attributtypen voneinander unterschieden werden. Vordefinierte Attribute bilden 

ein leistungsstarkes und flexibles Werkzeug, mit dem Knoten von Testhierarchien mit besonderen Eigenschaften 

ausgestattet werden können (z.B. Testfälle und Testdaten für SilkTest-Testspezifikationen). Vordefinierte 

Attribute besitzen ein Namenspräfix, das anzeigt, zu welchem Testspezifikationstyp sie gehören, oder ob es 

sich um ein Attribut für eine Erfolgsbedingung handelt. 

Folgende Präfixe werden verwendet: 

_sp_ 

_st_ 

_nunit_ 

_wsh_ 

_junit_ 

_sc_ 

SilkPerformer-Testspezifikationen 

SilkTest-Testspezifikationen 

NUnit-Testspezifikationen 

Windows Scripting Host-Testspezifikationen 

JUnit-Testspezifikationen 

Test Manager-Erfolgsbedingungen 


Beispiele 

_sp_ProjectFile 

_sp_Workload 

_st_ScriptFile 

_st_TestCase 

_st_TestData 

_junit_Classpath 

SilkPerformer-Projektdatei 

SilkPerformer Lasttest-Szenario 

SilkTest-Skriptdatei 

SilkTest-Testfall 

SilkTest-Testdaten 

JUnit-Klassenpfad für die Ausführung von JVM 

Typ II 

Diese Eigenschaft ermöglicht es, Knoten der Testhierarchie Systemeigenschaften (z.B. Plattformen und 

Komponenten) zuzuordnen, die von anderen Anwendungen genutzt werden und für die Berichtserstellung 

und für weitere Funktionen relevant sind: 



Tabellen für integrierte Attribute auf Seite 21 

Tabellen für integrierte Attribute 

Dieses Thema beschreibt die Tabellen, die für für integrierte Attribute relevant sind. 




SCC_Components 

SCC_Platforms 

TM_ComponentOptions 

Systemweit definierte Produktkomponenten, die getestet werden sollen. 

Systemweit definierte Plattformen für die durchzuführenden Tests. 

Jede Komponente des Systems kann als integriertes Komponentenattribut 

verwendet werden. Jede Zeile dieser Tabelle entspricht einer 

Komponentenoption, wobei der Komponenteneintrag in SCC_Components 

referenziert wird, der die gebräuchlichen Systemwerte der Test 

Manager-Anwendung außer Kraft setzt. 

TM_NodeComponentOptions Jeder Eintrag ordnet einen Knoten in der Testhierarchie einer integrierten 

Komponentenattributoption zu. Dabei wird auf die gleiche Weise verfahren 

wie bei der Zuordnung von benutzerdefinierten Attributen (siehe 

TM_NodeAttributeOptions). 

TM_PlatformOptions 

TM_NodePlatformOptions 

Jede Komponente des Systems kann als integriertes Plattformattribut 

verwendet werden. Jede Zeile dieser Tabelle entspricht einer Plattformoption, 

wobei der Plattformeintrag in SCC_Platforms referenziert wird, der die 

gebräuchlichen Systemwerte der Test Manager-Anwendung außer Kraft setzt. 

Jeder Eintrag ordnet einen Knoten in der Testhierarchie einer integrierten 

Plattformattributoption zu. Dabei wird auf die gleiche Weise verfahren wie bei 

der Zuordnung von benutzerdefinierten Attributen (siehe 

TM_NodeAttributeOptions). 



Integrierte Attribute auf Seite 20 

Tabellen für Parameter 

Dieses Thema erläutert die Parameter, die Testhierarchieknoten zugeordnet sind. 

Parameter werden ähnlich verwendet wie Attributwerte. Ein Parameter ist ein benutzerdefiniertes 

Name/Wert-Paar, das einem Knoten der Testhierarchie zugeordnet wird. Die Vererbung erfolgt auf die gleiche 

Weise wie bei Attributen. Parameter haben einen Typ und werden als Eingabewerte für Ausführungen der 

Testspezifikation verwendet. 



TM_TestDefParameters 

TM_TestDefParamValues 

TM_PlanNodeParameters 

In dieser Tabelle sind die Parameterdefinitionen gespeichert. 

In dieser Tabelle sind die benutzerdefinierten Werte der Parameter 

gespeichert.Werte werden als Strings gespeichert und von der Anwendung 

in den benötigten Typ konvertiert. 

Diese Tabelle speichert die Zuordnungen von Parametern und Knoten der 

Testhierarchie (siehe auch TM_NodeAttributeValues). 




Tabellen für die tägliche Fehlerstatistik 

Dieses Thema beschreibt die Tabellen, die zum Erstellen von täglichen Fehlerstatistiken verwendet werden. 



TM_DailyIssueStates 

SCC_IssueTrackingProfiles 

Diese Tabelle enthält Momentaufnahmen der Statistikdaten interner und externer 

Fehlerverfolgungsprofile und -produkte. In der Spalte ForDate ist der Zeitpunkt 

angegeben, zu dem die Aufnahme erstellt wurde. In state wird die Anzahl der 

Fehler angegeben, die in jedem Status aufgetreten sind. Die berechneten Werte 

werden in den entsprechenden OpenCount-Spalten gespeichert. Die Erfassung 

statistischer Daten von externen Fehlerverfolgungssystemen und die 

Speicherung der Ergebnisse in der Datenbank erfolgt auf dem Datenbankserver 

in regelmäßigen Abständen. Das Minutenintervall kann in der Datei 

Conf/AppServer/ TMAppServerHomeConf.xml konfiguriert werden. Siehe 

die Einstellungen Config, IssueStateUpdate und UpdateInterval. 

Speichert Informationen über Fehlerverfolgungsprofile. 




Tabellen für die LQM-Berichtserstellung 

Dieses Thema beschreibt die Tabellen, die für die Berichtserstellung für Testspezifikationen und deren Attribute 

relevant sind. 

Um die Berichtserstellung für Testspezifikationen und deren Attribute zu vereinfachen und zu beschleunigen, 

speichern die Tabellen für die LQM-Berichtserstellung redundante Daten in linearen Tabellen. Die Anzahl der 

erforderlichen Verknüpfungen wird so reduziert. 

Die Tabellen werden fortlaufend in einem definierten Zeitintervall durch einen Hintergrund-Thread aktualisiert. 

Die Standardeinstellung beträgt 5 Sekunden. Jede Datenänderung wird so alle 5 Sekunden in die Tabellen 

für die LQM-Berichtserstellung geschrieben. 

Tipp: Für Berichte: Siehe auch die Datenbankansicht LQM_V_Tests, die Informationen aus den Tabellen 

LQM_Tests und LQM_TestUDAs kombiniert. 

LQM_DataLoads 

Wird vom Aktualisierungs-Thread zum Überwachen der Datenfracht und der zu 

verarbeitenden Intervalle verwendet. Diese Tabelle sollte nicht für die Berichtserstellung 

verwendet werden. 

Hinweis: Wenn diese Tabelle geleert wird, wird sie bei der nächsten Aktualisierung 

wieder mit allen Daten gefüllt. 

LQM_Tests 

Repräsentiert eine Testspezifikation mit ihren Hauptattributen. Es werden nicht alle Knoten 

der Testhierarchie in dieser Tabelle gespeichert, nur die Testspezifikationen. 

Die Tabelle enthält die folgenden Felder: 

ExternalID 

NodeType 

Die extern ID eines Testpaketes, das in einem externen System 

definiert wurde. 

NodeType wird zur Unterscheidung von regulären und 

datengetriebenen Tests und Testpaketen verwendet. Folgende 

Werte sind möglich: 

dd_parent 

dd_instance 

tp_parent 

tp_suite 

tp_instance 

regular 

Ursprüngliche Testspezifikation, die 

datengetriebene Testknoten mit dem Knotentyp 

dd_instance enthält. 

Von den Daten aus der Datenquelle definierte 

Testspezifikation. 

Oberster Knoten eines Testpaketes. 

Knoten in einem Paket, die weitere 

untergeordnete Knoten enthalten. Dadurch 

werden leere Ordner ausgeschlossen. 

Alle untergeordnete Knoten in einem Testpaket. 

Knotentyp für allgemeine Tests (keiner der 

anderen Knotentypen). 


Type 

Component 

Platform 

PlannedTime 

CreatedAt, 

DbCreatedAt, 

ChangedAt und 

DbChangedAt 

Attributes 

Legt den Typ der Testspezifikation fest, z.B. SilkPerformer, 

SilkTest oder Manual. 

Eine durch Komma getrennte Liste der Namen aller zugeordneter 

Komponenten. 

Eine durch Komma getrennte Liste der Namen aller zugeordneter 

Plattformen. 

Wird nur für manuelle Tests mit der Eigenschaft PlannedTime 

gesetzt. 

Die Felder CreatedAt und ChangedAt speichern den Zeitpunkt, 

zu dem die Testspezifikation zuletzt in einer Benutzerperspektive 

erstellt/geändert wurde. Diese Werte werden im GUI angezeigt und 

häufig in Berichte aufgenommen. DbCreatedAt und DbChangedAt 

enthalten Datums-/Uhrzeitangaben des Systems (der Datenbank), 

die sich häufiger als die Benutzer-Datums-/Uhrzeitangaben ändern 

können. Diese Werte werden für Systemoperationen, wie etwa die 

Aktualisierung des Zwischenspeichers, verwendet. Die Anzeige 

dieser Angaben ist in der Regel nicht sinnvoll. 

Alle Attribute in dieser Tabelle verwenden das Präfix a_. Die 

folgenden Attribute sind verfügbar: 

a_script 

a_testcase 

a_datadriven 

a_dd_dataset 

a_dd_datasource 

a_dd_filterquery 

a_dd_multiple 

a_dotnet_exe 

Das Skriptdateiattribut von .NET 

(_dotnetexp_Script), SilkTest 

(_st_Script File), oder WSH Tests 

(_wsh_Script). 

Das Testfallattribut für .NET 

(_dotnetexp_TestCase) und SilkTest 

(_st_TestCase). 

Bei datengetriebenen Tests wird dieses Attribut 

für die Eigenschaft _ddtd_DataDriven 

verwendet. Bei SilkTest-Tests wird das Attribut 

für die Eigenschaften _st_DataDriven und 

DataDriven verwendet. In beiden Fällen legt 

das Attribut fest, dass die Testspezifikation 

datengetrieben ist. 

Gibt die Datenmenge für datengetriebene 

Tests an. 

Das Datenquellenattribut für datengetriebene 

Tests. 

Das Filterabfrageattribut für datengetriebene 

Tests. 

Gibt an, ob jede Datenzeile eines 

datengetriebenen Tests eine eigene 

Testspezifikation ist oder ob alle Zeilen Teil 

eines einzigen Tests sind. 

Die ausführbare .NET-Datei, 

_dotnetexp_Executeable. 


a_junit_* JUnit-bezogene Attribute. 

a_nunit_* NUnit-bezogene Attribute. 

a_sp_* 

SilkPerformer-bezogene Attribute. 

a_st_* 

SilkTest-bezogene Attribute. 

a_wsh_Switches Die WSH-Optionen für diesen Test. 

Erfolgsbedingungen 

Die Erfolgsbedingungen verwenden das Präfix _sc_. 




Testausführungsmanagement 


Testausführungsmanagement relevant ist und beschreibt, wie anhand des Schemas Testausführungen verwaltet 

werden. 


Tabellen für die Testsuitehierarchie auf Seite 28 

Tabellen für die Ausführungsergebnisse auf Seite 30 

Tabellen für die Testsuitehierarchie 

Dieses Thema beschreibt die Tabellen, die für die Testsuitehierarchie relevant sind. 



28 | Testausführungsmanagement

TM_ExecTreeNodes 

TM_ExecutionDefinitions 

Diese Tabelle speichert alle Ordner und Testsuiten, die in der 

Testsuitehierarchie enthalten sind. 

Diese Tabelle zeigt alle Testsuiten in der Testsuitehierarchie. Jede 

Testsuite ist ein Knoten in der Hierarchie, d.h. es besteht eine 

1:1-Beziehung zu TM_ExecTreeNodes. 

Testausführungsmanagement | 29

TM_ExecDefs_TestDefs 

TM_ExecTreePaths 

TM_ExecTreeNodes_Keywords 


TM_HiddenTestDefProperties 

SCC_Filters 

SCC_ExecKeywords 

SCC_Versions 

SCC_ExecServers 

SCC_ExecServers_ExecKeywords 

SCC_Projects 

Diese Tabelle zeigt, welche Testspezifikationen zu welchen Testsuiten 

zugeordnet sind. Eine Testspezifikation kann mehreren Testsuiten 

zugeordnet sein, und eine Testsuite kann mehrere Testspezifikationen 

haben. 

Diese Tabelle enthält alle in der Testsuitehierarchie möglichen 

Pfadangaben. Mit Hilfe dieser Informationen können alle übergeordneten 

Knoten eines Hierarchieknotens lokalisiert werden (NodeID_pk_fk). 

Der Knoten selbst ist in der Liste der übergeordneten Knoten in der 

Spalte ParentNodeID_pk_fk enthalten. 

Diese Tabelle speichert die Zuordnungen zwischen bestimmten 

Schlüsselwörtern und den entsprechenden Knoten in der 

Testsuitehierarchie. 

Unter einem Container versteht man den Stammknoten einer 

Testhierarchie. TM_TestContainers enthält die Informationen für 

jeden Container in TM_TestPlanNodes mit einer 1:1-Beziehung und 

weitere Informationen über den Container. 

Diese Tabelle speichert die verborgenen Eigenschaften aller Container. 

Die Zuordnung von Testsuiten zu Testspezifikationen kann dynamisch 

mit Hilfe von Filtern erfolgen. Jeder Testsuite kann ein Schlüssel für 

einen Filter zugeordnet werden. Die Tabelle TM_ExecDefs_TestDefs 

enthält auch bei Verwendung von Filtern die aktuellen Zuordnungen. 

Diese Tabelle speichert alle verfügbaren Schlüsselwörter. 

Diese Tabelle speichert Information über Produktversionen. 

Diese Systemtabelle speichert alle verfügbaren Ausführungsserver. 

Diese Tabelle speichert die Ausführungsserver und zusammen mit den 

den Servern zugewiesenen Schlüsselwörtern. 

Speichert Informationen über Projekte. 


Testausführungsmanagement auf Seite 28 

Tabellen für die Ausführungsergebnisse 

Dieses Thema beschreibt die Tabellen, die für die Ausführungsergebnisse relevant sind. 




TM_EDR_ExecutionMessages In dieser Tabelle werden während der Ausführung der Testsuite übergreifende 

Meldungen gespeichert, die von den ausgeführten Testspezifikationen 

unabhängig sind (z.B. wenn ein Fehler bei dem definierten 

Versionsverwaltungsprofil auftritt). Diese Tabelle ist mit der Tabelle 

TM_ExecDefinitionRuns verknüpft. 

TM_TDE_ExecutionMessages In dieser Tabelle werden Meldungen gespeichert, die von Testspezifikationen 

generiert werden, die in Testsuites ausgeführt werden. Diese Tabelle ist mit 

der Tabelle TM_TestDefExecutions verknüpft. Alle in dieser Tabelle 

gespeicherten Meldungen sind bestimmten Testläufen zugeordnet. 

TM_ExecInputParameters 

TM_ExecInputAttributes 

TM_ResultFiles 

TM_ExecDefinitionRuns 


Diese Tabelle speichert die Name/Wert-Paare aller 

Testspezifikationsparameter, die während der Ausführung gültig sind. 

Diese Tabelle speichert die Name/Wert-Paare aller Testspezifikationsattribute, 

die während der Ausführung gültig sind. 

Ergebnisdateien beinhalten unter anderem die Codeabdeckungsdateien, 

Ergebnisdateien, die von SilkTest-Ausführungen für Berichtsergebnisse 

angelegt werden, XML-Dateien, die von SilkPerformer-Ausführungen erstellt 

werden und die allgemeine Datei output.xml, die von 

Testspezifikationstypen von Fremdherstellern erzeugt wird. Ergebnisdateien 

sind über TM_EDR_ResultFiles oder TM_TDE_ResultFiles entweder 

dem Testsuitelauf oder dem Testspezifikationslauf zugeordnet. 

Diese Tabelle enthält für jeden Lauf einer Testsuite einen Eintrag. Der Eintrag 

wird erzeugt, wenn die Ergebnisse der Ausführung zusammengestellt werden. 

Diese Tabelle speichert die Ausführungen der Testspezifikationen, die zu 

dem jeweiligen Testlauf der Testsuite gehören. Wenn eine Testsuite drei 

Testspezifikationen referenziert, speichert die Tabelle drei 

Testspezifikationsausführungen, eine für jede Testspezifikation, und jede 

referenziert die zugehörige Testspezifikation. Abhängig vom Typ der 

Testspezifikation enthält auch TM_ManualTestResults, 

TM_SilkTestResults, TM_PerformerResults, 

TM_ExecInputAttributes, TM_ExecInputParameters, 

Testausführungsmanagement | 31

TM_ExecDefRunsKeywords 

TM_PackageRuns 

TM_ManualTestResults 

TM_PerformerResults 

TM_PerfReports 

TM_SuccessMeasures oder TM_PackageRuns einen entsprechenden 

Eintrag. 

Diese Tabelle enthält für jeden Aufruf einer Testsuite einen Eintrag für alle 

einer Testsuite zugeordneten Schlüsselwörter. 

Diese Tabelle repräsentiert ein detailliertes Ergebnis für die 

Testspezifikationen, die zu einem Testpaket oder einer Testsuite gehören. 

Einen zugehörigen Eintrag für das Testpaket oder die Testsuite finden Sie 

TM_TestDefExecutions. 

Diese Tabelle enthält Informationen zu den Ergebnissen manueller Tests. 

Von besonderer Bedeutung ist die Referenz auf die Tabelle 

TM_ManualTestStepResults. Diese enthält Einzelheiten zu allen Schritten 

eines manuellen Tests. 

Jede Zeile dieser Tabelle muss eine Referenz auf TM_PerfReport 

enthalten. 

Diese Tabelle speichert Information über SilkPerformer-Testausführungen. 


Testausführungsmanagement auf Seite 28 


Codeanalyse 

Dieser Abschnitt gibt einen Überblick über den Teil des Datenbankschemas von Test Manager, der für die 

Codeanalyse (Codeabdeckung) relevant ist und beschreibt, wie das Schema für die Codeanalyse eingesetzt 

werden kann. 


Tabellen für die Codeanalyse auf Seite 33 

Tabellen für die Codeanalyse 

Dieses Thema beschreibt die Tabellen, die für die Codeanalyse relevant sind. Weisen Sie anhand dieser 

Tabellen Ihrem Testcode eine Codeabdeckung zu. 



Codeanalyse | 33

CC_CoverageBuild 

CC_CoveragePackage 

CC_Package 

CC_CoverageSourceFile 

CC_SourceFile 

CC_Class 

CC_CoverageMethod 

CC_Method 

Über diese Tabelle werden die detaillierten Abdeckungsinformationen mit einem 

Build verknüpft. Sie enthält die Detailinformationen in Form kumulierter Daten. 

Diese Tabelle enthält Abdeckungsinformationen für ein bestimmtes Package 

eines Build. 

Diese Tabelle wird für jeden Testsuitenamen erstellt. Diese Tabelle enthält ein 

Quell-Package (Java), das über den vollständigen Package-Namen identifiziert 

wird. 

Diese Tabelle wird für jede Quelldatei mit Abdeckungsinformationen und jedes 

Build erstellt. 

Diese Tabelle wird für jeden Quelldateinamen erstellt. Sie Diese speichert die 

Quelldatei. 

Diese Tabelle wird für jeden voll qualifiziertem Klassennamen erstellt. 

Diese Tabelle speichert für jedes Build Abdeckungsinformationen zu Methoden. 

Diese Tabelle wird für jede Methode erstellt und speichert den Name und die 

Signatur der Methode. 

34 | Codeanalyse

CC_MethodCoverage 


SCC_Builds 

Über diese Tabelle werden die Methodenaufrufe mit den Läufen von 

Testspezifikationen verknüpft. 

Speichert die Ausführungen der Testspezifikationen, die immer zu Testläufen 

der Testsuite gehören.Wenn eine Testsuite drei Testspezifikationen referenziert, 

erhalten Sie drei Testspezifikationsausführungen, eine für jede Testspezifikation, 

und jede referenziert die zugehörige Testspezifikation. Abhängig vom Typ der 

Testspezifikation enthält auch TM_ManualTestResults, 

TM_SilkTestResults, TM_PerformerResults, 

TM_ExecInputAttributes, TM_ExecInputParameters, 

TM_SuccessMeasures oder TM_PackageRuns einen entsprechenden Eintrag. 

Diese Systemtabelle speichert Informationen über alle Builds. 


Codeanalyse auf Seite 33 

Codeanalyse | 35

Berichte 

In diesem Abschnitt wird der Teil des Datenbankschemas von Test Manager beschrieben, der für die 

Berichtserstellung relevant ist. 



SCC_ReportFilter 

SCC_ReportFilterPaths 

Dies ist die Basistabelle für Berichtserstellungshierarchien. Jeder Knoten der 

Hierarchie wird durch eine Zeile dargestellt, die folgende Attribute enthält: 

• Die Knoten-ID des übergeordneten Knotens, ParentFilterNodeID_fk. 

• Grundlegende Informationen zum Knoten, wie ReportFilterName und 

ReportFilterDescription. 

• Die Renderer-ID des zugeordneten Renderers für den Bericht. 

• Das Berichtsmodul, ReportModule. 

Diese Tabelle enthält für alle Knoten Paare von Berichtsfilter-IDs und IDs 

übergeordneter Berichtsfilter, die die vollständigen Pfade der Berichte bis zu 

ihrem Stamm beschreiben. Dieselbe Methode wird in allen Test 

Manager-Hierarchien verwendet. 

36 | Berichte

SCC_ReportFilterColumns 

SCC_ReportFilterSettings 

SCC_ReportFilterGroup 

SCC_ReportFilterJoins 

SCC_ReportFilterJoinConds 

Diese Tabelle enthält die Informationen zu den ausgewählten Ergebnisspalten 

in einem Bericht. Angegeben werden Sortierrichtung, Aliasname, Reihenfolge 

und Aggregationstyp. 

In dieser generischen Tabelle werden Einstellungen für einen Bericht 

gespeichert (z.B. der Diagrammtyp). 

Diese Tabelle enthält die IDs von Berichten (FilterNodeID), denen andere 

Berichte als Unterberichte (SubFilterNodeID_fk) zugeordnet sind. 

Diese Tabelle enthält die IDs von Berichten, die mit anderen Berichten 

verknüpft sind. 

Diese Tabelle enthält die Verknüpfungsbedingung (Spaltenverknüpfung) für 

alle in der Tabelle SCC_ReportFilterJoins gespeicherten Verknüpfungen. 

Berichte | 37

Datenbankansichten 

Dieser Abschnitt gibt einen Überblick über den für Ansichten relevanten Teil des Datenbankschemas von Test 

Manager und beschreibt, wie das Datenbankmodell für die Berichtserstellung verwendet werden kann. 

Als Grundlage für Berichte sollten nur RTM_V_*- und LQM_V_*-Ansichten verwendet werden. Die Daten dieser 

Ansichten übernimmt der Berichtsabfragegenerator von Test Manager. TM_V_*-Ansichten werden häufig 

geändert und sollten nicht als Grundlage für Berichte verwendet werden. 


Allgemeine Ansichten auf Seite 38 

Anforderungsansichten auf Seite 39 

Ansichten zum Anforderungsfortschritt auf Seite 40 

Testplanansichten auf Seite 44 

Ansichten zum Testplanfortschritt auf Seite 47 

Fehleransichten auf Seite 49 

Allgemeine Ansichten 

Dieses Thema enthält einen Überblick über die allgemeinen Ansichten für die Berichtserstellung. 

RTM_V_AllDays 

RTM_V_Builds 

Diese Ansicht vereinfacht die Erstellung von Berichten, die auf Datumsdaten (Tag, 

Woche oder Monat) basieren. Das verwendete Datenbanksystem spielt dabei keine 

Rolle. In dieser Ansicht werden für jeden Tag die folgenden Spalten mit 

Datumsinformationen angezeigt: 

• Date_pk 

• CreatedYear 

• CreatedMonth 

• CreatedDay 

• CreatedWeek 

In dieser Ansicht werden alle Builds für jedes in der Datenbank von SilkCentral 

gespeicherte Produkt dargestellt. Die Ansicht enthält folgende Spalten: 

• VersionID_fk 

• VersionOrder 

• BuildName 

• BuildID 

• BuildOrder 

• OrderNumber 

• ProductID 

• ProductCode 

38 | Datenbankansichten


Datenbankansichten auf Seite 38 

Anforderungsansichten 

Dieses Thema enthält einen Überblick über die Anforderungsansichten für die Berichtserstellung. 

RTM_V_Requirements 

Diese Ansicht enthält Spalten mit allen Standardeigenschaften für 

Anforderungen sowie die Spalte TreeOrder, in der die Reihenfolge der 

Anforderungen in der Hierarchie dargestellt wird: 

• ReqID 

• ReqParentID 

• PositionNumber 

• ProjectID 

• ProjectName 

• ReqName 

• Risk 

• Priority 

• ReqDescription 

• ReqCreator 

• ReqCreated 

• ReqReviewed 

• ReqCoverageStatus 

• ReqRevision 

• MarkedAsObsolete 

• Obsolete 

• TreeOrder 

RTM_V_RequirementsHistory Mit Hilfe dieser Ansicht können Historie-Informationen zu Anforderungen 

ermittelt werden. Es werden alle geänderten Eigenschaften sowie eine 

Revisionsnummer für die Änderung angezeigt. Die Ansicht enthält folgende 

Spalten: 

• ReqID 

• ReqName 

• PropertyID 

• PropertyName 

• ChangedFrom 

• OrderNumber 

• ChangedTo 

• ChangedAt 

• ChangedBy 

• RevisionNumber 

• Sequence_pk 

Datenbankansichten | 39

RTM_V_ProjRequirements 

In dieser Ansicht können Abhängigkeiten für das aktuell ausgewählte Projekt 

gefiltert werden. Mit Hilfe eines Filters lassen sich beispielsweise die 

Anforderungen eines Projekts ermitteln. Die Ansicht enthält folgende Spalten: 

• ProjectID 


• ReqID 

• ReqName 

• PriorityID 

• Priority 

• ProductID 


RTM_V_ReqCustomProperties 

In dieser Ansicht werden die Namen und Werte der benutzerdefinierten 

Eigenschaften für Anforderungen angezeigt. Sie enthält folgende Spalten: 

• ReqID 

• PropertyID 

• PropertyName 

• PropertyValue 

RTM_V_ReqTests 

In dieser Ansicht werden alle Testspezifikationen angezeigt, die mit 

Anforderungen verknüpft sind. Sie enthält folgende Spalten: 

• TestID 

• TestName 

• ReqID 

• ReqName 

• Risk 

• Priority 

• TestDescription 

• TestType 

• TestTypeName 

• TestCreator 

• TestCreated 

• TestContainerID 

• TestContainerName 

• ProjectID 




Ansichten zum Anforderungsfortschritt 

Dieses Thema enthält einen Überblick über die Ansichten zum Anforderungsfortschritt für die Berichtserstellung. 


Wenn Sie die Anforderungsabdeckung über einen bestimmten Zeitraum darstellen möchten, müssen Sie den 

Status einer Testspezifikation über mehrere Builds oder Tage hinweg nachverfolgen. 

Beispiel 

Die Testspezifikationen TD1, TD2, TD3 und TD4 wurden mit den Builds 320 bis 325 

ausgeführt und lieferten folgende Ergebnisse: 

1 gibt den Status Bestanden, 2 Fehlgeschlagen, 3 Nicht ausgeführt und 4 Nicht 

eingeplant an. 

TD1 

TD2 

TD2 

TD1 

TD1 

TD3 

TD4 

TD2 

TD4 

320 

320 

321 

322 

323 

323 

324 

324 

325 

1 -> Bestanden 

2 -> Fehlgeschlagen 

3 -> Nicht ausgeführt 

2 

1 

1 

4 -> Nicht eingeplant 

Wie Sie sehen, wurde die Testspezifikation TD1 nicht mit Build 321 ausgeführt. Für Ihren 

Fortschrittsbericht verwenden Sie den Status des letzten Build, mit dem TD1 ausgeführt 

wurde. Sie benötigen dazu die folgende Ansicht: 

1 

2 

320 

TD1 

320 

1 

320 

TD2 

320 

2 

321 

TD1 

320 

1 

321 

TD2 

321 

3 

322 

TD1 

322 

2 

322 

TD2 

321 

3 

323 

TD1 

323 

1 

323 

TD2 

321 

3 

323 

TD3 

323 

1 

324 

TD1 

323 

1 

324 

TD2 

324 

1 

324 

TD3 

323 

1 

324 

TD4 

324 

4 

325 

TD1 

323 

1 

325 

TD2 

324 

1 

325 

TD3 

323 

1 


325 

TD4 

324 

2 

Hier können Sie jetzt den Status aller Testspezifikationen für jedes Build sehen. 

RTM_V_ReqProgressBuilds und RTM_V_ReqProgressDays 

Sie möchten nun die im letzten Beispiel gezeigten Daten nach Anforderungen gruppieren und zusätzliche 

Spalten einführen, um eine Filterung nach Anforderungen, Produkten, Prioritäten, Builds und Zeitspanne 

durchzuführen. 

Da sich eine Gruppierung auf das Ergebnis auswirkt, müssen Sie zwei verschiedene Ansichten für den Bericht 

verwenden. Je nach gewünschtem Gruppierungstyp legen Sie fest, ob nach Build oder nach Datum gruppiert 

werden soll. Folgende Ansichten stehen für diesen Zweck zur Verfügung: 

RTM_V_ReqProgressBuilds Diese Ansicht enthält den nach Build sortierten Status aller Anforderungen. Zu 

jeder Anforderung wird der Status für ein Build angezeigt, wobei mit dem 

Erstellungsdatum begonnen wird. Die Spalten BuildFrom und DateFrom 

beziehen sich auf das Build, bei dem die Anforderungsabdeckung aufgrund 

von Änderungen in der Testabdeckung zuletzt berechnet wurde. Die Ansicht 

enthält folgende Spalten: 

• VersionID 

• BuildID 

• BuildName 

• BuildFrom 

• DateFrom 

• ReqID 

• ReqName 


• Priority 

• ProjectID 


• ProductID 


• CoverageStatus 

• CoverageStatusName 

RTM_V_ReqProgressDays 

Diese Ansicht enthält den nach Datum sortierten Status aller Anforderungen. 

Zu jeder Anforderung wird der Status für ein Datum ausgegeben. Die Spalten 

BuildFromID, BuildFrom und DateFrom beziehen sich auf das Build, bei 

dem die Anforderungsabdeckung aufgrund von Änderungen in der 

Testabdeckung zuletzt berechnet wurde. Die Ansicht enthält folgende Spalten: 

• DateVal 

• DateFrom 

• BuildFrom 

• BuildFromID 

• ReqID 

• ReqName 

• Priority 



• ProjectID 


• ProductID 


• CoverageStatus 

• CoverageStatusName 

Die folgenden Beispiele zeigen, wie diese Ansichten angewendet werden können: 

Gruppieren nach Builds: 

Eine Abfrage für einen Bericht mit mit vollständigem Anforderungsfortschritt, wobei 

ProjectID den Wert 0 hat: 

SELECT BuildName, CoverageStatus, CoverageStatusName, Count(ReqID) 

As Result 

FROM RTM_V_ReqProgressBuilds 

WHERE ProjectID = 0 

GROUP BY ProductID, BuildOrder, BuildName, CoverageStatus, 

CoverageStatusName 

ORDER BY ProductID, BuildOrder, CoverageStatus 

Das Ergebnis sieht in etwa folgendermaßen aus: 

BuildName 

CoverageStatus 

CoverageStatusName 

Result 

324 

4 

Nicht abgedeckt 

4 

325 

3 

Fehlgeschlagen 

2 

325 

4 

Nicht abgedeckt 

2 

350 

1 

Bestanden 

2 

Für Build 324 haben vier Anforderungen den Status "Nicht abgedeckt". Für Build 325 haben 

zwei Anforderungen den Status "Fehlgeschlagen" und zwei Anforderungen den Status 

"Nicht abgedeckt". 

Wenn sich der Bericht nur auf einen Teil der Anforderungshierarchie beziehen soll, können 

Sie nicht einfach eine weitere where-Klausel verwenden, da dann die untergeordneten 

Anforderungen und deren untergeordnete Anforderungen nicht berücksichtigt werden. Sie 

müssen zu diesem Zweck eine Verknüpfung zur Tabelle TM_ReqTreePaths herstellen: 

SELECT BuildName, CoverageStatus, CoverageStatusName, Count(ReqID) 

As Result 

FROM RTM_V_ReqProgressBuilds rps 

INNER JOIN TM_ReqTreePaths rt ON (rt.ReqNodeID_pk_fk = rps.ReqID) 

WHERE ProjectID = 0 AND (rt.ParentNodeID_pk_fk = 3) 

GROUP BY BuildOrder, BuildName, CoverageStatus, CoverageStatusName 

ORDER BY BuildOrder, CoverageStatus 


Gruppieren nach Tagen: 

Eine Abfrage für einen Bericht mit mit vollständigem Anforderungsfortschritt vom 12. bis 

(20050412) 13. April (20050413), wobei ProjectID den Wert 0 hat: 

SELECT DateVal, CoverageStatus, CoverageStatusName, Count(ReqID) 

As Result 

FROM RTM_V_ReqProgressDays 

WHERE ProjectID = 0 AND DateVal >= '20050412' AND DateVal

RTM_V_TestDefinitions 

In dieser Ansicht werden für alle Testspezifikationen Informationen zum Typ, 

Container und Projekt angezeigt. Sie enthält folgende Spalten: 



• ProjectID 







• CurrentExecStatus 

• LastExecutedAt 



• TreeOrder 

RTM_V_TestDefsComponents 

In dieser Ansicht werden für alle Testspezifikationen Container-, Produkt-, 

Komponenten- und Projektinformationen angezeigt. Sie enthält folgende 

Spalten: 



• ProjectID 




• ProductID 


• ComponentID 

• ComponentName 

RTM_V_TestsWithAttributes 

In dieser Ansicht werden für alle Testspezifikationen Container-, Projekt-, 

Testtyp- und Attributinformationen angezeigt. Integrierte Systemattribute, 

die sich auf Testspezifikationseigenschaften beziehen, werden nicht 

berücksichtigt. Die Ansicht enthält folgende Spalten: 



• ProjectID 







• CurrentExecStatus 

• LastExecutedAt 




• TreeOrder 

• NA_NodeID 

• AttributeID 

• AttributeName 

• ValueID 

• AV_AttributeValue 

LQM_V_Tests 

Anstelle von RTM_V_*-Ansichten zum Erstellen von Projekten können Sie 

auch die Ansicht LQM_V_Tests abfragen, die Informationen aus LQM_Tests 

und LQM_TestUDAs verknüpft. Diese Ansicht bietet einen effizienten Weg 

eine Vielzahl von Informationen zu Testspezifikationen und Attributen 

abzufragen. 

Tipp: Da bei der Abfrage dieser Ansicht keine Verknüpfungen verwendet 

werden, können Sie LIKE %-Abfragen einsetzen, ohne wesentliche 

Auswirkungen auf die Antwortzeit befürchten zu müssen. 

Spalten mit dem Präfix uda_ kommen aus LQM_TestUDAs. Alle anderen 

Spalten kommen aus LQM_Tests. Weitere Informationen finden Sie bei den 

betreffenden Tabellenbeschreibungen. Die Ansicht enthält folgende Spalten: 

• TestID_pk 

• ProjectID_fk 

• ParentID_fk 

• ContainerID_fk 

• ExternalID 

• NodeType 

• Name 

• Type 

• ProductID_fk 

• Component 

• Platform 

• PlannedTime 

• CreatedBy 

• CreatedAt 

• ChangedBy 

• ChangedAt 

• a_script 

• a_testcase 

• a_datadriven 

• a_dd_dataset 

• a_dd_datasource 

• a_dd_filterquery 

• a_dd_multiple 

• a_dotnet_exe 

• a_junit_classfile 

• a_junit_classpath 


• a_junit_coveragepath 

• a_junit_coverage14 

• a_junit_javahome 

• a_junit_testmethod 

• a_nunit_assembly 

• a_nunit_dependentlibs 

• a_nunit_dir 

• a_nunit_libs 

• a_sp_projectfile 

• a_sp_sourcecontrolid 

• a_sp_workload 

• a_st_optionset 

• a_st_testdata 

• a_st_truelog 

• a_wsh_Switches 

• sc_errors_allowed 

• sc_errors_value 

• sc_warnings_allowed 

• sc_warnings_value 

• sc_timeout_isactive 

• sc_timeout_value 

• sc_pagetime_avg_isactive 

• sc_pagetime_avg_value 

• sc_pagetime_max_isactive 

• sc_pagetime_max_value 

• sc_transtime_avg_isactive 

• sc_transtime_avg_value 

• sc_transtime_max_isactive 

• sc_transtime_max_value 

• DbCreatedAt 

• DbChangedAt 

• uda_1 

• uda_2 

• ... 

• uda_50 



Ansichten zum Testplanfortschritt 

Dieses Thema enthält einen Überblick über die Ansichten zum Testplanfortschritt für die Berichtserstellung. 


RTM_V_TDProgressBuilds Diese Ansicht enthält den nach Build sortierten Status aller Testspezifikationen. 

Zu jeder Testspezifikation wird der Status für ein Build angezeigt, wobei mit dem 

Erstellungsdatum begonnen wird. Die Spalten BuildFromID, BuildFrom und 

DateFrom beziehen sich auf das Build bzw. das Datum, an dem der 

Testspezifikationsstatus zuletzt gesetzt wurde (z.B. aufgrund eines 

Ausführungsergebnisses). Die Ansicht enthält folgende Spalten: 

• VersionID 

• VersionName 

• VersionOrder 

• BuildID 

• BuildName 

• BuildOrder 


• BuildFrom 

• DateFrom 



• ProjectID 




• ProductID 




• StatusID 

• StatusName 

RTM_V_TDProgressDays 

Diese Ansicht enthält den nach Datum sortierten Status aller Testspezifikationen. 

Zu jeder Testspezifikation wird der Status an einem bestimmten Datum angezeigt, 

wobei mit dem Erstellungsdatum begonnen wird. Die Spalten BuildFromID, 

BuildFrom und DateFrom beziehen sich auf das Build bzw. das Datum, an 

dem der Testspezifikationsstatus zuletzt gesetzt wurde (z.B. aufgrund eines 

Ausführungsergebnisses). Die Ansicht enthält folgende Spalten: 

• DateVal 

• DateFrom 

• BuildFrom 




• ProjectID 




• ProductID 





• StatusID 

• StatusName 



Fehleransichten 

Dieses Thema enthält einen Überblick über die Fehleransichten für die Berichtserstellung. 

RTM_V_TestDefects 

In dieser Ansicht werden alle Testspezifikationen angezeigt, für die mindestens ein 

Fehler existiert. Die Ansicht enthält folgende Spalten: 





• IssueID_pk 

• InternStatus 

• Name 

• Description 

• ExternIssueID 

• ExternHttpLink 

• ProjectID 


RTM_V_IssuesHistories 

Diese Ansicht enthält die Historie aller Fehler. Hierzu gehören Informationen zum 

Status und Build sowie Verknüpfungen zu Testspezifikationen, Komponenten, 

Produkten und Projekten. Die Ansicht enthält folgende Spalten: 

• HistoryID_pk 

• IssueID 

• IssueName 

• InternStatus 

• StatusID 

• CreatedAt 

• CreatedBy 

• BuildID 

• BuildName 





• ProductID 

• ProductName 


• ProjectID 


• CreatedYear 

• CreatedMonth 

• CreatedDay 

• CreatedWeek 




Index 

A 

Allgemeine Ansichten 

Überblick 38 

Anforderungen 

Grundlegende Tabellen 6 

Anforderungen verwalten 

Datenbankmodell 5 

Anforderungsansichten 

Überblick 39 

Anforderungsfortschrittsansichten 

Überblick 40 

Anforderungsimport 

Office-Dokumente 8 

Anforderungsmanagement 

Fremdhersteller 8 

Attribute 

Integrierte 20 

Tabellen 19 

Ausführungsergebnisse 

Tabellen 30 

B 

Bericht 

Tabellen 25 

Berichtserstellung 


C 

Codeabdeckung 

Tabellen 33 

Codeanalyse 


Tabellen 33 

Container 

Tabellen 13 

D 

Datenbankmodell 

Anforderungen verwalten 5 

Berichtserstellung 36 

Codeanalyse 33 

Testausführungsmanagement 28 

Testpläne verwalten 11 

Übersicht 4 

Datenbankmodell (Fortsetzung) 

Verfügbare Ansichten 38 

F 

Fehler 

Tabellen 18 

Fehleransichten 

Überblick 49 

I 

Integrierte Attribute 

Tabellen 21 

M 

Manuelle Testspezifikationen 

Tabellen 16 

P 

Parameter 

Tabellen 23 

T 

Tägliche Fehlerstatistiken 

Tabellen 24 

Testausführungsmanagement 


Testplanansichten 

Überblick 44 

Testpläne verwalten 


Testplanfortschrittsansichten 

Überblick 47 

Testspezifikationen 

Grundlegende Tabellen 12 

Tabellen 15 

Testsuitehierarchie 

Tabellen 28 

V 

Verfügbare Ansichten 


Index | 51

SilkCentralÂ® Test Managerâ¢ 2009 SP1

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?

SilkCentralÂ® Test Managerâ¢ 2009 SP1