Go Interface testing in Web Automation testing

1. Background

1.1 Interfaces in a Web program

1.1.1 Typical web Design architecture

The web is an application that implements network communication-based browser clients interacting with remote servers, typically consisting of two parts: a Web server and a Web client. The application of Web client is Html,javascript,ajax,flash and so on, the application of server side is very rich, such as Java servlet,jsp,ssh Framework,. NET ASPX, and other scripts such as PHP, Python.

The Web server-side design architecture has been more prevalent in recent years as a three-tier architecture (3-tier application), where the three-tier architecture typically divides business applications into: Presentation layer (UI), Business Logic Layer (BLL), data access Layer (DAL). The purpose of layering is to reduce code coupling and improve the maintainability of code architecture.

In general, the three-tier architecture has the following meanings:

1) Presentation layer (UI): User interface, i.e. user-visible operator interface or portal.

2) Business Logic Layer (BLL): Encapsulates an operation function that has business meaning.

3) Data access Layer (DAL): Encapsulates atomic operations on a database or other storage medium.

1.1.2 Concept of Web interface

A web interface is the way the server interacts with the client, the protocol that the browser or other client tools interact with the Web Services UI layer. There are two common categories, one is the interface between the browser and the server to interact with the HTTP protocol, another type of Web? Service interfaces such as SOAP,RMI,RPC protocols.

The HTTP interface request method commonly has get, post two types of requests. Features that have no connection and no state. HTTP requests such as Get? /images/logo.gif? http/1.1, which represents the request logo.gif this file from the/images directory.

1.2 Web Interface Automation

1.2.1 Web interface test

Web interface testing is a means of automating testing on the Web server's UI layer, which is to test the correctness of the Web service program's business logic from the user's perspective. The focus of the test is to check the correctness of the interface data around the interface exposed by the Web service, which uses the Web service program as a black box to improve test execution efficiency and reduce the cost of manual regression through automated testing techniques.

1.2.2 What to do interface test

This article illustrates the overall architectural features of Web applications based on HTTP interface, and develops projects according to this architecture, causing two problems:

First, system-level testing must wait until the Web server program and browser-side programs are developed before it can be done? Refer to the following Traditional Rd and QA collaborative project process, you can see that QA in the RD test program before actually entering the testing phase, then the project release cycle is naturally affected by this serial work arrangement, is the time period.

Second, in order to improve efficiency, the company's team introduced a system-level automated testing tools or solutions, since it is from the user's point of view to test, of course, it is hoped that from the simulation of user behavior instead of manual operation to test. For example, from the browser operation of the way to test, can very directly cover the user's hands, but need to think about, browser versions such as Ie6,7,8,chrome,firefox, each has its own characteristics, JavaScript in the browser performance is not the same, browser in different Windows environment, different network conditions, the situation is not the same, give QA a challenge: How to ensure that the browser automation case stable, efficient execution?

We first analyze the first problem, the project team needs to improve product release efficiency, advance QA test Intervention point in time, we can think of several scenarios:

1) QA follows Rd progress, adding to each level of code to participate in unit testing :

Assuming that we did not introduce the TDD pattern without introducing agility , the general solution is to submit a batch of the measured function code to the SVN after it has been written by Rd, then the QA update code takes more than 10 minutes to read the code and then to understand the business requirements and then spend more than 10 minutes writing Xunit case, consistent with the expected results of QA, and inconsistent with the need to spend time with RD communication reasons and so on. One QA takes more time to go deep into the code Logic of Rd, and the other for QA? Coding ability requirements are also very high, depending on the positioning of the company's QA personnel, is to require QA more familiar with the test design and code capability is the second, or the overall technical ability of QA is very high, generally speaking, most of the QA strengths lie in the business requirements of the familiar and test design capabilities, So this approach to the overall quality of the team's requirements is very high.

2) QA does not participate in the single test, RD according to the requirements of vertical splitting function points and then able measurement, QA can be in advance for a certain time to intervene in the test:

The process is illustrated by the following process, in fact, the traditional waterfall model has been split into a number of short-term "small waterfall model", which results in a long project cycle of products, can be early intervention testing to identify problems ahead of time.

In such an iterative process, how to make reasonable use of automated means to improve the efficiency of testing? Generally speaking, the iteration cycle will not be very long, the routine is 3-5 days a period, do too complex automation investment cost is higher. For Web systems, in order to avoid excessive automation investment, it is necessary to carefully judge the characteristics of the Web system for which automation mode. So here's a special focus on layered automated testing:

