Types of automated testing and several misunderstandings about automated testing!

There are three main types of automated testing.

1. Automated unit testingEdit

Automated unit testing tests at the code level. Bugs are identified in functions, methods, and routines written by developers.

Some companies require developers to perform unit testing themselves, while others hire dedicated test automation resources. These resources have access to the source code and they write unit tests to break the production code. Thanks to unit tests, every time the code compiles, all unit tests run and tell us if everything is working properly. If any unit test fails, it means there is now a bug in the production code.

Some of the most popular tools on the market are NUnit and Unity. Microsoft also provides its own unit testing framework called MSTest. Through these tools' websites, they will provide examples and tutorials on how to write unit tests.

2. Automated Web service/API testing

Application programming interfaces (APIs) enable software to talk to other software applications. Just like any other software, APIs need to be tested. In such tests, Gui is not usually involved.

What we test here are typically functionality, compliance and security issues. In a web application, we can test whether the application's requests and responses are secure and encrypted.

This is one of the examples we can use API testing. The most popular API testing tool is SOAPUI which has both free and paid versions. There are other tools that you can use as needed.

现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:110685036

3. Automatic GUI testingEdit

This type of automated testing is the most rigorous form of automation as it involves testing the user interface of the application.

This is difficult because the GUI is very easy to change. However, this type of testing also comes closest to what users do with our application. Since the user will be using a mouse and keyboard, automated GUI testing also mimics the same behavior by using the mouse and keyboard to click or write to objects on the user interface. Therefore, we can catch bugs early and it can be used in many scenarios, like regression testing or filling in forms, which takes too much time.

The most popular GUI testing tools are QTP (now called UFT), Selenium, Test Completion and Microsoft Coding UI (which is part of Visual Studio Ultimate and Premium editions).

4. Several misunderstandings about automated testing

Over the years, I've heard a few misconceptions about test automation. I thought I should clarify these issues in this post as well.

Myth #1. Automation will replace manual testers.

Test automation is about helping testers conduct testing in a faster and more reliable way. It can never replace humans.

Think of test automation as a car. If you walk, it will take you approximately 20 minutes to reach your home. But if you use a car, you'll be there in two minutes. The driver of the car is still you, a human being, however. The car helps the human being to achieve his/her goals faster. Also, most of your energy is saved because you're not walking. So you can use that energy to do more important things.

The same goes for automated testing. You can use it to quickly test most of the repetitive, lengthy, and tedious tests and save your time and energy to focus on and test new and important features.

As James Bach once said wonderfully:

“Tools don’t test. Only people test. Tools only do things that “help” people test.

Tools can click objects. But the location of the click is always told by the manual tester. I think you see what I mean now.

Myth 2. Everything under the sun can be automated.

If you try to automate 100% of your test cases, maybe you will be able to do that, but if you can, then our first point becomes wrong. Because if everything is automated, what will manual testers do?

Puzzled? Is it right?

Actually, the point is, you cannot automate 100% of your test cases. Because we, as testers, believe that no application can be 100% tested. There will always be scenes that we miss. Bugs only occur when clients use your application.

So if the application cannot be 100% tested, how can it be guaranteed to be 100% automated?

Moreover, the likelihood that you will be able to automate all existing test cases is very slim. There are always some scenarios that are difficult to automate and easier to do by hand.

For example, one user enters data, a second user approves the data, a third user views the data, and a fourth user prohibits viewing of the data. These scenarios can be automated, but they require a lot of time and effort. So it's easier if you just have to do it manually.

Remember, we use cars for distances, but there may be long signals on the road, there will be fuel consumption, there will be parking space issues, parking charges and more headaches. In some cases we just walk to our destination :).

Therefore, you shouldn't try to automate everything. Only those scenarios that are important need to be automated and would take a lot of time to do manually.

Myth #3. Automation only involves recording and playback.

Please don't live in a fantasy world. This illusion is actually caused by false advertising from different automation tool vendors. They say you just record and playback your steps and your test cases will be automated. This is a big lie!

Automation is everything except recording and playback. Pure automation engineers often do not use the record and playback features at all. Recording and playback are often used to understand how the tool generates scripts for our steps.

Once we understand scripting, we always use scripts to create automated tests. Remember, if you want to do test automation, you have to know programming. . On the other hand, if you don't know how to program, don't be too bold. Because like any other task, programming can be learned through practice and dedication.

I know people who didn't even have a computer science background, but they learned to program and now they're amazing automation engineers. At Microsoft, they hire testers who can program. They are called SDET (Software Development Engineer for Testing). The first line of the job description says: “sdet wrote a lot of code….”

Please learn programming, don't run away from it. It will make you an amazing tester

For an organization to implement automated testing, it must first have a correct understanding of automated testing. We usually have some misunderstandings about automated testing, such as:

Myth #4. All test cases can be automated

First of all, it is unnecessary to automate all test cases, because automated testing requires the development of test scripts, and it also takes time to execute automated tests. Automating all test cases may not be the most cost-effective.

On the other hand, automated testing is mainly used to reduce the workload of regression testing. The most important thing for regression testing is to avoid the most basic functions and the most commonly used functions from being affected. From this theory, we will It is enough to automate the test cases of the functions and the most commonly used functions.

At present, the highest automated testing rate in the world is only about 80%.

Misconception #5. Automated testing cannot find bugs

Automated testing is mainly to avoid bugs in the original correct functions due to code modifications, rather than to dig out more and deeper bugs. More and deeper bugs are discovered through exploratory testing after the testers are liberated.

Myth #6. Automated testing will immediately reduce the number of testers significantly

Although automated testing will eventually reduce the workload of testing, it will not be immediate, because if you want to implement automated testing, you must first develop automated test scripts and build an automated test environment, which requires a lot of personnel and energy. . How long it takes for automated testing to see results depends on the length of the process.

Myth #7. Automated testing can replace manual testing

Automated testing is only suitable for regression testing. For new function testing, you still have to rely on testers to design test cases and execute them manually.

Myth #8. Only performance testing needs automation

In addition to performance testing, automated testing is also widely used in functional testing.

More than half of the automated test scripts abroad are used for functional verification testing.

Myth #9. Automated testing is too difficult to get started

Automated testing has been implemented for a long time, and many automated testing frameworks, tools, and tutorials can be found online. If you really want to implement automated testing, just arrange for professional testers to start learning, and automated testing will be easy to implement.

Action is worse than excitement.

Finally, automated testing is neither so magical that it can solve all the problems of testing, nor is it very sophisticated and difficult to get started. With a correct understanding of automated testing and a down-to-earth implementation of automated testing, you will be able to enjoy the benefits that automated testing can give you. the benefits brought about.

This is exactly:

It is not advisable to talk about a tiger changing color, and it is not feasible to treat it as a silver bullet

Correctly understand automation and implement it down-to-earth

Finally, I would like to thank everyone who read my article carefully. Looking at the increase in fans and attention, there is always some courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly!

Software Testing Interview Document

We must study to find a high-paying job. The following interview questions are from the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
 

Insert image description here

Guess you like

Origin blog.csdn.net/IT_LanTian/article/details/132907070