1. Application of structural testing criteria 2. Features of application of testing criteria within OOP paradigm 3. Prepare report

Laboratory work N2 2 Subject "Software testing" Theme Testing by "white box" methods" 1 Work objective To make the acquaintance of methods of testing of program logics (by coverage methods), creation of formal description of testing results and providing testing session based on real example of program code. 2 Theoretical fundamentals In general software testing includes: - Formulation of test problem, - Test design, - Preparation of test, - Testing the tests, - Test session performance, - Analysis of testing sessions. Test design plays the main role in this process. There are a lot of approaches to design a test. The first is that a test is being designed based on or external requirements and specifications of a program and modules, or specifications of integration of programs and modules. In this case we consider a program as a "black box". The goal of this approach is to check that a program corresponds to the specifications. But we don't analyze program logics. The second approach is based on the analysis of program logic (strategy of "white box"). The idea is to check each path of each variants of algorithm performance. In this case we don't use external specifications of a program. Any approaches are not optimal. The first approach realization leads us to testing all possible combinations of initial values of input program parameters. But to finish such test fully is not possible, because there is an infinite set of initial values of the parameters. Therefore, we must estimate the maximum benefit from a test with comparison with the expenses to create a test. The benefit can be calculated as a possibility of error occurrence, when we perform a test. Of course if we predict that a program has errors. The expenses can be measured by time of test performance and costs of test preparation. The second approach also does not guarantee that if all possible paths of a program were realized, then a program has not an error. Because the performance of all paths in a test does not guarantee us that a program corresponds to a specification. Let us assume that we write a program to calculate a cube root. But in fact a program calculates a square root. Therefore, a program is wrong in spite of we have tested all possible paths of its performance. Next problem is lost paths. If a program satisfies a specification not fully (for example, it does not include special function to check negative values of input parameters of a program), then via testing we can not find out an error. At last, we have a problem that testing results depend on input values. Because testing path can be passed through on one data but can not be realized for another data. For example, we write the program to define the equality of three numbers via the following expression: IF(A+B+C)/3=A. It is right not for all values of A,B and C (we have the error when one value B or C more then A, but at the same time another value less than A ). Therefore, if we pay attention to testing the paths only, then we can not guarantee that we find a mistake of a program. Thus, full testing of a program is impossible. The strategy of testing is to decrease an incompleteness as far as possible. 2. Methods of 'white box' The principle of 'white box' testing characterizes by a degree of coverage of program logic (program code). 2.1.1 Method of operator coverage The goal is to perform each operator of a program at least one time. Let us discuss the sample on Figures 2.12.2. Samnle Figure 2.1 Figure 2.2 Here we can apply only one test to the program to cover the path ace. If input parameters are: A=2,B=0,X=3, then each operator is being performed once. But this criterion is bad. If in the first condition we replace "and" by "or" and in the second condition we replace " x>1 " by " x1,B=0},{A=2,X>1}. Therefore, it is necessary to perform the number of tests which is enough to realize the situations, where A>1,A1,B=0 and B=0 in the point a and A=2,A=2,X>1 and X1 in the point B. Tests satisfied to the criterion of covering of conditions and corresponded them paths are: a) A=2,B=0,X=4 ace ) A=1,B=1,X=0abd Table 2.3 - The testing results done by method of covering of conditions 2.4 Criteria of covering of decisions (conditions) The criterion of a covering of decisions/conditions requires such amount of tests when all possible results of each condition in the decision are being carried out at least once, all results of each decision are being carried out at least once and, control are being transferred to each input point at least once. There are two tests of this methods (see on Figure 2.1) a) A=2,B=0,X=4 ace b) A=1,B=1,X=0abd which are corresponded to the criterion of covering of decisions. This fact is a consequence of the problem, when one conditions hide another in the decisions. If the condition A>1 is false, the compiler may not check the condition B=0, because any results of the condition B=0, when the decision of ((A>1)&(B=0)), lead us to false value. Therefore, the disadvantage of the criterion is that it is impossible to apply the criterion to get all possible values of all possible conditions in a program. Other variant of realization of the sample is showed on Figure 2.3. The decisions of a program done by a series of conditions are divided into separate solutions and transitions. The most full coverage by tests can be done, when all possible results of each simple decision were being performed. Therefore, it is necessary to cover the paths: HILP (test I: A=2,B=0,X=4), HIMKT (test II A=3,B=1,X=0 ), HJKT (test III A=0,B=0,X=0 ), HJKR (test IV A=0,B=0,X=2 )... Having tested the algorithm on Figure 2.3, we see that the criteria of covering of conditions and decisions are not sensitive to the errors of the logical expressions. 2.5 Method of a combinatory covering of conditions. To solve the problem with error sensitiveness in logical expressions we use the criterion of the combinatory covering of conditions. It requires to create the number of tests when all possible combinations of results of a condition in each decision are being carried out at least once. The set of the tests, satisfying to criterion of a combinatory covering of conditions, satisfies as well to criteria of a covering of decisions, coverings of conditions and a covering of decisions/conditions According to this criterion for the sample we must prepare the following eight combinations: 1) A>1,B=0;2)A>1,B=0;3)A1,B=0;4)A1,B=0;5)A=2,X>1;6)A=2,X1; 7) A=2,X>1;8)A=2,X1. To test all these combinations it is not necessary to use all eight tests. In a fact, they can be covered by four tests: A=2,B=0,X=4{ covers 1,5}; A=2,B=1,X=1{ covers 2,8}; - A=0,5,B=0,X=2{ covers 3,6}; A=1,B=0,X=1{covers4,7}. Table 2.4 - The testing results done by method of a combinatory covering of conditions. 3 Task of laboratory work 1. As a basis for task performance to take the program code realised in laboratory work 1 according to task of the teacher. 2. As the program scheme to take the UML activity diagram and also the control graph, realized during performance of laboratory work 1 . 3. To designate by letters or figures the branches of algorithm on the control graph or on UML activity diagram. 4. To select the testing method, which is the most efficient to detect an error in a program: 4.1. Method of operator coverage; 4.2. Method of covering of decisions; 4.3. Method of covering of conditions; 4.4. Criterion of decisions; 4.5. Method of a combinatory covering of conditions. 5. To choose the paths of algorithm that must be checked by selected testing method. 6. To choose the tests, which allow You to cover fully the selected paths. 7. To test the program created by You. The results must be represented in a form of table (see Tables 2.1-2.4). 8. To prepare report. 4 Content of report 1. Title list. 2. Control graph or UML activity diagram with marked paths of algorithm. 3. Explanation of selection of testing method. 4. The list of paths and tests selected for testing session. 5. Table of testing results. 6. Summary: a) the amount of detected errors in the program; b) time of testing; c) which test allowed You to detect an error. Laboratory work 3 Subject Software testing" Theme Module Testing" PART 1. Module testing in JAVA. 1.1 Objectives To acquire with the methods and techniques of module testing based on real examples of a program code done by different programming languages such as Java, C\# and C++. 1.2 Theoretical fundamentals UNIT-testing has the following characteristics: - Unit-testing is the testing on the level separate modules, functions or classes. - The goal of unit testing is to detect located in a module defects (errors). - Unit testing is "white box" testing. - Unit testing requires to create around a module special environment. It allows us to find the following types of errors: - Mistakes in algorithms; - Errors of program coding. There are different approaches to unit testing in different programming studios: - Java-Junit; - C\#-NUnit; - C++-CppUnit; - PHP - PHPUnit - JavaScript - JQuery, Qunit. 1.2.1 The sample of JUnit application JUnit library simplifies and automates the process of test preparation. To demonstrate main features of JUnit Framework, let us consider and test a primitive class written on Java This class has two methods: a) to calculate a factorial and b) to calculate a sum of two numbers: public class MathFunc \{ private int variable; public MathFunc() variable =0; \} public MathFunc(int var) \{ variable = var; \} public int getVariable() \{ return variable; \} public void setVariable(int variable) \{ this.variable = variable; \} public long factorial() \{ long result =1; if (variable >1 ) for (int i=1;i -

