Projektgruppe 2011/2012. Testdokument. Zur Anwendung PlagTag. Version 1.0. Betreuer: Prof. Dr. Andreas Winter M.Sc. Jan Jelschen.

Transkript

1 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 Tore Bierwirth Christoph Gerken Marion Gottschalk Mitglieder: Sieglinde Hahn Maxim Klimenko Björn Wol Christian Wübbeling Oldenburg, den 30. September 2012

2

3 Inhaltsverzeichnis Inhaltsverzeichnis 1. Einleitung 1 2. Qualitätssicherung Tests Funktionstest Verbundtest / Integrationstest / Systemtest Abnahmetest / Akzeptanztests Dokumententest Usability-Test JUnit JUnit-Test für PlagTag Code Review Verlauf des Code Reviews Regeln des Code Reviews Durchgeführte Code Reviews Datenhaltung Plagiatserkennung Steuerungslogik Abnahmetest Übersicht über zu testende Anforderungen Rahmenbedingungen und Testfälle Erfassung von Test-Resultaten Auistung von Test-Resultaten A. Tabellenverzeichnis 21 B. Literaturverzeichnis 22 C. Glossar 23 D. Anhang 26 i

4 1. Einleitung 1. Einleitung Autor: Sieglinde Hahn Das Testdokument dient zum Feststellen von möglichen Fehlern, welche bei der Implementierung aufgetreten sind. Um mögliche Fehler erkennen und beheben zu können, ndet eine ausführliche Dokumentation der Tests statt. Das Testdokument teilt sich in die Testbereiche Qualitätssicherung und Abnahmetest. Zu Beginn werden im Rahmen der Qualitätssicherung 2 mögliche Testarten vorgestellt. Des Weiteren werden die verwendeten Testarten und ihre Vorgehensweise erläutert. Das Kapitel Abnahmetest 3 umfasst Abnahmetests von PlagTag, welche hinreichend dokumentiert werden. Unabhängig von diesem Dokument sind umfangreiche Funktionstests, wie in beschrieben wird, während der Implementierung von den jeweiligen Entwicklern durchgeführt worden. Dies resultiert in einer geringeren Fehleranzahl, sodass die genutzten Testverfahren eektiver eingesetzt werden können. 1

5 2. Qualitätssicherung 2. Qualitätssicherung Autor: Marion Gottschalk, Sieglinde Hahn Die Qualitätssicherung von PlagTag soll mithilfe von unterschiedlichen Tests erfolgen. Die Durchführung von Tests soll dabei helfen die Lauähigkeit von PlagTag zu überprüfen. Es existieren mehrere Testvarianten, um die Qualitätssicherung zu unterstützen. Daher werden im folgenden Abschnitt eine Reihe von Tests kurz vorgestellt, welche während des Entwicklungszeitraums eingesetzt werden können. Genutzt werden im Rahmen der Qualitätssicherung Unit-Tests in Form von JUnit und das Code Review, daher werden diese detaillierter beschrieben. Der Durchführungszeitraum der Tests ndet sich im Vorgehensmodell im Pichtenheft. Es wird parallel zu der Implementierung getestet Tests Autor: Sieglinde Hahn, Christian Wübbeling Grechenig und Bernhard [GB09] stellen folgende Test-Varianten vor, welche in diesem Projekt zusätzlich neben JUnit und Code Review durchgeführt werden könnten Funktionstest Das Ziel des Funktionstests ist es, die Implementierung jeder Funktion zu überprüfen. Die Implementierung jeder Funktion muss strikt den Kriterien der Anforderungen entsprechen. Jede Funktion soll individuell getestet werden. Das heiÿt, dass die Tests jeder Funktion nicht von der Eingabe 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 Funktionstest ist von den Entwicklern selbst durchzuführen, jeder Entwickler testet seine bearbeiteten Funktionen selbstständig und ist dafür verantwortlich. Gefundene Fehler werden i.d.r. sofort korrigiert und nicht schriftlich erfasst. Beispiel: Test der Komponente Datenhaltung, ob die Methode "referenzdokumentanlegen" die korrekten Rückgabewerte liefert 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 mehreren Systemen, deren Interaktion getestet werden soll, kann es sich auch um einen Systemintegrationstest handeln. Auf der Ebene des Gesamtsystems wird dieser Test als Systemtest bezeichnet. Der Verbundtest wird von Entwicklern der Funktionen oder Testverantwortlichen durchgeführt. Beispiel: Arbeiten die Funktionen der Datenhaltung und Vorverarbeitung korrekt zusammen? Abnahmetest / Akzeptanztests Der Abnahmetest für die Anwendung PlagTag wird bei Abgabe vom Kunden bzw. dem Systemadministrator durchgeführt. Das Ziel ist es, Fehler, die sich aus dem Vergleich der Anforderungen des Kunden mit dem Produkt ergeben, zu erkennen. Die aufgetretenen Fehler werden in einem Change Request vom Kunden festgehalten und an die Entwickler (PG) weitergeleitet. Die Anträge werden über den Single Point of Contact (SPOC) verwaltet, dieser verteilt die Anträge dementsprechend oder entscheidet, ob die Anforderung zu Komplikationen führt. Die bearbeiteten Change Request werden, mit eingearbeitetem Feedback, an den Antragsteller zurück geschickt. Werden bei der Durchführung der Tests keine Fehler gefunden, gilt der Vertrag als erfüllt. Beispiel: Prüfung des Gesamtsystems gegen die Anforderungen, umfasst auch z.b. die Installierbarkeit. 2

