Testdokument - se.uni-oldenburg.de · 2. Qualitätssicherung 2. Qualitätssicherung Autor: Marion...

Fakultät II: Department für Informatik

Projektgruppe 2011/2012

Testdokument

Zur Anwendung PlagTag

Version 1.0

Betreuer:Prof. Dr. Andreas Winter

M.Sc. Jan Jelschen

Mitglieder:

Tore BierwirthChristoph GerkenMarion Gottschalk

Sieglinde HahnMaxim Klimenko

Björn Wol�Christian Wübbeling

Oldenburg, den 30. September 2012

Inhaltsverzeichnis

Inhaltsverzeichnis

1. Einleitung 1

2. Qualitätssicherung 2

2.1. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.1. Funktionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2. Verbundtest / Integrationstest / Systemtest . . . . . . . . . . . . . . . . . . . 22.1.3. Abnahmetest / Akzeptanztests . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.4. Dokumententest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.5. Usability-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.1. JUnit-Test für PlagTag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3. Code Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.1. Verlauf des Code Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.2. Regeln des Code Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.3. Durchgeführte Code Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.3.1. Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3.2. Plagiatserkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3.3. Steuerungslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Abnahmetest 12

3.1. Übersicht über zu testende Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 123.2. Rahmenbedingungen und Testfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1. Erfassung von Test-Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2. Au�istung von Test-Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . 17

A. Tabellenverzeichnis 21

B. Literaturverzeichnis 22

C. Glossar 23

D. Anhang 26

i

1. Einleitung

1. Einleitung

Autor: Sieglinde Hahn

Das Testdokument dient zum Feststellen von möglichen Fehlern, welche bei der Implementierungaufgetreten sind. Um mögliche Fehler erkennen und beheben zu können, �ndet eine ausführlicheDokumentation der Tests statt.Das Testdokument teilt sich in die Testbereiche Qualitätssicherung und Abnahmetest. Zu Beginnwerden im Rahmen der Qualitätssicherung 2 mögliche Testarten vorgestellt. Des Weiteren werdendie verwendeten Testarten und ihre Vorgehensweise erläutert. Das Kapitel Abnahmetest 3 umfasstAbnahmetests von PlagTag, welche hinreichend dokumentiert werden. Unabhängig von diesem Do-kument sind umfangreiche Funktionstests, wie in 2.1.1 beschrieben wird, während der Implemen-tierung von den jeweiligen Entwicklern durchgeführt worden. Dies resultiert in einer geringerenFehleranzahl, sodass die genutzten Testverfahren e�ektiver eingesetzt werden können.

1

2. Qualitätssicherung

2. Qualitätssicherung

Autor: Marion Gottschalk, Sieglinde Hahn

Die Qualitätssicherung von PlagTag soll mithilfe von unterschiedlichen Tests erfolgen. Die Durchfüh-rung von Tests soll dabei helfen die Lau�ähigkeit von PlagTag zu überprüfen. Es existieren mehrereTestvarianten, um die Qualitätssicherung zu unterstützen. Daher werden im folgenden Abschnitteine Reihe von Tests kurz vorgestellt, welche während des Entwicklungszeitraums eingesetzt werdenkönnen. Genutzt werden im Rahmen der Qualitätssicherung Unit-Tests in Form von JUnit und dasCode Review, daher werden diese detaillierter beschrieben.

Der Durchführungszeitraum der Tests �ndet sich im Vorgehensmodell im P�ichtenheft. Es wirdparallel zu der Implementierung getestet.

2.1. Tests

Autor: Sieglinde Hahn, Christian Wübbeling

Grechenig und Bernhard [GB09] stellen folgende Test-Varianten vor, welche in diesem Projekt zu-sätzlich neben JUnit und Code Review durchgeführt werden könnten.

2.1.1. Funktionstest

Das Ziel des Funktionstests ist es, die Implementierung jeder Funktion zu überprüfen. Die Imple-mentierung jeder Funktion muss strikt den Kriterien der Anforderungen entsprechen. Jede Funktionsoll individuell getestet werden. Das heiÿt, dass die Tests jeder Funktion nicht von der Einga-be oder Ausgabe eines anderen Tests abhängig sein dürfen. Man verwendet hier Klassen-Stubs,um Ein- / Ausgabesimulationen (z.B. mittels JUnit für Java-Klassen) durchzuführen. Der Funk-tionstest ist von den Entwicklern selbst durchzuführen, jeder Entwickler testet seine bearbeitetenFunktionen selbstständig und ist dafür verantwortlich. Gefundene Fehler werden i.d.R. sofort kor-rigiert und nicht schriftlich erfasst. Beispiel: Test der Komponente Datenhaltung, ob die Methode"referenzdokumentAnlegen" die korrekten Rückgabewerte liefert.

2.1.2. Verbundtest / Integrationstest / Systemtest

Im Integrationstest wird die Richtigkeit der Verarbeitung von Daten im Teil- oder Gesamtsystemüberprüft. Es kann hierbei mehrere Integrationsstufen und somit Iterationen geben. Bei mehrerenSystemen, deren Interaktion getestet werden soll, kann es sich auch um einen Systemintegrationstesthandeln. Auf der Ebene des Gesamtsystems wird dieser Test als Systemtest bezeichnet. Der Ver-bundtest wird von Entwicklern der Funktionen oder Testverantwortlichen durchgeführt. Beispiel:Arbeiten die Funktionen der Datenhaltung und Vorverarbeitung korrekt zusammen?

2.1.3. Abnahmetest / Akzeptanztests

Der Abnahmetest für die Anwendung PlagTag wird bei Abgabe vom Kunden bzw. dem Syste-madministrator durchgeführt. Das Ziel ist es, Fehler, die sich aus dem Vergleich der Anforderungendes Kunden mit dem Produkt ergeben, zu erkennen. Die aufgetretenen Fehler werden in einemChange Request vom Kunden festgehalten und an die Entwickler (PG) weitergeleitet. Die Anträgewerden über den Single Point of Contact (SPOC) verwaltet, dieser verteilt die Anträge dement-sprechend oder entscheidet, ob die Anforderung zu Komplikationen führt. Die bearbeiteten ChangeRequest werden, mit eingearbeitetem Feedback, an den Antragsteller zurück geschickt. Werden beider Durchführung der Tests keine Fehler gefunden, gilt der Vertrag als erfüllt. Beispiel: Prüfung desGesamtsystems gegen die Anforderungen, umfasst auch z.B. die Installierbarkeit.

2

2.2. JUnit

2.1.4. Dokumententest

Der Dokumententest wird anhand von vorde�nierten Spezi�kationskriterien abgeprüft, ob die je-weiligen technischen Vorgaben, Funktionsspezi�kationen und Kommentare der Quelltexte vollstän-dig und korrekt formuliert vorhanden sind. Der Dokumententest der Funktionsspezi�kationen undKommentare der Quelltexte wird von Entwicklern der Funktionen vorgenommen. Der gesamte Do-kumententest wird von Testverantwortlichen durchgeführt. Beispiel: Transparenz der Funktionenim Quellcode des Systems.

2.1.5. Usability-Test

Dieser Test soll es ermöglichen, Schwächen in der Bedienbarkeit aufzudecken. Dazu wird sich durchTestfälle beholfen, die von einem Anwender, welcher technisch noch nicht mit dem System vertrautist, bewältigt werden müssen. Sie werden bei ihrer Arbeit beobachtet und mögliche Probleme werdenfestgehalten. Durch den Einsatz von Usability-Test sollen aufwändige Änderungen vermieden undder Aufwand reduziert werden, welches zu einer Zeitersparnis führt. Diese Tests müssen aufgrundder Anforderung Q100 durchgeführt werden.

