For testers, whether functional testing or automated testing, or performance testing, it is necessary to write test cases, so we must first understand some characteristics of manual test cases and automated test cases, in order to better carry out automated testing work.Copy the code1.1 Manual and automated test cases
Manual test cases are for functional testers, while automated test cases are for automated test case frameworks or tools.
Manual test case features
(1) Good exception handling ability, can judge and verify whether the current step is correctly realized through artificial logic;
(2) Manual execution of use cases has a certain step jump;
(3) Manual test step by step tracking, able to locate problems carefully;
(4) Mainly used to find functional defects;
Automated test case features
(1) The execution object is a script, and any calculation needs coding definition;
(2) Strong correlation between use case steps;
(3) mainly used to ensure that the main function of the product is correct and complete, so that the test personnel from the tedious and repetitive work out;
(4) At present, the automation test phase is focused on smoke test and regression test.
(note
Through comparison, it is found that automated testing can not completely replace manual testing, the purpose of automated testing is only to let testers from the tedious and repetitive testing process, put more time and energy on more valuable testing, such as exploratory testing.
)
Automated test case considerations
1. Not all manual test cases should be converted to automated test cases.
2. For the sake of script development costs, don’t choose use cases where the process is too complex, and if necessary, consider splitting the process into multiple use cases to implement the script.
3. Choose use cases that best build scenarios. For example, a functional module divided into multiple use cases that use the same scenario has the advantage of facilitating the construction of a keyword test model.
4. Use case selection can be purposeful. For example, this part of the use case for smoke testing, etc., of course, there is overlap, if the current use case does not meet the requirements, then the use case has to be modified to fit the script and requirements.
5. The selected use case can be the body flow, which is used for smoke testing (baike.so.com/doc/6504729…
6. Select test cases that you consider repetitive and obscene. Such as field validation, prompt validation, and so on, this part is suitable for regression testing.
7, automated tests can also be used to do configuration checks, database checks. These may go beyond manual use cases, but they are part of an extension of use cases that the project leader can optionally add.
8, usually in manual testing, if you need to construct some complex data or repeat some simple mechanical actions, tell the script, let it help you, perhaps your efficiency will be improved.
1.2 Types of automated tests
Testing static content
Static content tests are the simplest tests to verify the existence of static, immutable UI elements, such as:
(1) Each page has the expected page title, which can be used to verify that the link points to an expected page;
(2) The home page 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 and trademark information, etc.;
(4) Use title text on each page
The label? Does each page have the correct header text? You may (or may not) need to automate testing of page content. If your web page is impervious, testing the content manually is sufficient. If the location of your application file has been moved, content testing is very valuable.
The test link
A common mistake in 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 links do not change often, manual testing is sufficient. However, if your web designer changes links frequently or files are redirected from time to time, link testing should be automated.
A functional test
In your application, the need to test the application of a specific function, need some type of user input, and returns some kind of result, usually involving multiple pages, a functional test based on form input page, which contains a number of input fields, submit and cancel the operation, and one or more response page. User input can be entered through text input fields, check boxes, drop-down lists, or any other browser supported input.
Functional testing is often the most complex type of testing that requires automation, but it is often the most important. Typical tests are logging in, registering a website account user account operations, account Settings changes, complex data retrieval operations, and so on. Functional testing usually corresponds to a description of your application’s features or design usage scenarios.
Testing dynamic elements
Usually web elements have unique identifiers that uniquely locate the elements of the page. Typically, unique identifiers are implemented using the ID or name attribute of an HTML tag.
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, and other real-time data updates.
Ajax has numerous updates to the enlargement of elements on a web page, and the simplest way is in ajax-driven applications where data can be retrieved from the application server and then displayed on the page without the need to reload the entire page, only a small portion of the page, or only the elements themselves.
1.3 Automated test case coding
1.3 Principles of automated test case writing
Finally, I would like to share with you the principles of automated test case writing:
1. A use case is a complete scenario, from the user logging in to the user finally exiting and closing the browser;
2. Verify only one function point per use case, do not 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, the reverse logic has a lot of force (for example, there are dozens of mobile phone number errors), on the other hand, the automation script itself is relatively fragile, and the implementation of complex reverse logic use cases is more troublesome and prone to error;
4. Try to avoid dependency between use cases;
5. After one use case completes the test, the test scenario needs to be restored so as not to affect the execution of other use cases. **