new setup for tests ordering
authorpimjager <pim@pimjager.nl>
Mon, 9 Nov 2015 21:07:25 +0000 (22:07 +0100)
committerpimjager <pim@pimjager.nl>
Mon, 9 Nov 2015 21:07:25 +0000 (22:07 +0100)
a2/1cases.tex
a2/todo.txt

index e418a81..d8825ed 100644 (file)
@@ -34,43 +34,34 @@ a feasible test suite the tests are divided into equivalence partitions. Below
 these partitions are given.
 
 \begin{enumerate}
-       \item Single valid request.
-       \item Single invalid request with.
-       \begin{enumerate}
-               \item Corrupted checksum.
-               \item Corrupted payload with.
+       \item \emph{Number of packets} in request\footnotemark
+               \footnotetext{A request is considered establishing a connection 
+               (handshake) and any n number of payloadpackts}
                \begin{enumerate}
-                       \item Oven number of bits flipped.
-                       \item Odd number of bits flipped.
+                       \item 0 payload packets
+                       \item 1 payload packet
+                       \item n=small payload packets
+                       \item n=big payload packets
                \end{enumerate}
-               \item Corrupted source address.
-               \item Corrupted destination address.
-       \end{enumerate}
-       \item Multiple valid requests received in order.
-       \item Multiple valid requests received out of order.
-       \item Mixed valid and invalid requests with.
-       \begin{enumerate}
-               \item Missing packets.
-               \item Corrupted checksum.
-               \item Corrupted payload with.
+       \item Correct or Incorrect \emph{source port}
+       \item Correct or Incorrect \emph{Destination port}
+       \item Bits flipped in \emph{Payload}
                \begin{enumerate}
-                       \item Oven number of bits flipped.
-                       \item Odd number of bits flipped.
+                       \item Correct payload
+                       \item Payload with even number of bits flipped
+                       \item Payload with odd number of bits flipped
                \end{enumerate}
-               \item Corrupted source address.
-               \item Corrupted destination address.
-       \end{enumerate}
+       \item Correct or Incorrect \emph{checksum}
+       \item Packets received in or out of order, or missing packets
 \end{enumerate}
 
-Above enumeration results in a total of $14$ test cases.
+\textbf{hier iets over waarom deze partities relevant zijn!}
 
-\vspace{3mm}
-\textbf{Hier daadwerkelijke test cases tabel}
-\vspace{3mm}
+Partitions 2 to 6 are tested using pairwise testing to keep the number of test
+cases feasible. The pairs are then all *except some where it does not make sense
+to do so) tested with the different request sizes of partition 1.
 
-To reduce the number of tests that need to be executed when testing the SUT and
-to construct a feasible test suite these tests are combined according
-to Table~(\textbf{referentie naar decision table}). 
+This is expressed in the table below.
 
 \vspace{3mm}
 \textbf{Hier daadwerkelijke decision tabel}
@@ -78,7 +69,6 @@ to Table~(\textbf{referentie naar decision table}).
 
 \subsection{Quality, completeness and coverage of tests}
 
-\subsubsection{Quality}
 The network packets used in testing are constructed from prerecorded, known to
 be correct, network traffic. These packets are then modified with well used and 
 field tested tools. Due to this the chance of errors in the test cases is quite
@@ -88,19 +78,20 @@ Therefore detected defects should only indicate there is a high chance that
 there is a fault in the SUT and can not result directly in the conclusion that
 there actually is one. 
 
-\subsubsection{Coverage}
+\bigskip
+
 Due to the nature of black-box testing coverage of the code in the 
 implementation of the SUT is unknown. However completeness of the tests over 
 the specification of the SUT can be assessed. 
 
-\subsubsection{Completeness}
+\bigskip
+
 Due to the clear and exhaustive specification of TCP the completeness of the 
 test suite can be clearly assessed. 
 
 As always, $100\%$ completeness is not feasible, therefore test cases are
 carefully selected to cover the most interesting parts of the TCP specification
-to ensure a test suite which covers at least \textbf{percentage}\% of the 
-specification.
+to ensure a test suite.
 
 To further decrease the number of tests needed test cases are divided into
 equivalence partitions and the combination of cases as described in 
index f5800df..42991eb 100644 (file)
@@ -26,7 +26,7 @@ Woensdag - lijst van testcases maken:
 - trace met nummers en dan boven de case zodat je kan refereren
 - daadwerkelijke output
 
-Pim - completeness
+Pim - completeness __DONE__
 - percentage weghalen en iets zinnigs zeggen over coverage en completeness
 - aangeven dat je alleen confidence krijgt en nooit zekerheid en aangeven hoevaak je moet herhalen