How to test redis during software testing interview?

Software testing interview encounter: How to test redis?

First we need to know, what is redis? What can it do?

• Redis is a key-value type high-speed storage database.
• Redis is often used for: cache, queue, publish and subscribe, etc.

Therefore, the question "How to test redis?" can be transformed into:

• How to test cache?
• How to test queue?
• How to test subscription?

In the technology stack I am exposed to, redis is rarely used for publishing and subscription. We mainly talk about  caching  and  queues .

1. Classification of cache

There are several types of cache: file cache, database cache, memory cache, browser cache.

Browser cache refers to the browser's own caching capabilities. In order to speed up page loading, modern browsers often download resource files such as css and js once and then cache them for a period of time until the cache expires or the request explicitly informs that they need to be updated.

If the interface is output through direct rendering in the back-end language or template rendering such as smarty, file type caching will generally be selected.

Figure 1 File cache

With the rapid development of big front-end technology, the separation of front-end and back-end is becoming more and more popular, smart rendering is used less and less, and the interface response time requirements for back-end services are getting higher and higher. File caching is no longer suitable for this scenario. Database caching is becoming more and more popular.

The most common database caches are currently: redis and memcached. They are both distributed key-value caching systems.

Figure 2 redis cache

Memory cache is similar to database cache, but it is limited by the technology stack. For example, Java can be used, and it is used very frequently in Java, but PHP cannot be used. The memory cache is faster than the database cache, but because the memory cannot be increased all the time, it has more restrictions. If you are not careful, problems such as memory leaks may occur.

In actual use, the Java interface often stuffs some high-frequency data into the memory cache as the first-level cache, and stuffs the sub-high-frequency data into redis as the second-level cache, and finally queries the data from the db.

 Figure 3 Combined use

The role of cache:

From the above content, you may already know that the two most important functions of cache are to speed up access and reduce server and DB pressure.

2. Cache usage scenarios

You may ask, does the above have anything to do with testing? No, I think it is helpful to know the above for testing. Do you know when to add cache and when not to add cache in terms of technical implementation? This is the technical control of an interface. Not only developers need to know it, but testers also need to know it.

If an interface that should be cached is not cached and is discovered by you in advance before the stress test, wouldn't you feel proud? In fact, it corresponds to the role of cache. When the qps of the interface is high (for example, more than 100) or the response speed is required, or the server performance and db performance are poor, you can try to use cache to solve the problem.

Let me give a few examples:

1. In the new version of WeChat, the personal center has an additional "status" function.

WeChat has a very large user base and access QPS is very high. Hundreds of thousands of people access it at the same second. It is impossible to query the database every time.

For requirements like this, the general approach is as follows: first cache the user's status data in the app (browser cache), and then call the backend interface to request "status" data in a certain period of time through active push or passive pull. ;The interface reads data from the cache of redis/memcached and returns it; if the amount of data is not so large, the interface can directly read the data from the memory cache and return it; after the data is returned, the cache in the user app is updated.

Figure 4 Example 1

2. There is a product management backend list page of a small e-commerce company. There are not many visitors, and the frequency of SKU changes is very low. It may be visited dozens of times in three days. In this scenario, there is no need to use cache, and second, the updated data needs to be seen immediately after the product information is updated. It is not suitable to use cache, so it is not recommended to use cache.

3. The same e-commerce management backend, this time a statistics page that counts the sales of goods yesterday/today/the past week.

This scenario can be viewed on a case-by-case basis, and there are many different solutions.

(We put aside various technical solutions for big data statistics and simply implement the statistical function of a system)

No real-time statistics required

You only need to count statistics once at a scheduled time. For example, you only need to see yesterday's statistics: you can directly store them in the db after statistics by the scheduled script. When you need to view the statistics, you can directly query the db.

Need to query real-time statistical data

However, the execution efficiency of each statistical SQL that needs to be queried meets expectations: just query the db directly every time you view the data, and the db is not under much pressure at this time.

Need to query real-time statistical data

And due to the huge amount of business data, the execution efficiency of each statistical SQL is very low or cannot be directly counted: various indicators can be summarized and the statistical values ​​​​are maintained in the cache. For example, if sales information is required, for each item sold, the sales statistics value cache + 1, Just query the cache at this time when viewing statistics.

3. How to generate cache

After understanding the usage scenarios of cache, let's talk about how to generate cache.

Generally speaking, there are two ways to use cache. I can briefly summarize it as: outside  and  inside .

First, let’s talk about how an interface request is processed in the program:

Figure 5 Program processing flow

This is a typical MVC. The Controller receives and processes the request data, the Service processes the data obtained from the Model, and then the View outputs it.

For different scenarios, we can adopt various methods and add different caches on multiple nodes to solve different problems.

For example, if the request parameters are variable and the returned data is strongly related to the request parameters, it is suitable to cache the queried data "outside" (after filtering the request parameters). This type of data is generally cached for a short time, such as 5 minutes. It mainly deals with repeated requests with the same request parameters within a short period of time. If you encounter a request attack, even if the cache is valid for only 1 second, it is still very effective and can block a large number of requests.

 Figure 6 Caching “outside”

For example, if the request parameters change little and the returned data is very close to the data stored in the db, it is suitable to cache the data "inside", that is, update the cache while updating the db. In this optimal state, It is enough to read the cache without directly interacting with the db, which can greatly relieve the pressure on the db . This cache validity period can be set to a very long time.

 Figure 7 Caching “inside”

4. How to update the cache

After talking about generation, let’s talk about cache update. After the cache is generated, it will not remain unchanged, so the cache needs to be updated.

There are several ways to update:

• Automatically update after expiration : This is the laziest way to update. By setting the cache validity period, a new cache will be automatically created with new requests after the cache expires.
• Delete the cache : After updating the db data, delete the cache directly and automatically create a new cache through new requests.
• Reset the cache : After updating the db data, directly reset the cache.

5. redis cache test point

1. Performance testing perspective

Is the cache add/update function correct? Check whether the cache data is correct.

• Add related logs and view the logs
• Backdoor interface tool
• Using the command line, memcached and reids can be viewed directly after logging in.

Cache deletion

• The cache is valid, verify relevant business functions
• The cache is deleted and relevant business functions are verified.
• Cache expiration and invalidation. Memcached and redis can set the expiration time and check whether there are any invalidation events, right?

Excess elimination mechanism: What to do if the cache reaches the upper limit

• cache penetration
• cache avalanche
• The redis cache service is stopped
• cache timeout
• After the cached data is accidentally modified, quickly restore it to the specified version.
• Quickly restore cached data after it is accidentally deleted

To learn about cache penetration, cache avalanche, and cache breakdown, see the article "Redis that Test Engineers Can Understand"

2. Redis functional testing perspective

• When the redis data takes effect, is the reading correct?
• The redis data does not exist. Can the correct value be read from the db normally and written to Redis correctly and returned to the upper layer?
• Is the performance normal when the data does not exist in redis or db?
• When deleting data, are the data in redis and db consistent?

Practical cases

Optical theory is useless. You must learn to follow along and practice it in order to apply what you have learned to practice. At this time, you can learn from some practical cases.

If it is helpful to you, please like and save it to give the author an encouragement. It also makes it easier for you to search quickly next time.

If you don’t understand, please consult the small card below. The blogger also hopes to learn and improve with like-minded testers.

At the appropriate age, choose the appropriate position and try to give full play to your own advantages.

My path to automated test development is inseparable from plans at each stage, because I like planning and summarizing.

Test development video tutorials and study notes collection portal! ! !