{ Dominion - Test Plan Version 1 – 22 nd Apr Aravind Palanisami

 To test the dominion code and find the bugs.  To come out with a proper schedule to test.  Types of testing that will be tried on the code.  Tools that will be used.  Metrics to evaluate the testing approach.  Bug Reports.  Risks Goal

 Initial Dominion code was partly implemented.  Segmentation faults.  makeFile won’t work in Windows. So used Flop server and did things in Linux. I started with normal approach of writing some printf statements and identifying the places of fault. I started with normal approach of writing some printf statements and identifying the places of fault.  But it was very time consuming. So I thought of using Visual Studios. So I created a Console project in Visual Studios and added my files. So I thought of using Visual Studios. So I created a Console project in Visual Studios and added my files. Initial SetUp

 Once I added the files to Visual Studios, the compiler came up with many bugs. The compiler was pretty strict, it dint even allow declaration of variables in- between functions. So, I renamed my files to *.cpp and it worked!! So, I renamed my files to *.cpp and it worked!! There were setting in VS to set the command line arguments. There were setting in VS to set the command line arguments. Once the Visual Studios was set, I was able to use the debugger and identify the flow and the places where the segmentation faults occur. Once the Visual Studios was set, I was able to use the debugger and identify the flow and the places where the segmentation faults occur. Then I went on implementing code in the required places. Then I went on implementing code in the required places. Fight with VS2010

 Apr 24 – Finish complete implementation of the code.  Apr 30 – Make sure to read about every tool discussed and use some appropriate tool.  May 15 – Write some unit test cases for some core functionality and also set up the tool for testing.  May 25 – Finish the testing.  May 28 – Finish the Bug Reports.  June 5 – Buffer time for the above said tasks. Schedule

 Unit Testing – Unit test cases will be written to check specific functionalities of the system  Functional Testing – Will be achieved through unit test cases in our case.  Input Partitioning – To check for various types of inputs and make sure that the code is stable for all types of valid and invalid inputs.  Random Testing – Can be done if there are large number of test cases and if the coverage is randomized.  Black Box Testing – Testing the system without worrying about the inner implementation.  White Box Testing – Can test the code by making sure about the coverage etc. Types of Testing

 Valgrind for Segmentation faults.  Gcov for coverage (Code and Branch).  Thinking about using UNO for Static Analysis.  SPIN (Again planning to use, no idea how far I can go with this).  CBMC – The doc said this needs a Visual Studio install. As my programs are in VS, I am bit curious to use this.  Again, I am not finalized with the tool selection. I might update based on how it goes. Tools

 Breadth of functional coverage (Making sure most of the important functionalities are covered in the test cases.)  Percentage of paths, branches or conditions that were actually tested  Severity of Defects.  Number of Test cases executed  Number of Bugs found  Time for one test cycle. Metrics

 To maintain the caught bugs and keep track.  To store the information of the specific bug.  Sample Columns of a Report Bug Name, Bug ID, Severity,Priority,Assignedto, Reported By, Reported On, Steps to Reproduce, Defect Status Bug Reports

 Failure of testing tools.  Less branch Coverage.  Not enough test cases. Work Arounds:  Stronger Unit test cases or adding more test cases.  Changing the choice of tools.  Using the buffer time which was mentioned in the schedule. Risks

Thank you!!!