Non-functional requirmentsconstrain how such services
should be provided. They more involved in the quality of the product such as the safety of utilizing the software or how accurate it is. These tests ensure that the non-functional requirments of Gifitti are fufilled or the tests will allow the discovery of any requirments not satisfied by Gifitti.
Non-functional requirements constrain how the functional requirements and services should be provided. They are related to the quality of the product, such as the safety of utilizing the software or how accurate it is. These tests ensure that the non-functional requirements of Gifitti are fufilled.
\subsubsection{Look and Feel Requirements}
...
...
@@ -638,7 +637,7 @@ Input: GIF with number of frames on the magnitude of 100's of frames.
Output: Subsection of frames chosen to be exported.
How test will be performed: Create a timer inside the program to output the time it takes to output the files to a debug.txt file. The time should be
How test will be performed: Create a timer inside the program to output the time it takes to output the files, to a debug.txt file. The time should be
less than MAX\_EXPORT\_TIME.
\item{speed-02\\}
...
...
@@ -687,8 +686,7 @@ Input: GIF
Output: NA
How test will be performed: Export a subsection of frames the GIF to a foler. Try to export to the same folder again. The program should ask if you are okay with
overwriting the exisitng files.
How test will be performed: Export a subsection of frames from the GIF to a folder. Try to export to the same folder again. The program should ask if you are okay with overwriting the existing files.
\item{safety-02\\}
...
...
@@ -707,7 +705,7 @@ not continue the operation and inform the user that disk space needs to be clear
\section{Tests for Proof of Concept}
The proof of concept is a demonstration of the feasibility of the goal of the software project. Ensuring that the Proof on Concept is producing the intended results can only be achieved through tests specifically designed to root out any of the errors present in the build of the proof of concept. By successfully testing the proof of concept and achieving the intended goals it is shown that the software product is a possible product.
The proof of concept is a demonstration of the feasibility of the software project. Ensuring that the Proof on Concept is producing the intended results can only be achieved through tests specifically designed to root out any of the errors present in the build of the proof of concept. By successfully testing the proof of concept and achieving the intended goals, it is shown that the software-to-be is a possible entity.
\subsection{Opening a GIF file for playback}
...
...
@@ -721,7 +719,7 @@ Type: Manual Functional
Initial State: Program must be in normal state (form window is open and playback window is blank).
Input: File
Input: GIF File
Output: GIF is shown in playback window of the form.
...
...
@@ -765,16 +763,16 @@ How test will be performed: Click save frames button, select a folder, and verif
\end{enumerate}
\section{Unit Testing Plan}
The unit testing plan, is the devised set of tests code and system modules must undergo regardless of the system integration level. Unit testing allows the project to have white box testing on the individual system components, each unit test can be executed via testing frameworks in C Sharp.
The unit testing plan is the devised set of tests that the code and the system modules must undergo regardless of the system integration level. Unit testing allows the project to have white box testing on the individual system components where each unit test can be executed via testing frameworks in C Sharp.
\\
\\
The testing framework being ustilized is the native Visual Studio unit testing framework: Microsoft.VisualStudio.TestTools.UnitTesting.
The testing framework being utilized is the native Visual Studio unit testing framework: Microsoft.VisualStudio.TestTools.UnitTesting.
\subsection{Unit testing of internal functions}
Unit testing will be done on system methods that return a value, or modify known objects in an expected way. A metric for passing is to be used on all methods with an error tolerance, such as manipulation of a GIF (where slight variations can exist in files that present the same). A method with no expected error tolerance should be implemented as discreetly pass xor fail. All unit test inputs must fall in a known domain where the expected output can be assumed. No stubs will be required for unit testing of functions. Image reading is needed as a driver for any method using GIFs or other image types. Any written unit test must utilize the C Sharp attributes for Unit Testing provided by the framework. This ensures the system does not build the testing package into the consumer version of the software. We plan to have unit testing cover approximately 50 percent of our major methods due to project time constraints.
Unit testing will be done on system methods that return a value, or modify known objects in an expected way. A metric for passing is to be used on all methods with an error tolerance, such as manipulation of a GIF (where slight variations can exist in files that present the same). A method with no expected error tolerance should be implemented as discreetly pass XOR fail. All unit test inputs must fall in a known domain where the expected output can be assumed. No stubs will be required for unit testing of functions. Image reading is needed as a driver for any method using GIFs or other image types. Any written unit test must utilize the C Sharp attributes for Unit Testing provided by the framework. This ensures the system does not build the testing package into the consumer version of the software. We plan to have unit testing cover approximately 50 percent of our major methods due to project time constraints.
\subsection{Unit testing of output files}
To test the valdity of outputed GIF images the testing system will hold image resources of input frames, input GIFs, as well as the expected GIF outputted. A known GIF should be manipulated then compared to the expected GIF in a frame-by-frame matter. To exclude meta-data issues associated with GIF images, each frame should be cast to a known image format such as a bitmap, then compared pixel-by-pixel. Frames should have a 100 percent pixel match for the expected GIF to pass. A method for casting Frames to bitmaps then comparing the pixcels should be added to the testing package, prior to testing GIF manipulation. Simply verify this function by sending the same image as parameters.
To test the validity of outputted GIF images, the testing system will hold image resources of input frames, input GIFs, as well as the expected GIF outputted. A known GIF should be manipulated and then compared to the expected GIF in a frame-by-frame matter. To exclude meta-data issues associated with GIF images, each frame should be cast to a known image format such as a bitmap, then compared pixel-by-pixel. Frames should have a 100 percent pixel match for the expected GIF to pass. A method for casting Frames to bitmaps and then comparing the pixels, should be added to the testing package prior to testing GIF manipulation. This function can then be verified by simply sending the same image(s) as parameters.
\bibliographystyle{plainnat}
...
...
@@ -791,11 +789,16 @@ to a focus group upon initial completion of the application.
The definition of the test cases will call for SYMBOLIC\_CONSTANTS.
Their values are defined in this section for easy maintenance.
\begin{enumerate}
\item MAX\_UI\_LOAD: 3 Seconds
\item MAX\_EXPORT\_TIME: 10 Seconds
\end{enumerate}
\subsection{Usability Survey Questions}
The survey will be deliverered in the same format as the Questionaire for User Interface Satisfaction. This
questionaire is composed of various questions pertaining to several sub categories on a 0-9 scale. This includes the screen,
terminology and system information, learning, and system capabilites. It also allows the user to list the most
positive and negative aspects of the program. The questionaire can be found at \href{http://garyperlman.com/quest/quest.cgi?form=QUIS}{garyperlman.com}
The survey will be deliverered in the same format as the Questionaire for User Interface Satisfaction. This
questionnaire is composed of various questions pertaining to several sub categories on a 0-9 scale. This includes the screen,
terminology and system information, learning, and system capabilities. It also allows the user to list the most
positive and negative aspects of the program. The questionnaire can be found at \href{http://garyperlman.com/quest/quest.cgi?form=QUIS}{garyperlman.com}
