The test case consists of keywords, with three sources of the keywords:
1 introduced from the test library; 2 introduced from a resource file; 3 introduced from the keyword table (custom keywords)
Here is a typical form of test case organization.
There are 2 test cases "Valid Login" and "Settingvarriables" in the figure. The first column is the use case name, the second column is the keyword, these keywords to implement the specific test work, the following column is the parameter column, the parameters required to place the keyword. Validlogin This use case is actually very clear, we read this use case using the keyword can be clearly seen is a landing test.
We see that the keywords are actually similar to the functions in the programming language, and they sometimes have to input parameters (arguments). Keywords require parameters, how many parameters are required, and what parameters are usually given in the keyword's document. If you follow the annotation specification when you write an extension library, you can build it using libdoc.py or Javadoc (when you write an extension library using Java).
From the 2 examples, we can see:
- Create directory requires 1 parameters, CopyFile requires 2, and no operation does not require parameters.
- We can input the variable as a parameter (${curdir} is a variable, which is explained later).
- Some parameters have a default value, if you do not enter it will take the default value, such as Create File, the default value of the third parameter is UTF-8
There are also some details that we do not use, which are not noted here, and can be found in section 2.2 of the official documentation.
4. Named parameter: can give the parameter name, so that the meaning of the parameter is clearer (of course, the test class library to provide such support)
How to write the robot framework test Case 2---(test case Syntax 1)