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