As a test, we often encounter projects in the reverse period. When R&D has already taken up a lot of resources, the test at this time needs to improve efficiency. You have to make more preparations before the R&D test, so what can be done before the R&D test, I will share with you in this article based on my experience.

demand analysis

The first thing to do is to familiarize yourself with prd, which mainly needs to dig out the following information:

What is the business background of this prd?
What is the value to be realized by this business?
Who is the beneficiary (or user) of this business?
Which external departments do you need to cooperate with for this business, and who are the joint investigators?
Does the transformation of this function involve the transformation of historical functions? That is, it is necessary to clarify the scope of transformation
What test directions are involved in this function transformation? In addition to function, UI, usability, interface, smoke, and regression, do you need data testing and performance testing?

The author believes that at least the above problems should be clarified before it can be regarded as a qualified demand analysis, which will provide a strong support for you to understand the ins and outs of the entire system to be tested.

R&D Design Analysis

As R&D is the real place where the project falls, we also need to spend time reading and analyzing the R&D design documents they output, otherwise we will miss some abnormal processes. When reading any document, you must proceed with questions. Similarly, the author personally reads the design documents of R&D, mainly to dig out the following valuable information;

Which interfaces are involved this time, which of these interfaces are the services we provide, and which ones we are consumers. It is also necessary to sort out each jsf interface: interface name + alias + method, which is convenient for generalized calls and verification interfaces on the test platform;

As the interface of the server, we also need to clarify the maximum number of calls supported by the interface and the response time, and evaluate whether performance testing is required;

Do these interfaces involved in this time have a test environment? If not, you need to sort out the input and output parameters in advance and mock them
Whether JMQ is involved this time, whether it is JMQ4 or JMQ2, and whether the topic already exists in the test environment, if not, it is necessary to apply for the corresponding platform to create a topic
What are the abnormal processes involved in process transformation? These exception processes include, but are not limited to:

[1] For the interface, how should the program handle different exception response codes? Will it retry if the call times out?

[2] For jmq, if the consumption is abnormal, will it be retried?

[3] Abnormal scenarios under normal business processes. These scenarios should fully consider uncertain factors such as user habits, user common functions, system robustness, and abnormal input and output.

Does the process transformation include jimdb? If jimdb is used, it must be sorted out: which keys have been added this time, and are these keys time-sensitive? How long is the statute of limitations? Avoid program exceptions caused by cache expiration.
There is another point that is easy to overlook here. It is necessary to clarify who is the person in charge of the R&D of each module. When encountering problems and reporting bugs later, it needs to be accurately corresponded.

The above are the things that the author thinks should be paid attention to in the research and development design analysis, which may not be comprehensive enough, welcome to add.

Test case writing

The test case is used as the necessary output document for the test and the necessary basis for the test execution. I will not go into details here, because there are many interface tests in the current test system, but it is often unclear what the interface test should test. Based on So, here I would like to share with you how I test the interface, and what are the main points I focus on when testing the interface?

Interface Documentation Test

For the interface, the interface document is the most basic agreement agreed by both parties. Whether the data can be transmitted normally depends on the interface document and the standards and specifications defined by the interface document. Most of the work has already been done for this interface. From the interface document, we need to analyze the following points to start testing:

First of all, it is clear what the data type of the request is. The mainstream ones are Json, http and other requests.
Test the mandatory items defined in the interface document one by one to see if the receiving party has a reasonable prompt when a certain mandatory item is missing.
Test the non-mandatory items defined in the document one by one to see if the receiving party can access the information normally when a non-mandatory item is missing.
Test for date format. It supports the format of yyyy-MM-dd, yyyyMMdd or yyyy/MM/dd for verification.
Test for significant digit preservation. General interface documents require to retain up to two decimal places. At this time, it is necessary to verify the integer, retain one decimal place, and retain the response of the receiver when three decimal places are reserved. (equivalence class division)
For common ID numbers and mobile phone numbers, length and fault tolerance tests are required.
For enumeration values, test them one by one. (Using the method of equivalence class division)
For the data of the requesting party, check with the interface document to confirm whether it is completely transmitted according to the data type defined in the interface document.

internal business logic

