Previously, we introduced some relevant factors for writing black-box test cases. I believe that everyone should be able to more or less understand their new understanding and ideas for black-box testing.
Then following the previous content, it's time for us to talk in detail about another form of test case, which also plays a pivotal role in our automated testing activities.
Because there are many types of automated tests, the design methods, presentation methods, and execution processes of related automated test cases are also varied. Then we will choose a few of the more mainstream ones for discussion, and there may be some differences among them. You can read them according to your needs.
The significance of automation
So before we officially start the introduction, we need to understand the necessity and significance of automated testing.
The most obvious point is that it can improve our testing efficiency, because it is machines that help us perform testing activities. Of course, this view is correct, but there are still many companies that still stay at this level of cognition, as I explained before. However, many companies or teams still use KPI or promotion goals as motivation to carry out automated testing and related construction activities. This is what we say in our circle, "automation for the sake of automation".
Under such a general tone, it is unclear what benefits and improvements automation can bring to us. What is more is the huge consumption of manpower and time costs and the extremely disproportionate input-output ratio.
The meaning of automated testing that bloggers understand is divided into four levels: company, product, team, and individual.
01 Company
First of all, as far as the company is concerned, the essence of investing in automated testing is actually to reduce costs and increase efficiency. Some people may ask questions here, how can it be cost reduction? Whether it is recruiting professionals or investing in corresponding hardware, no matter how you look at it, it will increase costs.
In fact, there is a misunderstanding here. As far as we are concerned, what we see is indeed the case, but for the company, as long as it has a clear strategic goal, a long-term vision and a certain amount of investment, in the long run this is actually a problem. A steady profit decision.
02 Product
Here we will talk about our second level of "product". As we all know, in the Internet industry, whether it is the same industry or cross-industry, the fierce competition of software has never stopped. The timely launch and stable iterative update of a product are the prerequisites for seizing an effective market.
Just imagine, can a product that only relies on manual testing meet the above requirements? After all, artificial work still has a certain degree of uncertainty, which is inseparable from the emotions, environment, subjective ideas, and inertia of the performer. Any factor may affect the quality performance of the entire product.
Therefore, the company's initial investment is explicit investment, but the benefits brought by the later automated testing or CI/CD at a closer level are all recessive. Maybe in the end, what everyone can really see will be product sales. , Revenue growth.
Of course, not investing in automated testing will definitely make the product's quality and sales success, and many of the factors must be clarified and selected correctly. Such as what kind of problems or contradictions to solve after investment, choice of technology stack, framework design, daily maintenance, dedicated personnel, hardware support, review of input-output ratio, post-optimization, etc.
03 Team
For the team, having automated testing capabilities will undoubtedly bring the team's external evaluation to a higher level. Now the industry's requirements for testers are getting higher and higher, which is obvious to all.
A team with only manual testers and a team that can support developers stably for a long time and can perform automated testing activities autonomously, needless to say, they will compete with each other.
It is also because of this that it is understandable that a professional team can obtain more and better resources in the company. With these substantial supports, it is believed that the size or strength of the team will become stronger and stronger.
04 Personally
, at the personal level, mastering the ability of automated testing undoubtedly increases one's own core competitiveness. The fundamental starting point for enhancing competitiveness is nothing more than allowing us to go further and more steadily on the road of testing. Needless to say, promotion and salary increase. In addition, AI and big data are still the mainstream trend today. A test without programming ability and design concept will inevitably be eliminated by society and the times.
Factors for writing automated use cases
01 Everything is an object
Students who have studied java or python should know this sentence, yes, this concept is also needed when we design automated test cases.
After all, unlike black-box test cases, automated test cases are not executed for humans. We need to use the corresponding development language to write use cases. When writing test case scripts, you need to implement this concept all the time.
Of course, the process of writing use cases is not fundamentally different from the coding work of other developers, and don’t expect use case scripts to be written in place at one time. Most of the scripts need to be optimized again and again, and the efficiency of writing at the beginning is lower. It doesn't matter, let's make sure that it can run through, and the reusability and robustness can be slightly worse.
But after running it through, we should focus on performance. If you use python, it is no problem to run a few use cases, because python is a dynamic language, and the compiler cannot make any predictions when variables point to objects. In addition, It itself interprets and executes, so in the case of running a large number of test cases, there must be a long running cycle and unexpected error reports. At this time, improving the performance of the code has become the top priority, and the time complexity of the algorithm Optimization, reasonable use of built-in methods, avoiding global variables, reducing loops, etc. can all provide corresponding performance improvements to our code.
02 Strong business correlation
Unlike black-box test cases, the business correlation in automated test cases will be strong. In fact, if we consider its essential form, we can explore one or two. What it needs to solve are some positive test scenarios with stable functions and clear business paths. It is impossible for test case scripts to only operate a certain one of a certain business interface. function, it would be too wasteful.
Generally speaking, the test script needs to cover the entire process of a normal business, so that we can add various assertions we need during its operation to verify the expected test results in multiple use cases. In addition, because the nature of the black-box test case is different, it also better proves that the automated test case can quickly perform business verification, return, and smoke.
03 Forward scenarios
For automated testing, the most terrifying situation is to stuff all forward and reverse testing scenarios into the automated testing framework. Some people instinctively think that since it is automated execution, why can't reverse test cases be executed? As long as the appropriate parameters are designed and written into the test case, is it really foolproof?
In fact, the reason why reverse test scenarios and test cases are suitable for automated testing lies in its own uncertainty, which will affect the final running results of automated testing.
Students who have done automated testing know that what is really scary about performing automated testing is not reverse test cases, but the kind of test scenarios and use cases that do not know when an error will be reported. Most will appear in reverse testing scenarios.
We need to know that automated testing does not help testers do everything. Therefore, for forward testing scenarios with stable functions and little change in requirements, we can safely put automated testing into it, but this is not recommended for reverse testing scenarios.
If you really want to put it in, it is only recommended to put in relatively unimportant functional modules. It is safer to need experienced testers to manually confirm the reverse scenarios of some complex business and important functional modules.
Generally speaking, automated testing mainly covers the main happy path of the product, and there is no need to design too many reverse scenarios in it, which will affect the stability of automated testing activities. Don't forget, the main function of automated testing is to free our testers from the complicated and repetitive testing work, and put their energy into more important and complex module and business testing.
04 Multi-scenario construction
The concept of multi-scenario construction here is to make full use of the advantages of automated testing and cover as many test scenarios as possible with fewer runs.
For example, if there are multiple test cases in an automated test script, we need to make full use of the business interface in the script in the process of designing use cases to combine multiple scenarios.
Such as CRM, we will verify all kinds of customer information, add, delete, modify and check operations in the customer information interface, and these operations should be placed in the one-time operation of the page if possible, unless they are strongly related to the subsequent business (necessary for follow-up operations) data), otherwise it basically follows this principle.
This is what I said above, try to combine verifiable business scenarios together in one pass, instead of running multiple rounds of the same business line but only verifying different test points.
05 Strong pertinence
Generally speaking, when we design automated test cases, the source is based on the black-box test cases we designed before. The common practice is to add P0 and P1 level positive test cases to the automated test cases.
There is no problem at all in doing so, but we also need to pay attention to the fact that our automated test cases are not static for different test types. For example, the most commonly used smoke and regression tests in automated testing, these two types of automated test cases should not be the same.
The test cases of the smoke test should be more inclined to quickly verify the main process to ensure that the quality of the current version is worthy of the next test activities, and pay more attention to the application of the old use cases.
Regression testing is aimed at whether the repair of some functions will affect the normal operation of the overall function and some extended modules. This requires automated testing between the repaired functional modules and related modules that the test considers necessary. Therefore, automated testing Use cases may overlap with the smoking part, and new use cases for confirming the normal operation of the functions of the relevant extension parts will also be added.
06 Independent test function points
This is also easy to understand, and it is no different from black-box test cases. Although the current overall linear business operation of a certain page will be designed in the script, we still need to ensure that only one function is verified in each automated test case Points, must not be convenient to put multiple function points into a use case for confirmation.
At this time, someone will definitely ask, can I perform multi-function confirmation if I put a few more assertions? In fact, this point of view violates the original intention of the test case design. Multiple assertions can naturally judge multiple function points. Disassembly, this is different from writing black-box test cases in that your code cannot be disassembled independently.
Then the next question is that it is also a test case, is a bunch of combined test cases highly reusable? Or is the use case of independent test function points highly reusable? You don't need to think about it, the answer is already obvious. It's like Lego blocks. If you need to design a castle, is it better to be a whole block with irregular shapes or a small piece of regular small blocks?
07 Complete design
In addition to designing basic test cases, we can also use the advantages of automation to carry out some additional use case extension designs.
In our daily work, our automated testing does not only need to design related functional test points, but also includes some related test data operations. Then the pre- and post-operation of test data has naturally become one of the necessary steps in designing test cases.
In black box testing, our test data will be defined or created before we execute, and it will be smoother during execution. In automated testing, we do not need to manually perform this operation in advance. Generally speaking, we will put the test data that needs to be generated into an independent test case in advance for pre-creation. This is called pre-operation. In fact, that is what we call the prerequisites.
Similarly, after we execute certain operations or business flows, we can also recycle and delete these test data, which is called post-operation. In this way, we can always ensure that our test environment can repeat the same test cases without worrying about changes in factors such as the environment or data.
In addition, because our testing process is "passing without leaving traces", we can use screenshot functions, print logs, etc. to leave test evidence at important use cases and assertions, so that it is convenient to troubleshoot and locate bugs when they occur.
Well, the above are some design factors and experience about automated test cases, I hope it can help you better summarize your own experience.
The following are some supporting learning resources, I hope they can help you, if you need them, you can get them for free [guaranteed 100% free]
Software Testing Interview Documentation
Our advanced learning of automated testing—test development is bound to find a high-paying job. The following interview questions are from the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Answer, after reviewing this set of interview materials, I believe everyone can find a satisfactory job.
