Fundamentals of Automated Testing 2

Transferred from: http://www.cnblogs.com/ryansunyu/archive/2012/07/29/2614203.html

1. What is automated testing

Take the program test program, replace the thought with the code, take the script to run instead of the manual test. Automated testing covers: Functional (black box) automated testing, functional (white box) automated testing, performance testing, stress testing, GUI (graphical User Interface) testing, security testing, and more.

"Updated on 7/28/2015"

With regard to what is automation, there is some information, and there is no explanation of the authoritative specification, the following excerpt from Wikipedia:

In software testing, test automation are the use of special software (separate from the software being tested) to Control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test Automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or add Additional testing that would is difficult to perform manually.

First, test automation is different from automation test, and testing automation covers a wider range of facets. This article is about automated testing, where these two concepts are confused for the moment.

This paragraph of English is not difficult, self-translation. A few points in my eyes: 1. Tools required; 2. Tool control process, compare expected output and actual output; 3. High repeatability and necessary testing processes can be automated; 4. Areas that are difficult to achieve by manual testing

Talk about my own understanding:

Automated testing is an extension of the idea of testing, providing a "tentacle" for test engineers, whose behavior can be seen as a tool, but in essence automated testing is a thought.

By the way, the narrow sense of automated testing refers to the GUI-based automated testing, and unit testing and API testing, you have to think how to use the manual without any tools to do it? So they are inherently part of the test automation category.

2. Advantages of automated Testing

Regression testing is more convenient and reliable, can run more, more cumbersome test, and fast and efficient; perform some manual tests that are difficult or not to be performed, such as a large number of user concurrency, a better use of resources, consistency and repeatability, automated test scripts that are fully reusable, and improved software confidence , multi-environment testing and so on.

"Updated on 7/28/2015"

The real advantage of automation is that it is easy to find: There is a test engineer (not himself) who finds an interesting phenomenon, almost all of the test positions she has applied for, and the need for automated testing experience in recruiting. But when she started working, she found that the companies were trying to do automated testing, but most of the results were not very much. However, although she was involved in a number of cups, she could always wrap the cups in a wash to deal with the next interview.

So, since automated testing has so many advantages, why do so many projects fail?

I have a personal inference: The advantages of automated testing are the result of successful completion of automated testing, and the disadvantage of automated testing is the basis for automation projects.

There is also an advantage: automated testing can solidify the knowledge of the product into a script to reduce the impact of the test staff flow on the project. But the premise of this advantage is that these scripts are easy to maintain, which requires some necessary documentation, which is another issue.

3. What you can't do with automated testing and the disadvantages

It is never possible to completely replace manual testing, where automated testing does not cover manual testing, and not every test case is designed to be automated, such as recommending the layout of a page, installation testing, document testing, compatibility testing, and resiliency testing.

Manual testing has found defects far more than automation. Automated testing is almost impossible to detect new flaws, and the biggest use is to return to ensure that the bug was not re-appearing on the new version.

The automated test tool is dead and it does not have any imagination. The quality of the automated tests depends entirely on the test engineer.

High cost investment, big risk. The technical requirements for testers are high and the testing tools are also required.

"Updated on 7/28/2015"

About the cost, including the capital budget, human resources, personnel training, hardware resources and so on. Shows the relationship between the input cost and the time of the automated test, and it is clear that the cost is high most of the time ahead.

Based on the above disadvantages, so although "expensive for" automation test engineer, I have more than half time in persuading the boss, "Pro, can not do automation." This is really a sad story.

4. Suitable for the introduction of automation

The project has a long period of time, the system version is constant, and the demand does not change frequently, it is suitable to introduce the automation test.

The system's test objects are basically recognizable and can provide a solution to unrecognized controls.

There are not a large number of non-identifiable third-party controls in the system.

Repeated testing is required, such as reliability testing, regression testing, and thousands of system tests.

5. Not suitable for automation

The project cycle is short and requirements change frequently. Even long-term projects are not suitable for automation if frequently required changes are made.

The software version is not yet stable, the main function or a large number of features have been re-changed in the possible words, nor is it suitable for automation.

No clear Project Test automation plan, measures and management.

Most objects are not recognized, and the scripting is frequently and painstakingly maintained, and one of them is that automation must fail.