2.2. JUnit


Mithilfe von JUnit können automatische Unit Tests in Java ausgeführt werden. Die erstellten JU-nit-Test sind wiederholbar. JUnit bietet das Testen von Programmeinheiten, welche isoliert sindvon anderen zusammenhängenden Programmiereinheiten [Wes], wie bereits in Abschnitt 2.1 kurzbeschrieben.

JUnit ist ein reines Java-Framework, somit stellt die Programmiersprache die Testsprache dar.Die Testfälle werden in einer eigenen Klassenhierarchie hinterlegt, wodurch eine Trennung vonAnwendungs- und Testcode statt�ndet. Es muss eine Unabhängigkeit der Testfälle untereinanderbestehen, da es JUnit ermöglicht Gemeinsamkeiten von Tests in einer setUp()-Methode auszu-lagern, welche für jeden Test separat ausgeführt wird. Somit ist die Reihenfolge der Tests nichtrelevant. Es kann eine beliebige Zusammenfassung von Tests in Testsuiten durchgeführt werden.Durch die Assert-Methoden �ndet eine Überprüfung der Testergebnisse statt. Hier erfolgt einegra�sche Darstellung der Testergebnisse in Eclipse, ein Erfolg wird Grün und ein Misserfolg Rotdargestellt [Lin05].

Um das JUnit-Test-Verfahren jedem Teilnehmer der PG zu erläutern, �ndet im Rahmen der PGeine interne Schulung statt, um die Funktion und die Anwendung von JUnit-Tests zu vermitteln(siehe Anforderung V020 ). Diese Schulung fand am 10.05.12 statt. In dieser wurde eine kleine the-matische Einführung zu JUnit gegeben und aus der Theorie geschlussfolgert welchen Nutzen wir fürdie PG ziehen können.

JUnit bietet der PG die Möglichkeit in der Programmiersprache Java zu programmieren und gleich-zeitig zu testen. Des Weiteren ist eine schnelle und einfache Wiederholbarkeit der Tests möglich.Das Testen von isolierten Programmiereinheiten bietet sich im Rahmen der PG besonders an, daso Komplikationen bei einer gleichzeitigen Bearbeitung vermieden werden können. Eine schnelleAusführbarkeit ist aufgrund von JUnit-Kurztests möglich. Durch das Festlegen vom erwartetenVerhalten kann ein Vergleich mit dem tatsächlichen Verhalten durchgeführt werden [Lin05].

2.2.1. JUnit-Test für PlagTag

Getestet wurden mithilfe von JUnit die Hauptkomponenten der Architektur, bei den Komponentenhandelt es sich um Datenhaltung, ErgebnisGenerator, Internetrecherche, Normalisierung, Plagiats-

3

2.3. Code Review

erkennung und SteuerungsLogik. Die Tests werden nicht vom eigentlichen Programmierer durch-geführt sondern von einem weiteren PG-Mitglied, um mögliche Fehler so besser identi�zieren zukönnen. JUnit-Test �nden in der Testphase statt. JUnit-Tests wurden für Version 1 für alle obengenannten Komponenten ausgeführt. In der Version 2 und 3 wurden aufgrund des hohen Arbeits-aufwand die Junit-Tests reduziert und es wurden wie in Abschnitt 2.3 beschrieben Code Reviewsdurchgeführt.Aufgrund des Protokollumfangs der JUnit-Tests be�nden sich die Testprotokolle mit den Testklas-sen im jeweiligen Ordner im Subversion-Repository. Diese Testprotokolle sind im Ordner Entwick-lung\Version1\... der zu testenden Komponente in einem separaten Ordner zu �nden, welcher Testbenannt ist.

2.3. Code Review

Autor: Marion Gottschalk, Sieglinde Hahn

Code Reviews sollen nur bei elementaren Bestandteilen des Codes durchgeführt werden. Zu denelementaren Bestandteilen des Codes gehören die Algorithmen zur Erkennung von Plagiaten unddie Steuerungsabläufe zwischen den Komponenten, d.h. die Weitergabe von Informationen einzelnerKomponenten über die SteuerungsLogik zu einer anderen Komponente.

Auÿerdem werden durch die de�nierten Code-Konventionen ein Teil der Qualitätssicherung eingehal-ten, um die Lesbarkeit und Wartbarkeit von PlagTag zu gewährleisten. Diese Vorgehen erleichterndaher das spätere Code Review.

Die elementaren Bestandteile des Codes werden von einer Person, welche nicht direkt am Code gear-beitet hat, gegengelesen und auf Korrektheit und Funktionalität analysiert. Diese Überprüfung wirddokumentiert, um dem Programmierer und der PG einen Überblick über Korrektheit und Funktio-nalität zu geben. Für den Programmierer können Kommentare und Anmerkungen zusätzlich in derDokumentation vermerkt werden, um mögliche Fehler beheben zu können [Lin05]. Das Code Review�ndet in der Testphase statt. Die Testphase �ndet in jedem Zyklus parallel zur Implementierungstatt, siehe Vorgehensmodell im P�ichtenheft.

2.3.1. Verlauf des Code Reviews

Autor: Marion Gottschalk

Das Code Review �ndet innerhalb der Testphase statt und soll in Version 2 durchgeführt werden,da erst am Ende von Version 1 beschlossen wurde, dass Code Reviews eine sinnvolle Ergänzung zuden JUnit- und Abnahmetests sind. Die Code Reviews werden von der Projektleitung zugeteilt undsollen am Ende der Implementierungsphase von Version 2 statt�nden. Da am Ende von Version 2 dieZeit fehlte, sind einige Code Reviews nicht durchgeführt worden, sodass die hier aufgelisteten CodeReviews nur ein Teil der geplanten sind. In Version 3 wurde in den Kernkomponenten Steuerungs-Logik, Plagiatserkennung und Datenhaltung auf das Code Review verzichtet um mehr Zeit für dieAbnahmetests investieren zu können.

2.3.2. Regeln des Code Reviews

Autor: Marion Gottschalk

Bevor mit den Code Reviews begonnen wurde, sind Regeln für das Code Review festgelegt und derPG vorgestellt worden. Während der Implementierungsphase wurden diese Regeln im Wiki der PGfestgehalten und werden hier nochmal zum Verständnis aufgeführt. Die aufgelisteten Regeln dienendazu, dass Code Review so e�zient und erfolgreich wie möglich zu gestalten. Die Regeln wurdenaus der Dokumentation von SmartBear Software [Sma11] entnommen.

4

2.3. Code Review

1. Nie den eigenen Code reviewn.

2. Maximal 400 Zeilen Code am Stück reviewn.

3. Maximal 90 Minuten für diese 400 Zeilen Code investieren.

4. Bevor das Code Review durchgeführt wird, muss der Autor des Codes diesen vollständigdokumentieren.

5. Worauf soll beim Code Review geachtet werden?

� Java-Doc korrekt verwendet?

� Code Konventionen eingehalten?

� Macht die Methode, was sie soll?

6. Wird ein Fehler im Code entdeckt, muss der Reviewer dem Code-Autor eine Email mit Hinweisdarauf schreiben oder beim nächsten PG-Tre�en mit diesem besprechen. Auÿerdem soll einTicket vom Reviewer erstellt werden, welches vom Code-Autor geschlossen werden muss. Diessoll die interne Verwaltung unterstützen.

