Merge branch 'master' of https://gitlab.cas.mcmaster.ca/yuens2/Blaze-Brigade

Doc/TestPlan/TestPlan.aux

+\relax 
+\providecommand\zref@newlabel[2]{}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces \bf  Revision History}}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {1}General Information}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Purpose}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Scope}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Acronyms, Abbreviations, and Symbols}{1}}
+\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces \textbf  {Table of Abbreviations}}}{1}}
+\newlabel{Table1}{{2}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}Overview of Document}{1}}
+\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces \textbf  {Table of Definitions}}}{2}}
+\newlabel{Table2}{{3}{2}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Plan}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Software Description}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Test Team}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Automated Testing Approach}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Testing Tools}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.5}Testing Schedule}{4}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}System Test Description}{5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Tests for Functional Requirements}{5}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.1}GUI}{5}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.2}Game Structure}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.3}Unit Movement}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.4}Unit Attacking}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.1.5}Unit Structure}{12}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Tests for Nonfunctional Requirements}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {3.2.1}Usability}{13}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Performance Requirements}{13}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Security Requirements}{14}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Tests for Proof of Concept}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Area of Testing1}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Area of Testing2}{15}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Comparison to Existing Implementation}{16}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}Unit Testing Plan}{16}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Unit testing of internal functions}{16}}
+\bibstyle{plainnat}
+\bibdata{SRS}
+\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Unit testing of output files}{17}}
+\@writefile{toc}{\contentsline {section}{\numberline {7}Appendix}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Symbolic Parameters}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Usability Survey Questions?}{18}}

Doc/TestPlan/TestPlan.lot

+\contentsline {table}{\numberline {1}{\ignorespaces \bf Revision History}}{1}
+\contentsline {table}{\numberline {2}{\ignorespaces \textbf {Table of Abbreviations}}}{1}
+\contentsline {table}{\numberline {3}{\ignorespaces \textbf {Table of Definitions}}}{2}

Doc/TestPlan/TestPlan.tex

@@ -90,8 +90,9 @@ Date 2 & 1.1 & Notes\\
 \section{General Information}
 
 \subsection{Purpose}
-
+The purpose of this project is to recreate a tactical, turn based game much like Fantasy Heroes. The game shall test the macro management skills of the user. The user will have a bunch of information to process in order to determine their course of action for their turn. The game will progress based on user inputs and decisions. However, software like this will involve a wide variety of test cases. The testing for this software will follow the Visual Studio Unit Testing Framework for all automated unit tests. This document will highlight most test cases the software will follow, and provide information on the unit testing framework.
 \subsection{Scope}
+Software such as what Blaze Brigade aims to recreate has a complex interaction with the user. Giving the user many options for each decision they make. This means that each one of those options much function properly. Actions such as moving, attacking, equipping a different weapon, et cetera. Each one of these actions will need a proper test case in order to ensure their proper functionality. Other test cases based on functional requirements include, unit properties, menu navigation, structural properties of the game, and handling user input. The non-functional requirements of this software project are based on usability, performance and security. Proper test cases will be orchestrated to fulfil these requirements as well.
 
 \subsection{Acronyms, Abbreviations, and Symbols}
 	
@@ -102,8 +103,17 @@ Date 2 & 1.1 & Notes\\
 \toprule
 \textbf{Abbreviation} & \textbf{Definition} \\
 \midrule
-Abbreviation1 & Definition1\\
-Abbreviation2 & Definition2\\
+HP & Health points\\
+
+Str & Strength\\
+
+Int & Intelligence\\
+
+Def & Defense\\
+
+Res & Resistance\\
+
+GUI & Graphical user interface.\\
 \bottomrule
 \end{tabularx}
 
@@ -116,15 +126,40 @@ Abbreviation2 & Definition2\\
 \toprule
 \textbf{Term} & \textbf{Definition}\\
 \midrule
-Term1 & Definition1\\
-Term2 & Definition2\\
+Unit & A movable character that the user will manipulate to defeat the opponents army.\\
+
+Class & A category of unit type. Different classes have different strengths and weaknesses.\\
+
+Stat & A numerical value that belongs to a unit. There are a variety of stats that make each class of unit unique.\\
+
+Health Points & A stat determining how much damage a unit can take before it dies.\\
+
+Strength &  A stat used in calculating physical damage dealt to opposing units.\\
+
+Intelligence & A stat used in calculating magical damage dealt to opposing units.\\
+
+Defense & A stat that lessens the amount of physical damage the unit takes.\\
+
+Resistance & A stat that lessens the amount of magic damage the unit takes.\\
+
+Skill & A stat that determines how skillful a unit is on the battlefield. Used to determine hit rate, and critical hit rate.\\
+
+Speed & A stat that determines how many times a unit will get to attack in combat.\\
+
+Graphical User Interface & A system that interacts with the user through visual representation.\\
+
+Hit Rate & The percent chance that unit A will successfully hit unit B.\\
+
+Critical Hit & Multiplies the damage of a units attack by 3.\\
+
+Critical Hit Rate & The percent chance that unit A will perform a critical hit on unit B.\\
 \bottomrule
 \end{tabularx}
 
 \end{table}
 
 \subsection{Overview of Document}
