DELTA 114 119 258 SVN j#j: Test Plan} \author{Andrew La Motte-Mitchell} \date{\svnToday} \newcommand{\test}[3]{\noindent \textbf{Test Number: }#1 \\ \textbf{Purpose: }#2 \\ \textbf{Description of Test: }#3} \begin{document} \svnInfo $Id$ \maketitle \section{Module Testing Overview} In this document, we will detail the test-plan for the \textsc{Synchronizer} module, whose design is specified in the document \emph{Cue: Personal Device Synchronizer}. This module is responsible for the manual and automatic synchronization of files between a device (such as a PDA or iPod) and a computer. We will provide a number of general acceptance tests, to verify that all required functionality has been achieved, and then we will give more detailed white-box tests that will thoroughly exercise the module. Because our architecture is highly modular, the \textsc{Synchronizer} component can be tested without the need for complex stubbing. In following sections, we will describe in greater detail the elements that must be stubbed. \section{Test Automation Framework} This module lends itself well to a data driven framework. We will prepare various dummy files and directories to simulate the contents of the computer database and the personal device. Then we will exercise our code on these data, and compare the output to our pre-prepared, expected output. No test case will be able to overwrite or modify input files, instead their output will be stored elsewhere, so each test-case operates on carefully manufactured data. This will ensure an isolated testing environment, which will allow us to effectively determine if each aspect of the \textsc{Synchronizer} is performing as desired. Each test case will compare the output given by our program to the expected output. If they are identical, the given test passes. Otherwise, an error will be reported that will not affect the rest of the test suite. At the end of the testing process, the user will receive a brief message announcing which test cases failed. A detailed test-report will be saved to file so that the user can decide to investigate the failed test-cases at her leisure. We will write a small program to run this test suite. Given the pre-prepared data, the user simply needs to execute this program, and each test case will run. As mentioned above, any failures will be reported in a brief summary and in detail. The detailed version should give the following information: \begin{itemize} \item Test case number, \item Input given, \item Expected output, and \item Actual output \begin{itemize} \item For large amounts of output, the test program will save the expected and actual output to file, and let the user examine the differences using a diff tool. \end{itemize} \end{itemize} \section{Elements to be Stubbed} There are basically only two components that the \textsc{Synchronizer} must interact with: the database and a generic device. We do not need to create a stub for each specific device that will be supported, since this functionality is handled in other modules\footnote{As detailed in the document \emph{Cue: Personal Device Synchronizer}, the synchronizer is implemented at a higher level of abstraction than the individual device drivers.}. Instead, we must create a stub that simulates the behavior of any generic device. Now we will specify exactly what each stub must be able to do. \begin{enumerate} \item[] The Database will provide: \begin{itemize} \item the ID for this computer - the number devices will use to determine acquaintance. \item a list of device model number that are supported (can be arbitrary, as long as one is the number of the generic device we are stubbing). \item a list of known devices that can be read and written to, We will need two copies available, one that is empty and one that includes the ID of the stubbed device. \item a change log, for the stubbed generic device, that can be either empty, or have a manufactured list of file names. \item the ability to \emph{access} files from the database. What we'll really do is prepare a few dummy files that we can return. No actual database is necessary. \item the ability to write files to the directory that stores dummy files, simulating a writable database. \end{itemize} \item[] The device will provide: \begin{itemize} \item the ID for this device - the number the computer will use to determine acquaintance. \item a list of known computers that can be read and written to. We will need two copies available, one that is empty, and one that includes the ID of the stubbed database. \item a change log, for the stubbed computer database, that can be empty, or have a manufactured list of file names. \item the ability to retrieve and save files to the simulated database, as described above. \\ \end{itemize} \end{enumerate} Given access to this information, the test cases listed below will be able to exercise the \textsc{Synchronizer} module without building the entire system. \section{Acceptance and Black-Box Tests} The following test cases are designed to validate the functionality that is specific to this module. We have derived the required functionality from the Component Specifications document, and our original requirements\footnote{This component changed during our design, so the initial requirements are somewhat out of date. Instead of concentrating on iPods only, this component can synchronize with an array of personal devices.}. Please note that we do not wish to test the entire \textsc{Personal Device Exporter} component, just the \textsc{Synchronizer}. As such, the tests in this document do not validate each requirement listed at the relatively high level of abstraction found in the Component Specification document, they only test those applicable to the \textsc{Synchronizer} module. \test{1} {Verify Requirement stupid} {kdls;a} \section{White Box Design Testing} In this section, we will enumerate the test cases that really exercise the module. The tests in the previous section were designed to ensure that this component functions as desired, the tests in this section identify weaknesses in our design, and attempt to find problems. \test{number} {} {} \end{document} ENDREP id: 1y.0.r115/6294 type: file pred: 1y.0.r114/675 count: 1 text: 115 0 6269 6413 42c4a930b6d4f012e3de594a61d9184b props: 114 633 29 0 ff5c3c1f7bdb48ba0201950780ae7e31 cpath: /project4/lamottemitchell/test_cases.tex copyroot: 0 / PLAIN K 9 index.txt V 18 file 1x.0.r114/432 K 14 test_cases.tex V 19 file 1y.0.r115/6294 END ENDREP id: 1w.0.r115/6624 type: dir pred: 1w.0.r114/983 count: 1 text: 115 6524 87 87 59a3ec535519059d60fc35aceaecbc45 cpath: /project4/lamottemitchell copyroot: 0 / PLAIN K 15 lamottemitchell V 18 dir 1w.0.r115/6624 END ENDREP id: 1v.0.r115/6846 type: dir pred: 1v.0.r114/1182 count: 1 text: 115 6784 49 49 e18df8343f4166b9986f8d73ddc9847d cpath: /project4 copyroot: 0 / PLAIN K 8 project2 V 16 dir x.0.r41/3433 K 8 project3 V 17 dir y.0.r113/5763 K 8 project4 V 18 dir 1v.0.r115/6846 END ENDREP id: 0.0.r115/7116 type: dir pred: 0.0.r114/1431 count: 115 text: 115 6991 112 112 2fceb37321eb4d85c2cd45647409e157 cpath: / copyroot: 0 / 1y.0.t114-1 modify true false /project4/lamottemitchell/test_cases.tex 7116 7255