7. Der Reviewer überprüft, ob die besprochenen Hinweise auch umgesetzt wurden.

2.3.3. Durchgeführte Code Reviews


Im folgenden Abschnitt werden die Komponenten Datenhaltung, Plagiatserkennung und Steuerungs-logik mittels Code Review getestet. Diese Komponenten stellen die Kernkomponenten von PlagTagdar und unterliegen daher nicht nur den JUnit-Tests, siehe 2.2, sondern auch dem Code Review.Überprüft wird hierbei die Logik, die Einhaltung der Code-Konventionen und Java-Doc, wie im vor-herigen Abschnitt 2.3.2 beschrieben. Die Dokumentation erfolgt in Tabellenform, wie im Folgendenbeispielhaft dargestellt ist.

ID Eine eindeutige ID, um den Testfall zuordnen zu können.Getestete Komponenten Der Name der zu testenden Komponenten.Reviewer Name des Reviewers.Versionsnummer Die Versionsnummer.Logik Logische Aspekte des Codes.Java-Doc Einhaltung von Java-Doc.Code-Konventionen Einhaltung der Code-Konventionen.Anmerkungen Wichtige Anmerkungen.

Tabelle 1: Code Review - Aufbau

2.3.3.1. Datenhaltung

ID D01

Getestete Kom-ponenten

Datenhaltung - LogPrinter

Reviewer Sieglinde HahnVersionsnummer 2.0

5

2.3. Code Review

ID D01

Logik Logischer Aufbau der Klasse. Gute Nachvollziehbarkeit aufgrund der eingehal-tenden Code-Konventionen und Java-Doc.

Java-Doc Präzise und ausführlich beschrieben.Code-Konventionen

Die Code-Konventionen wurden eingehalten.

Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert.

Tabelle 2: Code Review - Datenhaltung - LogPrinter

ID D02


Datenhaltung - DatenhaltungImplementierung

Reviewer Sieglinde HahnVersionsnummer 2.0Logik Logischer Aufbau der Methoden. Gute Nachvollziehbarkeit aufgrund der ein-

gehaltenden Code-Konventionen und Java-Doc.Java-Doc Präzise und ausführlich beschrieben. Allerdings Alternative unklar.Code-Konventionen


Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert. Fehleranzeige in Zeile 2145�NamingException | SQLException�. opk und ord nicht in den Konventionenfestgehalten.

Tabelle 3: Code Review - Datenhaltung - DatenhaltungImplementierung

ID D03


Datenhaltung - Kon�gurationsdaten

Reviewer Sieglinde HahnVersionsnummer 2.0Logik Logischer Aufbau der Klasse. Gute Nachvollziehbarkeit aufgrund der eingehal-

tenden Code-Konventionen und Java-Doc.Java-Doc Zu wenig beschrieben.Code-Konventionen


Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert. Kommentare sehr knapp.

Tabelle 4: Code Review - Datenhaltung - Kon�gurationsdaten

ID D04


Datenhaltung - Konverter

Reviewer Sieglinde HahnVersionsnummer 2.0Logik Logischer Aufbau der Klasse.Java-Doc Präzise und ausführlich beschrieben.Code-Konventionen


6

2.3. Code Review

ID D04


Tabelle 5: Code Review - Datenhaltung - Konverter

ID D05


Datenhaltung - SQLBinding


Name der Klasse entspricht nicht den CodeKonventionen.


Tabelle 6: Code Review - Datenhaltung - SQLBindung

ID D06


Datenhaltung - Stammdaten




Tabelle 7: Code Review - Datenhaltung - SQLBindung

2.3.3.2. Plagiatserkennung

ID P01


Plagiatserkennung - BoyerMoore

Reviewer Sieglinde HahnVersionsnummer 2.0Logik int stringSuchen = ok

int[ ] createShiftTable = okint[ ] createO�setTable = okint su�xLength = okboolean isPre�x = okPlagiat[ ] sucheDurchfuehren = okLogischer Aufbau der Klasse.

Java-Doc Es fehlt die Versionsnummer. @brief ist kein festgehaltener Standard der PG.Ansonsten korrekt genutzt.

Code-Konventionen


Anmerkungen Fehlende Kommentare. Denglisch.

7

2.3. Code Review

ID P01

Tabelle 8: Code Review - Plagiatserkennung - BoyerMoore

ID P02


Plagiatserkennung - JavaString

Reviewer Sieglinde HahnVersionsnummer 2.0Logik Logischer Aufbau der Klasse.Java-Doc Es fehlt die Versionsnummer. @brief ist kein festgehaltener Standard der PG.

Ansonsten korrekt genutzt.Code-Konventionen


Anmerkungen Fehlende Kommentare.

Tabelle 9: Code Review - Plagiatserkennung - JavaString

ID P03


Plagiatserkennung - RabinKarp





Tabelle 10: Code Review - Plagiatserkennung - RabinKarp

ID P04


Plagiatserkennung - NGram





Tabelle 11: Code Review - Plagiatserkennung - NGram

8

2.3. Code Review

ID P05


Plagiatserkennung - RabinKarpDTO





Tabelle 12: Code Review - Plagiatserkennung - RabinKarpDTO

ID P06


Plagiatserkennung - Token


Umlautfehler. Ansonsten korrekt genutzt.Code-Konventionen



Tabelle 13: Code Review - Plagiatserkennung - Token

ID P07


Plagiatserkennung - PlagiatserkennungImplementierung





Tabelle 14: Code Review - Plagiatserkennung - PlagiatserkennungImplementierung

ID P08


Plagiatserkennung - Nachbereitung

Reviewer Sieglinde HahnVersionsnummer 2.0Logik Logischer Aufbau der Klasse.

9

2.3. Code Review

ID P08

Java-Doc Es fehlt die Versionsnummer. @brief ist kein festgehaltener Standard der PG.Umlautfehler. Ansonsten korrekt genutzt.

Code-Konventionen


Anmerkungen Fehlende Kommentare. Imports werden nicht alle verwendet.

Tabelle 15: Code Review - Plagiatserkennung - Nachbereitung

ID P09


Plagiatserkennung - StringMerge





Tabelle 16: Code Review - Plagiatserkennung - StringMerge

ID P10


Plagiatserkennung - NGramGenerator





Tabelle 17: Code Review - Plagiatserkennung - NGramGenerator

ID P11


Plagiatserkennung - TokenGenerator





Tabelle 18: Code Review - Plagiatserkennung - TokenGenerator

10

2.3. Code Review

ID P12


Plagiatserkennung - Vorbereitung




Anmerkungen Fehlende Kommentare. Nicht verwendet: private Plagiatsueberpruefung oPla-giatsueberpruefung und private int iPlagiatsueberpruefungsID

Tabelle 19: Code Review - Plagiatserkennung - Vorbereitung

2.3.3.3. Steuerungslogik

ID S01


SteuerngslogikImplementierung

Reviewer Maxim KlimenkoVersionsnummer 2.0Logik Angemessene stetig eingehaltene Methodenstruktur und Fehlerbehandlung. Ei-

ne Korrektur bezüglich der Anpassung von '<' auf '<=' ist vom Entwicklerdirekt umgesetzt worden

Java-Doc Angemessener Umfang und gleichbleibende Struktur, jedoch ohne @patternCode-Konventionen

