<commit_before>\chapter{LV 6 am 06.06.2014}
Ab seite 35
\subsection{Software-Reengineering}
Beim Reengineering wird ein altes bzw. bestehendes System "umgewandelt" hinsichtlich der Programmiersprache. Derzeit findet z.B. sehr häufig die Umstellung von COBOL-Programmen statt. Die Vorteile sind das verringerte Risiko und die geringeren Kosten.

Sommerville bietet eine Beurteilung von Systemen, die hilft die Entscheidung, ob ein System reengineered wird, oder nicht. 
TODO: Grafik einfügen und erklären? Seite 39

\section{Test}
Tests gehören auch zur Softwareentwicklung, damit die Qualität sichergestellt werden kann. Tests haben auch immer mit den Requirements zu tun. 
\subsection{Motivation}
Getesetet wird, um 

\begin{itemize}
\item Probleme zu erkennen und um sie anschließend beheben zu können
\item Überzeugen der Endanwender
\item TODO Seite 7 vervollständigen
\end{itemize}

\subsection{Grundlegende Konzepte}
Es müssen folgende Definitionen unterschieden werden (TODO Seite 8):
\paragraph{Irrtum:}
\paragraph{Fehler:}
\paragraph{Fehlverhalten:}
\paragraph{Defekt:}

Ursprünglich verstand man unter Bugs wirklich den Einfluss von Käfern auf die Hardware, wie der erste dokumentierte Bug von Grace Hoppers 1947 zeigt. Hier sorgte eine Motte für das Fehlverhalten einer Schaltung.
\linebreak
Um Defekte zu vermeiden, kann man standardisierte Prozesse einführen.
Um Defekte zu entdecken, kann man Reviews von Spezifikationen und Code bzw. Tests durchführen (Vier-Augen-Prinzip).
Um Defekte zu beseitigen, kann wieder anhand standardisierter Prozesse, Code-REviews und TEsts erfolgen.
Um Defekte zu isolieren, kann man mit Redundanzen (NVP) arbeiten. 
\linebreak
Im Testkontext wird zwischen Blackbox-Tests, Whitebox-Tests und Regressionstests unterschieden. 

\paragraph{Blackbox-Test:} es wird gegen die Spezifikation ohne Kenntnis des Codes getestet
\paragraph{Whitebox-Test:} es wird unter Kenntnis und Verwendung des Codes getestet
\paragraph{Regressionstest:} es wird die erwarteten Funktionalität sichergestellt, und dass die Software frei von allen bislang bereits beseitigten Fehlern ist.
\linebreak
\paragraph{abstrakten Testfall:} es werden abstrakte Definitionen eines einzelnen Tests anhand des Testziels, notwendige Vorbereitung, Eingabevariablen und erwartete ERgebnisse und Beobachtungen, abhängign von den Eingabevariablen definiert.
\paragraph{konkrete Testfall:} ist eine ausführbare Definition eines einzelnen abstrakten Tests. Er besitzt eine Referenz auf den abstrakten Testfall, Werte der Eingabevariablen und detaillierte erwartete Ergebnisse.
\paragraph{Testsuite:} ist eine Sammlung von abstrakten und konkreten Testfällen.

\subsection{Testprozess}
\subsubsection{Generischer Testprozess}
Es wird festgelegt welche Eingabewerte verwendet werden und welche Testergebnisse erwartet werden. Die Testergebnisse werden in der Analyse herangezogen und mit den erwarteten Ergebnissen verglichen. Gibt es in der Analyse Abweichungen, kann es auf einen Fehler im Code hinweisen, aber auch, dass in der Vorbereitung des Tests etwas geplant wurde, was sich nicht testen lässt. Die Analyseergebnisse ergeben anschließend genauestens ausgewertet, woraus sich ein Feedback und Verbesserungen für die Planung und die Ausführung des Tests ergeben. 

