1. Manual testing and automated test cases
Manual test cases are for functional testers, while automated test cases are for automated test case frameworks or tools.
1) Characteristics of manual test cases
Good exception handling capabilities, able to use human logical judgment to verify whether the current step is implemented correctly;
Manual execution of use cases has certain step jumps;
Manual test step-by-step tracking can locate problems in detail;
Mainly used to find functional defects;
2) Characteristics of automated test cases
The execution object is a script, and any calculation requires coding definition;
There is strong correlation between use case steps;
It is mainly used to ensure that the main functions of the product are correct and complete, freeing testers from tedious and repetitive work;
The current automated testing phase is positioned at smoke testing and regression testing.
(Note: Through comparison, it is found that automated testing cannot completely replace manual testing. The purpose of automated testing is only to free testers from tedious and repetitive testing processes and focus more time and energy on more valuable tests. Such as exploratory testing.)
3) Things to note about automated test cases
① Not all manual test cases need to be converted into automated test cases;
② Considering the cost of script development, do not choose use cases with too complex processes. If necessary, consider splitting the process into multiple use cases to implement the script;
③The selected use case should preferably be able to build a scenario. For example, a functional module is divided into multiple use cases, and multiple use cases use the same scenario. The advantage of this is that it facilitates the construction of keyword testing models;
④Selecting use cases can be purposeful. For example, this part of the use case is used for smoke testing, etc. Of course, there will be overlapping relationships. If the current use case does not meet the requirements, then the only way is to modify the use case to adapt to the script and requirements;
⑤ The selected use case can be the main process, which is used for smoke testing (if you don’t understand the professional terminology, it will take a lot of effort);
⑥The selected test cases can be the parts that you think are cumbersome to execute repeatedly. For example, field verification, prompt information verification, etc., this part is suitable for regression testing;
⑦Automated testing can also be used for configuration checks and database checks. These may exceed manual use cases, but they are also part of use case expansion, and the project leader can selectively add them;
⑧In normal manual testing, if you need to construct some complex data or repeat some simple mechanical actions, tell the script and let it help you, maybe your efficiency will be improved.
2. Automated test types
1) Test static content
Static content testing is the simplest test and is used to verify the existence of static, unchanging UI elements, such as:
① Each page has an expected page title, which can be used to verify that the link points to an expected page;
②The home page of the application contains an image that should be at the top of the page;
③Whether each page of the website contains a footer area to display the company's contact information, privacy policy, trademark information, etc.;
④Does the title text of each page use the <h1> tag? Whether each page has the correct header text;
You may (or may not) need to automate testing of page content. If your web pages are not susceptible, manual testing of the content may be sufficient. Assuming the location of your app files has moved, content testing can be extremely valuable.
2) Test link
A common mistake on web sites is broken links or links pointing to invalid pages. Link testing involves individual links and verifying that the expected page exists. If static linking does not change frequently, manual testing is sufficient. However, if your web designer frequently changes links or files are redirected from time to time, link testing should be automated.
3) Functional testing
In your application, you need to test a specific function of the application that requires some type of user input and returns some type of result. Usually a functional test involves multiple pages, a form-based input page that contains several input fields. , submit and cancel operations, and one or more response pages. User input can be through text input fields, check boxes, drop-down lists, or any other input supported by the browser .
Functional tests are typically the most complex type of testing that requires automated testing, but are often the most important. Typical tests are login, website account user account operations, account setting changes, complex data retrieval operations, etc. Functional tests typically correspond to usage scenarios of your application that describe application features or design.
4) Test dynamic elements
Usually web page elements have unique identifiers, which are used to uniquely locate the elements of the web page. Typically, a unique identifier is implemented using the id attribute or name attribute of the HTML tag.
5) Ajax test
Ajax is a technology that supports and dynamically changes user interface elements . Page elements can be changed dynamically without requiring the browser to reload the page, such as animations, RSS feeds, other real-time data updates, etc.
Ajax has numerous updates to the amplification of elements on a web page. The simplest way to do this is in an Ajax driven application, where the data can be retrieved from the application server and then displayed on the page without reloading the entire page, just a small portion of the page. , or only the element itself is reloaded.
3. Principles for writing automated test cases
Finally, let me share with you the principles of writing automated test cases:
①A use case is a complete scenario, from the user logging in to the system to finally exiting and closing the browser
②A use case only verifies one function point. Do not try to verify all functions after the user logs in to the system;
③Write as few reverse logic use cases as possible. On the one hand, reverse logic requires a lot of effort (for example, there are dozens of cases where a mobile phone number is entered incorrectly); on the other hand, the automation script itself is relatively fragile, and complex reverse logic use cases are cumbersome and error-prone to implement.
④ Try to avoid dependencies between use cases.
⑤After completing the test of a use case, the test scene needs to be restored to avoid affecting the execution of other use cases.
[Full 200 episodes] A collection of super detailed advanced tutorials on automated testing of Python interfaces, truly simulating the actual combat of enterprise projects.