Werden eingehalten. Eine Anmerkung, statt 'e' 'oFehler' zu verwenden, ist vomEntwickler direkt umgesetzt worden

Anmerkungen Zusammen mit dem verantwortlichem Entwickler wurden Optimierungen amCode durchgeführt

Tabelle 20: Code Review - Steuerungslogik

11

3. Abnahmetest

3. Abnahmetest

Autor: Christian Wübbeling

Es soll nach jeder Iteration ein Abnahmetest durchgeführt werden. Dabei gilt, dass möglichst alleKomponenten der Software beim Systemtest angesprochen / verwendet werden. Dies soll durchOrientierung an den im P�ichtenheft de�nierten Anwendungsfällen - hier mit AF X.Y abgekürzt -erreicht werden.

3.1. Übersicht über zu testende Anforderungen

Getestet wird auf alle funktionalen und nichtfunktionalen Anforderungen (aus dem P�ichtenheftbzw. dem Projekt-Wiki), u.a.:

� Erkennung von Plagiaten mittels mindestens zwei auswählbaren und kon�gurierbaren Al-gorithmen (F140, F321, F290, E050 ), darunter auch mittels eines linguistischen Verfahrens(F340 )

� Internetrecherche mit Auswahlmöglichkeit von Quellen (F150 ), diese muss zusätzlich - wiealle anderen längeren Prozesse - abbrechbar sein (F560, F450 )

� Eignung für die verschiedenen Plagiatskandidat- und Referenzdokument-Formate TXT undPDF (F360, F370 und F380 ). Die Internetrecherche muss zusätzlich HTML interpretierenkönnen.

� Ein Experten- und Standardmodus, u.a. mit Kon�gurierbarkeit der Algorithmen (F460, F470und F480 )

� Ein Ergebnisdokument soll einen Strichcode, ein Kuchendiagramm, farbliche Text-Markie-rungen der Plagitsverdachtsstellen, eine Abschätzung bzgl. der Plagiatsverdachtsstellen aus-geben und muss nach PDF exportierbar sein (F220, F250, F280 und F400 )

� Webfrontend ist mit Firefox, Chrome und Safari benutzbar (F510, F520 und F530 )

� Plagiatsüberprüfungen müssen personenbezogene Daten zum Autor von Plagiatskandidatenim Ergebnisdokument anonymisieren, Referenzdokumente und Plagiatskandidaten müssennach Überprüfung gelöscht werden (Q030, Q040 und Q050 )

Alle Anforderungen werden im folgenden Kapitel gegen die de�nierten Anwendungsfälle getestet. DieTests erfolgen als dynamische, funktionsorientierte Blackbox-Tests (also zur Laufzeit ohne Kenntnisdes Quellcodes). Es sollen je nach Funktion Positiv- und Negativtests durchgeführt werden (vgl.[Bal09]).

3.2. Rahmenbedingungen und Testfälle

Für alle folgenden Testfälle gelten neben den bereits de�nierten Anforderungen folgende Randbedin-gungen, welche für jeden Test zusätzlich zu den in den folgenden Tabellen de�nierten AnweisungenAnwendung �nden. Diese sollen Anforderungen erfassen, welche vom Durchschnittsbenutzer mut-maÿlich erwartet werden:

� Das System erzeugt �akzeptable� Antwortzeiten bis 10 Sekunden pro Benutzer-Anforderungje nach Komplexität der Operation.

� �Normale� Dateigröÿen bis 20 MB sind erlaubt.

� Die maximale gleichzeitige Datei-Anzahl pro Upload-Anforderung beträgt 100.

12


� Im Fehlerfall erfolgen sinnvolle Fehlermeldungen.

� Die Benutzerober�äche ist intuitiv bedienbar.

� Zuverlässigkeit bei paralleler Nutzung muss gegeben sein.

� Alle Testfälle werden jeweils mindestens einmal in den Browsern Mozilla Firefox, GoogleChrome, Apple Safari durchgeführt.

Hinweis: Aufgrund von zeitlichen Einschränkungen wird auf die Benutzung eines für Abnahmetestsspezialisierten Browser-Plugins (Selenium) verzichtet. Dies könnte jedoch in zukünftigen Iterationendurchgeführt werden.

ID 001

Bezeichnung LoginVorbedingungen Webfrontend wurde aufgerufenEingaben Der Benutzer authenti�ziert sich mit seinen Benutzerdaten über den

Login-Dialog mittels seines System-Logins.Erwartetes Verhal-ten

1. Korrekte BenutzerdatenDer Benutzer wird zur Datei-Au�istung weitergeleitet, es wird einSitzungs-Cookie gesetzt2. Inkorrekte BenutzerdatenDer Login wird mit einer Meldung abgebrochen. Der Benutzer wird wie-der zum Anmeldedialog weitergeleitet.

Prüfanweisungen 1. Groÿ-/Kleinschreibung beim Benutzernamen in verschiedenen Varian-ten überprüfen

Tabelle 21: Abnahmetest - Testfall 001

ID 002

Bezeichnung LogoutVorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggtEingaben 1. Manueller Logout

Der Benutzer nutzt die Logout-Funktion in der Navigation.2. Automatischer LogoutNach einer zu de�nierenden Zeit wird der Benutzer automatisch ausge-loggt bzw. wird seine Sitzung automatisch ungültig.

Erwartetes Verhal-ten

Der Benutzer wird ausgeloggt, sein Session-Cookie wird ungültig bzw.gelöscht.

Prüfanweisungen 1. Interne URLs des Webfrontends sind nach dem Logout nicht mehraufrufbar.


ID 003 (analog AF 1.1)

Bezeichnung Anlegen einer Plagiatsüberprüfung, Hochladen von Plagiatskandidatenund Kon�guration der Algorithmen

Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt

13



Eingaben Das Formular zum Anlegen von neuen Plagiatsüberprüfungen wurde auf-gerufen, eine Datei aus dem lokalen Dateisystem wurde ausgewählt unddie Schalt�äche zum Hochladen angeklickt.Vorher kann der Benutzer zwischen dem Standard- oder Expertenmoduswählen. Im Expertenmodus wird ihm die Kon�guration der verfügbarenAlgorithmen angeboten.Der Upload ist jeweils für bestimmte Dateien durchzuführen, um die Er-gebnisse reproduzieren zu können. Darin wurde eine de�nierte Anzahl anPlagiaten gefunden, welche die Software ebenfalls später au�nden muss.Diese Dateien be�nden sich im Subversion-Repository der Projektgrup-pe.


1. Hochladen erfolgreichAus dem Kontext ist ersichtlich, dass das Hochladen des/der Plagiats-kandidaten erfolgreich war.Prüfung in Version 3: Nach dem Hochladen erfolgt auf Basis der Plagi-atskandidaten eine Vorverarbeitung der enthaltenen Quellen (durch dieseAnalyse werden Literaturvorschläge unterbreitet).Es wird eine Internetrecherche nach weiteren Web-Quellen auf Basis derInhalte der Plagiatskandidaten durchgeführt. Der Prozess wird daher biszum Ende der Vorverarbeitung unterbrochen und kann im Hauptdialogder Anwendung später fortgesetzt werden.2. Hochladen nicht erfolgreichDer Benutzer wird informiert. Es können jedoch weitere Dateien hoch-geladen werden.