\subsubsection{Testplanung und Testvorbereitung}
In diesem Schritt müssen die Aktivitäten, sprich Sammluung von Informationen über den Testkandidaten, die defintiion validierbarer TEstziele, Festlegung der Teststrategie, Definition abstrakter Testfälle, Festlegung des anzuwendeen Testverfahren und die Ableitung konrekter Testfälle, geplant werden.
Daraus lassen sich die erwarteten ERgebnisse, welche in validierbaren Testzielen, dem Test zu Grunde liegenden Modelle, anzuwendenen Testverfahren
TODO S 2!???

\subsubsection{Testdurchführung}
Bei der Testdurchführung werden alle konkreten Testfälle bzw. Testsuiten gemäß der festgelegten Testverfahren ausgeführt. 
TODO S 23

\subsubsection{Ergebnisanalyse und Verfolgung}
Bei der Ergebnisanalyse wird ein Soll/Ist-Vergleich der Ergebnisse jedes einzelnen Testfalls und eine Vorklärung der Ursache von Abweichungen durchgeführt. Das Ergebnis sind identifizierbare Abweichungen (daher Defekte) und eine summarische Auswertung aller Testfälle.
TODO S 25  (notwendige Eingaben, Rückkopplung notwendig?)

\subsubsection{Testbewertung}
Bei der Testbewertung werden die Testziele mit den summarischen Auswertungen der Testfälle verglichen. Es liegt ein Ergebnis vor, wenn das Testende erreicht wird (z.B. Testziel erreicht oder alle Testfälle wurden ausgeführt). 
TODO S 27 (notwendige Eingaben, Rückkopplung notwendig?)

\subsection{Teststrategien}
\subsubsection{Motivation}
Das planlose "Ausprobieren" ist die häufigste Form des Testens und ist unzureichend. Es liefert keine reproduzierbaren Ergebnisse, erlaubt keine Aussage über die Qualität der getesteten Software und bietet keinerlei Gewährleistung. Dieser Ansatz ist hochgradig unprofessionell. 
\linebreak
Es muss berücksichtigt werden, dass ein vollständiges Testen aller Möglichkeiten meistens theoretisch gesehen nicht möglich ist und auch auf jeden Fall unwirtschaftlich ist.

\subsubsection{Checklisten und Benutzungsprofile}
Es können für die verschiedensten Inhalte Checklisten angelegt werden. Beispielsweise Funktions-Checklisten, die eine Liste der wesentlichen Funktionen bzw. anderer Eigenschaften beinhalten (Blackbox), oder Struktur-Checklisten, die eine Liste der Systembestandteile beinhaltet (Whitebox). Hier gibt es viele weitere Checklisten. Es gibt theoretisch keine Grenzen.

TODO S34 alle auflisten?
TODO S35 notwendig?

\subsubsection{Partitionen}
Es ist meistens theoretisch unmöglich alle Möglichkeiten zu Testen. Paritionen können helfen, Probleme von Checklisten zu lösen  bzw. zu lindern.
\linebreak
Grundannahme ist, dass alle Elemente einer Äquivalenzklasse gleich behandelt werden. Es reicht daher, ein beliebiges Element aus einer Äquivalenzklasse zu testen
\linebreak
Die Anwendung von Partitionen auf Checklisten erhöht den Überdeckungsgrad und verbessert damit die Qualität und reduziert den Gesamtaufwand. 
\linebreak
Die Verwendung mehrerer einfacher, von einander unahängiger und in sich konsistenter Partitionen ist möglich und daher auch sinnvoll.
Nachteil ist, dass eine gleiche Gewichtung aller Äquivalenzklassen zu unwirtschaftlichen Verteilung des Testaufwand führt.

\subsubsection{Benutzungsprofile}
Ein Benutzungsprofil ist eine quantitative Definition der unterschiedlichen Aufrufhäufigkeiten. Beispiele hierfür sind Funktionen für Endbenutzer oder für Administratoren. Damit wird sichergestellt, dass die am häufigsten verwendeten Funktionen auch am intensivsten und regelmäßig getestet werden. 
\linebreak
Um Benutzungsprofile definieren zu können, muss zwischen existierenden PRodukten, neuen Produkten und neuartigen PRodukten unterschieden werden. Bei existiertenden PRodukten wird die Messung in unterschiedlichen Anwendernumgebungen des aktuellen Produktes und der Vorgängerversion durchgeführt. Bei neuen Produkten kann ein Konkurenzprodukt herangezogen werden und dort die Benutz

