TUHH/software-testing
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Finish task 1

Browse Source
This commit is contained in:
Michael Chen 2022-05-04 19:56:23 +02:00
parent 67b7a04034
commit 5a4e12e7bd
No known key found for this signature in database
GPG Key ID: 1CBC7AA5671437BB
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
project_task_sheets/phase_02/project_phase02_tasks/Solution_Phase02_MichaelChen.tex
View File

@ -104,17 +104,21 @@
\item Which testing situations are suitable for the ISP approach? \item Which testing situations are suitable for the ISP approach?
\begin{answer} \begin{answer}
[TODO: Add answer here] ISP is suitable for complex functions that require extensive testing but it is infeasible to test even large parts of the entire input domain. In such scenarios ISP is a tool that can be used to systematically apply input selection from different functionally categories of inputs. Instead of blindly picking inputs ISP can help picking specific values that ideally trigger every possible scenario of errors and additionally it helps you to realize when enough tests were executed because the partitions are complete (of course the characteristics for partitioning have to be ideally complete).
\end{answer} \end{answer}
\item Name and briefly explain the two main strategies to model the input domain. What are their significant pros and cons? \item Name and briefly explain the two main strategies to model the input domain. What are their significant pros and cons?
\begin{answer} \begin{answer}
[TODO: Add answer here] \textbf{Interface-Based:} We extract characteristics from the input parameters without knowledge about the relation between input parameters. This allows for a rather easy and automatable identification of characteristics, however it does not incorporate any knowledge of the semantics of the test subject and might thus miss important cases where the functionality is dependent on the input combination.
\textbf{Functionality-Based:} Here we create characteristics from the behaviour of the program or the output values. This approach requires domain knowledge as well as knowledge of the semantics of the program which makes it reasonably harder to develop characteristics. Sometimes program specifications directly correspond to possible characteristics by specifying the wanted behaviour of programs which \textit{can} sometimes make it easy model the input domain and even develop the IDM in the earlier development stages because specifications are made before the program is implemented. This method is harder to automate because it requires domain knowledge, but it might yield more effective tests for the same reason (No-free-lunch theorem).
\end{answer} \end{answer}
\item Using the standard values that may be provided in the specifications is one way to select the actual test values from each partition block. Which other strategies can you consider to derive representative values from a given partition? Name and describe two of them. \item Using the standard values that may be provided in the specifications is one way to select the actual test values from each partition block. Which other strategies can you consider to derive representative values from a given partition? Name and describe two of them.
\begin{answer} \begin{answer}
[TODO: Add answer here] \textbf{Pair-wise:} With this strategy we have to select input values from each block and combine them with values from all other blocks. This ensures that most combinations of blocks are covered without having to test the absolute powerset of text values.
\textbf{Base-choice:} This method again incorporates domain knowledge to select a base block from each characteristic. The base test is then performed using choices form all base blocks for each characteristic and then performing tests for the other characteristics keeping a base block constant and modifying only the other blocks. This massively decreases the amount of test cases while increasing the selection effort (No-free-lunch theorem, similar to functionality-based IDM).
\end{answer} \end{answer}
\end{enumerate} \end{enumerate}