As mentioned, the web system can do several functional tests: unit testing, integration testing, system testing. Most product QA does not involve too much unit testing, concentrating on integration testing and system testing. Combined with the above mentioned iteration scheduling, in fact, the development of the middle-level UI in general projects tend to lag behind, the result of the rush is not high quality of the test. So one of the recommended patterns is that the UI interface divides the function points in the iteration cycle, and the UI development can be measured after the UI interface is stable. So in an iterative cycle, the automation of UI-oriented interfaces is a great opportunity to put the test in front of you and to accumulate automated case to replace manual operations when you return.

With this conclusion, the second question that is thrown at the beginning of this section, "Stability and reliability of system-level automation testing", is presented in the first few points:

1) There are some test points, from the system-level point of view to do the automation of low cost:

First: At present, the technical means do not have a low-cost means of implementation, such as Flash, JS implementation of some of the effects, not standardized HTML tags, the browser run version of the environment is not considered as a result of problems. resulting in high development costs and low operational stability.

Second: The UI implementation logic is thin, such as just querying the db a field and then displayed on the page, focus on the back-end logic check on the cost-effective higher.

2) The focus of system-level testing and integration testing is different: System-level testing focuses on the results that users can see directly from the UI, while integration testing focuses on the accuracy of the UI interface data. For example, the report function, see a table on the page, and for the UI interface needs to overwrite the n parameter combination.

The above two points are the difference between system-level testing and integration testing, in the automated implementation process, the recommendation of layered test ideas, both can refine the test can also be integrated to measure the cost of automation, the overall point is the following points:

1) The traditional Waterfall project, long duration, through the iterative mode can be pre-intervention testing, and the iterative cycle of system-level functions may not be measurable, but the interface can be measurable.

2) The advantages and disadvantages of UI-based automation, need to combine the system features to consider the need for layered testing, layered after the focus of testing, such as UI Automation focused on the UI of the operation process and display, integration testing more attention to the UI interface parameter equivalence class coverage and data correctness.

Analysis of 1.2.3 Interface testability

The interface is clearly more simple than the UI, just need to know the protocol and parameters to complete a request, from the automation test implementation of the ease of view, there are several characteristics:

1) The automation cost of driving the execution interface is not high: Http,rpc,soap,rmi can encapsulate a client as an executor of the interface request according to the corresponding protocol.

2) Overall automation test cost-effective: The interface test is still a black box category, so it is less difficult than unit testing, and compared to the stability of UI Automation more reliable.

2. Interface test Tool selection

2.1 Common Test Tools

2.1.1 JUnit

JUnit is often used as a unit test framework for White-box testing, and some of the good features of the framework are:

1) provides a rich API to support a variety of logic to verify the correctness of results

2) Support use case code reusability through parameterization, @before, @after and other features

3) Suite mode supports batch operation of case

4) have a good presentation of the report

5) integrated with Eclipse IDE for ease of use

2.1.2 HttpClient

HttpClient is a feature rich Client programming toolkit that supports the HTTP protocol, with the following key features:

1) Encapsulates a method that implements all HTTP, such as Get,post,put,head

2) Support Redirect, Session hold

3) Support File upload

2.1.3 HttpUnit

HttpUnit is a test aid for HTTP requests that can handle the requirements of a Web test. Handle HTTP requests, session hold, redirects, and HTTP to simulate browser behavior? Response do DOM parsing.

Compared to httpclient, the difference is:

1) HttpUnit can parse the result page returned by HTTP, such as DOM element positioning

2) HttpUnit can start a servlet himself to run the service under test

2.1.4 Htmlunit

Htmlunit is more powerful than HttpUnit, like a browser, Htmlunit is one of JUnit's extended test frameworks that simulates the browser's behavior, and developers can use the APIs they provide to manipulate the elements of a page. Htmlunit supports Http,https,cookie, the form's post and get methods, the ability to wrap HTML documents, the various elements of the page can be called as objects, and support for JavaScript is better.

2.1.5 Jwebunit

Jwebunit a Web testing tool based on HttpUnit and JUnit. can be used to verify link jumps, form input and submission, table contents, and others? Web? The correctness of the application attributes. It is easier to write a case than a htmlunit,jwebunit package.

Reprint Address: http://www.blogjava.net/qileilove/archive/2013/06/20/400768.html

Go Interface testing in Web Automation testing