WAS???
TODO S 42

Für die Konstruktion kann die Top-Down-Methode verwendet werden. Hierbei werden Kundenkategorien mit einer Gewichtung nach relativem Benutzungsgrad definiert. Zusätzlich werden die Anwendertypen mit einer Gewichtung der Anwendungshäufigkeit pro Kundenkategorie definiert.

TODO Überschriften??? Überdeckung ist ein Unterkapitel von Teststrategien

\subsubsection{Überdeckungen}
\paragraph{Grundlegende Konzepte} 
TODO S 48-49
Wichtig ist, dass die Partitionierung vollständig und überlappungsfrei ist. Die Grenzen bilden die Teile des Eingaberaums, an dem Unterdomänen zusammensoßen - im einfachsten Fall ist diese Grenze linear.  Ein Grenzpunkt liegt genau auf einer Grenze und ein Knotenpunkt liegt auf mindestens zwei Grenzen).

\paragraph{Überdeckungsbasiertes Testen}
Um Überdeckungsabsiertes Testen zu ermöglichen, muss eine Identifikation des  Eingaberaums (Eingabevariablen mit ihren Beschränkungen) durchgeführt werden. 
TODO S52

\paragraph{Probleme}
\begin{itemize}
\item Testpunkte können vom Testkandidaten nicht bearbeitet werden (Ursache hierfür sind unvollständige Spezifikationen oder Implementierungen oder Spezifikationen auf Basis von Unterdomänen)
\item Testpunkte haben mehrere widersprüchliche Verarbeitungsregeln (Ursache hierfür sind überlappende Unterdomänen)
\item Probleme mit der Grenzdefinition (Ursachen hierfür sind Abschlussprobleme, Grenzverschiebungen mit minimalen Abweichungen (Rundungsfehlern), fehlende Grenzen durch fehlerhafte Partitionierung und überflüssige Grenzen durch übertriebene Partitionierung)
\end{itemize}

\paragraph{Überdeckungsbasierte Teststrategien}
Bei der EPC (Extreme Point Combination) Strategie, wird für jede Unterdomäne für jede Dimensionen i des Eingaberaums ein Minimum und Maximum definiert und als Testpunkte dienen alle 4^n möglichen Kombinationen der underi, mini, maxi und overi. 
Mit dieser Strategie is tman im Eindimensionalen auf der sicheren Seite, da Abschlussprobleme, Grenzverschiebungen (nicht alle), fehlende Grenzen und überflüssige Grenzen (abhängig von der Lage des inneren Testpunkts) erkannt werden. Im Mehrdimensionalen allerdings ist diese Strategie nicht zu empfehlen, da unter Umständen erhebliche Probleme abhängig von der Art und Lage der Grenzen entstehen können.
TODO underi, mini etc - i untergestellt
\linebreak
Mit der Schwachen Nx1-Strategie (sehr wichtig) können Grenzverschiebungen erkannt werden. Es werden für jede Unterdomäne und für jede Grenze n linear unabhängige Testpunkte auf der Grenze, ein Testpunkt nicht auf der Grenze, ein Testpunkt außerhalb der Unterdomäne, falls die Grenze abgeschlossen ist, ein Testpunkt innerhalb der Unterdomäne, falls die Grenzen offen sind definiert. Zusätzlich wird ein Testpunkt im Inneren der Unterdomäne definiert. Insgesat hat man dann (n+1)*b+1 Testpunkte pro Unterdomäne mit b Grenzen. Der Aufwand dieser Strategie ist sehr groß, doch sie erkennt dafür Abschlussprobleme, Grenzverschiebungen, fehlende Grenzen und die meisten überflüssigen Grenzen (allerdings nicht alle).<commit_msg>lv 6 - bis seite 62<commit_after>\chapter{LV 6 am 06.06.2014}
Ab seite 35
\subsection{Software-Reengineering}
Beim Reengineering wird ein altes bzw. bestehendes System "umgewandelt" hinsichtlich der Programmiersprache. Derzeit findet z.B. sehr häufig die Umstellung von COBOL-Programmen statt. Die Vorteile sind das verringerte Risiko und die geringeren Kosten.