6 2.2. JUnit Dokumententest Der Dokumententest wird anhand von vordenierten Spezikationskriterien abgeprüft, ob die jeweiligen technischen Vorgaben, Funktionsspezikationen und Kommentare der Quelltexte vollständig und korrekt formuliert vorhanden sind. Der Dokumententest der Funktionsspezikationen und Kommentare der Quelltexte wird von Entwicklern der Funktionen vorgenommen. Der gesamte Dokumententest wird von Testverantwortlichen durchgeführt. Beispiel: Transparenz der Funktionen im Quellcode des Systems Usability-Test Dieser Test soll es ermöglichen, Schwächen in der Bedienbarkeit aufzudecken. Dazu wird sich durch Testfälle beholfen, die von einem Anwender, welcher technisch noch nicht mit dem System vertraut ist, bewältigt werden müssen. Sie werden bei ihrer Arbeit beobachtet und mögliche Probleme werden festgehalten. Durch den Einsatz von Usability-Test sollen aufwändige Änderungen vermieden und der Aufwand reduziert werden, welches zu einer Zeitersparnis führt. Diese Tests müssen aufgrund der Anforderung Q100 durchgeführt werden JUnit Autor: Sieglinde Hahn Mithilfe von JUnit können automatische Unit Tests in Java ausgeführt werden. Die erstellten JUnit-Test sind wiederholbar. JUnit bietet das Testen von Programmeinheiten, welche isoliert sind von anderen zusammenhängenden Programmiereinheiten [Wes], wie bereits in Abschnitt 2.1 kurz beschrieben. 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 von Anwendungs- und Testcode stattndet. Es muss eine Unabhängigkeit der Testfälle untereinander bestehen, da es JUnit ermöglicht Gemeinsamkeiten von Tests in einer setup()-methode auszulagern, welche für jeden Test separat ausgeführt wird. Somit ist die Reihenfolge der Tests nicht relevant. 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 eine grasche Darstellung der Testergebnisse in Eclipse, ein Erfolg wird Grün und ein Misserfolg Rot dargestellt [Lin05]. Um das JUnit-Test-Verfahren jedem Teilnehmer der PG zu erläutern, ndet im Rahmen der PG eine interne Schulung statt, um die Funktion und die Anwendung von JUnit-Tests zu vermitteln (siehe Anforderung V020). Diese Schulung fand am statt. In dieser wurde eine kleine thematische Einführung zu JUnit gegeben und aus der Theorie geschlussfolgert welchen Nutzen wir für die PG ziehen können. JUnit bietet der PG die Möglichkeit in der Programmiersprache Java zu programmieren und gleichzeitig 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, da so Komplikationen bei einer gleichzeitigen Bearbeitung vermieden werden können. Eine schnelle Ausführbarkeit ist aufgrund von JUnit-Kurztests möglich. Durch das Festlegen vom erwarteten Verhalten kann ein Vergleich mit dem tatsächlichen Verhalten durchgeführt werden [Lin05] JUnit-Test für PlagTag Getestet wurden mithilfe von JUnit die Hauptkomponenten der Architektur, bei den Komponenten handelt es sich um Datenhaltung, ErgebnisGenerator, Internetrecherche, Normalisierung, Plagiats- 3

7 2.3. Code Review erkennung und SteuerungsLogik. Die Tests werden nicht vom eigentlichen Programmierer durchgeführt sondern von einem weiteren PG-Mitglied, um mögliche Fehler so besser identizieren zu können. JUnit-Test nden in der Testphase statt. JUnit-Tests wurden für Version 1 für alle oben genannten Komponenten ausgeführt. In der Version 2 und 3 wurden aufgrund des hohen Arbeitsaufwand die Junit-Tests reduziert und es wurden wie in Abschnitt 2.3 beschrieben Code Reviews durchgeführt. Aufgrund des Protokollumfangs der JUnit-Tests benden sich die Testprotokolle mit den Testklassen im jeweiligen Ordner im Subversion-Repository. Diese Testprotokolle sind im Ordner Entwicklung\Version1\... der zu testenden Komponente in einem separaten Ordner zu nden, welcher Test benannt ist Code Review Autor: Marion Gottschalk, Sieglinde Hahn Code Reviews sollen nur bei elementaren Bestandteilen des Codes durchgeführt werden. Zu den elementaren Bestandteilen des Codes gehören die Algorithmen zur Erkennung von Plagiaten und die Steuerungsabläufe zwischen den Komponenten, d.h. die Weitergabe von Informationen einzelner Komponenten über die SteuerungsLogik zu einer anderen Komponente. Auÿerdem werden durch die denierten Code- ein Teil der Qualitätssicherung eingehalten, um die Lesbarkeit und Wartbarkeit von PlagTag zu gewährleisten. Diese Vorgehen erleichtern daher das spätere Code Review. Die elementaren Bestandteile des Codes werden von einer Person, welche nicht direkt am Code gearbeitet hat, gegengelesen und auf Korrektheit und Funktionalität analysiert. Diese Überprüfung wird dokumentiert, um dem Programmierer und der PG einen Überblick über Korrektheit und Funktionalität zu geben. Für den Programmierer können Kommentare und Anmerkungen zusätzlich in der Dokumentation 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 Implementierung statt, siehe Vorgehensmodell im Pichtenheft 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 zu den JUnit- und Abnahmetests sind. Die Code Reviews werden von der Projektleitung zugeteilt und sollen am Ende der Implementierungsphase von Version 2 stattnden. Da am Ende von Version 2 die Zeit fehlte, sind einige Code Reviews nicht durchgeführt worden, sodass die hier aufgelisteten Code Reviews 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 die Abnahmetests investieren zu können Regeln des Code Reviews Autor: Marion Gottschalk Bevor mit den Code Reviews begonnen wurde, sind Regeln für das Code Review festgelegt und der PG vorgestellt worden. Während der Implementierungsphase wurden diese Regeln im Wiki der PG festgehalten und werden hier nochmal zum Verständnis aufgeführt. Die aufgelisteten Regeln dienen dazu, dass Code Review so ezient und erfolgreich wie möglich zu gestalten. Die Regeln wurden aus der Dokumentation von SmartBear Software [Sma11] entnommen. 4