6. Automated testing process "Updated on 7/28/2015"

A reasonable automated entry point: Usually, the project only has undergone a complete system test before the basic introduction of test automation conditions.

"Updated on 7/28/2015"

Personal point of view: No matter what the test, the earlier the intervention is more conducive to lower costs and reduce risk. With the emergence of new development models, automated testing also has the condition of early intervention. For example, in agile development, after the core function of a core module is completed, automated testing can be implemented for the function of the module.

Test Automation Analysis:

(1) Feasibility analysis

(2) Sample demo analysis, demo general selection of smoke test cases, check whether the script can successfully run through, the designed test points are all executed

(3) Test requirements analysis, analyze which function points are ready for automation

"Updated on 7/28/2015"

(1) Feasibility analysis is one of the most important parts of automated testing. Feasibility analysis is one of the most important parts of automated testing. Feasibility analysis is one of the most important parts of automated testing. It's important to say three times.

For feasibility analysis, please refer to 2,3,4,5 Point; one of your wrong decisions (automated test project), it is likely to give several people full-time job opportunities, from this point of view, but also promote chicken fart =

(2) Smoking demo, mainly used to verify whether your tool can be used

(3) Automated testing is not 100% test, it is impossible to achieve the coverage of manual testing, to filter function points for automated testing

Test Plan customization: The more comprehensive automated test plan, the later the more orderly to implement, the higher the success rate of automated testing

Plans don't catch up, sometimes they're too comprehensive, and maybe not a good thing.

Automated Test design phase: mainly divided into automated test framework and automated test cases.

(1) The design, development and construction of automated testing framework: should be able to ensure the distribution of testing, script modularization, data-driven, log analysis, error, Report collection, shared object library, public function library, environment configuration, unified design mode, exception handling, scene recovery of an unattended, Test framework for each individual project

"Updated on 7/29/2015"

I have another article detailing why you need an automated test framework, which is not repeated here.

Http://www.cnblogs.com/ryansunyu/p/4080985.html

(2) Automated test Case Design trilogy: The manual Test case is from scratch, and then the automated test case is written according to the manual test case. First, filter the manual test cases. Then convert the manual test cases, and finally add & Add automated test cases.

Why can't you completely replace automated test cases with manual test cases?

The scope of automated test cases is often the core business process or high repetition rate, and the coverage of automated tests cannot reach the coverage of manual tests. The use case selection for automated testing is generally positive, but there are many reverse cases, but not all automated tests for reverse scenarios are covered, but are part of the selection. Not all manual test cases can be used to automate, for example, page layout checks. Manual testing can be done without the need to return to the origin, but automated testing is often required. Automated test cases are different from manual test cases and do not require each step to write the expected results.

"Updated on 7/29/2015"

Usually when I do automated testing, I write a test case called Shake-down Test, which passes all the completed forms in the system once, just doing a navigate operation to make sure a page is available.

You can run the Shake-down test before each regression test, and you can quickly determine which features are accessible, equivalent to doing a smoke test for a whole system.

Test script design and development:

The test scripts can be roughly divided into:

(1) Linear script: A linear executable script produced directly by recording

(2) Structured scripts: scripts with sequential, looping, branching structures

(3) Shareable scripts: scripts that can be used by multiple test cases, called by other scripts (i.e., modular scripts)

(4) Data-driven scripting: scripts that test data is separated from business process control by reading data files to drive processes

(5) keyword-driven scripting: scripts, data, business separations, data and keywords in different data tables, with keywords to drive test business logic. The keyword-driven feature is that it is more like describing what a test case is doing, rather than how to do it.

(6) Hybrid script: any of the above two or more

Automated Test Execution:

(1) Unattended Testing: Environment construction, deployment and configuration; Automated test cases and test scripts are bound to each other; Automated test case execution sequence and combination

(2) exception handling and scene recovery

Submit Automated Test Products: generally need to submit implementation, test results, analysis reports, test reports, quality and so on.

test Script maintenance: strictly speaking, each phase is doing test script maintenance. An automated test program that is not worth maintaining is not worth the project. (usually there are a lot of full-time job opportunities ~lol)

Automated Test Basics 2 (RPM)