Third time job

I. Process of unit Testing

1, judge the function of the component: by defining the application's overall requirements, and then dividing the system into several objects, we need to be very clear about the basic function of the component. Therefore, the Java EE Unit test is actually part of the design process.
2, design component behavior: According to the process of processing, can be a formal or informal process to achieve the design of the component behavior, we can use UML or other document view to design the component behavior, so as to lay the foundation for testing components.
3. Write the Unit test program (or test case) to confirm the component behavior: At this stage, you should assume that the component's encoding is over and the component is working properly, we need to write a unit test program to determine whether its functionality is the same as the pre-defined function, and the test program needs to consider all normal and unexpected inputs. and the overflow that a particular method can produce.
4. Write the component and execute the test: First, create the class and its corresponding method identity, then traverse each test instance, write the code for it to pass, and return to the test. Continue this process until all instances pass. At this point, stop encoding.
5. Test alternatives: Consider other ways of component behavior, design more comprehensive input or other error conditions, write test cases to capture these conditions, and then modify the code to make the test pass.
6, the reorganization code: If necessary, at the end of the code to re-restructure and optimize, after the change, return unit test and confirm the test pass.
7. When a component has a new behavior, write a new test case: Every time a failure is found in the component. Write a test instance to repeat the failure, and then modify the component to ensure that the test instance passes. Similarly, when new requirements or existing requirements change, write or modify the test instance in response to this change, and then modify the code.
8. Code modification, return all tests: Every time the code is modified, all tests are returned to ensure that the code is not scrambled.

Ii. Basic methods of unit testing

The Unit test object is the smallest unit of software design-the module. Unit tests are based on a detailed set of descriptions, and unit tests should design test cases for all important control paths within the module in order to discover errors within the module. The Unit Test adopts white box test technology, and several modules in the system can be tested in parallel.
Unit Test Tasks
Unit test tasks include: 1 module interface test, 2 module local data structure test, 3 module boundary condition test, 4 module all independent execution path test, 5 module error handling path test.
Module interface testing is the basis of unit testing. Other tests make sense only if the data flows correctly into and out of the module. The following factors should be considered when testing the interface correctly:
1 The actual parameters of the input are the same as the number of formal parameters;
2 The actual parameters of the input match the attributes of the formal parameters;
3 The actual parameter of the input is consistent with the dimension of the formal parameter;
4 the number of actual parameters given when calling other modules is the same as the number of parameter of the module;
5 whether the properties of the actual parameters given to the other modules match the parameter attributes of the modulated module;
6 when the other modules are called, the dimensions of the actual parameters are consistent with the shape parameters of the modulated modules;
7 The number, attributes, and order of the parameters used when invoking the predefined function;
8 whether there are parameter references unrelated to the current entry point;
9 If the read-only parameter is modified;
10 the definition of the whole variable is the same as each module;
11 whether to pass some constraints as parameters.
If you include external input and output within the module, you should also consider the following factors:
1 file attributes are correct;
2 Open/close statement is correct;
3 format description and input and output statements are matched;
4 The buffer size matches the record length;
5 whether the file has been opened before use;
6 Whether the end of the file is processed;
7 the input/output error is handled;
8 whether there is a textual error in the output information;
The local data structure is checked to ensure that the information stored temporarily in the module is complete and correct during the execution of the program. Local data structures are often the source of errors, and test cases should be carefully designed to uncover the following types of errors:
1 inappropriate or incompatible type descriptions;
2 variables have no initial value;
3 variable initialization or missing value error;
4 incorrect variable name (misspelled or improperly truncated);
5 overflow, underflow, and address exceptions occur.
In addition to local data structures, when possible, unit tests should also identify the effects of global data (such as Fortran's common areas) on the module.
Each independent execution path should be tested in the module, and the basic task of unit testing is to ensure that each statement in the module is executed at least once. The test case is designed to discover errors caused by incorrect calculations, incorrect comparisons, and inappropriate control flows. Basic path testing and cyclic testing are the most commonly used and most effective test techniques at this point. Common errors in the calculation include:
1 misunderstanding or using the wrong operator priority;
2 mixed type operation;
3 variable initial value error;
4 accuracy is not enough;
5 expression symbol is wrong.
Comparative judgments are often closely related to control flows, and test cases should also focus on finding the following errors:
1 comparisons between objects of different data types;
2 The use of logical operators or precedence in error;
3 Because of the limitations of the computer, it is expected that the equivalent of two is equal in theory and is not equal;
4 comparison operation or variable error;
5 cyclic termination conditions or impossibility to appear;
6 The iteration divergence cannot exit;
7 modified the loop variable incorrectly.
A good design should be able to anticipate all kinds of error conditions, and preset a variety of error handling pathways, error handling pathways also need to be carefully tested, testing should focus on the following issues:
1 output error information is difficult to understand;
2 The errors recorded do not correspond to the actual errors encountered;
3 The system has intervened before the program's custom error-handling segment is run;
4 improper handling of abnormal;
The 5 Error statement failed to provide sufficient positional error information.
Boundary condition testing is the last and most important task in unit testing. As is known to all, software often fails on the boundary, using boundary value analysis technology, for the boundary value and its left and right design test cases, it is likely to find new errors.

Three, unit testing process

New JUnit Test Case:JunitTest001.java

1 package JunitTestSample001; 2  3 import junit.framework.TestCase; 4  5 import org.junit.After; 6 import org.junit.Before; 7 Import Org.junit.Te St 8  9 Import testsample001.check;10 public class JunitTest001 extends TestCase {     @Before14 public     void S Etup () throws Exception {         super.setup ();     }17     @After19 public     void TearDown () throws Exception {         Super.teardown ();     }22     @Test24 public     void Testsearchresult () {+/         /fail ("not yet Implemented ");         Check cooner = new Check ();         Cooner. Connectoracle ("1");         assertequals ("Query results Match case", "Security code exists!") ", Cooner. Connectoracle ("1"));     }31}

Running Junittest001.java (run As-junit test) results in the following:

Third time job