8 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ändig dokumentieren. 5. Worauf soll beim Code Review geachtet werden? ˆ Java-Doc korrekt verwendet? ˆ Code eingehalten? ˆ Macht die Methode, was sie soll? 6. Wird ein Fehler im Code entdeckt, muss der Reviewer dem Code-Autor eine mit Hinweis darauf schreiben oder beim nächsten PG-Treen mit diesem besprechen. Auÿerdem soll ein Ticket vom Reviewer erstellt werden, welches vom Code-Autor geschlossen werden muss. Dies soll die interne Verwaltung unterstützen. 7. Der Reviewer überprüft, ob die besprochenen Hinweise auch umgesetzt wurden Durchgeführte Code Reviews Autor: Sieglinde Hahn Im folgenden Abschnitt werden die Komponenten Datenhaltung, Plagiatserkennung und Steuerungslogik mittels Code Review getestet. Diese Komponenten stellen die Kernkomponenten von PlagTag dar 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- und Java-Doc, wie im vorherigen Abschnitt beschrieben. Die Dokumentation erfolgt in Tabellenform, wie im Folgenden beispielhaft dargestellt ist. Reviewer Versionsnummer Logik Java-Doc Code- Anmerkungen Eine eindeutige, um den Testfall zuordnen zu können. Der Name der zu testenden Komponenten. Name des Reviewers. Die Versionsnummer. Logische Aspekte des Codes. Einhaltung von Java-Doc. Einhaltung der Code-. Wichtige Anmerkungen. Tabelle 1: Code Review - Aufbau Datenhaltung D01 Datenhaltung - LogPrinter 5

9 2.3. Code Review D01 Logischer Aufbau der Klasse. Gute Nachvollziehbarkeit aufgrund der eingehaltenden Code- und Java-Doc. Präzise und ausführlich beschrieben. Die Code- wurden eingehalten. Die aktuelle Version wurde nicht auf 2.0 geändert. Tabelle 2: Code Review - Datenhaltung - LogPrinter Logik Java-Doc Code- Anmerkungen D02 Datenhaltung - DatenhaltungImplementierung Logik Logischer Aufbau der Methoden. Gute Nachvollziehbarkeit aufgrund der eingehaltenden Code- und Java-Doc. Java-Doc Präzise und ausführlich beschrieben. Allerdings Alternative unklar. Code- Die Code- wurden eingehalten. Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert. Fehleranzeige in Zeile 2145 NamingException SQLException. opk und ord nicht in den festgehalten. Tabelle 3: Code Review - Datenhaltung - DatenhaltungImplementierung D03 Datenhaltung - Kongurationsdaten Logik Logischer Aufbau der Klasse. Gute Nachvollziehbarkeit aufgrund der eingehaltenden Code- und Java-Doc. Java-Doc Zu wenig beschrieben. Code- Die Code- wurden eingehalten. Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert. Kommentare sehr knapp. Tabelle 4: Code Review - Datenhaltung - Kongurationsdaten D04 Datenhaltung - Konverter Logik Logischer Aufbau der Klasse. Java-Doc Präzise und ausführlich beschrieben. Code- Die Code- wurden eingehalten. 6

10 2.3. Code Review Anmerkungen D04 Die aktuelle Version wurde nicht auf 2.0 geändert. Tabelle 5: Code Review - Datenhaltung - Konverter Tabelle 6: Code Review - Datenhaltung - SQLBindung Plagiatserkennung Tabelle 7: Code Review - Datenhaltung - SQLBindung D05 Datenhaltung - SQLBinding Logik Logischer Aufbau der Klasse. Java-Doc Präzise und ausführlich beschrieben. Code- Name der Klasse entspricht nicht den Code. Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert. D06 Datenhaltung - Stammdaten Logik Logischer Aufbau der Klasse. Java-Doc Präzise und ausführlich beschrieben. Code- Die Code- wurden eingehalten. Anmerkungen Die aktuelle Version wurde nicht auf 2.0 geändert. P01 Plagiatserkennung - BoyerMoore Logik int stringsuchen = ok int[ ] createshifttable = ok int[ ] createosettable = ok int suxlength = ok boolean isprex = ok Plagiat[ ] suchedurchfuehren = ok Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. Denglisch. 7

11 2.3. Code Review P01 Tabelle 8: Code Review - Plagiatserkennung - BoyerMoore Tabelle 9: Code Review - Plagiatserkennung - JavaString Tabelle 10: Code Review - Plagiatserkennung - RabinKarp P02 Plagiatserkennung - JavaString Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P03 Plagiatserkennung - RabinKarp Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P04 Plagiatserkennung - NGram Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. Tabelle 11: Code Review - Plagiatserkennung - NGram 8

12 2.3. Code Review Tabelle 12: Code Review - Plagiatserkennung - RabinKarpDTO Tabelle 13: Code Review - Plagiatserkennung - Token Tabelle 14: Code Review - Plagiatserkennung - PlagiatserkennungImplementierung P05 Plagiatserkennung - RabinKarpDTO Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P06 Plagiatserkennung - Token Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Umlautfehler. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P07 Plagiatserkennung - PlagiatserkennungImplementierung Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P08 Plagiatserkennung - Nachbereitung Logik Logischer Aufbau der Klasse. 9

