Two days ago, I went out with my boss to do pre-sales. The main purpose was to sell our automated testing services, and the tool used was HP UFT. People who have done automation should know that UFT is already one of the best tools in the field of automated testing. The customer is a person with a technical background, so it is not easy to fool him. We prepared a lot of slides about the advantages of automated testing, so he came up and asked directly what the shortcomings of your tools were. Then I started to talk to him about the shortcomings. What got out of hand was that every time I explained a problem, he would have more questions. In the end, my mouth was dry and I couldn't explain everything clearly. Apart from sighing that money is not so easy to make, I can only blame myself for not being able to brag fluently in English.
Among them was a question that I thought about for a long time after I came back. At that time, he pointed to the POC (Prove of Concept) script I made and asked: "Since record & playback can be used as a script, why do we need an automated testing framework?" In short, why should I spend more money? Money to buy your framework? My first reaction was, what? are you kidding me? How to do automated testing without a framework? Of course, my answer is very official, mainly explaining it to him from the perspective of maintenance, reusability, and ease of use, and he doesn't seem very satisfied.
Looking back, I thought about it, why do we need an automated testing framework? The more I think about it, the more I feel wronged, because I want to ask you developers, why do you use frameworks when you are doing projects? The essence of automation is not to write programs to test programs. Since development requires a framework, why not automate testing.
Complaints are complaints. I checked some information carefully.
What is a framework?
A framework is a reusable design of all or part of a system, represented by a set of abstract components and methods of interaction between component instances; another definition holds that a framework is an application skeleton that can be customized by application developers. The former is defined from the aspect of application and the latter is given from the aspect of purpose. It can be said that a framework is a reusable design component that stipulates the application architecture, clarifies the dependencies, responsibility distribution and control flow between the entire design and collaborating components, and is expressed as a set of abstract classes and their instances. The method of collaboration among them provides a context relationship for component reuse. Therefore, large-scale reuse of component libraries also requires frameworks. In fact, so far, the framework has not been uniformly defined. I prefer the definition given by Ralph Johnson:
A framework is a reusable design expressed by a set of abstract classes and collaborative relationships between their instances [Johnson 98]. This definition defines the framework from the perspective of the connotation of the framework. Of course, the definition of the framework can also be given from the perspective of the purpose of the framework: a framework is a part of the design and implementation of an application within a given problem area [Bosch 97].
Why use a framework?
Another natural question. Because the development of software systems has become very complicated today, especially server-side software, which involves too much knowledge, content, and problems. Using other people's mature frameworks in some aspects is equivalent to asking others to help you complete some basic work. You only need to concentrate on completing the business logic design of the system. Moreover, the framework is generally mature and robust, and it can handle many detailed issues of the system, such as transaction processing, security, data flow control and other issues. In addition, frameworks are generally used by many people, so the structure is very good, so the scalability is also very good, and it is constantly upgraded, and you can directly enjoy the benefits of other people's code upgrades.
Why build an automated testing framework?
I used to think that the most important thing in automated testing was to find the test object. Now I understand a truth, automated testing without a framework cannot find the object, and even if it is found, it will not be happy. Just like in reality, it is difficult for people without a car or a house to find a partner.
The development of automated testing is usually determined by the needs of automated testing. This requirement mainly includes:
- Automated testing is easier to implement. What this means is that you need to be able to write test scripts conveniently. A good automated testing framework allows people who are not very technical to write automated test scripts, hum.
- Solve problems existing in the automated test script itself, such as exception handling and scenario recovery.
- Tests are easy to maintain. Automated testing projects are basically not well managed and maintained, so it must be a big pit. I can say responsibly that you won't see the output without automated testing for a year or so. So management and maintenance has become the most important thing. And a good framework can reduce the manpower and material resources you invest in management and maintenance.
- Reusability. One of the meanings of a framework is that it can be reused. So in the framework, you can implement some common functions and simplify the script development process.
- Beautiful and easy-to-read test reports. Take UFT as an example. The test reports it produces are only based on test scripts, and there are no reports based on test sets, so if you want it, you can implement it in the testing framework.
There are many test requirements, I can't list them all. Most of the requirements can be customized in the test framework. Now you can answer the above question, record & playback will not be happy, you need an automated testing framework.
Please carefully consider whether you need automated testing (high cost and high risk)
Automated testing is a very arrogant thing, and it is very picky. First, the project cycle must be long, but the requirements will not change frequently; secondly, most objects in the system must be identifiable, and there should not be a large number of third-party plug-ins. And you need to know that you can't expect automated testing to help you find new bugs. Automated testing itself is not imaginative (compared to manual testing). Its advantage lies in repeated iterations, and its value output lies in long-term regression testing to ensure long-term stable version updates of the product under test.
Regarding the entry point for automated testing, the basic conditions for introducing automated testing are usually only met after a complete system test.
The successful cases of automated testing I have done so far all have good management and excellent testing frameworks. Without one of the two, automated testing will inevitably become a big pitfall.
Finally, filling in holes is very expensive~
2023 latest Jmeter interface test from entry to proficiency (full set of practical project tutorials)