Simplify J2EE-based projects using Rational Tools Part 1: Test Software

This article demonstrates the series of Rational tools used in distributed, J2EE-based projects.Article(As listed below.

• Part 1: Project Introduction and high-level planning
• Part 1: risk management and demand management
• Part 1: model creation and access control; Requirement Analysis
• Part 1: Refined use cases, production reports, and selection of tools and technologies
• Part 1: architecture and design
• Part 1: Detailed design; early development; Bidirectional Engineering; early Unit Testing
• Part 1: Continue development; early build; Demonstration
• Part 1: unit test policy; function test; GUI test script
• Part 1: system construction and testing; defect tracking; Product Delivery
• Part 1: project completion; Conclusion; Future Work

In this article, we are a fictitious software company lookoff technologies inreceivated. Our customer audiophile speaker design, Inc. (ASDI) hired us to fulfill their initial it needs. For more information, see section 1st.

This article is part 1 of this series of articles. This article discusses in detail the topics of testing described in part 1 of this series. In Part 1 of the article, we saw that in early development, we began to use rational purify and rational quanify to check memory usage and performance bottlenecks. We also discussed many details about our early unit testing work. This article will describe the progress of these jobs and review our automated testing capabilities using Rational testing tools to reduce testing costs, primarily the use of rational purecoverage and rational robot. At this stage of the project, we focus mainly on functional testing (including GUI testing), although we have also been engaged in some early load testing.

Note that the Rational Unified Process (RUP) term used here reflects two different dimensions of the test: "unit testing" is carried out in the development phase of the software to be tested-at this time testing is targeted at the smallest testable software unit-while "function testing" and "load testing ""is targeted at specific test targets, no matter which development stage of the software to be tested. Most of the unit testing content discussed in this article can also be applied to the testing work in the development phase following us (for example, merging different components or subsystems during integration testing ).

Part 1 snapshots

The tools and technologies demonstrated in part 1 are as follows: Rational purecoverage-Used for analysis during unit testingCode(Number of times the code is executed) Rational Robot-Repeated automated recording and playback test scripts Rational Administrator-Used to create a project and use it with rational robot to associate the test script related to the project. Rational testmanager-Organize and manage tests and view test results Products created or updated: Robot test script-Created for execution of Automated Testing

Unit Test

During the development process, we found that our unit test work exceeded our development work because the application we are building has very complicated user interaction. Unit testing always requires a lot of work, and we may not have enough budget and time to execute a lot of unit testing work. We found that our GUI testing, including monotonous manual testing, especially slowed down our speed.

Although the 1st phase of the ASDI project is only a conceptual verification, we have a hard time to endure the obvious bugs in the system. Finding a balance between robust, reliable software, frequent integration, and fast demos is not easy. We defined the scope of the 1st phase project so that we had to perform more than one technical demonstration; the customer expected the demo to be a usable beta version of the system.

Here, we will take a look at the scope of our unit testing work, we can choose (or not) to use Automation capabilities, and we use rational purecoverage to determine the completeness of our testing.

Test Scope

The scope of unit testing-what, how many times, and when to test-is the basis for several variables, including:

• Software complexity
• Product Features and interfaces
• Whether the tested part is critical to the entire product
• Team's degree of tolerance for defects in Software

In terms of the number of code tests, we did not plan to perform a 100% code coverage test in our software in previous projects. Full coverage is very expensive and hard to achieve, because we have to manually check our code to determine which line of code is not covered by the test. Small changes to unit tests will require us to reinspect the Code to ensure that full coverage is maintained. However, thanks to rational purecoverage, we can easily achieve code coverage of nearly 100% in the ASDI Project (due to the project budget and scope, A small number of untested residues are allowed ). Purecoverage greatly simplifies the task of checking code coverage, which makes it easy to identify which part of the code has been or has not been tested.

As we mentioned in part 1 of this series, our unit testing work has almost started as early as the core software development itself. Most of our developers started writing unit tests shortly after they had a software unit that could be tested. They like to test the internal components of software when code is generated in their minds.

The execution of unit tests is always prior to system building; introducing simple defects that can be obviously eliminated through unit tests into a build version is unacceptable. Unit Tests are always executed before the code is checked for distribution. In addition, developers run their unit tests on a standardized basis to ensure that their regular changes do not disrupt the software. Our methods are not as radical as some software methods-such as extreme programming (XP ), in XP, unit test development is usually prior to code development-but we regard unit test as an important early step of software development.

Automation capability

Of course, there are some questions about how to perform tests, especially what tests should be automated. Developers who write "background" (non-Gui) code are lucky to be able to write automated tests, including Java-drivenProgram, Code stubs, and scripts. However, as we mentioned earlier, testing by GUI developers is more difficult.

For our non-Gui tests, we observe the habits of unit tests associated with each class; we write the driver code into class and report the success or failure. We try to use a testing framework that can automatically generate, manage, and run tests for us, such as the tools recommended by XP, but they will produce mixed results. Although the theory is good, these frameworks (including JUnit, for example) are not mature enough for our project purposes. However, our developers are confident that, if they have time to familiarize themselves with and improve these tools, these testing frameworks are very valuable to our unit tests. We may use these testing frameworks more in future projects. In our ASDI project, the use of XP may be too risky; on the contrary, we are more willing to accept XP's concepts and ideas in terms of control and risk reduction methods. You can find a lot of content related to XP ideas on the xprogramming.com website.

We didn't use rational testing tools to test non-Gui code, because we don't think they can reach a level that is low enough. For automated testing of our Gui-driven code, the rational testing tool is really outstanding. User Interface testing is very manual and interactive, and requires a large amount of content validation; rational testing tools make repeated tests easier and easier in a consistent and fast manner.

Code coverage

By using Rational purecoverage, We can significantly reduce the time we spend determining code coverage during our unit test execution-that is, which methods or code lines are executed or omitted. This tool allows us to observe the code coverage test we provide, and then decide whether to improve the test or test the Code through manual check.

In addition to C or C ++ applications, purecoverage also supports Java programs, it can be configured and run in the same way as quanloud (discussed in part 1 of this series ). This tool allows us to browse our unit tests; code coverage testing in two ways: using the coverage browser or the coverage FileView method of the specified file.

Using the coverage browser method (Figure 1), we can see the statistical summary of code coverage tests for each file (and directory) included in the unit test. These statistical tables include the number of calls to all methods, the number of times a method is accessed or missed, and the number of accessed or missing code lines.

Figure 1:Coverage Browser

(Click to enlarge)

We can double-click a method in the summary to enter the coverage FileView. Only the code lines in the method are accessed or missed. As shown in figure 2, the missing code lines are highlighted in red (the accessed code lines are marked in blue ).

Figure 2:Coverage FileView

(Click here to enlarge)

Function Testing

Functional testing verifies that the software works correctly based on the requirements defined in the use case. To ensure that we have tested all the requirements, we use rational robot and rational testmanager when designing and organizing our functional tests. (A Discussion on functional testing strategies for using robot can be found in the Robot User Guide .) Robot makes the test script easier to be recorded and then plays back the automated test. You can use robot to create two types of test scripts:

• Gui scriptRecord your user interface actions. during playback, it is like a window for users to operate the application's login and control programs. Some client tests-for example, ActiveX controls embedded in our web applications-require these scripts. This type of functional testing will be discussed in detail in the next section because GUI testing causes special problems.
• VU scriptsWhen you use it to track what kind of network information is sent and accepted at the package level, it detects your application. During playback, these scripts can be re-run without logging on to the application, which makes them run faster than gui scripts. We use the VU script for our command gateway non-Gui function tests and B2B load tests.

We should start creating our function testing set as early as possible because these tests are very valuable tools for the engineering team. It is sometimes difficult to implement a proper target with a test script before the code is distributed and checked, it may be because some parts of the Code and some components take more time to complete than other code and components, or because of integration and testing (I & T) the team is too slow to complete the test script in time. In one case, when the user interface is still changing, the test script has been completed. Some rework is necessary, but the appearance of changes is quite easy to integrate.

Once we have a strong set of functional tests, retesting the system will be very easy. In this way, when you need to re-test small system changes in later iterations, you will get a great deal of return, and you can ensure that the changes do not affect other code parts. We map our function test script to the use case so that we can immediately know which test should be run when the requirement associated with the given use case is modified.

Gui Testing

When non-Gui code developers Perform unit testing very efficiently, it is difficult for JSP/servlet developers to ensure the time progress. The sting of them is the process of testing the GUI domain, which includes repeated steps below:

1. Create test data in the database.
2. Log on to the application through a web browser.
3. Navigate to the page to be tested (a form to be filled ).
4. Fill in one or more fields on the page, depending on the specific test.
5. Click the appropriate button to submit the form.
6. Check results.
7. Return to Step 4 using different tests (different domain values or different domains) until all reasonable combinations are tested.

Some GUI tests are particularly annoying, including Entering lengthy values in several domains at the same entry point. You can use cut and paste, but it is very trivial for the team to repeat these tests once and again. Some pages have 50 different tests that must be executed, and each test involves many steps.

Although we initially did not tend to use rational testing tools, we felt that the difficulty in Gui was a good reason for us to study rational testing tools in depth. We decided to use rational robot to automate most of our GUI tests. We adjusted these tests in the following ways:

• Developers draft a unit test description for each test.
• Junior integration and test team members accept unit test instructions and create test scripts based on the current software build version.
• Unit test scripts can be configured and managed so that changes to test scripts can be tracked.
• On a regular basis, a developer executes unit test scripts for the integration and testing teams and provides a report indicating the success or failure according to the unit test instructions.

This method works very well. It not only gives the integration and testing teams more work in the early stages of the development process without many things, they are also given the opportunity to understand the entire software system by revealing unit test instructions. In addition, our experience in using robot for GUI testing also prepares other functional testing scripts for Alibaba.

When rational robot is started, it requires an existing project (created using Rational administrator) and the test script will be associated with this project. In our example, the project must be located on the network, so that we can share the project database across the team. We created an ASDI project in administrator, as shown in Figure 3. When the robot prompts us to select a project, we chose this project.

Figure 3:Use rational administrator to create a project

Example of a verification test

As a simple example of GUI testing, we need to confirm thatPartsearch. jspFor the page, client verification is correct. The page executes Javascript code to verify their domain. For each ASDI condition, some numbers are input to the entire page. For example, they must be integer numbers greater than 0. If a user inputs an invalid number, javaScript code reports an error and does not send bad data to the server. Our JavaScript code follows the sample code for form verification.Formchek. jsThe file has compiled our own verification code. If you use this code properly, a negative number is displayed in the window 4.

Figure 4:Proper partsearch. jsp page Verification

Create test script

We created a test script in the robot to test whether the verification of the number field shows the appropriate. First, the robot prompts us to provide a name for the script (figure 5 ).

Figure 5:Recording a New Gui script

After clicking OK, we are provided with a recording controller (Figure 6). Then, when the robot record our actions, we use our window-based application. In this example, we started Internet Explorer 5Partsearch. jspBrowse the page, enter a bad number (-123456), and click the submit button on the page.

Figure 6:Robot recording Controller

Robot records our actions in a GUI script (figure 7 ). This is a very simple example; our actual test will include more complex test scripts. Instead of creating hundreds of independent scripts, we try to design a large script for each screen interface. The robot article contains detailed information for testing and design. We can get a lot of reference from the content recommended in the robot document.

Figure 7:Simple robot GUI script

(Click to enlarge)

By using easy-to-read and easy-to-edit scripts, we do not have to record the test scripts for repeated tests. Sometimes we can directly edit the test script without re-running the test, or record a small part of the test and paste it into an existing script.

Run the test

To run the test again, we simply click the play button on the recording controller of the robot (or select playback from the File menu. The script plays back our test operations just as we initially executed the test, and when the script is completed, rational testmanager is started to summarize our test results. For the simple example above, the result shown in Figure 8 shows that the test script runs successfully.

Figure 8:Testmanager reports that the robot test has passed

(Click to enlarge)

Suppose we want to test the Code's error handling capability, for example, bad numbers are no longer captured-that is, there is no window indicating errors, our application will send the entire data to the servlet for query. When we re-run the GUI test through the playback script, the robot will capture the problem and write the result to the report (figure 9), including displaying that the test failed.

Figure 9:Testmanager reports robot test failure

(Click to enlarge)

Summary

When we started the ASDI project, we expected to use rational analysis and design tools instead of rational testing tools. We were surprised and pleased to see that we automated and improved our testing process by using Rational testing tools. These tools have a solid learning curve, but once we master the use of each of our tools, our integration and testing team's productivity will be greatly improved. In some cases, individual developers use tools such as rational purify, quanify, and purecoverage to supplement their unit test work. Other tools, such as rational robot, require the integration and testing team to have higher skills and put more attention.

Plan the future

The team must still undertake integration and testing tasks at the system level. Most of the unit testing work is assigned to developers, but we still need a more comprehensive and formal testing subsystem and the entire system. This means that we need formal build versions, final build documents, and important attention in integration and testing. Load Testing for specific purposes is only a small part of our testing work, but it is very important in the testing of the entire system. Fortunately, our test set has completed 95% and we are a little ahead of schedule, therefore, we can have some extra effort to focus on system testing to ensure high-quality first-stage system delivery.

Major Risks

Our risk list is very short at the moment. The customer's cooperation on the evolution system is not surprising, and our technical risks are very low. We are very grateful to the engineering team for their great progress.

Now we must final process our code development, perform system testing, identify any defects in the system, and deliver Phase I systems to customers as planned. It is usually difficult to package all the details in a timely manner when the team approaches the end of the main phase. If we want to avoid exceeding the plan, we need the system to have a small number of defects and be able to quickly correct any problems found during the test.

About the author Steven Franklin has a broad background in software design, architecture, and engineering processes. These experiences are often used in large distributed information management and control systems. He has been using Rational tools since 1997 and is primarily interested in XML, J2EE, wireless, and software engineering technologies. You can contact Steven through steve@sfranklin.net.