13 2.3. Code Review P08 Es fehlt die ist kein festgehaltener Standard der PG. Umlautfehler. Ansonsten korrekt genutzt. Die Code- wurden eingehalten. Fehlende Kommentare. Imports werden nicht alle verwendet. Tabelle 15: Code Review - Plagiatserkennung - Nachbereitung Tabelle 16: Code Review - Plagiatserkennung - StringMerge Tabelle 17: Code Review - Plagiatserkennung - NGramGenerator Java-Doc Code- Anmerkungen P09 Plagiatserkennung - StringMerge Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P10 Plagiatserkennung - NGramGenerator Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. P11 Plagiatserkennung - TokenGenerator Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. Tabelle 18: Code Review - Plagiatserkennung - TokenGenerator 10

14 2.3. Code Review P12 Plagiatserkennung - Vorbereitung Logik Logischer Aufbau der Klasse. Java-Doc Es fehlt die ist kein festgehaltener Standard der PG. Ansonsten korrekt genutzt. Code- Die Code- wurden eingehalten. Anmerkungen Fehlende Kommentare. Nicht verwendet: private Plagiatsueberpruefung oplagiatsueberpruefung und private int iplagiatsueberpruefungs Steuerungslogik Tabelle 19: Code Review - Plagiatserkennung - Vorbereitung S01 SteuerngslogikImplementierung Reviewer Maxim Klimenko Logik Angemessene stetig eingehaltene Methodenstruktur und Fehlerbehandlung. Eine Korrektur bezüglich der Anpassung von '<' auf '<=' ist vom Entwickler direkt umgesetzt worden Java-Doc Angemessener Umfang und gleichbleibende Struktur, jedoch Code- Werden eingehalten. Eine Anmerkung, statt 'e' 'ofehler' zu verwenden, ist vom Entwickler direkt umgesetzt worden Anmerkungen Zusammen mit dem verantwortlichem Entwickler wurden Optimierungen am Code durchgeführt Tabelle 20: Code Review - Steuerungslogik 11

15 3. Abnahmetest 3. Abnahmetest Autor: Christian Wübbeling Es soll nach jeder Iteration ein Abnahmetest durchgeführt werden. Dabei gilt, dass möglichst alle Komponenten der Software beim Systemtest angesprochen / verwendet werden. Dies soll durch Orientierung an den im Pichtenheft denierten Anwendungsfällen - hier mit AF X.Y abgekürzt - erreicht werden Übersicht über zu testende Anforderungen Getestet wird auf alle funktionalen und nichtfunktionalen Anforderungen (aus dem Pichtenheft bzw. dem Projekt-Wiki), u.a.: ˆ Erkennung von Plagiaten mittels mindestens zwei auswählbaren und kongurierbaren Algorithmen (F140, F321, F290, E050), darunter auch mittels eines linguistischen Verfahrens (F340) ˆ Internetrecherche mit Auswahlmöglichkeit von Quellen (F150), diese muss zusätzlich - wie alle anderen längeren Prozesse - abbrechbar sein (F560, F450) ˆ Eignung für die verschiedenen Plagiatskandidat- und Referenzdokument-Formate TXT und PDF (F360, F370 und F380). Die Internetrecherche muss zusätzlich HTML interpretieren können. ˆ Ein Experten- und Standardmodus, u.a. mit Kongurierbarkeit der Algorithmen (F460, F470 und F480) ˆ Ein Ergebnisdokument soll einen Strichcode, ein Kuchendiagramm, farbliche Text-Markierungen der Plagitsverdachtsstellen, eine Abschätzung bzgl. der Plagiatsverdachtsstellen ausgeben 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 Plagiatskandidaten im Ergebnisdokument anonymisieren, Referenzdokumente und Plagiatskandidaten müssen nach Überprüfung gelöscht werden (Q030, Q040 und Q050) Alle Anforderungen werden im folgenden Kapitel gegen die denierten Anwendungsfälle getestet. Die Tests erfolgen als dynamische, funktionsorientierte Blackbox-Tests (also zur Laufzeit ohne Kenntnis des Quellcodes). Es sollen je nach Funktion Positiv- und Negativtests durchgeführt werden (vgl. [Bal09]) Rahmenbedingungen und Testfälle Für alle folgenden Testfälle gelten neben den bereits denierten Anforderungen folgende Randbedingungen, welche für jeden Test zusätzlich zu den in den folgenden Tabellen denierten Anweisungen Anwendung nden. Diese sollen Anforderungen erfassen, welche vom Durchschnittsbenutzer mutmaÿlich erwartet werden: ˆ Das System erzeugt akzeptable Antwortzeiten bis 10 Sekunden pro Benutzer-Anforderung je nach Komplexität der Operation. ˆ Normale Dateigröÿen bis 20 MB sind erlaubt. ˆ Die maximale gleichzeitige Datei-Anzahl pro Upload-Anforderung beträgt

16 3.2. Rahmenbedingungen und Testfälle ˆ 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, Google Chrome, Apple Safari durchgeführt. Hinweis: Aufgrund von zeitlichen Einschränkungen wird auf die Benutzung eines für Abnahmetests spezialisierten Browser-Plugins (Selenium) verzichtet. Dies könnte jedoch in zukünftigen Iterationen durchgeführt werden. 001 Bezeichnung Login Vorbedingungen Webfrontend wurde aufgerufen Eingaben Der Benutzer authentiziert sich mit seinen Benutzerdaten über den Login-Dialog mittels seines System-Logins. Erwartetes Verhalten 1. Korrekte Benutzerdaten Der Benutzer wird zur Datei-Auistung weitergeleitet, es wird ein Sitzungs-Cookie gesetzt 2. Inkorrekte Benutzerdaten Der Login wird mit einer Meldung abgebrochen. Der Benutzer wird wieder zum Anmeldedialog weitergeleitet. Prüfanweisungen 1. Groÿ-/Kleinschreibung beim Benutzernamen in verschiedenen Varianten überprüfen Tabelle 21: Abnahmetest - Testfall Bezeichnung Logout Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt Eingaben 1. Manueller Logout Der Benutzer nutzt die Logout-Funktion in der Navigation. 2. Automatischer Logout Nach einer zu denierenden Zeit wird der Benutzer automatisch ausgeloggt bzw. wird seine Sitzung automatisch ungültig. Erwartetes Verhalten 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 mehr aufrufbar. Tabelle 22: Abnahmetest - Testfall (analog AF 1.1) Bezeichnung Anlegen einer Plagiatsüberprüfung, Hochladen von Plagiatskandidaten und Konguration der Algorithmen Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt 13

