Finished task 1

project_task_sheets/phase_03/project_phase03_tasks/Solution_Phase03_MichaelChen.tex

@@ -5,11 +5,21 @@
 \usepackage{listings}
 \usepackage{enumitem}
 \usepackage{subcaption}
+\usepackage[acronym]{glossaries}
 
 \usepackage{pgf}
 \usepackage{tikz}
 \usetikzlibrary{arrows,automata}
 
+\newacronym{nc}{NC}{node coverage}
+\newacronym{ec}{EC}{edge coverage}
+\newacronym{adupc}{ADUPC}{all-du-path coverage}
+\newacronym{ppc}{PPC}{prime path coverage}
+\newacronym{auc}{AUC}{all-uses coverage}
+\newacronym{adc}{ADC}{all-defs coverage}
+\newacronym{srtc}{SRTC}{simple round-trip coverage}
+\newacronym{crtc}{CRTC}{complete round-trip coverage}
+
 \usepackage{xparse}
 \usepackage{multirow}
 
@@ -63,8 +73,8 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\def\name{[Add name here]}
+\def\name{Michael Chen}
-\def\group{[Add group here]}
+\def\group{Group 01 (fastjson)}
 
 \begin{document}
 \projectinfo{3}{Software Testing - Graph Coverage\small}{\today}{\name}{\group}
@@ -78,38 +88,38 @@
   \begin{enumerate}
       \item Graph
       \begin{answer}
-      [TODO: Add answer here]
+      A graph is a set of vertices and edges between two such vertices. This allows us to create mathematical models of real world applications. This includes for example network architectures with computers and links as vertices and edges, or in our situation we can model program source code to vertices and the program flow to edges between code lines.
       \end{answer}
 
       \item (Test-)Path
       \begin{answer}
-      [TODO: Add answer here]
+      In software testing we use directed graphs, because in a directed graph we always have unidirectional edges between the vertices. This is usesful because our program can only flow in one direction usually. A path on a directed graph is a sequence of vertices that are connected by edges pairwise, which corresponds to a connected set of directional edges. For software this can refer to a possible execution in a program flow. A test path is a path such that the path starts at an entrypoint of the graph and ends in an exit point. A test path thus refers to a path that corresponds to one possible complete execution of a program.
       \end{answer}
 
       \item Syntactic and Semantic Reach
       \begin{answer}
-      [TODO: Add answer here]
+      Syntactic reach describes if a vertex in the graph can be reached (with a path) from another vertex. This of course only refers to the graph model without taking in account if such a path is actually possible using the semantics of our language. Therefore we have semantic reach, which describes if such a path is taken from any possible program execution (including inputs). The difference between these reaches is that we check if, even though a path might exist in the graph, it might still not be a useful path, because our program state never executes this path given any input values.
       \end{answer}
 
   \end{enumerate}
   \item Which testing situations are suitable for the Graph Coverage approach?
   \begin{answer}
-  [TODO: Add answer here]
+  Graph Coverage is suitable for white-box testing situations where we have detailed knowledge of the system under test. A program graph can be created from different aspects of a program, for example from the code directly (control-flow graph), from a software specification model, or even from higher-level abstractions such as calls between different software modules. Graph coverage allows us to very precisely specify semantically different program states, where, in contrast to black-box testing, we can (and must) incorporate edge cases and domain knowledge directly into our execution paths.
   \end{answer}
 
   \item What is the difference between \textit{Tours}, \textit{Tours With Sidetrips}, and \textit{Tours With Detours}?
   \begin{answer}
-  [TODO: Add answer here]
+  A path $p_1$ can \textit{tour} another path $p_2$ if and only if $p_2$ is a subpath of $p_1$. This means that if $p_1$ is traversed, this includes the exact sequence of vertices that are also given in $p_2$. This makes a test on $p_2$ redundant, because we know, that we already traversed the graph in this manner. A tour with a sidetrip is a tour, except that it is allowed to insert loops into the subpath, as long as all edges of $p_2$ also appear in $p_1$ in the same order. A detour is similar, but instead of the edges, we enforce that all nodes of $p_2$ must also appear in $p_1$.
   \end{answer}
 
   \item Describe (1-2 sentences) the \textit{Node Coverage} (NC) and \textit{Edge Coverage} (EC) criterion. What are their counterparts for code-based coverage?
   \begin{answer}
-  [TODO: Add answer here]
+  \Gls{nc} is satisfied for a test set if every syntactically reachable vertex in the graph is reached by any test path of our test set. \Gls{ec} however is satisfied if every syntactically reachable edge in the graph was used by any test path. A mapping to code-based coverage maps vertices in the graph to statements (or non-branching blocks of statements) and edges to branches between the statements. \Gls{nc} then refers to every statement being executed, which means we have statement coverage, while \gls{ec} refers to every branch being executed, which corresponds to branch coverage.
   \end{answer}
 
   \item Name and describe (2-3 sentences) 2 \textit{Path Coverage Criteria} OR 2 \textit{Data Flow Test Criteria}. Does one of these two criteria subsume the other?
   \begin{answer}
-  [TODO: Add answer here]
+  Path coverage criteria are concerned with checking if all possible paths in a graph have been executed, while data-flow criteria check if all variable definitions and their usages have been reached. \Gls{ppc} is an example for a path coverage criterion that subsumes the \gls{adupc} criterion. \Gls{ppc} requires that every prime path (path that is not subpath of any other path) must be executed, while \gls{adupc} requires that every possible path between every definition and usage of a variable must be covered, which is of course less strong than checking every possible syntactically reachable path. Another example for data-flow coverage is \gls{auc} which verifies that every usage of variables are covered by at least one path in the test set, which is easily subsumed by \gls{adupc} and thus by \gls{ppc}. Another example for path coverage is \gls{srtc} which checks if a round-trip path is executed for every node that is the start and end of a round-trip.
   \end{answer}
 
 \end{enumerate}