Prüfanweisungen 1. Dateien mit Sonderzeichen (anderen Zeichen als a-z, A-Z, 0-9, _ und.) prüfen � müssen korrekt behandelt werden2. Dateien mit 0 Byte oder > 20 MB prüfen � gröÿere Dateien sind nichterlaubt3. Dateien mit besonders langen Namen prüfen (>255 Zeichen) � müssenohne Fehler hochgeladen werden4. HTML und/oder JavaScript und/oder SQL-Code sind in sämtlichenFormularen verboten � Zeichen müssen konvertiert werden6. Das Hochladen von mehr als 100 Dateien gleichzeitig ist verboten7. Sitzungsablauf prüfen (1 Stunde)8. Dateien im Format PDF und Text hochladen9. Eingabefelder leer lassen10. Eingabefelder zur Kon�guration mit o�ensichtlich ungültigen Wertenbefüllen11. U.a. Test-Datei Testdatei.pdf hochladen



Bezeichnung Auswahl der Internetquellen, Hochladen von ReferenzdokumentenVorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, ein oder mehrere

Plagiatskandidaten wurden hochgeladen, der Benutzer setzt durch dieentsprechende Schalt�äche bei der Plagiatsüberprüfung den Prozess fort.

14



Eingaben Die Internetquellen werden vom Benutzer an- oder abgewählt.Auch werden werden eine oder mehrere Referenzdokumente aus demlokalen Dateisystem ausgewählt und die Schalt�äche zum Hochladen an-geklickt.Der Upload ist jeweils für bestimmte Dateien durchzuführen, um die Er-gebnisse reproduzieren zu können. Darin wurde eine de�nierte Anzahl anPlagiaten gefunden, welche die Software ebenfalls später au�nden muss.Diese Dateien be�nden sich im Subversion-Repository der Projektgrup-pe.


1. Hochladen erfolgreichAus dem Kontext ist ersichtlich, dass das Hochladen des/der Referenz-dokumente erfolgreich war.Der Prozess wird an dieser Stelle zur Normalisierung und Internetsucheerneut unterbrochen und kann im Hauptdialog nach Beendigung fortge-setzt werden.2. Hochladen nicht erfolgreichDer Benutzer wird informiert. Der Prozess-Teil wird abgebrochen. DiePlagiatsüberprüfung hat weiterhin den Status �Internetquellensuche ab-geschlossen�.

Prüfanweisungen 1. Dateien mit Sonderzeichen (anderen Zeichen als a-z, A-Z, 0-9, _ und.) prüfen � müssen korrekt behandelt werden2. Dateien mit 0 Byte oder > 20 MB prüfen � gröÿere Dateien sind nichterlaubt3. Dateien mit besonders langen Namen prüfen (>255 Zeichen) � müssenohne Fehler hochgeladen werden4. Das Hochladen von mehr als 100 Dateien gleichzeitig ist verboten5. Sitzungsablauf prüfen (1 Stunde)6. Dateien im Format PDF und Text hochladen7. Für Administratoren: Die Kernanwendung vom Internet trennen.8. U.a. Test-Datei Testdatei-Referenz.pdf hochladen



Bezeichnung Starten einer PlagiatsüberprüfungVorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, eine Plagiats-

überprüfung wurde angelegt und mindestens ein Plagiatskandidat hoch-geladen

Eingaben In der Au�istung der Plagiatsüberprüfungen im Haupt-Dialog wird diePlagiatsüberprüfung gestartet.


Die Plagiatsüberprüfung startet in paralleler Form: Das Webfrontendreagiert weiter auf Nutzer-Eingaben. Der Status der Plagiatsüberprüfungändert sich nach Abschluss der Bearbeitung auf �Prüfung abgeschlossen�.

Prüfanweisungen 1. Eine Plagiatsüberprüfung mit und ohne Referenzdokumente starten2. Eine Plagiatsüberprüfung mit vielen gröÿeren Dokumenten starten



Bezeichnung Ergebnisdokument und -visualisierungen abrufen

15



Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, eine Plagiats-überprüfung wurde abgeschlossen

Eingaben In der Au�istung der Plagiatsüberprüfungen im Haupt-Dialog wird dieVisualisierung gestartet.


1. Es wird eine Visualisierung mitsamt eines Strichcodes, eines Kuchen-diagrammes und farblicher Markierungen angezeigt, bei der Plagiats-kandidat und Referenzdokument bzw. Internetquellen gegenüber gestelltwerden.2. Es wird aus der Bildschirmanzeige ersichtlich, welcher Algorithmus fürdas Au�nden von spezi�schen Plagiatsverdachtsstellen zuständig war.Der Benutzer erhält zusätzlich eine Abschätzung, inwiefern es sich beidem gesamten Dokument um ein Plagiat handeln könnte.3. Gra�ken und textuelle Anzeigen sind dem Anschein nach konsistent.4. Das o�ensichtliche Komplettplagiat sowie die Verschleierung in Test-datei.pdf wurden erkannt.

Prüfanweisungen 1. Durch die Ausgabe scrollen und die angebotenen Funktionen auspro-bieren


ID 007 (analog AF 1)

Bezeichnung Plagiatsüberprüfungen au�istenVorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, es wurden meh-

rere Plagiatsüberprüfungenen angelegtEingaben -Erwartetes Verhal-ten

Alle Plagiatsüberprüfungenn werden mitsamt ihres jeweils aktuellstenStatus angezeigt.

Prüfanweisungen 1. Dateien mit Sonderzeichen im Dateinamen sollten so wie im Orgiginal-Dateinamen angegeben angezeigt werden.2. Die Datei-Au�istung darf es dem Benutzer immer nur ermöglichen, denjeweils nächsten logischen Schritt bei der Plagiatsprüfung durchzuführen.3. Eine Plagiatsüberprüfung abbrechen bzw. löschen


ID 008

Bezeichnung Anlegen eines BenutzerkontosVorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggtEingaben Ein Benutzerkonto wird im Seitenbereich für die Anmeldung registriert.Erwartetes Verhal-ten

Das Benutzerkonto wird ordnungsgemäÿ angelegt. Eine Anmeldung un-ter diesem Konto ist sofort möglich.

16


ID 008

Prüfanweisungen 1. Nur entsprechend privilegierte Benutzer dürfen diese Funktion ver-wenden.2. Leere Felder prüfen3. Ungleiche Passwort-Felder prüfen4. Doppelte Benutzernamen prüfen5. Ungültige EMail-Adressen prüfen6. Wird das Passwort doppelt abgefragt oder besteht die Gefahr einerFehleingabe?7. Besonders lange Texte eingeben8. SQL-Befehle in Feldern prüfen9. HTML-Code in Feldern prüfen10. Sonderzeichen prüfen


3.2.1. Erfassung von Test-Resultaten

Um die Ergebnisse der Tests schnell zu erfassen und Probleme übersichtlich darstellen zu können,werden Fragebögen D verwendet (vgl. [Bal09]). Diese Tabellen sind vom Tester auszufüllen und un-verzüglich den Gruppenmitgliedern weiterzuleiten. Zusätzlich werden Tickets mit den aufgedecktenProblemen den mutmaÿlich zuständigen Programmierern zugeordnet, damit diese sie strukturiertabarbeiten.

3.2.2. Au�istung von Test-Resultaten

Stukturierte Tests nach diesem Vorbild wurden nach einiger Vorbereitung mit Version 2 aufgenom-men.

Version 2.0:Folgende Probleme oder Hinweise wurden in Version 2.0 aufgedeckt:

