Jtest Tools Introduction and use Cases

1 Tools Introduction

1.1 Overview

For some time, the software development industry has been advocating for unit testing, programming standards execution, evaluation of indicators and design by contract (Designby contract) and other technologies. The implementation of these technologies can greatly improve software reliability and reduce development time and costs. But so far, with a complex and huge workload, only a handful of developers have been able to actually adopt them. Jtest implements automated solutions that eliminate barriers to Java Developer Technology applications and enable developers to successfully adopt these technologies. There are two key aspects to successfully developing reliable Java software: reducing the probability of error by implementing Java programming standards, and by thoroughly testing each newly written class to nip the error in the bud.

Jtest is the first automated Java Unit Testing tool. Jtest automatically tests any Java class or part without requiring you to write a test case, driver, or pile function. With a single click, Jtest automatically tests code constructs (White-box testing), tests code functionality (Black-box testing), maintains code integrity (regression testing), and static analysis (programming standard execution and metric metrics). Without complex settings, Jtest can immediately use and point out problems. If you use "design by contract" techniques to include descriptive information in your code, jtest can automatically establish and execute test cases to verify that a class's functionality conforms to its functional description.

Jtest can help you prevent errors, and its customizable static analysis features enable you to automate more than 240 software industry-approved programming standards, establish and execute any number of custom programming standards, and tailor them to fit specific projects and teams.

Advantage:

1) Make it possible to prevent code errors, resulting in significant cost savings and improved software quality and development efficiency

2) Enable unit testing, including white box, black box, and regression testing to be possible

3) Make code specification check and automatic correction possible

4) Encourage the development team to collaborate horizontally to prevent code errors

Characteristics:

1) Automatic code error prevention through simple clicks, including unit testing and code specification checks

2) Generate and execute JUnit unit test cases to check the code in real time

3) provides a quick way to perform black-box testing, model testing, and system testing

4) identify and block non-trapping exceptions, function errors, memory leaks, performance issues, security weaknesses in your code

5) Monitoring the coverage of the test

6) automatically perform regression testing

7) Support DBC Coding specification

8) Inspection of more than 350 development specifications from Java experts

9) Automatically correct errors that violate more than 160 code codes

10) allows the user to customize the encoding specification graphically or in the form of automatic creation

11) Support the sharing of test settings and test files in large team development

12) Implementation and Eclipseide security integration

1.2 Working principle

Jtest improves code reliability by automating unit testing and code standard validation for Java. Jtest analyzes each Java class first, then automatically generates test cases and executes the use cases to maximize the coverage of the code and exposes exceptions that are unhandled when the code is run, and it can also examine the correctness of the code developed in the DBC (Designby Contract) specification. Users can also add more use cases by extending the automatic generator of test cases. Jtest can also check and automatically correct deviations on most common coding rules based on the existing 350 coding standards, and users can customize these standards to prevent code problems like unhandled exceptions, function errors, memory leaks, performance problems, and security concerns with a few simple clicks.

1.3 Basic Concepts 1.3.1 Unit Test

Developers often treat unit tests as module tests. Usually a module is a part of a large application, such as an application module or a subroutine. Here we make a difference, the unit tests we refer to are for basic units or parts in an application; in Java, a class is tested. 1.3.2 jtest white box test

Jtest's patented Test generation system (patent#5,784,553 & #5, 761,408) provides developers with a time-saving and effective method for white-box testing. Jtest fully automates white-box testing by automating the generation and execution of test cases that fully test class code. Jtest executes the class using a symbolic virtual machine and searches for an uncaught runtime exception. For each uncaught run-time exception that is detected, Jtest reports an error and provides the stack track and call sequence that caused the error. Jtest's advanced technology ensures that it can automatically test all the code branches of a class, thus thoroughly examining the structure of the class being tested.

In other words, Jtest automatically generates high-quality sets of test cases, discovering as many structural errors as possible, and:

· Users are not required to write a little test script language or test case.

· Users are not required to write test drivers.

· The source code is not modified.

· Does not require a complete application.

Jtest reports the following uncaught run-time Exceptions:

· Ways to behave incorrectly: these methods do not produce an exception for some specific input. You must modify the code.

· Unexpected parameter: This problem occurs when a method encounters an unexpected input (without knowing any processing) and produces an exception. These problems can be corrected by checking the input and generating a illegalargumentexception (IAE) (if the input is illegal). Correcting such problems can make the code clearer and easier to maintain.