17 3.2. Rahmenbedingungen und Testfälle 003 (analog AF 1.1) Eingaben Das Formular zum Anlegen von neuen Plagiatsüberprüfungen wurde aufgerufen, eine Datei aus dem lokalen Dateisystem wurde ausgewählt und die Schaltäche zum Hochladen angeklickt. Vorher kann der Benutzer zwischen dem Standard- oder Expertenmodus wählen. Im Expertenmodus wird ihm die Konguration der verfügbaren Algorithmen angeboten. Der Upload ist jeweils für bestimmte Dateien durchzuführen, um die Ergebnisse reproduzieren zu können. Darin wurde eine denierte Anzahl an Plagiaten gefunden, welche die Software ebenfalls später aunden muss. Diese Dateien benden sich im Subversion-Repository der Projektgruppe. Erwartetes Verhalten 1. Hochladen erfolgreich Aus 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 Plagiatskandidaten eine Vorverarbeitung der enthaltenen Quellen (durch diese Analyse werden Literaturvorschläge unterbreitet). Es wird eine Internetrecherche nach weiteren Web-Quellen auf Basis der Inhalte der Plagiatskandidaten durchgeführt. Der Prozess wird daher bis zum Ende der Vorverarbeitung unterbrochen und kann im Hauptdialog der Anwendung später fortgesetzt werden. 2. Hochladen nicht erfolgreich Der Benutzer wird informiert. Es können jedoch weitere Dateien hochgeladen werden. Prüfanweisungen 1. Dateien mit Sonderzeichen (anderen Zeichen als a-z, A-Z, 0-9, _ und.) prüfen müssen korrekt behandelt werden 2. Dateien mit 0 Byte oder > 20 MB prüfen gröÿere Dateien sind nicht erlaubt 3. Dateien mit besonders langen Namen prüfen (>255 Zeichen) müssen ohne Fehler hochgeladen werden 4. HTML und/oder JavaScript und/oder SQL-Code sind in sämtlichen Formularen verboten Zeichen müssen konvertiert werden 6. Das Hochladen von mehr als 100 Dateien gleichzeitig ist verboten 7. Sitzungsablauf prüfen (1 Stunde) 8. Dateien im Format PDF und Text hochladen 9. Eingabefelder leer lassen 10. Eingabefelder zur Konguration mit oensichtlich ungültigen Werten befüllen 11. U.a. Test-Datei Testdatei.pdf hochladen Tabelle 23: Abnahmetest - Testfall (analog AF 1.2) Bezeichnung Auswahl der Internetquellen, Hochladen von Referenzdokumenten Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, ein oder mehrere Plagiatskandidaten wurden hochgeladen, der Benutzer setzt durch die entsprechende Schaltäche bei der Plagiatsüberprüfung den Prozess fort. 14

18 3.2. Rahmenbedingungen und Testfälle 004 (analog AF 1.2) Eingaben Die Internetquellen werden vom Benutzer an- oder abgewählt. Auch werden werden eine oder mehrere Referenzdokumente aus dem lokalen Dateisystem ausgewählt und die Schaltäche zum Hochladen angeklickt. Der Upload ist jeweils für bestimmte Dateien durchzuführen, um die Ergebnisse reproduzieren zu können. Darin wurde eine denierte Anzahl an Plagiaten gefunden, welche die Software ebenfalls später aunden muss. Diese Dateien benden sich im Subversion-Repository der Projektgruppe. Erwartetes Verhalten 1. Hochladen erfolgreich Aus dem Kontext ist ersichtlich, dass das Hochladen des/der Referenz- dokumente erfolgreich war. Der Prozess wird an dieser Stelle zur Normalisierung und Internetsuche erneut unterbrochen und kann im Hauptdialog nach Beendigung fortgesetzt werden. 2. Hochladen nicht erfolgreich Der Benutzer wird informiert. Der Prozess-Teil wird abgebrochen. Die Plagiatsüberprüfung hat weiterhin den Status Internetquellensuche abgeschlossen. Prüfanweisungen 1. Dateien mit Sonderzeichen (anderen Zeichen als a-z, A-Z, 0-9, _ und.) prüfen müssen korrekt behandelt werden 2. Dateien mit 0 Byte oder > 20 MB prüfen gröÿere Dateien sind nicht erlaubt 3. Dateien mit besonders langen Namen prüfen (>255 Zeichen) müssen ohne Fehler hochgeladen werden 4. Das Hochladen von mehr als 100 Dateien gleichzeitig ist verboten 5. Sitzungsablauf prüfen (1 Stunde) 6. Dateien im Format PDF und Text hochladen 7. Für Administratoren: Die Kernanwendung vom Internet trennen. 8. U.a. Test-Datei Testdatei-Referenz.pdf hochladen Tabelle 24: Abnahmetest - Testfall (analog AF 1.3) Bezeichnung Starten einer Plagiatsüberprüfung Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, eine Plagiatsüberprüfung wurde angelegt und mindestens ein Plagiatskandidat hochgeladen Eingaben In der Auistung der Plagiatsüberprüfungen im Haupt-Dialog wird die Plagiatsüberprüfung gestartet. Erwartetes Verhalten Die Plagiatsüberprüfung startet in paralleler Form: Das Webfrontend reagiert 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 starten 2. Eine Plagiatsüberprüfung mit vielen gröÿeren Dokumenten starten Tabelle 25: Abnahmetest - Testfall (analog AF 1.4) Bezeichnung Ergebnisdokument und -visualisierungen abrufen 15

