Remove slides not covered for IntoToVerificContd, updated Overview of testing

Lectures/L30_IntroToVerificationContd/IntroToVerificationContd.tex

@@ -408,230 +408,4 @@ to an ``acceptable'' level
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\begin{frame}
-\frametitle{Dynamic Testing}
-\begin{itemize}
-\item \structure{Is there a dynamic testing technique that can guarantee
-    correctness?}
-\item \structure{If so, what is the technique?}
-\item \structure{Is this technique practical?}
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Dynamic Versus Static Testing}
-\begin{itemize}
-\item Another classification of verification techniques, as previously discussed
-\item Use a combination of dynamic and static testing
-\item Dynamic analysis
-\begin{itemize}
-\item Requires the program to be executed
-\item Test cases are run and results are checked against expected behaviour
-\item Exhaustive testing is the only dynamic technique that guarantees program
-validity
-\item Exhaustive testing is usually impractical or impossible
-\item Reduce number of test cases by finding criteria for choosing representative test cases
-\end{itemize}
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Static Testing Continued}
-\begin{itemize}
-\item Static analysis
-\begin{itemize}
-\item Does not involve program execution
-\item Testing techniques simulate the dynamic environment
-\item Includes syntax checking
-\item Generally static testing is used in the requirements and design stage, where there is no code to execute
-\item Document and code walkthroughs
-\item Document and code inspections
-\end{itemize}
-\end{itemize}
-\end{frame}
- 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Manual Versus Automated Testing}
-\begin{itemize}
-\item \structure{What is the difference between manual and automated testing?}
-\item \structure{What are the advantages of automated testing?}
-\item \structure{What is regression testing?}
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Manual Versus Automated Testing}
-\begin{itemize}
-\item Manual testing
-\begin{itemize}
-\item Has to be conducted by people
-\item Includes by-hand test cases, structured walkthroughs, code inspections
-\end{itemize}
-\item Automated testing
-\begin{itemize}
-\item The more automated the development process, the easier to automate testing
-\item Less reliance on people
-\item Necessary for \structure{regression testing}
-\item Test tools can assist, such as Junit, Cppunit, CuTest etc.
-\item Can be challenging to automate GUI tests
-\item Test suite for Maple has 2 000 000 test cases, run on 14 platforms, every
-  night, automated reporting
-\end{itemize}
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Automated Testing at MapleSoft}
-\begin{itemize}
-\item Three steps
-\begin{itemize}
-\item Write the problem description
-\item result := solver(problem)
-\item assert(result == expected)
-\end{itemize}
-\item Assert writes out code to reproduce any failures
-\item Track failures
-\begin{itemize}
-\item Source code management (like CVS or Subversion)
-\item Database of test cases, functions called
-\item Database of source files, functions defined
-\item Database of 40 days of timings and resources used
-\end{itemize}
-\item Automatically sends an e-mail to the programmer and his/her boss
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Continuous Integration Testing}
-\begin{itemize}
-\item \structure{What is continuous integration testing?}
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Continuous Integration Testing}
-\begin{itemize}
-\item Information available on
-  \href{https://en.wikipedia.org/wiki/Continuous_integration}{Wikipedia}
-\item Developers integrate their code into a shared repo frequently (multiple
-  times a day)
-\item Each integration is automatically accompanied by regression tests and
-  other build tasks
-\item Build server
-\bi
-\item Unit tests
-\item Integration tests
-\item Static analysis
-\item Profile performance
-\item Extract documentation
-\item Update project web-page
-\item Portability tests
-\item etc.
-\ei
-\item Avoids potentially extreme problems with integration when the baseline and
-  a developer's code greatly differ
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Continuous Integration Tools}
-\begin{itemize}
-\item Gitlab
-\bi
-\item Example at
-  \href{https://gitlab.cas.mcmaster.ca/andrem5/RogueReborn/pipelines}{Rogue
-    Reborn}
-\ei
-\item Jenkins
-\item Travis
-\item \href{https://www.docker.com/}{Docker}
-\bi
-\item Eliminates the ``it works on my machine'' problem
-\item Package dependencies with your apps
-\item A container for lightweight virtualization
-\item Not a full VM
-\ei
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Quality Testing: Installability}
-\begin{itemize}
-\item \structure{How might you test installability?} %virtual machines, docker
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Fault Testing}
-\begin{itemize}
-\item Common analogy involves planting fish in a lake to estimate the fish population
-\item T = total number of fish in the lake (to be estimated)
-\item N = fish stocked (marked) in the lake
-\item M = total number of fish caught in lake
-\item M' = number of marked fish caught
-\item T = (M - M')*N/M'
-\item Artificially seed faults, discover both seeded and new faults, estimate the total number of faults
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Fault Testing Continued}
-\begin{itemize}
-\item Method assumes that the real and seeded faults have the same distribution
-\item Hard to seed faults
-\begin{itemize}
-\item By hand (not a great idea)
-\item Independent testing by two groups and obtain the faults from one group for use by the other
-\end{itemize}
-\item Want most of the discovered faults to be seeded faults
-\item If many faults are found, this is a bad thing
-\item The probability of errors is proportional to the number of errors already found
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Fault Testing Usage Homework}
-After completion of a complex software project, two independent groups test
-it. The first group finds 300 errors and the second group finds 200 errors. A
-comparison of the errors discovered by the two teams shows that they found the
-same error in 50 cases. What is the range that estimates the number of errors in
-the original software project?
-
-% M1 = 300, M1'=50, N1 = 200, T1 = 1000
-% M2 = 200, M2'=50, N2 = 300, T2 = 900
-
-\be[A.]
-\item 900--1000 %answer
-\item -17--25
-\item 600--1500
-\item 0--150
-\item 150--250
-\ee
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \end{document}
\ No newline at end of file