Sommerville bietet eine Beurteilung von Systemen, die hilft die Entscheidung, ob ein System reengineered wird, oder nicht. 
TODO: Grafik einfügen und erklären? Seite 39

\section{Test}
Tests gehören auch zur Softwareentwicklung, damit die Qualität sichergestellt werden kann. Tests haben auch immer mit den Requirements zu tun. 
\subsection{Motivation}
Getesetet wird, um 

\begin{itemize}
\item Probleme zu erkennen und um sie anschließend beheben zu können
\item Überzeugen der Endanwender
\item TODO Seite 7 vervollständigen
\end{itemize}

\subsection{Grundlegende Konzepte}
Es müssen folgende Definitionen unterschieden werden (TODO Seite 8):
\paragraph{Irrtum:}
\paragraph{Fehler:}
\paragraph{Fehlverhalten:}
\paragraph{Defekt:}

Ursprünglich verstand man unter Bugs wirklich den Einfluss von Käfern auf die Hardware, wie der erste dokumentierte Bug von Grace Hoppers 1947 zeigt. Hier sorgte eine Motte für das Fehlverhalten einer Schaltung.
\linebreak
Um Defekte zu vermeiden, kann man standardisierte Prozesse einführen.
Um Defekte zu entdecken, kann man Reviews von Spezifikationen und Code bzw. Tests durchführen (Vier-Augen-Prinzip).
Um Defekte zu beseitigen, kann wieder anhand standardisierter Prozesse, Code-REviews und TEsts erfolgen.
Um Defekte zu isolieren, kann man mit Redundanzen (NVP) arbeiten. 
\linebreak
Im Testkontext wird zwischen Blackbox-Tests, Whitebox-Tests und Regressionstests unterschieden. 

\paragraph{Blackbox-Test:} es wird gegen die Spezifikation ohne Kenntnis des Codes getestet
\paragraph{Whitebox-Test:} es wird unter Kenntnis und Verwendung des Codes getestet
\paragraph{Regressionstest:} es wird die erwarteten Funktionalität sichergestellt, und dass die Software frei von allen bislang bereits beseitigten Fehlern ist.
\linebreak
\paragraph{abstrakten Testfall:} es werden abstrakte Definitionen eines einzelnen Tests anhand des Testziels, notwendige Vorbereitung, Eingabevariablen und erwartete ERgebnisse und Beobachtungen, abhängign von den Eingabevariablen definiert.
\paragraph{konkrete Testfall:} ist eine ausführbare Definition eines einzelnen abstrakten Tests. Er besitzt eine Referenz auf den abstrakten Testfall, Werte der Eingabevariablen und detaillierte erwartete Ergebnisse.
\paragraph{Testsuite:} ist eine Sammlung von abstrakten und konkreten Testfällen.

\subsection{Testprozess}
\subsubsection{Generischer Testprozess}
Es wird festgelegt welche Eingabewerte verwendet werden und welche Testergebnisse erwartet werden. Die Testergebnisse werden in der Analyse herangezogen und mit den erwarteten Ergebnissen verglichen. Gibt es in der Analyse Abweichungen, kann es auf einen Fehler im Code hinweisen, aber auch, dass in der Vorbereitung des Tests etwas geplant wurde, was sich nicht testen lässt. Die Analyseergebnisse ergeben anschließend genauestens ausgewertet, woraus sich ein Feedback und Verbesserungen für die Planung und die Ausführung des Tests ergeben. 

\subsubsection{Testplanung und Testvorbereitung}
In diesem Schritt müssen die Aktivitäten, sprich Sammluung von Informationen über den Testkandidaten, die defintiion validierbarer TEstziele, Festlegung der Teststrategie, Definition abstrakter Testfälle, Festlegung des anzuwendeen Testverfahren und die Ableitung konrekter Testfälle, geplant werden.
Daraus lassen sich die erwarteten ERgebnisse, welche in validierbaren Testzielen, dem Test zu Grunde liegenden Modelle, anzuwendenen Testverfahren
TODO S 2!???