19 3.2. Rahmenbedingungen und Testfälle 006 (analog AF 1.4) Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, eine Plagiatsüberprüfung wurde abgeschlossen Eingaben In der Auistung der Plagiatsüberprüfungen im Haupt-Dialog wird die Visualisierung gestartet. Erwartetes Verhaltediagrammes 1. Es wird eine Visualisierung mitsamt eines Strichcodes, eines Kuchenkandidat und farblicher Markierungen angezeigt, bei der Plagiats- und Referenzdokument bzw. Internetquellen gegenüber gestellt werden. 2. Es wird aus der Bildschirmanzeige ersichtlich, welcher Algorithmus für das Aunden von spezischen Plagiatsverdachtsstellen zuständig war. Der Benutzer erhält zusätzlich eine Abschätzung, inwiefern es sich bei dem gesamten Dokument um ein Plagiat handeln könnte. 3. Graken und textuelle Anzeigen sind dem Anschein nach konsistent. 4. Das oensichtliche Komplettplagiat sowie die Verschleierung in Testdatei.pdf wurden erkannt. Prüfanweisungen 1. Durch die Ausgabe scrollen und die angebotenen Funktionen ausprobieren Tabelle 26: Abnahmetest - Testfall (analog AF 1) Bezeichnung Plagiatsüberprüfungen auisten Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt, es wurden mehrere Plagiatsüberprüfungenen angelegt Eingaben - Erwartetes Verhalten Alle Plagiatsüberprüfungenn werden mitsamt ihres jeweils aktuellsten Status angezeigt. Prüfanweisungen 1. Dateien mit Sonderzeichen im Dateinamen sollten so wie im Orgiginal- Dateinamen angegeben angezeigt werden. 2. Die Datei-Auistung darf es dem Benutzer immer nur ermöglichen, den jeweils nächsten logischen Schritt bei der Plagiatsprüfung durchzuführen. 3. Eine Plagiatsüberprüfung abbrechen bzw. löschen Tabelle 27: Abnahmetest - Testfall Bezeichnung Anlegen eines Benutzerkontos Vorbedingungen Webfrontend wurde aufgerufen, Benutzer ist eingeloggt Eingaben Ein Benutzerkonto wird im Seitenbereich für die Anmeldung registriert. Erwartetes Verhalteter Das Benutzerkonto wird ordnungsgemäÿ angelegt. Eine Anmeldung un- diesem Konto ist sofort möglich. 16

20 3.2. Rahmenbedingungen und Testfälle 008 Prüfanweisungen 1. Nur entsprechend privilegierte Benutzer dürfen diese Funktion verwenden. 2. Leere Felder prüfen 3. Ungleiche Passwort-Felder prüfen 4. Doppelte Benutzernamen prüfen 5. Ungültige -Adressen prüfen 6. Wird das Passwort doppelt abgefragt oder besteht die Gefahr einer Fehleingabe? 7. Besonders lange Texte eingeben 8. SQL-Befehle in Feldern prüfen 9. HTML-Code in Feldern prüfen 10. Sonderzeichen prüfen Tabelle 28: Abnahmetest - Testfall 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 unverzüglich den Gruppenmitgliedern weiterzuleiten. Zusätzlich werden Tickets mit den aufgedeckten Problemen den mutmaÿlich zuständigen Programmierern zugeordnet, damit diese sie strukturiert abarbeiten Auistung von Test-Resultaten Stukturierte Tests nach diesem Vorbild wurden nach einiger Vorbereitung mit Version 2 aufgenommen. Version 2.0: Folgende Probleme oder Hinweise wurden in Version 2.0 aufgedeckt: ˆ Der Benutzername wird Case-sensitiv überprüft. ˆ Die Login-Auorderung 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 noch Referenzdokumente 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änkung unterschritten wurde. ˆ Die Datenhaltung produziert Fehler, sofern ein Log-Kommentar oder ein Dateiname zu lang sind. ˆ Dateien mit Umlauten oder Sonderzeichen werden falsch ausgegeben. ˆ Textdokumente werden nicht normalisiert. 17

21 3.2. Rahmenbedingungen und Testfälle ˆ 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 Konguration ist nichts vorausgewählt, es kann auch nichts ausgewählt werden. 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 Wahrscheinlichkeit nicht zwischen 0 und 1 liegt. ˆ Der Fortschritt eines Uploads sollte visualisiert, Interaktions-Buttons währenddessen gesperrt werden. ˆ 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äug unsinnige Zwei-Wort-Plagiate gefunden. ˆ Beim Anklicken von Plagiatsverdachtsstellen im HTML-Ergebnisdokument werden gelegentlich bei wiederholtem Klick unterschiedliche Fundstellen angezeigt. ˆ Exportierte PDF-Ergebnisdokumente sind unvollständig. ˆ Die Gegenüberstellung von Plagiatskandidaten und Referenzdokumenten im PDF-Ergebnisdokument 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. Version 3.0: Folgende Probleme oder Hinweise wurden in Version 3.0 aufgedeckt: ˆ Es gibt auf dem Button Zum nächsten Schritt einen Encoding-Fehler im Text (fehlerhaftes Zeichen 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ëinstellen?). Meine meisten Test-Dokumente erhalten Sprach-Code 3 ("nicht zugeordnet"). Nachtrag: Dies scheint insbesondere dann fehl zuschlagen, wenn ich im Frontend die Autoren bearbeitet habe. Hinweis: Dokumente werden scheinbar bei der Erstanlage mit Sprach-Code "1"gespeichert. Dies ist falsch. 18