Lectures/L31_OverviewOfTesting/OverviewOfTesting.tex

@@ -29,7 +29,7 @@
 \mode<presentation>{}
 
 \input{../def-beamer}
-\Drafttrue
+\Draftfalse
 
 \newcommand{\topicTitle}{31 Overview of Testing (Ch.\ 6)}
 \ifDraft
@@ -44,7 +44,8 @@
 
 \input{../footline}
 
-\lstset{language=java,breaklines=true,showspaces=false,showstringspaces=false,breakatwhitespace=true}
+\lstset{language=java, breaklines=true, showspaces=false,
+  showstringspaces=false, breakatwhitespace=true}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -80,13 +81,25 @@ TBD
 
 \item Today's slide are partially based on slides by Dr.\ Wassyng
 
-\item A4
+\item A3: Part 2 - Code: due 11:59 pm Mar 26
+
+\item A4: Due April 9 at 11:59 pm
+
+\item No classes on Thurs, Mar 29 or Fri, Mar 30
+\item Final tutorial (examination review)
 \bi
-\item Now available in our repo
-\item Your own design and specification
-\item Due April 3 at 11:59 pm
+\item Monday, Mar 26
+\item Tuesday, Mar 27
+\item Friday, Apr 6 (no tutorial on Fri, Mar 30)
 \ei
 
+\item Course Evaluation
+\bi
+\item \href{https://evals.mcmaster.ca}{https://evals.mcmaster.ca}
+\item Start: Tues, Mar 27, 10:00 am
+\item Close: Tues, Apr 10, 11:59 pm
+\item \emph{Grade bonus for class participation!}
+\ei
 \end{itemize}
 }
 \fi
@@ -326,6 +339,15 @@ validity
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Quality Testing: Installability}
+\begin{itemize}
+\item \structure{How might you test installability?} %virtual machines, docker
+\end{itemize}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}
 \frametitle{Fault Testing}
 \begin{itemize}
@@ -359,7 +381,7 @@ validity
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{Fault Testing Usage Homework}
+\frametitle{Exam Question: Homework}
 After completion of a complex software project, two independent groups test
 it. The first group finds 300 errors and the second group finds 200 errors. A
 comparison of the errors discovered by the two teams shows that they found the