· The correct way to behave: At this point, the correct output of the method is to produce an exception. In this case, it is recommended that the developer modify the code to place the generation of such exceptions in the throw clause of the method. This gets clearer code and is easy to maintain.

· Methods used only by developers: In this case, these methods are "not assumed" to process jtest generated input, and the developer is the only consumer of these methods, and these input parameters are not passed. The best way is to modify the code so that it produces a iae. This brings additional benefits and makes the code easier to read.

In summary, Jtest can save developers a significant amount of time and prevent errors by performing automated white-box testing and prompting for these types of problems. Due to the ability to automate the various steps of white-box testing, Jtest is very practical for developers, and this comprehensive test can be performed frequently to ensure quality. Further, Jtest makes white-box testing more accurate and effective than manual testing by using test-generation system technology to generate test inputs.

White box (construction) test verifies that unexpected input to a class does not cause a program crash. To perform a white-box test, you need to design and execute test input based on the internal structure of the class, check for any possible use of the class that would cause the class to fail, and some programming flaws that could lead to more error-prone code. The key to the success of a white box test depends on the ability to test the input, whether the method of the class can be overridden as comprehensively as possible, and the input that causes the non-captured runtime exception to be found.

Preventing and detecting structural problems as early as possible is more critical to Java software development. In most languages, such as C and C + +, an illegal program operation often results in a sudden interruption of the program. Java provides a relatively simple mechanism to capture runtime exceptions and keep programs running, a mechanism designed to simplify the processing of systems and other service invocations. On the other hand, an illegal operation causes a run-time exception to actually indicate an error in the program. Catching them and getting the program to continue is usually more problematic than a sudden interruption in C + +. The problematic program will continue to run as if there were no problems, but it is very likely to enter a contradictory state and produce inaccurate results or destroy the resources it accesses.

While white-box testing is a key step in guaranteeing class and application quality, the difficulty of manual execution often discourages or quickie the developer. The effective execution of white-box testing requires that we be able to determine exactly what test cases are required to fully examine the tested class, which is too difficult for manual testing. Current research shows that typical companies test only 30% of the code they develop, while the remaining 70% are never tested. One reason is that it is difficult to write test cases that are capable of testing rarely executed paths or extreme conditions. For example, a typical 10,000-line code has about 100 million possible paths; it is impractical or almost impossible to manually write test inputs that perform all paths.

Jtest uses unique technology to fully automate the white box testing process. Jtest analyzes the internal structure of each class being tested, automatically designs and executes test cases that fully test the structure of the class, and then determines whether each test input produces an uncaught run-time exception. An error message is reported for each detected exception and provides a stack trace and a sequence of calls that cause the error.

1.3.3 jtest black box test

Using Jtest for black-box testing is easier (and more effective) than using any other tool. Jtest's patented technology automatically generates a set of core inputs by analyzing the bytecode of the class, which is carefully designed to reach the highest possible code coverage. Because the design goal of the auto-generated input is to override the method of the class, rather than validating its definition, users may need to add their own test cases. (This is understandable, the automatic technique is for grammar, and the machine does not understand the true intentions of people.) ）

User-defined input can be added directly to a tree-shaped test case where the node represents each parameter of the method or the constants and methods that can be stored in a global or local repository, where the input can be easily added to the parameters of any method. When the test is in progress, Jtest automatically executes all the inputs and displays the corresponding output in a simple tree representation. When an error occurs in a later functional or regression test test, Jtest automatically advertises the user.

Since jtest automatically generates a great set of core inputs, it greatly reduces the number of test cases that developers and testers need to build, and is able to override more code in the program-M.F.B. s than hand-crafted.

The black box (functional) test checks whether the behavior of a class conforms to its functional description. In order to perform a black-box test, you need to establish a set of input/output relationships that test whether the class's functional description is implemented accurately. At least one test case is required for each item in the description document, and it is best to test the various boundary conditions for each description. After the test cases are ready, you execute them and verify that the results are accurate.

If your class code contains descriptive information in contract design (DbC) format, jtest can fully automate the black-box testing process. If not, jtest can be easier and more effective than making black-box tests by hand.

DBC is a formalized method that uses annotations to add descriptive information to the code. Basically, a formal language that describes a software contract can be used to express code descriptions clearly. These contracts illustrate the need for:

· A condition (precondition) that must be satisfied before a method is called.