\subsubsection{Testdurchführung}
Bei der Testdurchführung werden alle konkreten Testfälle bzw. Testsuiten gemäß der festgelegten Testverfahren ausgeführt. 
TODO S 23

\subsubsection{Ergebnisanalyse und Verfolgung}
Bei der Ergebnisanalyse wird ein Soll/Ist-Vergleich der Ergebnisse jedes einzelnen Testfalls und eine Vorklärung der Ursache von Abweichungen durchgeführt. Das Ergebnis sind identifizierbare Abweichungen (daher Defekte) und eine summarische Auswertung aller Testfälle.
TODO S 25  (notwendige Eingaben, Rückkopplung notwendig?)

\subsubsection{Testbewertung}
Bei der Testbewertung werden die Testziele mit den summarischen Auswertungen der Testfälle verglichen. Es liegt ein Ergebnis vor, wenn das Testende erreicht wird (z.B. Testziel erreicht oder alle Testfälle wurden ausgeführt). 
TODO S 27 (notwendige Eingaben, Rückkopplung notwendig?)

\subsection{Teststrategien}
\subsubsection{Motivation}
Das planlose "Ausprobieren" ist die häufigste Form des Testens und ist unzureichend. Es liefert keine reproduzierbaren Ergebnisse, erlaubt keine Aussage über die Qualität der getesteten Software und bietet keinerlei Gewährleistung. Dieser Ansatz ist hochgradig unprofessionell. 
\linebreak
Es muss berücksichtigt werden, dass ein vollständiges Testen aller Möglichkeiten meistens theoretisch gesehen nicht möglich ist und auch auf jeden Fall unwirtschaftlich ist.

\subsubsection{Checklisten und Benutzungsprofile}
Es können für die verschiedensten Inhalte Checklisten angelegt werden. Beispielsweise Funktions-Checklisten, die eine Liste der wesentlichen Funktionen bzw. anderer Eigenschaften beinhalten (Blackbox), oder Struktur-Checklisten, die eine Liste der Systembestandteile beinhaltet (Whitebox). Hier gibt es viele weitere Checklisten. Es gibt theoretisch keine Grenzen.

TODO S34 alle auflisten?
TODO S35 notwendig?

\subsubsection{Partitionen}
Es ist meistens theoretisch unmöglich alle Möglichkeiten zu Testen. Paritionen können helfen, Probleme von Checklisten zu lösen  bzw. zu lindern.
\linebreak
Grundannahme ist, dass alle Elemente einer Äquivalenzklasse gleich behandelt werden. Es reicht daher, ein beliebiges Element aus einer Äquivalenzklasse zu testen
\linebreak
Die Anwendung von Partitionen auf Checklisten erhöht den Überdeckungsgrad und verbessert damit die Qualität und reduziert den Gesamtaufwand. 
\linebreak
Die Verwendung mehrerer einfacher, von einander unahängiger und in sich konsistenter Partitionen ist möglich und daher auch sinnvoll.
Nachteil ist, dass eine gleiche Gewichtung aller Äquivalenzklassen zu unwirtschaftlichen Verteilung des Testaufwand führt.

\subsubsection{Benutzungsprofile}
Ein Benutzungsprofil ist eine quantitative Definition der unterschiedlichen Aufrufhäufigkeiten. Beispiele hierfür sind Funktionen für Endbenutzer oder für Administratoren. Damit wird sichergestellt, dass die am häufigsten verwendeten Funktionen auch am intensivsten und regelmäßig getestet werden. 
\linebreak
Um Benutzungsprofile definieren zu können, muss zwischen existierenden PRodukten, neuen Produkten und neuartigen PRodukten unterschieden werden. Bei existiertenden PRodukten wird die Messung in unterschiedlichen Anwendernumgebungen des aktuellen Produktes und der Vorgängerversion durchgeführt. Bei neuen Produkten kann ein Konkurenzprodukt herangezogen werden und dort die Benutz