t argument for text u -

s argument for swing ui public static void main(String] args) \{ if (( args.length ==0)(args[0].equals("-t") )) junit.textui.TestRunner.run(AllTests.suite()); else if (args[0].equals("'-s")) junit.swingui.TestRunner.run(AllTests.class); j public static Test suite() \{ TestSuite suite = new TestSuite("Test for MathFunc"); //\$UUnit-BEGIN\$ suite.addTestSuite(TestClass); //SUUIt-ENDS return suite; y j public void testFactorialPositive() MathFunc math = new MathFunc(5); assertEquals (120, math.factorial ()) public void testPlus() MathFunc math = new MathFunc(45); assertTrue (math.plus (123)==168 ); 1.2.2 Example of performance of tests via JUnit for Eclipse At the beginning, please add junit.jar to path of your project. Installation of Eclipse has JUnit in package org.junit already. To add JUnit in your project you must: 1. Create a project "JUnitTest" 2. Open page of setup of project path (in context menu of a project) and select menu item Properties > Java Build Path). 3. Switch to tab named Libraries. 4. Add junit.jar, storing in org. junit in catalog, as external JAR for your project. To see source code of JUnit, please add junitsrc.zip to junit.jar. The archieve of source code is palced in org.eclipse.jdt. Initial source code of connection is in src/ org.junit_3.8.1. When the project JUnitTest had an access to classes JUnit, we could start to write your first test. At first, we realize the test as sub-class TestCase. You can do it or using standard Wizard Class, or special Wizard Test Case. The algorithm of your actions is: 1. Open Wizard New (File > New > JUnit Test Case). 2. Input name of class of a test "TestFailure" (see in Figure 2.1): 3. Click on Finish to create class of test. Then we add the method of testing in class TestFailure. Quick approach to create test method can be realized by pattern named test. Please, input "test" and click Ctrl+Space to activate help, then select "test". Change the name of creating method on testFailure and invoke method failo. Also please change visibility modifier to open this test method. public void testFailure( { fail (0;} To perform TestFailure, please activate tool panel and select Run as and then JUnit Test. You can inspect the testing results in view of JUnit. This view shows the state and process in a progress - Figure. 2.2. View shows in real time the current state of test performance. Representation of JUnit has two tabs: one shows you the list of errors and another - the test elements as a tree.. You can activate via found error appropriate program code using double click on corresponding item in error protocol. Understanding JUnit as quick representation, please delete operator failo in method testFailure(), and perform a test again. You can do it or by double click on button Rerun on tool panel of view, or restart a program, which was started by item of context menu named Run. Figure 2.2 - Start a test If test was with a success then you can not see the view of JUnit. But indicator of a success shows a result on icon of JUnit, but status line shows the result of a test. To remind you, that you have re-started a test, the icon view changes by adding the symbol " ". - Test with a success. - Test with a success, but the content was changed till last time. Also you can: - perform a test in a project, in a folder or in a package - Select a project, package, or initial folder and start all tuned on tests by Run as > JUnit Test. This command finds all tests inside a project, initial folder or a package. - perform single method of test - Select method of test in Outline or Package Explorer and when you click on Run as > JUnit Test, selected method is being performed. If you want to transmit the parameters or set up settings for a test, you must open dialog named Launch Configuration. Select button Run... in drop-down menu Run on tools panel - Figure 2.3. Run Create, manage, and run configurations Create a configuration that will launch a Jurit test. Figure 2.3 - Starting a test performance In this dialog you can select performing test, its arguments, and its classpath. If error occurs please act as follows: 1. Double click on error item in protocol in view of Junit to open appropriate file in editor. 2. Set up a break point at the beginning of test method. 3. Select a variant of test and click on Debug As > JUnit Test in drop-down menu named Debug. In JUnit Wizard TestSuite helps you to create a test package. You can select a series of classes as parts of a package as follows: 1. Open a Wizard - click on New 2. Select item Java > JUnit > JUnit Test Suite and click on Next. 3. Input class name of your complex of tests (as default "All Tests") - Figure. 2.4. 4. Select classes as elements of your test package. Figure 2.4 - Creation of test package You can add or delete the classes from a package in two ways: - Manually if you edit file of a package. - By re-starting a Wizard and selecting new set of test classes. Remark: Wizard adds two labels, //\$JUn-BEGINS //SUnit-END\$, in the file of a package. They allow a wizard to change the elements of a package. We strongly don't recommend to edit the code placed between these labels. 1.3 Help infomation Hierarchy of JUnit classes: - java.lang.Object - org.junit.Assert - org.junit.Assume java.lang. Throwable (implements java.io.Serializable) java.lang.Error - java.lang.AssertionError - org.junit.ComparisonFailure - org.junit.'Test.None Annotation Type Hierarchy - org.junit. Test (implements java.lang.annotation.Annotation) - org.junit.Ignore (implements java.lang.annotation.Annotation) - org.junit.BeforeClass (implements java.lang.annotation.Annotation) - org.junit.Before (implements java.lang.annotation.Annotation) - org.junit.AfterClass (implements java.lang.annotation.Annotation) - org.junit.After (implements java.lang.annotation.Annotation) To check a correctness of performance of method in JUnit it is necessary to use group of methods Assert. They check conditions and if they are not satisfied, these methods mark a test as failed. Method Summary static assertarrayEquals (byte[] expecteds, byte[] actuals) Asserts that two byte void arrays are equal. static assertArrayEquals (char[] expecteds, char[] actuals) Asserts that two char void arrays are equal. statie assertArrayEquals [int[] expecteds, int[] actuals) Asserts that two int void arrays are equal. static assertarrayzquals(long[1 expecteds, long[] actuals) Asserts that two void long arrays are equal. static assertArrayzquals(java.lang.object[] expecteds, java.lang.object[] void actuals) Asserts that two object arrays are equal. static assertArrayEquals (short[] expecteds, short[] actuals) Asserts that two void short arrays are equal. static assertArrayEquals (java.lang.String message, byte[] expecteds, byte[] void actuals) Asserts that two byte arrays are equal. static assertArrayEquals (java.lang.String message, char[] expecteds, char[] void actuals) Asserts that two char arrays are equal. static assertArrayzquals [java.lang.string message, int[] expecteds, int[] void actuals) Asserts that two int arrays are equal. Asserts that two objects do not refer to the same object. static assertNull (java.lang.object object) Asserts that an object is null. void Function failo marks a test as failed. Please use it if you realize your own personal test and the result of this test was failed. 1.4 Task Based on previously created Java-program prepare using JUnit test classes and series of tests for each class of your Java-program. To form a series of tests please use the results reached in Laboratory work 2. Step 1. Create a project with test classes. Step 2. To be sure that all test data prepared during Laboratory work 2 were passed through with a success. ar 3. To add to test classes nethods assertTrue and/or assertFalse. Uar 4. To change Java-program by operators "try-catch" to repeat previously developed tests. 1.5 Requirements to report 1. Title. 2. Code of Java-program. 3. Code of test classes. 4. Results of testing as screen shots in Eclipse. 5. Conclusions (The defects were detected? What tests were failed? What is the best way of unit testing? A) using JUnit or B) using the mechanism of Try-Catch?). 1.6 Additional example of development of test classes Figure 2.5. Program Mathematical functions" a) b) Figure 2.6. Program Test classess