-
+This document will explain in depth what the plans for testing this project are, and provide a comparison to the existing implementation. In this document, a description for each test case is provided along with expected input and output for each case. This document will referenced by the team of this project when conducting any tests on developer code. A brief description of what automated testing is, and the groups chosen framework to simulate such automated tests. The document will also contain a comparison of the project to the existing implementation (a game called Fantasy Heroes). The goal of the comparison is to determine how much progress has been made, and if any changes are necessary for the scope of the project.
 \newpage
 
 \section{Plan}
@@ -567,8 +602,7 @@ For additional details, consult the \href{https://gitlab.cas.mcmaster.ca/yuens2/
 \newpage
 	
 \section{Comparison to Existing Implementation}	
-
-\newpage
+The final product of Blaze Brigade is supposed to be a turn based, strategy, role playing game. Blaze Brigade is based on a previous implementation of this style of game called Fantasy Heroes. It is important that this project is compared to it's previous implementation in order to determine the future of the project. Depending on the project's progress, there might need to be changes in the scope for the final product. This would mean that if there are some requirements that cant be met within the time constraint, then the scope could be narrowed. Fantasy Heroes helped derive a set of constraints for the project.The subsections of the functional requirements were named, GUI, Game Structure, Unit Movement, Unit Attacking, Combat Damage calculations. The requirements that belong to Unit Movement have been fulfilled, and this section is completed. The GUI section is nearly completed, and everything else still needs to be developed. Seeing that this much work has been made so far, most of requirements of the software will be fulfilled by the end product of this project. If other requirements seem like they are not worth the project's time, then they may be removed from the list of requirements in order to narrow the scope of the project. Comparing Blaze Brigade to Tactics Heroes at this is point shows that the project is becoming much like it was modelled to do by it's requirements.
 
 \section{Unit Testing Plan}
 
@@ -590,7 +624,8 @@ The only output file of the game is a window which comprises the visual represen
 
 \section{Appendix}
 
-This is where you can place additional information.
+
+
 
 \subsection{Symbolic Parameters}
 

Doc/TestPlan/TestPlan.toc

+\contentsline {section}{\numberline {1}General Information}{1}
+\contentsline {subsection}{\numberline {1.1}Purpose}{1}
+\contentsline {subsection}{\numberline {1.2}Scope}{1}
+\contentsline {subsection}{\numberline {1.3}Acronyms, Abbreviations, and Symbols}{1}
+\contentsline {subsection}{\numberline {1.4}Overview of Document}{1}
+\contentsline {section}{\numberline {2}Plan}{4}
+\contentsline {subsection}{\numberline {2.1}Software Description}{4}
+\contentsline {subsection}{\numberline {2.2}Test Team}{4}
+\contentsline {subsection}{\numberline {2.3}Automated Testing Approach}{4}
+\contentsline {subsection}{\numberline {2.4}Testing Tools}{4}
+\contentsline {subsection}{\numberline {2.5}Testing Schedule}{4}
+\contentsline {section}{\numberline {3}System Test Description}{5}
+\contentsline {subsection}{\numberline {3.1}Tests for Functional Requirements}{5}
+\contentsline {subsubsection}{\numberline {3.1.1}GUI}{5}
+\contentsline {subsubsection}{\numberline {3.1.2}Game Structure}{6}
+\contentsline {subsubsection}{\numberline {3.1.3}Unit Movement}{8}
+\contentsline {subsubsection}{\numberline {3.1.4}Unit Attacking}{9}
+\contentsline {subsubsection}{\numberline {3.1.5}Unit Structure}{12}
+\contentsline {subsection}{\numberline {3.2}Tests for Nonfunctional Requirements}{13}
+\contentsline {subsubsection}{\numberline {3.2.1}Usability}{13}
+\contentsline {subsection}{\numberline {3.3}Performance Requirements}{13}
+\contentsline {subsection}{\numberline {3.4}Security Requirements}{14}
+\contentsline {section}{\numberline {4}Tests for Proof of Concept}{15}
+\contentsline {subsection}{\numberline {4.1}Area of Testing1}{15}
+\contentsline {subsection}{\numberline {4.2}Area of Testing2}{15}
+\contentsline {section}{\numberline {5}Comparison to Existing Implementation}{16}
+\contentsline {section}{\numberline {6}Unit Testing Plan}{16}
+\contentsline {subsection}{\numberline {6.1}Unit testing of internal functions}{16}
+\contentsline {subsection}{\numberline {6.2}Unit testing of output files}{17}
+\contentsline {section}{\numberline {7}Appendix}{18}
+\contentsline {subsection}{\numberline {7.1}Symbolic Parameters}{18}
+\contentsline {subsection}{\numberline {7.2}Usability Survey Questions?}{18}