· A condition that must be satisfied after a method is called (a post condition).

· Assertions that must be satisfied in the execution of the description point.

Jtest reads the description information that is defined in the DBC language in the class code and then automatically develops test cases based on that information. Jtest Design the black box test case according to the following rules:

· If there is a post condition, jtest establishes a test case that verifies whether these conditions are met.

· If there is an assertion, Jtest establishes a test case that attempts to make the assertion fail.

· If there are invariant conditions (that is, all methods applied to the Class), Jtest establishes a test case that attempts to make the invariant condition fail.

· If there is a precondition, Jtest tries to find the input that can walk through all the paths in the pre-condition.

· If the other method called by the method being tested contains the pre-condition described, Jtest determines whether the method being tested can pass the disallowed value to another method.

For a detailed description of how jtest automatically establishes and executes validation class functional test cases and how DBC explains how to help jtest black-box testing, see "Automating Java Software and component testing with contract-based design methods".

If you do not use Dbc,jtest, you can also help you build black box test cases. You can use Jtest to automatically generate a set of test cases as the basis for a collection of black-box test cases and then extend them by joining your own test cases.

There are a number of ways to add test cases. For example:

· Type the input of the method directly in the tree node that represents each method parameter.

· Set global or local constants and methods, and then add to any method parameters.

· The JUnit-formatted test class is used as a test case.

If a class references an external resource, you can enter your own pile function or let jtest invoke the actual external method. When the test is run, Jtest uses any available pile function, automatically executes the input, and displays the output corresponding to these inputs in a tree-shaped representation. You can then observe the output and verify the results. Jtest can automatically notify when the description and regression test errors occur. 1.3.4 jtest regression test

Performing accurate regression testing is another necessary step to ensure software quality and reliability. Regression testing uses the same set of input and test parameters used in the previous tests to test the modified code, which is the only way to ensure that a class does not introduce a new error after modification or to check whether the error was successfully excluded. Each time a class is modified or used in a new environment, regression testing should be performed to ensure the integrity of the class.

Jtest regression testing allows you to perform regression testing at the class level, which means that you can run test cases earlier to monitor the integrity of your code. Jtest fully automates all steps related to regression testing. If the user does not specify the correct output, jtest is able to memorize the previous output and compare it at each test, and report an error when any output has changed. Of course, if the user specifies the correct output, Jtest uses these values as reference results during regression testing. To make automated regression testing as fast and accurate as possible, Jtest automatically saves all test inputs and settings when testing one or a set of classes, and then joins the tests into the Jtest menu options. As a result, the user needs to perform a regression test simply by selecting an appropriate test in the Test menu and pressing the Start button. You can also integrate batch mode jtest into Night-time builds to ensure that regression errors can be found and corrected in a timely manner.

　 1.3.5 Programming Standard

The Jtest programming standard can be divided into the following categories:

· Code not used

· Initialization

· Object-Oriented Programming

· Naming conventions

· Javadoc notes

· Transplant sex

· Optimization

· Useless information Recycling

· Threads and synchronization

· Ejb

· Class indicator

· Project Metrics

· Internationalization

· Safety

· Servlets

· Miscellaneous

In addition, Jtest includes a set of programming standards to help you use DBC to add descriptive information to your code. Each jtest programming standard has a level of severity of violations, the most likely to cause errors is level 1, and the weakest is level 5. By default, Jtest reports a level 1-3 violation of programming standards. You can turn on and off individual, one-level, or a class of programming standards. This customization capability allows jtest to better suit your team or project and reduce unnecessary information.

You can use Rulewizard to build and execute custom programming standards to suit your programming style, development team, and entire project. You design and modify programming standards ("rules") in rulewizard with graphical representation patterns. To establish a rule, simply click on the mouse, add rules to create a component in a flowchart-like representation, and make the necessary changes with a dialog box. No knowledge about parsing is required. When testing, Jtest treats custom standards just like built-in programming standards.

For example, if you find that you often misuse the assignment equals in the conditions of the IF statement (that is, if you should write if (a==b) and write if (a=b)), you can establish a programming standard to "avoid assigning an equal sign in the conditions of an if statement".

By providing a useful and adaptable way to achieve even the most complex and unique Java programming standards, Jtest helps you perform many software development experts believe to be the most effective software quality Assurance method: Error prevention or prevention. Preventing the introduction of as many errors as possible when writing code reduces the time, effort, and expense involved in discovering and correcting errors, and can greatly reduce the risk of some errors from being tested.