� Der Benutzername wird Case-sensitiv überprüft.

� Die Login-Au�orderung verschwindet nach dem Login nicht.

� Für ungültige Dateien gibt die Normalisierung keine Meldung aus.

� Der Internetquellen-Dialog erscheint auch, sofern keine gefunden wurden.

� Der Status der Plagiatsprüfung wird nicht fortgesetzt sofern es weder Internetquellen nochReferenzdokumente gibt.

� Der Weiter-Button ist während des Uploads weiter anklickbar.

� Leere Dateien werden nicht hochgeladen, es erscheint auch keine Fehlermeldung.

� Knapp 20 MB groÿe Dateien können nicht hochgeladen werden, obwohl die Gröÿenbeschrän-kung unterschritten wurde.

� Die Datenhaltung produziert Fehler, sofern ein Log-Kommentar oder ein Dateiname zu langsind.

� Dateien mit Umlauten oder Sonderzeichen werden falsch ausgegeben.

� Textdokumente werden nicht normalisiert.

17


� Die Datenhaltung gibt ab und an aus: "Konnte Commit nicht absetzen".

� Das Dokument "JZ2NP9.pdf"kann nicht normalisiert werden.

� Die Internetrecherche sucht gelegentlich nach leeren Strings oder Zeilenumbrüchen.

� In Formulare lässt sich HTML-Code eingeben.

� Bei der erweiterten Kon�guration ist nichts vorausgewählt, es kann auch nichts ausgewähltwerden. Ebenso werden Eingaben nicht gespeichert.

� Alles an- und abwählen wäre bei den Internetquellen sinnvoll.

� Multitasking bei mehreren aktiven Prüfungen scheint nicht möglich.

� Nach dem Upload eines Plagiatskandidaten heiÿt es "Referenzdaten erfolgreich hochgeladen".

� Autor und Sprache werden nicht gespeichert.

� Die Funktion "plagiateSpeichern()ÿchlägt gelegentlich fehl, sofern deren errechnete Wahr-scheinlichkeit nicht zwischen 0 und 1 liegt.

� Der Fortschritt eines Uploads sollte visualisiert, Interaktions-Buttons währenddessen gesperrtwerden.

� Die Normalisierung bricht beim Guttenberg-Dokument ab.

� Uploads dauert beim Guttenberg-Dokument sehr lange.

� Der Abruf eines HTML-Ergebnosdokumentes dauert sehr lange.

� Es werden häu�g unsinnige Zwei-Wort-Plagiate gefunden.

� Beim Anklicken von Plagiatsverdachtsstellen im HTML-Ergebnisdokument werden gelegent-lich bei wiederholtem Klick unterschiedliche Fundstellen angezeigt.

� Exportierte PDF-Ergebnisdokumente sind unvollständig.

� Die Gegenüberstellung von Plagiatskandidaten und Referenzdokumenten im PDF-Ergebnis-dokument ist unbrauchbar.

� Der Status einer Plagiatsüberprüfung in der Übersicht wird quasi doppelt ausgegeben.

� Funktionen direkt in der Liste der Plagiatsüberprüfungen wären eine sinnvolle Idee.


� Es gibt auf dem Button �Zum nächsten Schritt� einen Encoding-Fehler im Text (fehlerhaftesZeichen anstatt "ä").

� Lade ich Dateien hoch, breche ab und rufe den Dialog erneut auf, wird später im FensterÄutoren und Sprache auswählenäuch die �alte� Datei wieder als hochgeladen angezeigt.