WAS???
TODO S 42

Für die Konstruktion kann die Top-Down-Methode verwendet werden. Hierbei werden Kundenkategorien mit einer Gewichtung nach relativem Benutzungsgrad definiert. Zusätzlich werden die Anwendertypen mit einer Gewichtung der Anwendungshäufigkeit pro Kundenkategorie definiert.

TODO Überschriften??? Überdeckung ist ein Unterkapitel von Teststrategien

\subsubsection{Überdeckungen}
\paragraph{Grundlegende Konzepte} 
TODO S 48-49
Wichtig ist, dass die Partitionierung vollständig und überlappungsfrei ist. Die Grenzen bilden die Teile des Eingaberaums, an dem Unterdomänen zusammensoßen - im einfachsten Fall ist diese Grenze linear.  Ein Grenzpunkt liegt genau auf einer Grenze und ein Knotenpunkt liegt auf mindestens zwei Grenzen).

\paragraph{Überdeckungsbasiertes Testen}
Um Überdeckungsabsiertes Testen zu ermöglichen, muss eine Identifikation des  Eingaberaums (Eingabevariablen mit ihren Beschränkungen) durchgeführt werden. 
TODO S52

\paragraph{Probleme}
\begin{itemize}
\item Testpunkte können vom Testkandidaten nicht bearbeitet werden (Ursache hierfür sind unvollständige Spezifikationen oder Implementierungen oder Spezifikationen auf Basis von Unterdomänen)
\item Testpunkte haben mehrere widersprüchliche Verarbeitungsregeln (Ursache hierfür sind überlappende Unterdomänen)
\item Probleme mit der Grenzdefinition (Ursachen hierfür sind Abschlussprobleme, Grenzverschiebungen mit minimalen Abweichungen (Rundungsfehlern), fehlende Grenzen durch fehlerhafte Partitionierung und überflüssige Grenzen durch übertriebene Partitionierung)
\end{itemize}

\paragraph{Überdeckungsbasierte Teststrategien}
Bei der EPC (Extreme Point Combination) Strategie, wird für jede Unterdomäne für jede Dimensionen i des Eingaberaums ein Minimum und Maximum definiert und als Testpunkte dienen alle 4^n möglichen Kombinationen der underi, mini, maxi und overi. 
Mit dieser Strategie is tman im Eindimensionalen auf der sicheren Seite, da Abschlussprobleme, Grenzverschiebungen (nicht alle), fehlende Grenzen und überflüssige Grenzen (abhängig von der Lage des inneren Testpunkts) erkannt werden. Im Mehrdimensionalen allerdings ist diese Strategie nicht zu empfehlen, da unter Umständen erhebliche Probleme abhängig von der Art und Lage der Grenzen entstehen können.
TODO underi, mini etc - i untergestellt
\linebreak
Mit der Schwachen Nx1-Strategie (sehr wichtig) können Grenzverschiebungen erkannt werden. Es werden für jede Unterdomäne und für jede Grenze n linear unabhängige Testpunkte auf der Grenze, ein Testpunkt nicht auf der Grenze, ein Testpunkt außerhalb der Unterdomäne, falls die Grenze abgeschlossen ist, ein Testpunkt innerhalb der Unterdomäne, falls die Grenzen offen sind definiert. Zusätzlich wird ein Testpunkt im Inneren der Unterdomäne definiert. Insgesat hat man dann (n+1)*b+1 Testpunkte pro Unterdomäne mit b Grenzen. Der Aufwand dieser Strategie ist sehr groß, doch sie erkennt dafür Abschlussprobleme, Grenzverschiebungen, fehlende Grenzen und die meisten überflüssigen Grenzen (allerdings nicht alle).

Bis Seite 62
{'fraction_non_alphanumeric': 0.035331695331695334, 'fraction_numerical': 0.004373464373464374, 'mean_word_length': 6.296880602366439, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2325550', 'n_tokens_mistral': 6391, 'n_tokens_neox': 6637, 'n_words': 2416}