For testers, whether to perform functional testing, automated testing, or performance testing, test cases need to be written, so we must first understand some of the characteristics of manual test cases and automated test cases in order to better carry out automated testing jobs.
1.1 Manual test cases and automated test cases
Manual test cases are for functional testers, while automated test cases are for automated test case frameworks or tools.
1
Features of manual test cases:
(1) Good exception handling capabilities, able to verify whether the current step is implemented correctly through human logic judgment;
(2) Manual execution of use cases has a certain step jump;
(3) Step-by-step tracking of manual testing can locate problems in detail;
(4) Mainly used to find functional defects;
2
Features of automated test cases:
(1) The execution object is a script, and any calculation requires coding definition;
(2) The use case steps are strongly related;
(3) It is mainly used to ensure the correct and complete functions of the main product, freeing testers from tedious and repetitive work;
(4) The current automated testing phase is positioned in 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 the tedious and repetitive testing process, and devote more time and energy to more valuable testing. For example, exploratory testing.)
3
Note for automated test cases:
1. Not all manual test cases need to be converted to automated test cases.
2. Considering the cost of script development, do not choose use cases with too complicated processes. If necessary, consider splitting the process into multiple use cases to implement scripts.
3. The selected use case is best 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 to facilitate the construction of a keyword test model.
4. Select use cases can be purposeful. For example, these use cases are used for smoke testing. Of course, there will be overlaps. If the current use cases do not meet the requirements, then the use cases can only be modified to adapt to the scripts and requirements.
5. The selected use case can be the main process, which is used for smoke testing.
6. The selected test case can be the part that you think is repetitive and trivial. For example, field verification, prompt message verification, etc., this part is suitable for regression testing.
7. Automated testing can also be used for configuration check and database check. These may exceed manual use cases, but they are also part of the use case expansion, and the project leader can selectively increase them.
8. 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, perhaps your efficiency will be improved.
1.2 Types of automated testing
1
Test static content:
Static content testing is the simplest test used to verify the existence of static and unchanging UI elements, for example:
(1) Each page has an expected page title, which can be used to verify that the link points to an expected page;
(2) The homepage of the application contains an image that should be at the top of the page;
(3) Whether each page of the website contains a footer area to display the company's contact information, privacy policy, trademark information, etc.;
(4) The title text of each page is used
Tags? Does each page have the correct header text? You may need (or may not need) automated testing of page content. If your web pages are not susceptible to impact, manually testing the content is sufficient. Assuming that the location of your application files has moved, content testing is very valuable.
2
Test link:
A common mistake of a web site is an invalid link or a link pointing to an invalid page. Link testing involves each link and verifying the existence of the expected page. If the static link 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
function test:
In your application, you need to test specific functions of the application, require some types of user input, and return a certain type of result. Usually a function test involves multiple pages, a form-based input page, which 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 browser supported input.
Functional testing is usually the most complex type of testing that requires automated testing, but it is usually the most important. Typical tests are login, registration of website account user account operations, account settings changes, complex data retrieval operations, and so on. Functional testing usually corresponds to your application’s description of application features or design usage scenarios.
4
Test dynamic elements:
Usually webpage elements have unique identifiers, which are used to uniquely locate the elements of the webpage. Usually, the unique identifier is realized by the id attribute or the 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, but the browser does not need to reload the page, such as animations, RSS feeds, and other real-time data updates.
Ajax has countless updates to enlarge the elements on the web page. The easiest way is in an Ajax-driven application. The data can be retrieved from the application server and then displayed on the page without reloading the entire page, only a small part of the page. , Or only the element itself is reloaded.
1.3 Principles of writing automated test cases
1.3 Principles of writing automated test cases
Finally, I will share with you the principles of writing automated test cases:
1. A use case is a complete scenario, from the user logging in to the system to finally exiting and closing the browser;
2. A use case only verifies one function point, don't try to verify all functions after the user logs in to the system;
3. Write as few reverse logic use cases as possible. On the one hand, because the reverse logic is a lot of effort (for example, there are dozens of cases where the phone number is incorrectly entered), on the other hand, the automated script itself is relatively fragile, and complex reverse logic use cases are troublesome and error-prone to implement;
4. Try to avoid dependencies between use cases;
5. After a use case is tested, the test scenario needs to be restored to avoid affecting the execution of other use cases.