How to use Robotframework to write good test cases

Source: Internet
Author: User

Introduced
    • This document will be a "high-level" principle of how to use Robotframework to write good test cases. The details of how to use robotframework to interact with your test system are not included in this document.
    • The most important rule is to ensure that the test case is People who are familiar with this field are as simple as possible.
    • For more information on this topic, you can check out these great resources below:
    • Writing maintainable Automated Acceptance Tests Dale H. Emery
    • How to Structure a scalable and maintainable acceptance Test Suite Andreas Ebbert-karroum
Naming a test suite
    • The name of the kit should describe as much as possible the purpose of the kit.
    • The name can be a bit longer, but it's a bit too long if it's more than 40 words.
    • Remember that the Robotframework suite name is converted directly from the file/directory name. The suffix of the file is removed and the underscore is converted to a space, and if your words are lowercase, the initial letters are converted to uppercase. For example, Login_test.txt will be converted to login Tests, Dhcp_and_dns will be converted to DHCP and DNS.
Name of the test case
    • The name of the test case should be similar to the name description of the package.
    • If a suite contains many similar test cases, and the test suite itself is well-named, then the name of the use case can be shortened.
    • The name in the test case file should exactly say what you need to do.

Keyword naming
    • Similarly, the name of the keyword should be clear and specific.
    • Should be able to express what this keyword has done, not how it is done.
    • Keywords should be very different levels of abstraction (for example, "input character" or "user logged in to System").

Generation and decomposition of naming
    • Try to describe what this step has done with a name.
    • Maybe you can use a keyword that already exists.
    • If the build or decomposition contains unrelated steps, you can accept a more abstract name.
    • Listing the steps in the name is a recurring and maintenance problem (e.g. login system, add user, activate alarm and check balance).
    • It may be necessary to use some generic names like "Initialize the system"
    • Everyone who uses these test cases needs to understand what these build or explode actions are.

Documentation for the document test suite
    • It is often a good idea to add a document to the lowest-level suite that contains the test case.
    • High-level packages do not need to be documented so frequently.
    • The documentation should contain the necessary background information, such as why to create these test cases, the points to be aware of in the test environment, and so on.
    • The document content does not simply duplicate the name of the suite.
    • If you don't have a document, you might as well not add it.
    • The contents of the document do not contain too detailed information about the test case.
    • The test case itself should be sufficiently clear and understandable.
    • Repetitive information is a waste, and it is not easy to maintain.
    • You can add some links to the details in the document.
    • If you need to add a "name-value" group such as (version: 1.0 or Os:linux) to a document, consider using a test suite metadata

Documentation for test Cases
    • Test cases typically do not require documentation.
    • The package name and document and the name of the use case have provided sufficient background information.
    • The structure of the test case should be that no documentation is required or that other comments are clear enough.
    • Tags are usually more flexible than documents, and they provide more functionality.
    • When the documentation for the test case is useful, don't worry about adding yo.

User-defined keyword document
    • If the keyword is very simple and clear, no documentation is required.
    • A good name and a clear structure are enough to explain everything.
    • One important use of user-defined keyword documents is to record information about parameters and return values.
    • The documents that are displayed in the RIDE (for example, where the keyword is complete) and in the resource file are generated by libdoc.py.
Structure of the test suite
    • The use cases in the suite should be interrelated.
    • If the test case has the same build or decomposition part, then they should belong to a suite.
    • Unless it is data-driven, do not put more than 10 test cases in a suite.
    • The test case should be independent.
    • Initialize them with build and explode.
    • Sometimes if the test cases are not related to each other
    • For example, it may be because all the use cases are independent to take too much time to initialize.
    • The associated test cases are just a few (up to 4 to 5)
    • The next use case is used to validate the results of the previous use case. (with ${prev TEST STATUS} this variable)
Structure of test Cases
    • The test case should be understandable.
    • A test case tests only one thing.
    • Of course, things can be big and small.
    • Choose an appropriate level of abstraction.
    • Consistent use of abstract levels (single-level abstract principles)
    • Contains only information relevant to the test.
    • Use cases can be divided into two types
    • Test Cases for workflow
    • Data-driven test cases
Test Cases for workflow
    • Generally, the following sections are available:
    • Preconditions (optional, usually in the build section)
    • Action (perform some action on the system under test)
    • Verify (there must be a validation section!) )
    • Cleanup (optional, usually in the decomposition section, to ensure that the use case has been completed)
    • Keywords are used to describe what this use case does.
    • Use a clear keyword name and an appropriate level of abstraction.
    • Should contain enough information to enable manual execution to start.
    • You should never need documentation or communication to tell you what this use case is doing.
    • Different use cases can have different levels of abstraction.
    • Detailed functional testing is more accurate.
    • End-to-end testing can be a high level of abstraction.
    • A test case should use only one level of abstraction.
    • Different styles.
    • More attention should be paid to technical details for the underlying detailed testing and integration test cases.
    • "Executable definition" to play the demand.
    • Use the language in the domain (terminology?) )。
    • Everyone (including the customer and the product owner) should be able to understand.
    • No complicated logic.
    • Do not use for loops or if/else to judge the structure.
    • Be careful to assign values to variables.
    • Test cases should not look as difficult to read as scripts.
    • Up to 10 steps, the less the better.
Data-driven test cases
    • Each test case has a high-level keyword.
    • Different parameters are created for different tests.
    • Keywords typically contain processes that are similar to the processes described in the workflow test cases in the same use case file.
    • It is recommended to use the test template feature.
    • There is no need to repeat the keywords multiple times.
    • Testing in one use case makes it easier to test multiple changes.
    • If possible, it is recommended to name the column header.
    • If you really need a lot of test cases, consider making them dependent on the external model.

User Defined Keywords
    • It should be easy to understand.
    • The same criteria as the workflow test case.
    • Different levels of abstraction.
    • Can contain some programming logic (for loop, if judging these)
    • Especially for the bottom of the keyword.
    • Complex logic should be placed in the library rather than in user-defined keywords.
Variable
    • Encapsulates a constant or complex value.
    • Passing information from the command line.
    • Pass information between keywords.
Name of the variable
    • Clear, but not too long.
    • It can be explained in the variable table with comments.
    • Keep consistent with each usage scenario:
    • The lowercase local variables are only available in the current use case or keyword.
    • Global variables or suites, use case-level variables need to be capitalized.
    • Spaces or underscores can be used to split the words in a variable.
    • It is recommended to also list variables that are set as dynamic in the variable table.
    • Use Set Global/Suite/Test variable keywords to name variables.
    • The initial value of the variable should be able to explain what the actual value should be.

Passing and returning values
    • The usual way is to return values by keyword, assign them to variables, and pass them to the parameters of other keywords.
    • Follow this method clearly and easily.
    • It looks like programming.
    • The alternative is to use Set Test Variable keywords
    • No programming style is required on the test case level.
    • It's difficult to reuse keywords if you want to follow them more complex.
    • Avoid this level of test cases below.

Avoid using sleeping
    • The sleeping is very fragile.
    • On average, safe boundary values can make sleeping a long time.
    • Replace sleeping with keywords that contain a certain action trigger
    • Wait for a value that needs to have a timeout.
    • Keywords can be used Wait Until… to start
    • If possible, use the built-in keywords Wait Until Keyword Succeeds to wrap other keywords.
    • Sometimes sleeping is one of the simplest ways to solve a problem.
    • Always use caution, not sleeping in custom keywords or other keywords that you use frequently.
    • Sleeping is useful for pausing test execution when debugging.
    • Although dialogslibrary is usually more suitable for doing this.

How to use Robotframework to write good test cases

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.