22 3.2. Rahmenbedingungen und Testfälle ˆ Erweiterter Modus: Das Fortfahren ohne Anklicken eines StringMatching-Algorithmus ist möglich. ˆ Ich kann momentan noch jede Prüfung abschlieÿen oder entfernen, obwohl diese Stati nur in bestimmten Fällen verfügbar sein dürfen. ˆ Der Strichcode im Ergebnisdokument ist noch nicht klickbar. ˆ Schreibfehler auf Button: "Hier klick, um..." ˆ Die grasche Legende der Graken im HTML-Ergebnisdokument passt nicht mehr. ˆ Das PDF-Ergebnisdokument enthält noch unbestätigte Plagiatsverdachtsstellen sowie ebenfalls die alte Legende. ˆ Habe ich einen Plagiatsverdacht bestätigt, klicke dann einen anderen an, wird dieser später wieder als unbestätigt angezeigt. ˆ Bei der Benutzer-Registrierung werden die früheren Eingaben bei einem Fehler in den Eingabefeldern 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 rechte Spalte 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 - üngültige groÿe binärdatei.pdf") ab und Prozess bleibt stehen. ˆ Bei der Plagiatsprüfung zweier gleicher Dokumente einmal im Standardmodus und zum zweiten im erweiterten Modus ergeben sich völlig unterschiedliche Ergebnisse (jeweils mit dem Qualitätstest 1 ohne Web-Quellen) ˆ Bei der Prüfung meiner Standard-Testdokumente ("Testdatei.pdf"mit den Sätzen "Thomas jagt im komplett verwahrlosten Taxi quer durch Bayern.") werden die Komplettplagiate mal erkannt, mal nicht. Version 3.1: Folgende Probleme oder Hinweise wurden in Version 3.1 aufgedeckt: ˆ 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 graschen Visualisierungen werden bei nalisierten Prüfungen nicht korrekt angezeigt. ˆ Die Cluster-Variante der Plagiatsprüfung gibt Wahrscheinlichkeiten auÿerhalb des gültigen Intervalls 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

23 3.2. Rahmenbedingungen und Testfälle ˆ 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. ˆ Das Web-Ergebnisdokument zeigt trotz Sonderzeichen (insb. Anführungszeichen) Fragezeichen an, obwohl der Service diese ordnungsgemäÿ ausliefert. ˆ Nach Aktivierung neuer Funktionen in der Normalisierung können keine Plagiatsüberprüfungen mehr gelöscht werden. ˆ Vor dem Finalisieren heiÿt es Sind sie sicher, dass (...)? *I*n weiteres Bearbeiten ist nicht mö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 grau angezeigt. ˆ Die Normalisierung gibt sehr häug Stop reading corrupt stream in die Konsole aus, auÿerdem andere für den Anwender unwichtige Meldungen. ˆ Ich kann wieder bereits bestätigte Plagiatsverdachtsstellen erneut bestätigen, teils aber die Bestätigung sogar nicht mehr entfernen. ˆ Die Status-Aktualisierungs-Frequenz ist zu häug: Fünf Sekunden führen schnell zu einer ordentlichen Serverlast. 20

24 A. Tabellenverzeichnis A. Tabellenverzeichnis 1. Code Review - Aufbau Code Review - Datenhaltung - LogPrinter Code Review - Datenhaltung - DatenhaltungImplementierung Code Review - Datenhaltung - Kongurationsdaten Code Review - Datenhaltung - Konverter Code Review - Datenhaltung - SQLBindung Code Review - Datenhaltung - SQLBindung Code Review - Plagiatserkennung - BoyerMoore Code Review - Plagiatserkennung - JavaString Code Review - Plagiatserkennung - RabinKarp Code Review - Plagiatserkennung - NGram Code Review - Plagiatserkennung - RabinKarpDTO Code Review - Plagiatserkennung - Token Code Review - Plagiatserkennung - PlagiatserkennungImplementierung Code Review - Plagiatserkennung - Nachbereitung Code Review - Plagiatserkennung - StringMerge Code Review - Plagiatserkennung - NGramGenerator Code Review - Plagiatserkennung - TokenGenerator Code Review - Plagiatserkennung - Vorbereitung Code Review - Steuerungslogik Abnahmetest - Testfall Abnahmetest - Testfall Abnahmetest - Testfall Abnahmetest - Testfall Abnahmetest - Testfall Abnahmetest - Testfall Abnahmetest - Testfall Abnahmetest - Testfall Testprotokoll - Tabellenkopf Testprotokoll - Testfall Testprotokoll - Testfall Testprotokoll - Testfall Testprotokoll - Testfall Testprotokoll - Testfall Testprotokoll - Testfall Testprotokoll - Testfall Testprotokoll - Testfall

25 B. Literaturverzeichnis B. Literaturverzeichnis [Bal09] Balzert, Helmut ; Rüdinger, Andreas (Hrsg.) ; Kohl, Kerstin (Hrsg.) ; Fraude, Dagmar (Hrsg.): Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering. Spektrum, 2009 [BBK01] Back, A. ; Becker, J. ; König, W. ; Stürken, M. (Hrsg.): Lexikon der Wirtschaftsinformatik. Springer, 2001 [CSFP] [GB09] [Lin05] Collins-Sussman, B. ; Fitzpatrick, B. W. ; Pilato, M.: Version Control with Subversion. Letzter Zugri am Grechenig, Thomas ; Bernhart, Mario: Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten. Pearson, 2009 Link, Johannes: Softwaretests mit JUnit - Techniken der testgetriebenen Entwicklung. Dpunkt Verlag, 2005 [Sma11] SmartBear: SmartBear Software: 11 Best Practices for Peer Code Review. White Paper. Version: 2011 [Teca] [Tecb] [Wes] TechTerms: API. Letzter Zugri am TechTerms: PDF. Letzter Zugri am Westphal, Frank: Unit Tests mit JUnit. gmitjunit.html. Zugri am

