Shulou(Shulou.com)06/03 Report--

The following is selected from the book "Xiaoqiang Software testing Crazy handout"

Here I would like to say in advance: everything has a certain audience, and there is nothing in the world that can make everyone 100% satisfied. So, so is this book. As long as there is a chapter in this book that has an impact on you, that is the value of this book! Thank you for your support.

Introduction

Why did I put this topic at the beginning? It is because I have come into contact with many friends in enterprise work and education training over the years. In this process, I find that more than 95% of my friends do not understand what performance testing is and what is automated testing. It does not matter. But what is even more terrible is that there is a huge misunderstanding of these concepts, which leads to a lot of detours in learning, and I have no choice but to look at it. So let's talk about what performance testing and automated testing are, hoping to help you have a more comprehensive and profound understanding of them. Don't underestimate this. If your cognition is wrong, how can you learn it right?

In addition, I must also point out at the beginning that everyone's learning needs a process. Maybe a colleague around you has gone through stage A to stage B. he may despise you or criticize you from the technical level. but don't be discouraged. No one can talk or run from birth, they all need to go through this special "low-level" stage, this is inevitable. We will always adhere to the positive energy to lead the "new person" to grow up and help you complete the phased transformation.

What exactly is a performance test?

I believe many friends cannot fully answer this seemingly simple question. Friends who may know about it will say that performance testing is to use LoadRunner or Jmeter tools to create a concurrency to test the system, or they may say that performance testing is to let a lot of people access the system at the same time to see if the system can stand it. I can only say yes to these answers, but they are not comprehensive or profound enough. I just describe the appearance. In fact, the real performance testing can not be summed up in one or two sentences, because it involves too many things.

As soon as most rookies talk about performance testing, they understand the stress testing server to see if the server can handle it, but this is only one of them. In fact, performance testing can be divided into multiple levels. The concerns and testing methods of each level are different. We often think of server-side performance testing. As for the layering of performance testing, we will explain it in later chapters.

How on earth should performance testing be understood? We might as well look at it from another point of view. Whether we understand that testing the system through tools or calling on 100 people to access the system at the same time are just means or methods of implementation, we should pay more attention to the purpose of performance testing. Because the purpose is different, the means or methods to achieve may be different. So let's look at the performance test backwards for just a few purposes:

1) the pressure test system depends on whether the front end and back end of the system meet the expectations (similar to the concept of expected results and actual results in functional test cases)

2) the pressure test system can judge the bearing limit of the system by looking at the best pressure and the maximum pressure that the system can bear.

3) the pressure test system to see whether the system can handle requests normally under long-term operation (similar to fatigue test).

4) capacity planning, when the system becomes more and more stable, we should consider its long-term planning in advance, or a more popular explanation is that "people are not far-sighted, there must be near-term worries". The "foresight" here is capacity planning.

In this way, we should be able to understand that performance testing is actually more of a process than a specific definition. At the same time, we should temporarily put aside the idea of functional testing when learning performance testing, otherwise it is easy to fall into a trap. This is also the most common mistake made by most rookies.

Hierarchical model of performance testing

The hierarchical model of performance testing is summed up in order to make it easier for people to understand and learn performance testing. Even for friends who have some experience, I think this hierarchical model will be helpful to your cognition. The hierarchical model is not high-end, may not be perfect, only to summarize and refine the messy knowledge, but for rookie friends is a very good medicine, can help you quickly and comprehensively understand the performance test. The hierarchical model is shown in figure 1.1.

Let's take a look at what each layer represents in this performance test hierarchical model.

Front end layer

The front-end layer mainly refers to the page that the user sees. For example, the home page of the e-commerce website and the various pages of the mobile APP are what users are most concerned about. For users, the speed of your system will only be judged by the display speed of the page, and they will not care about the speed of your back-end processing, so I often say that even if your back-end optimization is very strong, the front-end page performance is very poor. That's futile.

In the past, this level is not concerned by many enterprises and test engineers, but in recent years, the requirements for front-end performance are getting higher and higher, and it is also the knowledge that we should know. This book will explain the knowledge and practical experience of front-end performance in detail in later chapters.

