-
W. Spencer Smith authoredW. Spencer Smith authored
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
BlackBoxTesting.tex 12.42 KiB
%\documentclass[t,12pt,numbers,fleqn,handout]{beamer}
\documentclass[t,12pt,numbers,fleqn]{beamer}
\usepackage{pgfpages}
\usepackage{hyperref}
\hypersetup{colorlinks=true,
linkcolor=blue,
citecolor=blue,
filecolor=blue,
urlcolor=blue,
unicode=false}
\urlstyle{same}
\usepackage{hhline}
\usepackage{booktabs}
\usepackage{multirow}
\usepackage{multicol}
\usepackage{array}
\usepackage{listings}
\usepackage{amssymb}
\usepackage{amsmath}
\useoutertheme{split} %so the footline can be seen, without needing pgfpages
% \pgfpagesuselayout{resize to}[letterpaper,border
% shrink=5mm,landscape] %if this is uncommented, the hyperref links do not work
\mode<presentation>{}
\input{../def-beamer}
\newcommand{\topic}{34 Black Box Testing (Ch.\ 6)}
\input{../titlepage}
\begin{document}
\input{../footline}
\lstset{language=java, breaklines=true, showspaces=false,
showstringspaces=false, breakatwhitespace=true}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Black Box Testing}
\begin{itemize}
\item Administrative details
\item Black Box Testing
\begin{itemize}
\item Formal using PointT
\item Function tables
\end{itemize}
\item Testing boundary conditions
\item The oracle problem
\item Module testing
\item Integration testing
\item Testing OO and generic programs
\item Testing concurrent and real-time systems
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Administrative Details}
\begin{itemize}
\item Today's slide are partially based on slides by Dr.\ Wassyng
\item No tutorials next week
\item A4
\bi
\item Due April 3 at 11:59 pm
\ei
\item Course evaluations
\bi
\item CS 2ME3: 26\%
\item SE 2AA4: 35\%
\item \href{https://evals.mcmaster.ca/login.php}{https://evals.mcmaster.ca/}
\item Closes: 11:59 pm, Monday, April 10
\ei
% \item CAS poster and demo competition
% \bi
% \item April 6, 4 - 6 pm
% \item ITB/201 (tentative)
% \item 12 graduate student submissions
% \ei
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Black Box Testing Example}
The program receives as input a record describing an invoice. (A detailed
description of the format of the record is given.) The invoice must be inserted
into a file of invoices that is sorted by date. The invoice must be inserted in
the appropriate position: If other invoices exist in the file with the same
date, then the invoice should be inserted after the last one. Also, some
consistency checks must be performed: The program should verify whether the
customer is already in a corresponding file of customers, whether the customer's
data in the two files match, etc. \\
~\newline
{\structure{What test cases would satisfy the complete-coverage principle?}}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Invoice Example Test Cases}
\begin{enumerate}
\item An invoice whose date is the current date
\item An invoice whose date is before the current date (This might be even
forbidden by law) This case, in turn, can be split into the two following
subcases:
\begin{enumerate}
\item An invoice whose date is the same as that of some existing invoice
\item An invoice whose date does not exist in any previously recorded invoice
\end{enumerate}
\item Several incorrect invoices, checking different types of inconsistencies
\end{enumerate}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Systematic Black-Box Techniques}
\begin{itemize}
\item Testing driven by logic specifications
%\item Decision table based testing
\item Function table based testing
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Test Cases from MIS for PointT}
\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exceptions}\\
\hline
PointT & real, real & PointT & InvalidPointException\\
\hline
xcoord & ~ & real & ~\\
\hline
ycoord & ~ & real & ~\\
\hline
dist & PointT & real & ~\\
\hline
\end{tabular}
~\newline
$exc := ((\neg(0 \leq x \leq \mbox{Contants.MAX\_X}) \vee \neg(0 \leq y \leq \mbox{Constants.MAX\_Y})) \Rightarrow
\mbox{InvalidPointException})$
~\newline
\noindent dist($p$):
\begin{itemize}
\item output: $out := \sqrt{(\mathit{self}.xc - p.xc)^2 + (\mathit{self}.yc - p.yc)^2}$
\item exception: none
\end{itemize}
~\newline
\structure{What test cases do you recommend?}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[allowframebreaks]
\frametitle{TestPointT.java}
\lstset{language=java, breaklines=true, showspaces=false,
showstringspaces=false, breakatwhitespace=true}
\noindent \lstinputlisting{TestPointT.java}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Function Table-Based Testing}
\begin{itemize}
\item Boundaries are obvious in table predicates
\item Make test cases that exercise between and on boundaries
\item Coverage already aided by function table ``rules''
\end{itemize}
\includegraphics[scale=0.5]{../Figures/FunctionTableTestingNoPicture.png}
\uncover<1->{\structure{What test cases do you recommend?}}\\
\uncover<2->{\structure{What if you use the heuristic [-Large, -Normal,
Boundary-1, Boundary, Boundary+1, Normal, Large]?}}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Function Table-Based Testing}
\begin{itemize}
\item Boundaries are obvious in table predicates
\item Make test cases that exercise between and on boundaries
\item Coverage already aided by function table ``rules''
\end{itemize}
\includegraphics[scale=0.5]{../Figures/FunctionTableTesting.png}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Testing Boundary Conditions}
\begin{itemize}
\item Testing criteria partition input domain in classes, assuming that behavior
is ``similar'' for all data within a class
\item Some typical programming errors, however, just happen to be at the
boundary between different classes
\begin{itemize}
\item Off by one errors
\item $<$ instead of $\leq$
\item equals zero
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Criterion}
\begin{itemize}
\item After partitioning the input domain D into several classes, test the
program using input values not only ``inside'' the classes, but also at their
boundaries
\item This applies to both white-box and black-box techniques
\item In practice, use the different testing criteria in combinations
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{The Oracle Problem}
\structure{When might it be difficult to know the ``expected''
output/behaviour?}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{The Oracle Problem}
\begin{itemize}
\item Given input test cases that cover the domain, what are the expected
outputs?
\item Oracles are required at each stage of testing to tell us what the right
answer is
\item Black-box criteria are better than white-box for building test oracles
\item Automated test oracles are required for running large amounts of tests
\item Oracles are difficult to design - no universal recipe
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{The Oracle Problem Continued}
\begin{itemize}
\item Determining what the right answer should be is not always easy
\begin{itemize}
\item Air traffic control system
\item Concurrent system
\item Scientific computing
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{The Oracle Problem Continued}
\structure{What are some strategies we can use when we do not have a test
oracle?}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Strategies Without An Oracle}
\begin{itemize}
\item Using an indendent program to approximate the oracle (pseudo oracle)
\item Properties of the expected values can be easier than stating the expected
output
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Module Testing}
\structure{Is it possible to begin testing before all of the modules have been
implemented when there is a use relation between modules?}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Module Testing}
\begin{itemize}
\item Scaffolding needed to create the environment in which the module should be
tested
\item Stubs - a module used by the module under test
\item Driver - module activating the module under test
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Testing a Functional Module}
\includegraphics[scale=0.5]{../Figures/TestingAFunctModule.png}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Integration Testing}
\begin{itemize}
\item Big-bang approach
\begin{itemize}
\item First test individual modules in isolation
\item Then test integrated system
\end{itemize}
\item Incremental approach
\begin{itemize}
\item Modules are progressively integrated and tested
\item Can proceed both top-down and bottom-up according to the USES relation
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Integration Testing and USES relation}
\begin{itemize}
\item If integration and test proceed bottom-up only need drivers
\item Otherwise if we proceed top-down only stubs are needed
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Example}
\begin{center}
\includegraphics[scale=0.35]{../Figures/Example.png}
\end{center}
\begin{itemize}
\item $M_1$ USES $M_2$ and $M_2$ IS\_COMPOSED\_OF \{$M_{2,1}$, $M_{2,2}$\}
\item Case 1
\begin{itemize}
\item Test $M_1$ providing a stub for $M_2$ and a driver for $M_1$
\item Then provide an implementation for $M_{2,1}$ and a stub for $M_{2,2}$
\end{itemize}\item Case 2
\begin{itemize}
\item Implement $M_{2,2}$ and test it by using a driver
\item Implement $M_{2,1}$ and test the combination of $M_{2,1}$ and $M_{2,2}$
(i.e.\ $M_2$) by using a driver
\item Finally implement $M_1$ and test it with $M_2$ using a driver for $M_1$
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Testing OO and Generic Programs}
\begin{itemize}
\item New issues
\begin{itemize}
\item Inheritance
\item Genericity
\item Polymorphism
\item Dynamic binding
\end{itemize}
\item Open problems still exist
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Inheritance}
\includegraphics[scale=0.5]{../Figures/Inheritance.png}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{How to Test Classes of the Hierarchy}
\begin{center}
\includegraphics[scale=0.5]{../Figures/UsesRelation.png}
\end{center}
\begin{itemize}
\item ``Flattening'' the whole hierarchy and considering every class as totally
independent component
\item This does not exploit incrementality
\item Finding an ad-hoc way to take advantage of the hierarchy
\item Think about testing PointT.java and PointMassT.java
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{A Sample Strategy}
\begin{itemize}
\item A test that does not have to be repeated for any heir
\item A test that must be performed for heir class X and all of its further
heirs
\item A test that must be redone by applying the same input data, but verifying
that the output is not (or is) changed
\item A test that must be modified by adding other input parameters and
verifying that the the output changes accordingly
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{Testing Concurrent and Real-time Systems}
\begin{itemize}
\item Nondeterminism inherent in concurrency affects repeatability
\item For real-time systems, a test case consists not only of input data, but
also of the times when such data are supplied
\item Considerable care and detail when testing real-time systems
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}