1. Please describe the automated testing process?
The automated testing process can generally be divided into the following seven steps:
Write automated test plans;
Design automated test cases;
Write automated testing frameworks and scripts;
Debug and maintain scripts;
Unattended testing;
Post-script maintenance (adding use cases, developing updated versions).
2. Has automated testing ever falsely reported bugs? What about false positives?
There have been false positives. Sometimes the automated test report shows that a bug has been found, but the actual bug does not exist through manual testing.
Common reasons for false positives are:
The element positioning is unstable, and the stability of the script needs to be improved as much as possible;
The development updated the page but the test did not update the maintenance in time.
3. What is PO mode?
Full name: page object model Abbreviation: POM/PO, the core idea of the PO model is layering, achieving loose coupling, realizing script reuse and easy maintainability of scripts.
The PO mode is mainly divided into three layers:
1. Basic layer BasePage: Encapsulate some of the most basic selenium's native api methods, element positioning, frame jumping, etc.
2. PO layer: element positioning, element object acquisition, page action
3. Test case layer: business logic, data-driven.
The relationship between the three: the PO layer inherits the base layer, and the test case layer calls the PO layer.
What is the difference between po mode and non-po mode?
4. How to automate the testing of functions containing verification codes?
Automated testing of functional modules with verification codes can be done in the following ways:
Let the development remove the captcha. Before going online, let the development remove the verification code verification to facilitate automated testing;
Set up a universal verification code. Before going online, let the development generate a fixed verification code to facilitate automated testing.
Bypass login via cookie.
Automatic identification technology recognizes the verification code. The first is: OCR automatic identification technology, and the second is: identification through the interface of the third-party coding platform.
5. How to improve the stability of the script?
To improve the stability of the script, you can do the following:
Do not right-click to copy xpath (the absolute path is very unstable), write the relative path yourself;
There is no problem with positioning, the second influencing factor is waiting, and sleep waiting should be used as little as possible (affecting execution time);
The positioning element method is repackaged, combined with WebDriverWait and expected_conditions to determine the element method, and encapsulates a set of positioning element methods by itself;
6. If an element cannot be positioned, what reasons do you generally consider?
An element cannot be located, possible reasons are:
Page loading elements are too slow, adding waiting time;
The page has a frame frame page, you need to jump into the frame frame before positioning;
Maybe the element is a dynamic element, and the positioning method needs to be optimized. You can use some elements to locate or locate through parent nodes or sibling nodes;
The element may be recognized, but it cannot be operated, such as the element is unavailable, unwritable, etc. You need to use js to complete the pre-operations first.
7. What is the execution strategy for your automation use case?
The meaning of the execution strategy of the automation use case:
Automated test cases are used for monitoring. Integrate into Jenkins to create scheduled tasks and execute them regularly;
Some use cases have to come back before the product goes live. Bind the task to the developed build task on Jenkins to trigger execution;
Some use cases don't need to be executed very often. Jenkins creates a task and manually builds it when it needs to be executed.
8. Principles for writing automation use cases?
The principles of writing automation use cases include the following aspects:
A use case is a complete scenario.
A use case verifies only one function point.
Try to avoid dependencies between use cases and use cases.
After a use case is tested, the test scenario needs to be restored to avoid affecting the execution of other use cases.
After the script is written, it needs to be executed repeatedly and debugged until it runs normally. The writing and naming of scripts must comply with management regulations for unified management and maintenance.
9. How does selenium work?
The working principle of Selenium can be summarized in the following five aspects:
Selenium client (an automated test script written in Python and other languages) initializes a service service, and starts the browser driver chromedriver.exe through webdriver;
Send an HTTP request to the browser driver through RemoteWebDriver, the browser driver parses the request, opens the browser, and obtains the sessionid, which needs to be carried if the browser is operated again;
After opening the browser, all selenium operations (access address, search element) are linked to the remote server through RemoteConnection, and then use the execute method to call the request method to request the remote server through urlib3;
The browser performs the corresponding action through the requested content;
The browser returns the result of the executed action to the test script through the browser driver.
10. What is your automation framework?
The automated testing framework built adopts a layered design model framework, which is mainly divided into the following modules:
common: Some basic underlying method classes, such as: test report class, data configuration reading class, log class, encapsulating webdriver class, database connection class, sending mail class, public method class, as long as it is some functions we want to achieve, You can put the implementation of the basic method in the common folder.
config: Configuration files are placed here, such as: account password, database connection address, etc.
log: After running the use case, the log storage folder.
report: After running the test case, the storage folder of the test report.
page: In the POM design mode, the method for specific UI page operations.
test_case: Specifically store the written test cases.
run_all: Used to run test cases in batches.