In addition, APP testing is also a question that people often ask. Sometimes I am very helpless. People open their mouths and ask, "how do you do APP performance testing?" It's really impossible to answer such a question. The performance test of APP includes at least two aspects: the front end of APP, which is now often called APP special test in the industry, and the back end of APP, essentially and Web.

The side performance test is the same. Therefore, be sure to understand this knowledge before asking before others can answer you in a targeted way.

Network layer

Any system can be roughly divided into client, network and server, in which the network is the lifeblood of the front and back end of the connection, and the quality of the network also has a great impact. The situations that may be encountered in the performance test are roughly divided into two types, one is to test the performance of large traffic under different network conditions (generally less contact), and the other is that the press and the server should be in the same network segment. Otherwise, the pressure can not reach the back end completely, it will drag down in the network layer, so it is impossible to evaluate the performance of the server more accurately. If you are testing mobile APP, you may also want to consider testing in different network states. I have very little contact with the performance testing of the network layer, so I don't have to play tricks here in order not to mislead people. The focus is on understanding this hierarchical model, which is important for understanding performance testing.

Back end layer

Here I am divided into three situations, which is also the direction of application in the vast majority of enterprises, which we must understand and master. At the same time, we should also understand that whether it is the web side or the mobile app side, the method of performance testing in the back-end layer is similar.

First, business level: the popular explanation is to record your scene script from the page. For example, there is a Xiaoqiang e-commerce site where you need to complete the process of logging in, browsing the item page and placing an order through a page recording script. This level I think you are most familiar with, because LoadRunner this tool is used to complete such a process, but also most rookie students must learn. As for how to complete it, we will explain it in detail in later chapters.

A fatal disadvantage of this performance testing method is that it depends on the page, and if the page is not developed, the test cannot be carried out in advance, but in reality, the test time is often blindly compressed, so we sometimes have no choice but to do so. so how to make the test entry point as early as possible is more important. And the interface level just solves this problem.

Second, interface level: this level is the first choice and one of the most efficient ways for most companies to do performance testing. For example, now there is a login interface, you only need to know the input parameters, output parameters and rules to write the test interface code, do not need to wait for the development of the page, much ahead of the test entry point, but it requires the test engineer to have a certain coding ability. In addition, the interface-level testing has strong expansibility, and the efficiency can be improved by completing the interface performance testing and functional automation testing framework. The details of how to complete it will be explained in detail in later chapters.

Third, the unit level: this level is exactly the opposite of the interface level, many companies want to do, but do not want to. Unit-level we understand as similar to "unit test" can, for example, there is a PHP code block, we may need to test the performance of the core algorithm functions, you can stake or the introduction of unit test framework to complete, so as to get its execution time, CPU consumption and memory usage and other information to optimize code performance, as shown in figure 1.2.

So why can't many companies do unit-level testing? There may be several reasons:

1) the business is changing too fast, and the code logic changes involved are relatively large, so the loss of unit-level testing outweighs the gain.

2) developers really do not have much time to write unit test code, after all, business logic code is also very time-consuming, there is not much time to do anything else.

3) the coding ability of test engineers is relatively weak, and very few people can complete unit tests on their own, and it is even more difficult to do unit-level tests because of the shortage of time.

After we talk about these layering, maybe some friends will feel that some of them are very skilled and feel very high-end. But I personally think that it is not how powerful technology you use, only using the right technology to bring a higher performance-to-price ratio is the king, there is a good saying: "the best is not necessarily appropriate, only the right can play the best effect."

After reading these, I don't know if you have a different understanding of performance testing. Of course, this model is not necessarily the best, it is only based on experience, and there is a lot of room for improvement. I hope to improve it by communicating with you. I do not want to argue about right or wrong. There is no absolute right or wrong in the world itself. Only with more exchanges can you absorb more knowledge to arm and improve yourself. As the saying goes, "you have an idea, I have an idea." We communicate with each other and have two ideas. "Why not?"

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.