� Die Sprach-Festlegung für hochgeladene Dokumente erfolgt unzuverlässig ("Toleranzëinstel-len?). Meine meisten Test-Dokumente erhalten Sprach-Code 3 ("nicht zugeordnet"). Nachtrag:Dies scheint insbesondere dann fehl zuschlagen, wenn ich im Frontend die Autoren bearbeitethabe. Hinweis: Dokumente werden scheinbar bei der Erstanlage mit Sprach-Code "1"gespei-chert. Dies ist falsch.

18


� Erweiterter Modus: Das Fortfahren ohne Anklicken eines StringMatching-Algorithmus istmöglich.

� Ich kann momentan noch jede Prüfung abschlieÿen oder entfernen, obwohl diese Stati nur inbestimmten Fällen verfügbar sein dürfen.

� Der Strichcode im Ergebnisdokument ist noch nicht klickbar.

� Schreibfehler auf Button: "Hier klick, um..."

� Die gra�sche Legende der Gra�ken im HTML-Ergebnisdokument passt nicht mehr.

� Das PDF-Ergebnisdokument enthält noch unbestätigte Plagiatsverdachtsstellen sowie eben-falls die alte Legende.

� Habe ich einen Plagiatsverdacht bestätigt, klicke dann einen anderen an, wird dieser späterwieder als unbestätigt angezeigt.

� Bei der Benutzer-Registrierung werden die früheren Eingaben bei einem Fehler in den Einga-befeldern nicht übernommen (Beispiel: Benutzername bereits vergeben)

� Beim Abwählen von Web-Quellen erscheint noch kurz ein Dialog mit Debug-Meldungen.

� Im HTML-Ergebnisdokument rutscht das Kuchendiagramm unter den Test, sofern die rechteSpalte länger als der Text ist.

� In einigen Fällen passen Plagiatsverdachtsstellen noch nicht. Beispiel in Plagiatsüberprüfung"Test AW", Nutzer "test", Textstelle "gration process model with an emphasis on".

� Normalisierung stürzt bei zu groÿen Dokumenten (jedoch unterhalb der 20MB-Grenze - ün-gültige groÿe binärdatei.pdf") ab und Prozess bleibt stehen.

� Bei der Plagiatsprüfung zweier gleicher Dokumente einmal im Standardmodus und zum zwei-ten im erweiterten Modus ergeben sich völlig unterschiedliche Ergebnisse (jeweils mit demQualitätstest 1 ohne Web-Quellen)

� Bei der Prüfung meiner Standard-Testdokumente ("Testdatei.pdf"mit den Sätzen "Thomasjagt im komplett verwahrlosten Taxi quer durch Bayern.") werden die Komplettplagiate malerkannt, mal nicht.


� Die Farben im HTML-Ergebnisdokument passen nicht mehr.

� In der PDF-Variante des Ergebnisdokuments sind die Farben nicht mehr konsistent zur HTML-Variante.

� Auch unbestätigte Plagiate müssen im Ergebnisdokument angezeigt werden.

� Die gra�schen Visualisierungen werden bei �nalisierten Prüfungen nicht korrekt angezeigt.

� Die Cluster-Variante der Plagiatsprüfung gibt Wahrscheinlichkeiten auÿerhalb des gültigenIntervalls zurück, welche dann von der Datenhaltung abgelehnt und nicht gespeichert werden.

� Das Guttenberg-Dokument kann im Web-Frontend nicht angezeigt werden.

� Bei TXT-Normalisierungen werden keine Zeilenumbrüche entfernt.

19


� Die Internetrecherche sucht mittels eines nicht angemessenen Verfahrens nach Quellen.

� Sofern Bing nicht erreichbar ist oder keine Resultate liefert, bricht der Prozess ab.

� Sofern fehlerhafte Dateien (wie "winhlp32.pdf") normalisiert werden, bricht der Prozess ab.

� DasWeb-Ergebnisdokument zeigt trotz Sonderzeichen (insb. Anführungszeichen) Fragezeichenan, obwohl der Service diese ordnungsgemäÿ ausliefert.

� Nach Aktivierung neuer Funktionen in der Normalisierung können keine Plagiatsüberprüfun-gen mehr gelöscht werden.

� Vor dem Finalisieren heiÿt es �Sind sie sicher, dass (...)? *I*n weiteres Bearbeiten ist nichtmöglich�.

� Es gibt einen Rechtschreibfehler in �Neuer Status verfügbar - bitte *neuladen*�.

� Prüfungs-Ergebnisse können verloren gehen, wenn SSH-Verbindung fehlschlägt.

� Der Barcode im Ergebnisdokument wird bei sehr groÿen Plagiatskandidaten lediglich grauangezeigt.

� Die Normalisierung gibt sehr häu�g �Stop reading corrupt stream� in die Konsole aus, auÿer-dem andere für den Anwender unwichtige Meldungen.

� Ich kann wieder bereits bestätigte Plagiatsverdachtsstellen erneut bestätigen, teils aber dieBestätigung sogar nicht mehr entfernen.

� Die Status-Aktualisierungs-Frequenz ist zu häu�g: Fünf Sekunden führen schnell zu einer�ordentlichen� Serverlast.

20

A. Tabellenverzeichnis

A. Tabellenverzeichnis

1. Code Review - Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52. Code Review - Datenhaltung - LogPrinter . . . . . . . . . . . . . . . . . . . . . . . . 63. Code Review - Datenhaltung - DatenhaltungImplementierung . . . . . . . . . . . . . 64. Code Review - Datenhaltung - Kon�gurationsdaten . . . . . . . . . . . . . . . . . . . 65. Code Review - Datenhaltung - Konverter . . . . . . . . . . . . . . . . . . . . . . . . . 76. Code Review - Datenhaltung - SQLBindung . . . . . . . . . . . . . . . . . . . . . . . 77. Code Review - Datenhaltung - SQLBindung . . . . . . . . . . . . . . . . . . . . . . . 78. Code Review - Plagiatserkennung - BoyerMoore . . . . . . . . . . . . . . . . . . . . . 89. Code Review - Plagiatserkennung - JavaString . . . . . . . . . . . . . . . . . . . . . . 810. Code Review - Plagiatserkennung - RabinKarp . . . . . . . . . . . . . . . . . . . . . 811. Code Review - Plagiatserkennung - NGram . . . . . . . . . . . . . . . . . . . . . . . 812. Code Review - Plagiatserkennung - RabinKarpDTO . . . . . . . . . . . . . . . . . . 913. Code Review - Plagiatserkennung - Token . . . . . . . . . . . . . . . . . . . . . . . . 914. Code Review - Plagiatserkennung - PlagiatserkennungImplementierung . . . . . . . . 915. Code Review - Plagiatserkennung - Nachbereitung . . . . . . . . . . . . . . . . . . . 1016. Code Review - Plagiatserkennung - StringMerge . . . . . . . . . . . . . . . . . . . . . 1017. Code Review - Plagiatserkennung - NGramGenerator . . . . . . . . . . . . . . . . . . 1018. Code Review - Plagiatserkennung - TokenGenerator . . . . . . . . . . . . . . . . . . 1019. Code Review - Plagiatserkennung - Vorbereitung . . . . . . . . . . . . . . . . . . . . 1120. Code Review - Steuerungslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121. Abnahmetest - Testfall 001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1322. Abnahmetest - Testfall 002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1323. Abnahmetest - Testfall 003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424. Abnahmetest - Testfall 004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525. Abnahmetest - Testfall 005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526. Abnahmetest - Testfall 006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627. Abnahmetest - Testfall 007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628. Abnahmetest - Testfall 008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729. Testprotokoll - Tabellenkopf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2630. Testprotokoll - Testfall 001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2631. Testprotokoll - Testfall 002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2632. Testprotokoll - Testfall 003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2733. Testprotokoll - Testfall 004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2734. Testprotokoll - Testfall 005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2735. Testprotokoll - Testfall 006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2836. Testprotokoll - Testfall 007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2837. Testprotokoll - Testfall 008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

21

B. Literaturverzeichnis

B. Literaturverzeichnis

[Bal09] Balzert, Helmut ; Rüdinger, Andreas (Hrsg.) ; Kohl, Kerstin (Hrsg.) ; Fraude, Dag-mar (Hrsg.): Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering.Spektrum, 2009

[BBK01] Back, A. ; Becker, J. ; König, W. ; Stürken, M. (Hrsg.): Lexikon der Wirtschaftsin-

formatik. Springer, 2001

[CSFP] Collins-Sussman, B. ; Fitzpatrick, B. W. ; Pilato, M.: Version Control with Sub-

version. http://svnbook.red-bean.com/. � Letzter Zugri� am 08.08.2012

[GB09] Grechenig, Thomas ; Bernhart, Mario: Softwaretechnik: Mit Fallbeispielen aus realen

Entwicklungsprojekten. Pearson, 2009

[Lin05] Link, Johannes: Softwaretests mit JUnit - Techniken der testgetriebenen Entwicklung.Dpunkt Verlag, 2005

[Sma11] SmartBear: SmartBear Software: 11 Best Practices for Peer Code Review. WhitePaper. http://smartbear.com/CMSPages/GetFile.aspx?guid=429d6abc-7d6d-4863-

9118-848e4b135029. Version: 2011

[Teca] TechTerms: API. http://www.techterms.com/definition/api. � Letzter Zugri� am08.08.2012

[Tecb] TechTerms: PDF. http://www.techterms.com/definition/pdf. � Letzter Zugri� am08.08.2012

[Wes] Westphal, Frank: Unit Tests mit JUnit. http://www.frankwestphal.de/UnitTestin

gmitJUnit.html. � Zugri� am 05.04.2012

22

http://svnbook.red-bean.com/

http://smartbear.com/CMSPages/GetFile.aspx?guid=429d6abc-7d6d-4863-9118-848e4b135029

http://smartbear.com/CMSPages/GetFile.aspx?guid=429d6abc-7d6d-4863-9118-848e4b135029

http://www.techterms.com/definition/api

http://www.techterms.com/definition/pdf

http://www.frankwestphal.de/UnitTestingmitJUnit.html

http://www.frankwestphal.de/UnitTestingmitJUnit.html

C. Glossar

C. Glossar

Abnahmetest Der Abnahmetest hilft beim Testen vom Verhalten unterschiedlicher Komponentenin der Gesamtheit [GB09].

API API steht für die Abkürzung Application Programming Interface. Dies ist ein Programmteil,welcher von einem Softwaresystem für ein anders System zur Verfügung gestellt wird [Teca].

AppID Die AppID ist eine alphanummerische Folge von Zeichen, welche bei der Anmeldung vonBing vergeben wird.

Bing Bing eine die kostenlose Suchmaschine von Microsoft, welche einen Zugri� auf ihre API übereine AppID ermöglicht.

Code Review Das Code Review beschreibt ein Vorgehen, indem Programmabschnitte manuell voneinem anderen Programmierer überprüft werden [Lin05].

Datenhaltung Die Datenhaltung dient für die Anbindung an eine Datenbank, wobei noch nichtentschieden wurde, welche Datenbank verwendet werden soll.

ErgebnisGenerator Der ErgebnisGenerator ist eine Komponente in der Architektur von PlagTag.Sie dient der Aufbereitung der Daten, welche bei der Plagiatsüberprüfung generiert wurden,zur Visualisierung.

Erkennungs-Algorithmen Die Erkennungs-Algorithmen sind Algorithmen zur Erkennung von Pla-giate. Diese sind derzeit noch nicht bestimmt.

HTML Hyper Text Markup Language ist eine Web-Auszeichnungssprache, ist Grundlage des WorldWide Web und wird von einem Webbrowser dargestellt. Aktuell be�ndet sich HTML Version5 in der Standardisierung.

Internetquelle Die Internetquellen werden durch eine automatische Internetrecherche durch Plag-Tag gefunden. Dabei soll PlagTag Webseiten �nden, die durch den Ersteller des Plagiatskan-didat plagiiert wurden.

Internetrecherche Die Internetrecherche ist eine Komponente der Anwendung PlagTag. Diese dientdem Finden von Referenzdaten im Internet.

JUnit JUnit ist ein Framework für Unit-Tests in Java. Es ist für die automatisierte Unit-Testseinzelner Units geeignet [Wes].

Komponente Eine Komponente (hier: Software-Komponente) ist ein Software-Element, das kon-form zu einem Komponentenmodell (z.B. aus der UML) ist und über Schnittstellen mit an-deren Komponenten verknüpft und ausgeführt werden kann. Komponentenbasierte Softwarewird z.B. mittels Web-Services, CORBA, Enterprise Java Beans (EJBs) oder COM entwickelt.

Normalisierung Die Normalisierung ist eine Komponente der Anwendung PlagTag. Diese dient demAuslesen von PDFs und dem Speichern der PDFs in einem einheitlichem Format.

PDF Das Portable Document Format (PDF) ist ein plattformunabhängiges Dateiformat für Doku-mente, das vom Unternehmen Adobe Systems entwickelt und 1993 verö�entlicht wurde. Zielist die originalgetreue Wiedergabe auf allen Plattformen [Tecb].

23

Glossar

Plagiat Ein Plagiat liegt dann vor, wenn jemand vorgibt, ein Werk selbst erstellt zu haben, obwohldie Inhalte ganz oder teilweise aus fremden Quellen stammen, die falsch oder unvollstän-dig zitiert wurden. Je nachdem wie die Zitiertechnik falsch verwendet wurde, lassen sich diePlagiate zusätzlich genauer kategorisieren Je nachdem wie die Zitiertechnik falsch verwen-det wurde, lassen sich die Plagiate zusätzlich genauer kategorisieren. Es existieren vielfältigeFormen geistiger Leistung, z.B. Texte, Bilder oder Videos.

Plagiatserkennung Die Plagiatserkennung meint das Ausführen der Erkennungs-Algorithmen aufeinen Computer, um Plagiate zu identi�zieren.

Plagiatskandidat Ein Plagiatskandidat ist ein Dokument, welches vom Anwender in das Systemeingefügt und dort auf Plagiate überprüft wird.

Plagiatsüberprüfung Die Plagiatsüberprüfung beschreibt das Vorgehen in PlagTag, welches dengesamten Ablauf der Anwendung ab dem Anlegen einer Überprüfung vom Anwender bis zurAusgabe des Ergebnisses der Überprüfung meint. Dazu wird es eine Klasse Plagiatsüberprü-fung geben, welche zur Identi�zierung dient, also festlegt welche Daten (Plagiatskandidat,Referenzdokument usw.) zu einem Ablauf gehören. Dies ermöglicht allen Komponenten derArchitektur ihre Ergebnisse unter einer eindeutigen Bezeichnung in der Datenhaltung abzule-gen.

PlagTag PlagTag ist der Name der Plagiatserkennungssoftware.

Referenzdaten Die Referenzdaten sind der Sammelbegri� für Referenzdokumente und Internet-quellen.

Referenzdokument Die Referenzdokumente sind die Dokumente, welche durch den Anwender zu-sätzlich neben dem Plagiatskandidat in das System eingefügt werden, um genau diese Doku-mente mit dem Plagiatskandidat zu vergleichen.

SteuerungsLogik Die SteuerungsLogik ist eine Komponente der Anwendung PlagTag. Sie ist denKomponenten zur Plagiatsüberprüfung übergeordnet, um die Kommunikation zwischen diesenzu organisieren.

Subversion-Repository Subversion ist eine Software zur Versionsverwaltung von Dokumenten undProgrammen [CSFP]. Repository beschreibt das Verzeichnis, in dem Dokumente und Pro-gramme mit zusätzlichen Metadaten gespeichert werden, um eine Versionverwaltung zu er-möglichen [BBK01].

System Wird der System-Begri� ohne explizite Einschränkungen verwendet, so bezieht sich dieserimmer auf das im Projekt zu entwickelnde Gesamtprodukt. Dieses teilt sich auf in eine zentraleBerechnungs-Komponente und ein angebundenes Webfrontend.

Systemtest Soll die Interaktion bei mehreren Systeme getestet werden, handelt es sich um einenSystemintegrationstest. Auf der Ebene des Gesamtsystems wird dieser Test als Systemtestbezeichnet [GB09] plural.

Test Ein Test ist die Überprüfung von Programmabschnitten, welche mit Hilfe von verschiedenenTools durchgeführt werden kann [GB09].

Vorverarbeitung Die Vorverarbeitung beinhaltet alle Teilprozesse zur Vorbereitung der Plagiats-überprüfung. Unter dieser Vorbereitung wird die Vereinheitlichung der Plagiatskandidatenund Referenzdokumente durch die Normalisierung, aber auch die Internetrecherche gezählt,da diese noch vor der Plagiatsüberprüfung Vorschläge für mögliche plagiierte Dokumente

24

Glossar

aus dem Internet anbietet. Der Anwender beendet die Vorverarbeitung dadurch, dass er diePlagiatsüberprüfung explizit mit den von ihm bestimmten Referenzdaten und Parameternstartet.

Webfrontend Das Webfrontend stellt ein System für den Anwender auf der Clientseite visuell dar.Es repräsentiert die Benutzerober�äche (GUI).

25

D. Anhang

D. Anhang

Test-Datum:Test-Produkt PlagTagRelease-Nr. Version 2 von 3

Tabelle 29: Testprotokoll - Tabellenkopf

Test- Haupttest Zusätzliche Prüf-AnmerkungenID bestanden Anweisungen (ggf. auf gesondertem

bestanden Blatt fortsetzen)

1 O O O O Test nicht durchgeführtO schwerwiegende FehlerO kleine Fehler

Kommentar / Empfehlung: O beheben O so belassen

Tabelle 30: Testprotokoll - Testfall 001






26

D. Anhang



3 O O O OO OO O O Test nicht durchgeführtO OO O O schwerwiegende Fehler

O kleine Fehler





4 O O O OO OO O O Test nicht durchgeführtO O O schwerwiegende Fehler

O kleine Fehler





5 O O OO O Test nicht durchgeführtO schwerwiegende FehlerO kleine Fehler



27

D. Anhang








7 O O OO O Test nicht durchgeführtO schwerwiegende FehlerO kleine Fehler





8 O O OO OO OOO OO

O Test nicht durchgeführt

O schwerwiegende FehlerO kleine Fehler



28

Date post:	09-Aug-2019
Category:	Documents
Upload:	vanxuyen
View:	225 times
Download:	0 times

Testdokument - se.uni-oldenburg.de · 2. Qualitätssicherung 2. Qualitätssicherung Autor: Marion...

Documents