Jtest automatically measures the relevant metrics for classes and projects during static analysis. If any metric exceeds the preset "reasonable" range (which you can set), Jtest will report a static analysis violation that will explain the violation and report the exact location of the problem, and you can easily decide what to simplify and how to change it. Jtest provides a summary report of all metrics for each class and each project.

In addition, Jtest helps you track metrics across projects, save project metrics for each test, and graphically visualize changes to the following metrics in your project:

· The total number of bytes for all class files.

· The number of classes.

· The number of Java source files.

· Total number of code lines for the class

· The number of packages.

· The number of private classes.

· The number of protected classes.

· The number of public classes.

1.4 Instructions for use 1.4.1 Installation

1. In the Windows installation steps:

1) Double-click Jtest Self-extracting file Jtest_win32.exe

2) Follow the instructions to complete the installation

3) Replacement Rules

Will.. The rules under the \parasoft\jtest4.5\jrules are replaced by what we have set out. 1.4.2 Basic use of 1.4.2.1 jtest interface

Jtest interface is divided into Classtesting UI and project testing UI two kinds

1.4.2.2 Class testing UI MenuBar

The ClassName panel is used to specify the class to be tested, the tester or the choice or enter the specific location and name of the class to be tested. Recommended testers Use the Browse button to select a method for testing a class. The advantage of this is that when you select a test class, the work path is set in the root directory of the class package.

The test Progress panel Displays the following testing process and coverage information:

Staticanalysis: Displays the test process for static analysis. In the figure, "Numberof rulesanalyzed" represents the number of static analysis laws used.

Dynamicanalysis: Displays the test process for dynamic analysis.

Numberof Test Cases Executed: Shows the number of all test cases performed

Automatic shows the part that was automatically generated by jtest in the test case that was executed.

UserDefined user-defined part of the test case

Numberof outcome Comparisons: Shows the number of comparison test class results in black box and regression tests

Totalcoverage: Shows the cumulative test coverage achieved by jtest

Multi-conditionbranch shows the coverage of the reached compound condition branch

Method shows the coverage of the approach achieved

Constructor shows the coverage of the reached constructors

The errorfound panel is used to display error messages that Jtest found during testing and allows testers to perform a variety of actions to help understand and customize the results.

Staticanalysis Errors The number of errors found during static analysis

The name of the rule that is violated (the ID of the rule is displayed in parentheses), the information for the rule that is violated, to suppress the display of such information, or to view the relevant rule description, you need to right-click the node and select the appropriate command from the shortcut menu that appears. Wrong number of files/rows, right click on the node, from the Popup shortcut menu to select the appropriate action command, you can view or edit the relevant source code.

The Uncaught runtime Exception is the number of non-captured runtime exception errors found by jtest during dynamic analysis, and each non-captured runtime exception is followed by a complete stack trace, and the input of one case is also caused by this exception.

Stack track information, in order to view or edit the source code, you need to right click on this node, and then select the appropriate action command from the shortcut menu that appears (if the file and the number of rows information is missing, please recompile the class file according to debugging information)

; Define the input values for the test case, and for the automated test case, the input is thecalling sequence

For the user-defined case, it is the input for each variable.

Specification&regressionexception is the canonical error and regression error that jtest discovered when performing dynamic analysis. This column error is also found by comparing the results of a test case that is running at this time with the earlier run or a user-specified run.

Discovery of specifications and regression errors

; Define the input values for the test case, the input is thecalling sequence for the automated test case, and the input for each variable for the user-defined case.

1.4.2.3 Project testing Uimenu Bar

The controls panel allows testers to specify the basic parameters to be used during the engineering test, as well as the reporting base data for an engineering test .

Searchin: Indicates where Jtest started the test.

Filter-in: Tells Jtest to find and test only those classes that match the given expression. Use the ' * ' character to match 0 or more characters.

The results panel displays the error messages that Jtest found during an engineering test, and it also allows testers to perform a number of operations to help understand and customize the results.

1.4.3 Illustrative Examples