The business scenarios are different, and the input parameter combinations are different, so the program processing is also different. At this time, the business scenario should be fully considered, and different input parameters should be organized for inspection. The two most common scenarios are listed below:

When encountering the query interface, on the one hand, it is necessary to control as few or no input parameters as possible. At this time, see if all business data can be returned. On the other hand, it is necessary to pass as many parameters as possible to verify whether all query conditions are valid. , only the query results are returned according to the intersection of all query conditions.
When encountering an amount, think of whether there is a relationship between equality and inequality. Take the example of a borrower borrowing from a bank: after borrowing money, the borrower needs to repay, and the repayment request includes the total repayment amount, repayment principal and repayment interest amount. At this time, we must analyze that: the total repayment amount and the repayment principal must be >0 (the inequality holds), which is the correct request.
When encountering permissions and roles: different permissions pass different permission codes, and the businesses that can be processed are also different;
For the compatibility of historical data, some interfaces are not only for new business, but must also include the processing of old business. At this time, the compatibility processing of historical data needs to be considered.

database test

The test for the interface database part actually occupies a large proportion. We should focus on the following aspects of testing:

How business flow is mapped in the database. Generally, they are distinguished by status and process nodes.
How updates to individual tables map to business processes. That is, which tables are accessed by an interface are simply storing data, which tables are updating data, and what are the updated data. It must be clear.
Is there any exception handling between the transfers of each table? For example: after interface A is successfully received, tables tab1 and tab2 need to be stored, and tab2 is stored only after tab1 is stored. At this time, an exception occurs in the database, and tab1 is stored but tab2 fails to be stored. At this time, it is necessary to verify whether the function is rolled back , Is there any exception handling for this part.
Whether the follow-up business has a strong dependence on the current data, if there is a strong dependence, under what circumstances the current table data will be updated, logically or physically deleted, and what impact it will have on the subsequent business test, it needs to be listed clearly;

jimdb test

Many of our internal business scenarios use jimdb, and based on this, detailed testing is also required;

Which jimdb has been operated on by an interface call, including but not limited to adding and updating
After the jimdb key is generated, whether there is any business operation will clear it, and whether there is any business that strongly depends on it is judged.
Will the jimdb key expire, and will the short expiration time affect subsequent business?
Has this jimdb cache been pulled to the local cache.
You also need to pay attention to the values that exist in the database and jimdb at the same time. When an update operation occurs, whether the cache and the database are synchronized, especially for inventory-related businesses. For performance, the operation of first deducting the cache and then deducting the database records is often used. At this time, it is necessary to ensure The consistency of the final data between the two.

Exception process testing

Pay attention to retries, jsf jmq itself has a retry mechanism, but whether the impact of retries on the business is good or bad needs to be evaluated according to needs.
Pay attention to timeout processing: once timeout occurs, an exception will be thrown.
Pay attention to exception response handling. Generally, the interface will list successful response codes and abnormal response codes. We need to pay attention to whether the program handles exception responses as expected. In many cases, some exception responses cannot be triggered. The mock will get twice the result with half the effort.
Focus on critical handling: especially for numeric classes, max and min
Pay attention to the exception equivalence class: if there is a positive number, there must be a negative number, if there is a length limit, there should be a value of 0, and so on.

A good test case is an indispensable part of testing, and it is particularly important to master a test point of a test.

Summarize

In fact, we can do many other things in the test before R&D and testing, such as: risk assessment, test scheduling, automation, etc. I will not describe too much here, but only list the most important three aspects here: demand analysis, R&D design Analysis and test case writing, the final result may still be unsatisfactory, but it’s good to do your best, isn’t it? Welcome to ask questions and leave a message~

Author: Jingdong Retail Wang Haibao

Source: JD Cloud Developer Community

What can be done by testing before R&D testing | JD Cloud technical team

demand analysis

R&D Design Analysis

Test case writing

Interface Documentation Test

internal business logic

database test

jimdb test

Exception process testing

Summarize

Guess you like

What can be done by testing before R&D testing | JD Cloud technical team

demand analysis

R&D Design Analysis

Test case writing

﻿﻿Interface Documentation Test

internal business logic

database test

jimdb test

Exception process testing

Summarize

Guess you like

Interface Documentation Test