-Hello world
+%6
+%7
+%8
+%9
+%10
+%11
+%12
+
+The test process consists of several stages. The results of the first stage,
+planning, are descibed in this document. On the basis of this document actual
+test cases will be designed. Afterwards the actual tests will be implemented
+and executed. The results of these tests will then be evaluated against the
+exit criteria (see Section~\ref{sec:exitcriteria}) and depending on the outcome
+of these evaluations further tests might be deemed necessary.
+
+\subsection{Quality Characteristics}
+The quality characteristics that are to be tested are described using the
+ISO/IEC 25010 \cite{iso25010} as a guideline. In the following sections we will
+discuss the relevant \textit{product quality} and \textit{quality in use}
+characteristics.
+
+\subsubsection{Product quality}
+Product quality is divided into eight main categories which are divided into
+several subcategories. Below we will discuss the qualities which are relevant
+to the SUT.
+\begin{itemize}
+ \item \textbf{Functional suitability}\\
+ As described in Section~\ref{sec:risks} the SUT is core functionality of
+ the networking capable system. Because many other systems running on the
+ system could rely on it it is very important that the SUT is functionality
+ suitable. Therefore all three sub characteristics of Functional
+ Suitability (\textit{Functional completeness, Functional correctness,
+ Functional appropriateness}) are of vital importance. As was previously
+ mentioned in Section~\ref{sec:risks} extra emphasis should be placed on
+ testing \emph{Functional Correctness} as recovery from Failures in
+ computer-to-computer systems is problematic.
+\end{itemize}
+
+\subsubsection{Quality in use}
+
+\subsection{Levels and types of testing} \label{levels}
+
+The client will deliver a product for certification. This means our team will only conduct acceptance testing and assume that the client who requested certification has conducted unit, module and integration testing. We will only be conducting black-box testing and the client is not required to handover any source-code. Initially we will conduct several basic test cases based on experience acquired from previous certification requests (error guessing). If the product fails these basic tests we reject it and seize all further activities. If the product is not rejected we will proceed with more thorough testing. For each test we produce a test report. If any of the test cases fail the product is still rejected but in order to deliver usable feedback to the client we will still produce a test report.
+
+\subsubsection{Test generation}
+
+The basic tests mentioned in section \ref{levels} are conducted using a checklist. If any of the checks fail we immediately reject the product.
+
+\begin{enumerate}
+ \item Is the product complete?
+ \item Does the product come with a manual or quick start guide?
+ \item Is it possible to get the product in a usable state?
+ \item Can we use the product to initiate a connection in a corruption free environment?
+ \item ....
+\end{enumerate}
+
+For the remaining tests we first use equivalence partitioning to reduce the overall number of test cases.
+
+\begin{enumerate}
+ \item Valid requests:
+ \begin{enumerate}
+ \item Single request.
+ \item Multiple requests.
+ \end{enumerate}
+ \item Invalid requests:
+ \begin{enumerate}
+ \item Single request.
+ \item Multiple requests.
+ \end{enumerate}
+\end{enumerate}
+
+For these requests we can introduce more cases using equivalence partitioning for the different packets that are sent during one request.
+
+\begin{enumerate}
+ \item Packets received in order.
+ \item Packets received out of order.
+\end{enumerate}
+
+For each individual packet we can specify the follow equivalent classes.
+
+\begin{enumerate}
+ \item Valid packet.
+ \item Corrupted packet.
+ \item Missing packets.
+\end{enumerate}
+
+We will test all possible combinations of requests/packet order/packet content. For each combination we will use boundary value analysis to reduce the total number of test cases. Boundary values are constructed using the following parameters:
+
+\begin{enumerate}
+ \item Checksum: valid/invalid
+ \item Header: valid/invalid
+ \item Payload: valid/invalid
+ \item ...
+\end{enumerate}
+
+\subsubsection{Test environment en automatization}
+
+All the tools we are going to use togetter with the SUT gives us the following collection of software.
+
+\begin{enumerate}
+ \item Windows, used as a host OS.
+ \item Linux, used as both a host and guest OS.
+ \item VirtualBox, used to run the guest OS containing the SUT.
+ \item Wireshark, used on the host in order to capture and analyze network traffic.
+ \item Bit-Twist, used to prepare network packets.
+\end{enumerate}
+
+All test will be conducted in a virtual environment. We will use VirtualBox to run a Linux distro with the product installed. All the different tests are performed either in VirtualBox (basic tests) or from the host system (transmission analysis). When testing network transmissions we will only analyze the packets received on the host system which originate from the product running in the virtual environment. The host system is disconnected from the Internet or any other network in order to prevent unnecessary traffic.
+
+For each test case (except for the basic tests) a file containing previously captured network traffic will be replayed using Wireshark. We will use Bit-Twist to update the prepared packets with the MAC address of the guest network adapter. The response packets coming from the guest OS will be recorded and analyzed at a later stage. The valid packets are obtained by capturing traffic between known working alternatives to the SUT. The invalid packets are generated from this valid traffic using Bit-Twist. The boundary values for the different parameters (fields in packets) are determined by hand.
+
+\begin{enumerate}
+ \item VirtualBox, https://www.virtualbox.org/
+ \item Whireshark, https://www.wireshark.org/
+ \item Bit-Twist, http://bittwist.sourceforge.net/
+\end{enumerate}
repositories / tt2015.git / blobdiff