diff options
| -rw-r--r-- | assignments/assignment1.tex | 14 |
1 files changed, 4 insertions, 10 deletions
diff --git a/assignments/assignment1.tex b/assignments/assignment1.tex index 13ccae5..9be82e2 100644 --- a/assignments/assignment1.tex +++ b/assignments/assignment1.tex @@ -36,7 +36,7 @@ The chosen SUT is the \texttt{chesshs} Haskell package. \cite{SUT} It should be able to run in any software environment and hardware platform which supports Haskell. The latest version of the SUT, since the 13\textsuperscript{th} of March 2015, is \texttt{0.2.1}. -\subsubsection*{Executing/Running the SUT} +\subsubsection*{Executing/Running the SUT}\label{S:ERSUT} It is required to be able to compile Haskell, typically through the Glasgow Haskell Compiler (GHC), @@ -199,7 +199,7 @@ The majority of our test generation techniques are based upon or similar to blac \subparagraph{Black Box Techniques} -The focus of the black box testing is on the SUT in its entirety, that is, the \texttt{chesshs} package surrounded by the wrapper. The black box tester will try to find faults in the input-output behavior of the program as described in \S\ref{P:ERSUT}. In this type, test generation is based on error guessing and an examples database. +The focus of the black box testing is on the SUT in its entirety, that is, the \texttt{chesshs} package surrounded by the wrapper. The black box tester will try to find faults in the input-output behavior of the program as described in \S\ref{S:ERSUT}. In this type, test generation is based on error guessing and an examples database. Error guessing is based mostly on our collective experience of developing and testing software in the past. But also somewhat on our experience with the game of Chess and using other similar SUTs. @@ -211,17 +211,11 @@ Sadly, equivalence partitioning and boundary value analysis are hard to apply to \subparagraph{White Box Techniques} -The focus of the white box testing is on the \texttt{chesshs} package only, that is, the components of the library. The white box tester will try to find faults in the implementation of the package with regards to its specification. In this type, test generation is based on statement coverage and manual path based coverage. - -Statement coverage, in Haskell's case, marks the lines of code that have been executed at least once. - -Path based coverage analysis is not included in the testing tools used. To compensate, we will measure path based coverage manually. By hand, the implementation is transformed into a control flow graph, and we manually determine how the test cases ``traverse" the code. - -We will continuously adapt the white box tester until it reaches a sufficient level of coverage, that is full coverage, unless achieving so is unfeasible or unreasonable. +The focus of the white box testing is on the \texttt{chesshs} package only, that is, the components of the library. The white box tester will try to find faults in the implementation of the package with regards to its specification. Sadly, path, branch and condition coverage are not included in the tools we will be using during the testing. Hence, it is substantially harder to implement these test generation techniques and will not be applied during our testing. \\ -As every software developer and tester knows, it is very hard, if not impossible, to completely test a given system. Noting that the risks surrounding our SUT are almost negligible (see \S\ref{P:ERSUT}), the pressure on the testing is not noticeable. However, we still feel the tests as described should give a more than sufficient scrutiny. The black box testing will likely find, if any, faults in the wrapper and the interaction with the \texttt{chesshs} package. The white box testing will likely find, if any, errors in the implementation of the library. +As every software developer and tester knows, it is very hard, if not impossible, to completely test a given system. Noting that the risks surrounding our SUT are almost negligible (see \S\ref{S:ERSUT}), the pressure on the testing is not noticeable. However, we still feel the tests as described should give a more than sufficient scrutiny. The black box testing will likely find, if any, faults in the wrapper and the interaction with the \texttt{chesshs} package. The white box testing will likely find, if any, errors in the implementation of the library. \subsection*{Test Environment} |