26 C. Glossar C. Glossar Abnahmetest Der Abnahmetest hilft beim Testen vom Verhalten unterschiedlicher Komponenten in 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]. App Die App ist eine alphanummerische Folge von Zeichen, welche bei der Anmeldung von Bing vergeben wird. Bing Bing eine die kostenlose Suchmaschine von Microsoft, welche einen Zugri auf ihre API über eine App ermöglicht. Code Review Das Code Review beschreibt ein Vorgehen, indem Programmabschnitte manuell von einem anderen Programmierer überprüft werden [Lin05]. Datenhaltung Die Datenhaltung dient für die Anbindung an eine Datenbank, wobei noch nicht entschieden 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 Plagiate. Diese sind derzeit noch nicht bestimmt. HTML Hyper Text Markup Language ist eine Web-Auszeichnungssprache, ist Grundlage des World Wide Web und wird von einem Webbrowser dargestellt. Aktuell bendet sich HTML Version 5 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 Plagiatskandidat plagiiert wurden. Internetrecherche Die Internetrecherche ist eine Komponente der Anwendung PlagTag. Diese dient dem Finden von Referenzdaten im Internet. JUnit JUnit ist ein Framework für Unit-Tests in Java. Es ist für die automatisierte Unit-Tests einzelner Units geeignet [Wes]. Komponente Eine Komponente (hier: Software-Komponente) ist ein Software-Element, das konform zu einem Komponentenmodell (z.b. aus der UML) ist und über Schnittstellen mit anderen Komponenten verknüpft und ausgeführt werden kann. Komponentenbasierte Software wird z.b. mittels Web-Services, CORBA, Enterprise Java Beans (EJBs) oder COM entwickelt. Normalisierung Die Normalisierung ist eine Komponente der Anwendung PlagTag. Diese dient dem Auslesen von PDFs und dem Speichern der PDFs in einem einheitlichem Format. PDF Das Portable Document Format (PDF) ist ein plattformunabhängiges Dateiformat für Dokumente, das vom Unternehmen Adobe Systems entwickelt und 1993 veröentlicht wurde. Ziel ist die originalgetreue Wiedergabe auf allen Plattformen [Tecb]. 23

27 Glossar Plagiat Ein Plagiat liegt dann vor, wenn jemand vorgibt, ein Werk selbst erstellt zu haben, obwohl die Inhalte ganz oder teilweise aus fremden Quellen stammen, die falsch oder unvollständig zitiert wurden. Je nachdem wie die Zitiertechnik falsch verwendet wurde, lassen sich die Plagiate zusätzlich genauer kategorisieren Je nachdem wie die Zitiertechnik falsch verwendet wurde, lassen sich die Plagiate zusätzlich genauer kategorisieren. Es existieren vielfältige Formen geistiger Leistung, z.b. Texte, Bilder oder Videos. Plagiatserkennung Die Plagiatserkennung meint das Ausführen der Erkennungs-Algorithmen auf einen Computer, um Plagiate zu identizieren. Plagiatskandidat Ein Plagiatskandidat ist ein Dokument, welches vom Anwender in das System eingefügt und dort auf Plagiate überprüft wird. Plagiatsüberprüfung Die Plagiatsüberprüfung beschreibt das Vorgehen in PlagTag, welches den gesamten Ablauf der Anwendung ab dem Anlegen einer Überprüfung vom Anwender bis zur Ausgabe des Ergebnisses der Überprüfung meint. Dazu wird es eine Klasse Plagiatsüberprüfung geben, welche zur Identizierung dient, also festlegt welche Daten (Plagiatskandidat, Referenzdokument usw.) zu einem Ablauf gehören. Dies ermöglicht allen Komponenten der Architektur ihre Ergebnisse unter einer eindeutigen Bezeichnung in der Datenhaltung abzulegen. PlagTag PlagTag ist der Name der Plagiatserkennungssoftware. Referenzdaten Die Referenzdaten sind der Sammelbegri für Referenzdokumente und Internetquellen. Referenzdokument Die Referenzdokumente sind die Dokumente, welche durch den Anwender zusätzlich neben dem Plagiatskandidat in das System eingefügt werden, um genau diese Dokumente mit dem Plagiatskandidat zu vergleichen. SteuerungsLogik Die SteuerungsLogik ist eine Komponente der Anwendung PlagTag. Sie ist den Komponenten zur Plagiatsüberprüfung übergeordnet, um die Kommunikation zwischen diesen zu organisieren. Subversion-Repository Subversion ist eine Software zur Versionsverwaltung von Dokumenten und Programmen [CSFP]. Repository beschreibt das Verzeichnis, in dem Dokumente und Programme mit zusätzlichen Metadaten gespeichert werden, um eine Versionverwaltung zu ermöglichen [BBK01]. System Wird der System-Begri ohne explizite Einschränkungen verwendet, so bezieht sich dieser immer auf das im Projekt zu entwickelnde Gesamtprodukt. Dieses teilt sich auf in eine zentrale Berechnungs-Komponente und ein angebundenes Webfrontend. Systemtest Soll die Interaktion bei mehreren Systeme getestet werden, handelt es sich um einen Systemintegrationstest. Auf der Ebene des Gesamtsystems wird dieser Test als Systemtest bezeichnet [GB09] plural. Test Ein Test ist die Überprüfung von Programmabschnitten, welche mit Hilfe von verschiedenen Tools durchgeführt werden kann [GB09]. Vorverarbeitung Die Vorverarbeitung beinhaltet alle Teilprozesse zur Vorbereitung der Plagiatsüberprüfung. Unter dieser Vorbereitung wird die Vereinheitlichung der Plagiatskandidaten und 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