Layered automated testing

Five to 10 years ago, the automated testing we were exposed to was more focused on automated testing at the UI level. Mercury’s WinRunner/QTP was a typical representative of commercial automated testing products in that era, when people simply thought that they could replace human clicks with an automated tool. Commercialisation or privatisation frameworks are in vogue.

Layered automated testing advocates the need for automated testing at different stages (levels) of the product. In “The Google Way of Software Testing,” 70% of Google’s spending is unit testing (small tests), 20% is interface/integration testing (medium tests), and 10% is UI layer automation (large tests). This is the familiar pyramid model, where automation gets harder as you go up. (It is important to note that automated testing at the UI level, as the closest test to user action, still has meaning and context).

Meaning of interface testing

Interface testing is to verify the interaction between two or more module applications (usually in the form of interfaces). The test focuses on checking the data exchange, transfer and control management process, including the number of processing times.

The core strategy of interface testing is to ensure the correctness and stability of the system as the core, to improve the efficiency of testing, improve user experience, reduce the cost of product development by means of continuous integration.

Interface test to escort for the writing of the code, strengthen the confidence of developers and testers, let hidden BUG exposed in advance, to let the developers to fix the BUG in the first time, to make business tester in the test of time more conveniently, maximum limit to reduce the occurrence of the underlying BUG number, want to let the product development process more agile, To shorten the product research and development cycle, finally after the launch of the product, to let users use more smoothly, to let users feel that the product service zero defect.

Unlike unit testing, interface testing is essentially black-box testing, making it ideal for professional test engineers to participate in and cover.

Interface testing framework selection

  1. At present, the most common method to select the interface test framework is to use JMeter, soapUI, postman, robotframework and other UI interface test framework to do.

The advantage is that business testers can write little or no test code, and the threshold of entry is low. In the past few years, many companies have developed similar testing frameworks with front-end and back-end, which are maintained by full-time test developers. Business testers only need to know how to operate without participating in specific coding. This method looks very tall, but the actual problems in the implementation process is the main work into the maintenance of the test framework, depended on the design and development of professional test developers ability, increase a new interface protocol (such as Dubbo, Hessian or internal custom protocol) will need to increase on the frame support; More fatal is once the flow of core test developers, it is easy to cause the collapse of the whole interface test system; It is also unfair to the skill development of business testers. I have interviewed too many engineers who only know how to use a large company’s XXX testing framework but have no idea how to implement it.

As predicted in “The Google Way of Software Testing,” a secret and privatized infrastructure does not reap the benefits it is supposed to, which means it is expensive, slow, and difficult to reuse across different projects within the company. The test infrastructure of the future will be built on shared code and open source frameworks, and test developers will need to leverage and contribute more to open source projects. I recently reread the book that almost changed the software testing industry, and found that its predictions were so accurate that it is safe to assume that the entire industry in China is evolving in the same way as Google.

  1. Use Junit, Testng and other Java interface frameworks, directly write test code to test, at the same time to establish a base library or method for some repetitive work abstraction.

Similar to unit testing, this method is extensible and flexible. Programmers can use code to achieve flexible scenario organization and functions with a little secondary development, but test engineers need to have a certain coding foundation.

This way in a few years ago the difficulty of implementation is relatively large, because in the market to find a understand Java code test engineers are few, but in the more and more engineers to develop ability of the test required for implementation is not difficult, difficult languages such as Java/Python coding ability has become the basic requirement of our team when hiring.

In addition, the reason for using Java instead of other languages is mainly the technical reserve of the team. Java is a strong point, and there are rich open source test libraries. In addition, the products of Internet companies are basically developed by using Java framework, so it is very necessary to keep consistent with the technical stack of the development team.

The GTest interface tests the framework

There are many companies that do different interface frameworks based on their own business. Based on our own business characteristics, we have also encapsulated our own interface testing framework, Gtest-Framework, which is gradually being used in the unit testing of developers.

Gtest-framework does the following:

  1. Pre-data preparation and automatic clearing.
  2. Implementation and encapsulation of common interface protocols.
  3. Dependency injection configuration support.
  4. Integration of common processing methods such as files, images, XML, characters, etc.
  5. Extension of assertion mode, etc.

Interface testing key practices

1. Data preparation

Data preparation for interface tests generally refers to data preparation for databases, and sometimes also includes data preparation for files and caches. Concrete implementation can be considered from the following aspects

(1) Prepare test data by hard coding, insert any data used when writing test code. To avoid data duplication, many people get used to using random characters or random numbers (this method can cause instability in test cases and should be avoided).

(2) You can directly call other apis to prepare test data, which is more useful in the testing of the upper-level services. For example, when testing the purchase of goods, you need to prepare the data of the goods to be purchased and the data of the users to purchase goods. At this time, Test data can be generated directly by calling the API that generates goods and the API that generates users. This method is simple to implement, but only if you have the appropriate API and the API functions correctly.

(3) Use Excel or XML to prepare test data. This method of preparing test data is mainly aimed at the preparation of object data. For example, one commodity data can correspond to one data in Excel, because general development will use POJO mapping, while preparing test data, The setup of these POJO object properties is often repetitive and heavy work, and preparing them in Excel or XML reduces the need to prepare the data repeatedly in code.

Generally, we use two methods of 2/3, among which, the third method mainly uses the characteristics of Dbunit, Spring-test, Unitils and other testing frameworks to add custom annotations after secondary development. It’s easy to import Excel or XML files and roll back the data automatically when the test is done.

/** * @classname: TestJdbcDataSet * @description: Use custom TestDataSet annotations to prepare test data. * @author Cay.Jiang * @date 2017 年 7 月 10 日 9:29 aM * */ Public Class TestJdbcDataSet extends BaseCase{Map<String, Object> args = new HashMap<String, Object>(); @Test @TestDataSet(locations={"/tmp/domaininfo.xls"},dsNames={"mysqlDataSource"})    public void test01_mysql(){        args.put("selfdomain"."baidupc2");        List<Map<String, Object>> result=JdbcUtil.queryData(mysqlJdbcTemplate, "domaininfo", args);        System.out.println(result);        assertEquals("Partner Access Name",result.get(0).get("remark"));    }}Copy the code

For/TMP /domaininfo. XLS, see domaininfo. XLS, where the Excel format is the name of the Sheet table, the first line defines the field name, and the data corresponding to the other actions.

Multi-data set: @testDatadataset (locations={” data1.xls “,” data2.xls “},dsNames={“dsNameA”,”dsNameB”}); The data of datA2.xls is inserted into the database referred to by dsNameB

If you want to continue reading, check out the article below.

(Article from Hogwarts Testing Institute)