Publicclass SimpleClassTest1 {

/**

* Determine input, when input equals 0 or 9 o'clock, function output 0 when input equals 6 o'clock, function output 11,

* Output 8 for other cases;

**/

public static int Test (int input) {

switch (input) {

Case 0:

Case 9:

return 0;

Case 6:

return 11;

Default

return 8;

}

}

/**

* Determine the input of the two strings, the current string after the beginning of a start and contain the following string,

* The function returns TRUE, otherwise false is returned.

**/

public static Boolean Contains (Stringstr1,string str2)

{

for (int i=0;i<str2.length (); i++)

if (Str1.charat (i)!=str2.charat (i))

return false;

return true;

}

/**

* Add two integers to the input, and the function returns the result of its addition.

**/

public static int Add (int a,int b)

{

return a+b;

}

} 1.4.3.1 White box test

Steps:

1. Click on the Jtest program icon on the desktop

2. Open the classtesting UI

3. Press the browse button and navigate to the example program Simpleclasstest1.class

4. Click Start

1.

2.

5. After a little wait, jtest will be able to identify problems in the SIMPLECLASSTEST1 and report the problem to the Errors Found panel:

6. Go to the problem point and double click on the bug

7. How to view Jtest auto-generated use cases

Right-click in the Test Progress panel to enter the viewtest case option

Enter values manually

test of 1.4.3.2 black box

1. Add input to static method

Open the class button and open the dynamic analysis> Test casegeneration> User defined> Method Inputs in the pop-up classtest parameters window.

Then open Add, right click on intARG1, select Add Input Value, enter 16, press ENTER.

The same way, add int ARG2, enter its value to 28.

2. The steps to view and legalize user-defined input and output results are as follows:

Click the View button to open the Viewtest case window

Open User Defined test cases>method inputs> add> test Case 1.

Fully expand test Case 1

To assert that the input produces the correct result, right-click on the Outcomes node and select Set all Correct in the popup shortcut menu.

3. Increase the input of the object type

Open the class button and open the dynamic analysis> Test casegeneration> common in the Classtest parameters window that pops up

Right-click on input Repository and select Addmethod Item from the popup shortcut menu.

4. In the Addmethod window, add the method declaration:

In the Decl area of the window, enter: Java.util.VectorCreateVector ()

; Enter the method body in the blank space below the window:

Java.util.Vectorv = new Java.util.Vector ();

for (int i = 0; i < 5; i++) {

V.addelement (New Integer (i*2));

}

RETURNV;

Select the method to store the input option>save.

Select Option>quit to exit the Addmethod window.

If the input type of the program interface method used in the test is vector, it can be established directly using the Creatvector () method.

1.4.3.3 regression Test

In Jtest's projecttesting UI, testers are able to automatically test all class files contained in any directory, or jar files, zip files, and the entire process is simply a single click.

To give a simple example:

Open Jtest, click the Project button, click the Browse button in the pop-up projecttesing UI window, and navigate to the appropriate directory.

Click the Start button on the Project tools bar to start the test.

Popup Results after test

1.4.3.4 rule Settings

1. Use the Jrules folder under Jtest rule settings to overwrite your own native folder with the same name. Empty the Brules folder of your own machine, open the Jtest, and follow the figure below to set the embedded rules for jtest. To set the method: Click "Project" or "global" "Rules" on the jtest as needed, and select it in the popup dialog (pictured below).

2. In a directory that does not have a point open in the figure, if the number before its directory name does not appear, a minus sign (such as [5],[4],[2],[1]) indicates that the rule under it is selected.

3. If [1-1],[16-16],[10-10],[11-11], then all do not, that is, point empty.

4. Other [2-1],[10-2],[9-2] is selected as shown.

Note that the first line of the "Severity levelsenabled" under the selection, the current selection of the first three levels; "Built-inrules" is the number of "73-49"; "UserDefined Rules" is 144 , in short, to prevent the selection of the wrong, pay attention to the numbers in front of each title.

A Jtest and Development Tools integration: Open Jtest, select Ideintegration under the Tools menu to integrate with a variety of development tools so that you can call jtest directly in the development tools for testing. Just set the rules as described above.

Two If you are not integrating with development tools, we recommend that you use the project testing UI to run all your class files at once. Choose whether to use the Projecttesting UI or the class testing UI in the toolbar point "class" or "Project". Take Projecttesting UI as an example: Click the Toolbar "Project" or "global rules" to set the rules as described above, set the reference package path and the source file path separately in the Classpath and SourcePath shown in the following illustration. Click Browse to set the path of the class file to run in the popup dialog box. Click Start to run, you can click on the toolbar to generate a report after the reports.