In the software development process, the recurrence and positioning of online problems is a daily activity of development. However, the headache for developers is that due to the differences in configuration and data between the online environment and the local environment (such as data in the database, data in the cache, etc.), online problems often cannot be quickly reproduced in the local test environment , the difficulty of investigation is greatly increased.
Faced with this kind of problem, AREX, an automated regression testing tool, can be used to quickly reproduce it. The basic principle of AREX is to record traffic and data in the production environment, play it back in the test environment, and automatically compare the differences in external requests in the interface service and the differences in the packets returned by the interface, and combine precise testing tools to find the correlation between code changes and result differences , to complete the complete automated verification test. With the help of AREX's powerful Mock mechanism, AREX will automatically mock all the external dependencies of the real request during the recording process, and perfectly restore the online production data environment locally, so that the reproduction in the local environment can be successfully completed and the problem can be quickly checked .
Specific steps are as follows:
- Send a request with the flag force-record=true to the production environment, AREX will record the production data, and record the RecordID (AREX-Detail-ID) in the response header
- Go to the Local development environment, prepare the corresponding code and AREX Agent configuration, and enable the Debug mode
- Use AREX to send a request message whose RecordID is AREX-Detail-ID to the Local environment, and the Local service enters the Debug state after receiving the message
- The Local application mounts the AREX Agent, and the dependent data will be obtained and loaded from the AREX database
- Development can start to reproduce production problems as you like, and quickly reproduce and locate
The following is a practical demonstration.
Step 1: Deploy the AREX service
git clone https://github.com/arextest/deployments.git
cd deployments
docker-compose up
Step 2: Configure AREX Agent for the application under test and start it
AREX Agent is the core component for traffic recording, so before using the recording function, you need to configure AREX Agent for the application under test.
First, compile AREX Agent:
git clone [email protected]:arextest/arex-agent-java.git
mvn clean install
After successful compilation, a new folder named arex-agent-jar can be obtained in the arex-agent-java folder, which contains two jar packages.
Add the Java Agent configuration to the startup of the Java application under test:
The complete configuration of environment variables is as follows:
JAVA_TOOL_OPTIONS='-javaagent:E:/github-arex/arex-agent-java/arex-agent-jar/arex-agent-0.1.0.jar'
Complete configuration of program parameters:
-Darex.service.name=arex-community-test6 -Darex.storage.service.host=10.5.153.1:8093 -Darex.enable.debug=true -Dspring.datasource.url=jdbc:mysql://10.5.153.1:13306/community?useUnicode=true&characterEncoding=utf-8 -Dspring.datasource.username=arex_admin -Dspring.datasource.password=arex_admin_password -Dspring.redis.host=10.5.153.1 -Dspring.redis.port=16379
You can observe the output or view the log when starting:
You can see that in the printed information ArexJavaAgent installed, it means that the Agent is installed successfully.
At the same time, you can see that Java prints out command line parameter information, such as Agent address information, Storage service address information, etc., as shown by the arrow in the figure above.
Step 3: Force recording of requests that have problems in the production environment
The general request of AREX to the production environment interface is shown in the figure below, and the response message is all normal data.
When there is a problem with a certain use case in the production environment, construct all configurations of the requested use case in AREX, and click to action.recordenable forced recording, as shown in the figure below:
After clicking the Force Recording button, a new arex-force-recordfield with a value of true. Click Save to save.
After saving and sending the request, you can see that the response header has been added arex-record-idwith a value AREX-172-20-0-4-708656889122(a unique value randomly generated by AREX Agent), indicating that the request has been successfully recorded, and all the data that the request depends on in the production environment have been recorded. stored in AREX.
Step 4: Local playback for Debug operation
After the recording is completed, it can be played back locally.
Create a new request, change the address to the local test environment, add arex-record-ida field set the value to the one generated before AREX-172-20-0-4-708656889122, click Save and send the request.
Now you can step through the problem in your IDEA environment. As shown below:
After debugging, you can see the response message of this AREX request:
Appears in the response message arex-replay-id，值为 ``AREX-172-20-0-4-708658384473(ID randomly generated by AREX Agent for analysis).
The above is the complete process of quickly reproducing online problems locally and performing debugging operations through the AREX traffic recording function.
AREX Documentation: http://arextest.com/zh-Hans/docs/intro/
AREX official website: http://arextest.com/
AREX GitHub：https://github.com/arextest
AREX official QQ communication group: 656108079