From 76437983436a80d12dca827fe255eb44716bae3a Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 21 Nov 2020 14:44:50 +0300 Subject: [PATCH 01/24] initial translation --- README.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/README.rst b/README.rst index 0b632e1..cc56cca 100644 --- a/README.rst +++ b/README.rst @@ -1,7 +1,8 @@ -How to write good test case -=========================== +Как писать автотесты используя Robot Framework +===================================================== -This project documents general guidelines for writing good test cases using + +Этот проект является авторизованым переводом оригинального руководства `How to write good test cases using Robot Framework `_ и описывает общие правила написания хороших автоматизированных тестов с использованием `Robot Framework `_. -The how-to itself is in ``_ file. +Собственно советы по написанию находятся в файле ``_. From dad21185c5cdab386d7f732498a9ade9b96215ce Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 21 Nov 2020 15:28:00 +0300 Subject: [PATCH 02/24] Update README.rst style fix --- README.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.rst b/README.rst index cc56cca..68347d1 100644 --- a/README.rst +++ b/README.rst @@ -2,7 +2,7 @@ ===================================================== -Этот проект является авторизованым переводом оригинального руководства `How to write good test cases using Robot Framework `_ и описывает общие правила написания хороших автоматизированных тестов с использованием +Авторизованый перевод оригинального руководства `How to write good test cases using Robot Framework `_ описывает общие правила написания автоматизированных тестов с использованием `Robot Framework `_. Собственно советы по написанию находятся в файле ``_. From 09483067c6b5f99937e7033ae3972a46db1de814 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 21 Nov 2020 15:36:33 +0300 Subject: [PATCH 03/24] "Test suite names" section translated. --- HowToWriteGoodTestCases.rst | 54 +++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 30 deletions(-) diff --git a/HowToWriteGoodTestCases.rst b/HowToWriteGoodTestCases.rst index 988e10b..53b0588 100644 --- a/HowToWriteGoodTestCases.rst +++ b/HowToWriteGoodTestCases.rst @@ -1,62 +1,56 @@ .. default-role:: code ================================================== -How to write good test cases using Robot Framework +Как писать автотесты используя Robot Framework ================================================== -.. contents:: Table of contents: +.. contents:: Содержание: :local: :depth: 2 -Introduction +Введение ============ -- These are high-level guidelines for writing good test cases using Robot +- Это руководстов дает обобщенные советы по написания наборо тестов с использованием Robot Framework. - - How to actually interact with the system under test is out of - the scope of this document. + - Детальное описание взаимодействия с тестируемыми системами выходит за рамки настоящего руководства. -- Most important guideline is keeping test cases as easy to understand as - possible for people familiar with the domain. +- Важнейшим принципом написания тестов является его максимальная понятность для людей знакомых с предметной областью. - - This typically also eases maintenance. + - Обычно такие тесты еще и легко поддерживать. -- For more information about this subject, you may want to take a look at - these great resources: +- За дополнительными сведениями по этой теме вы можете обратится к следующим замечательным источникам: - - `Robot Framework Dos and Don'ts`__ slides that are based on this how-to. - - `Writing Maintainable Automated Acceptance Tests`__ article by Dale Emery. - - `How to Structure a Scalable And Maintainable Acceptance Test Suite`__ - blog post by Andreas Ebbert-Karroum. + - `Robot Framework Dos and Don'ts`__ презентация в основе которой это руководство. + - Статья Дейла Эмери `Writing Maintainable Automated Acceptance Tests`__. + - Запись в блоге Андреаса Эбберт-Кароум `How to Structure a Scalable And Maintainable Acceptance Test Suite`__. __ http://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts -__ http://cwd.dhemery.com/2009/11/wmaat +__ http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintainable-acceptance-test-suite -Naming -====== +Именование +========== -Test suite names ----------------- +Названия наборов тестов +----------------------- -- Suite names should be as descriptive as possible. +- Названия наборов тестов должны быть описательными настолько, насколько это возможно. -- Names are created automatically from file or directory names: +- Имена создаются автоматически на основе названий файлов или каталогов: - - Extensions are stripped. - - Underscores are converted to spaces. - - If name is all lower case, words are capitalized. + - Расширения файлов отбрасываются. + - Символы подчеркивания преобразуются в пробелы. + - Если имя в нижнем регистре, то слова пишутся заглавными буквами. -- Names can be relatively long, but overly long names are not convenient for - the file system. +- Имя может быть длинным, но слишком длинные имена могут не походит под ограничения файловой системы. -- The name of the top level suite can be overridden from the command line - using the `--name` option if needed. +- В случае необходимости имя набора тестов может быть перезаписано из командной строки с использованием опции `--name`. -Examples: +Примеры: - `login_tests.robot` -> `Login Tests` - `IP_v4_and_v6` -> `IP v4 and v6` From 8e97e825ab51b3a8f584abc149504ddbf0791f67 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 21 Nov 2020 18:16:42 +0300 Subject: [PATCH 04/24] Revert "initial translation" This reverts commit 76437983 --- README.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/README.rst b/README.rst index 68347d1..0b632e1 100644 --- a/README.rst +++ b/README.rst @@ -1,8 +1,7 @@ -Как писать автотесты используя Robot Framework -===================================================== +How to write good test case +=========================== - -Авторизованый перевод оригинального руководства `How to write good test cases using Robot Framework `_ описывает общие правила написания автоматизированных тестов с использованием +This project documents general guidelines for writing good test cases using `Robot Framework `_. -Собственно советы по написанию находятся в файле ``_. +The how-to itself is in ``_ file. From fe3c367d5eaedce5eaf7d8e38ec969b0f71db8b2 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 21 Nov 2020 18:19:15 +0300 Subject: [PATCH 05/24] Revert ""Test suite names" section translated." This reverts commit 09483067 --- HowToWriteGoodTestCases.rst | 54 ++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/HowToWriteGoodTestCases.rst b/HowToWriteGoodTestCases.rst index 53b0588..988e10b 100644 --- a/HowToWriteGoodTestCases.rst +++ b/HowToWriteGoodTestCases.rst @@ -1,56 +1,62 @@ .. default-role:: code ================================================== -Как писать автотесты используя Robot Framework +How to write good test cases using Robot Framework ================================================== -.. contents:: Содержание: +.. contents:: Table of contents: :local: :depth: 2 -Введение +Introduction ============ -- Это руководстов дает обобщенные советы по написания наборо тестов с использованием Robot +- These are high-level guidelines for writing good test cases using Robot Framework. - - Детальное описание взаимодействия с тестируемыми системами выходит за рамки настоящего руководства. + - How to actually interact with the system under test is out of + the scope of this document. -- Важнейшим принципом написания тестов является его максимальная понятность для людей знакомых с предметной областью. +- Most important guideline is keeping test cases as easy to understand as + possible for people familiar with the domain. - - Обычно такие тесты еще и легко поддерживать. + - This typically also eases maintenance. -- За дополнительными сведениями по этой теме вы можете обратится к следующим замечательным источникам: +- For more information about this subject, you may want to take a look at + these great resources: - - `Robot Framework Dos and Don'ts`__ презентация в основе которой это руководство. - - Статья Дейла Эмери `Writing Maintainable Automated Acceptance Tests`__. - - Запись в блоге Андреаса Эбберт-Кароум `How to Structure a Scalable And Maintainable Acceptance Test Suite`__. + - `Robot Framework Dos and Don'ts`__ slides that are based on this how-to. + - `Writing Maintainable Automated Acceptance Tests`__ article by Dale Emery. + - `How to Structure a Scalable And Maintainable Acceptance Test Suite`__ + blog post by Andreas Ebbert-Karroum. __ http://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts -__ http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf +__ http://cwd.dhemery.com/2009/11/wmaat __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintainable-acceptance-test-suite -Именование -========== +Naming +====== -Названия наборов тестов ------------------------ +Test suite names +---------------- -- Названия наборов тестов должны быть описательными настолько, насколько это возможно. +- Suite names should be as descriptive as possible. -- Имена создаются автоматически на основе названий файлов или каталогов: +- Names are created automatically from file or directory names: - - Расширения файлов отбрасываются. - - Символы подчеркивания преобразуются в пробелы. - - Если имя в нижнем регистре, то слова пишутся заглавными буквами. + - Extensions are stripped. + - Underscores are converted to spaces. + - If name is all lower case, words are capitalized. -- Имя может быть длинным, но слишком длинные имена могут не походит под ограничения файловой системы. +- Names can be relatively long, but overly long names are not convenient for + the file system. -- В случае необходимости имя набора тестов может быть перезаписано из командной строки с использованием опции `--name`. +- The name of the top level suite can be overridden from the command line + using the `--name` option if needed. -Примеры: +Examples: - `login_tests.robot` -> `Login Tests` - `IP_v4_and_v6` -> `IP v4 and v6` From aef20670df521cff1c7e71b7c330ec29abd8fa75 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 21 Nov 2020 18:21:40 +0300 Subject: [PATCH 06/24] add Russian translation. --- HowToWriteGoodTestCases_RU.rst | 584 +++++++++++++++++++++++++++++++++ 1 file changed, 584 insertions(+) create mode 100644 HowToWriteGoodTestCases_RU.rst diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst new file mode 100644 index 0000000..53b0588 --- /dev/null +++ b/HowToWriteGoodTestCases_RU.rst @@ -0,0 +1,584 @@ +.. default-role:: code + +================================================== +Как писать автотесты используя Robot Framework +================================================== + +.. contents:: Содержание: + :local: + :depth: 2 + + +Введение +============ + +- Это руководстов дает обобщенные советы по написания наборо тестов с использованием Robot + Framework. + + - Детальное описание взаимодействия с тестируемыми системами выходит за рамки настоящего руководства. + +- Важнейшим принципом написания тестов является его максимальная понятность для людей знакомых с предметной областью. + + - Обычно такие тесты еще и легко поддерживать. + +- За дополнительными сведениями по этой теме вы можете обратится к следующим замечательным источникам: + + - `Robot Framework Dos and Don'ts`__ презентация в основе которой это руководство. + - Статья Дейла Эмери `Writing Maintainable Automated Acceptance Tests`__. + - Запись в блоге Андреаса Эбберт-Кароум `How to Structure a Scalable And Maintainable Acceptance Test Suite`__. + +__ http://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts +__ http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf +__ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintainable-acceptance-test-suite + + +Именование +========== + +Названия наборов тестов +----------------------- + +- Названия наборов тестов должны быть описательными настолько, насколько это возможно. + +- Имена создаются автоматически на основе названий файлов или каталогов: + + - Расширения файлов отбрасываются. + - Символы подчеркивания преобразуются в пробелы. + - Если имя в нижнем регистре, то слова пишутся заглавными буквами. + +- Имя может быть длинным, но слишком длинные имена могут не походит под ограничения файловой системы. + +- В случае необходимости имя набора тестов может быть перезаписано из командной строки с использованием опции `--name`. + +Примеры: + +- `login_tests.robot` -> `Login Tests` +- `IP_v4_and_v6` -> `IP v4 and v6` + + +Test case names +--------------- + +- Test names should be descriptive like the suite names. + +- If a suite contains many similar tests and is well named, + test names can be shorter. + +- Name is exactly the same as you specified in the test case file without any + conversion. + +For example, if we have tests related to invalid login in a file +`invalid_login.robot`, these would be OK test case names: + +.. code:: robotframework + + *** Test Cases *** + Empty Password + Empty Username + Empty Username And Password + Invalid Username + Invalid Password + Invalid Username And Password + +These names would be somewhat long: + +.. code:: robotframework + + *** Test Cases *** + Login With Empty Password Should Fail + Login With Empty Username Should Fail + Login With Empty Username And Password Should Fail + Login With Invalid Username Should Fail + Login With Invalid Password Should Fail + Login With Invalid Username And Invalid Password Should Fail + + +Keyword names +------------- + +- Keyword names should be descriptive and clear. + +- Should explain what the keyword does, not how it does its task(s). + +- Very different abstraction levels (e.g. `Input Text` or `Administrator + logs into system`). + +- There is no clear guideline on whether a keyword should be fully title cased or have + only the first letter be capitalized. + + - Title casing is often used when the keyword name is short (e.g. `Input Text`). + - Capitalizing just the first letter typically works better with keywords + that are like sentences (e.g. `Administrator logs into system`). These + type of keywords are often higher level. + +Good: + +.. code:: robotframework + + *** Keywords *** + Login With Valid Credentials + +Bad: + +.. code:: robotframework + + *** Keywords *** + Input Valid Username And Valid Password And Click Login Button + + +Naming setup and teardown +------------------------- + +- Try to use name that describes what is done. + + - Possibly use an existing keyword. + +- More abstract names are acceptable if a setup or teardown contains unrelated steps. + + - Listing steps in name is duplication and a maintenance problem + (e.g. `Login to system, add user, activate alarms and check balance`). + + - Often better to use something generic (e.g. `Initialize system`). + +- BuiltIn keyword `Run Keywords`__ can work well if keywords implementing lower + level steps already exist. + + - Not reusable so best used when the setup or teardown scenario is + needed only once. + +- Everyone working with these tests should always understand what a setup or + teardown does. + +Good: + +.. code:: robotframework + + *** Settings *** + Suite Setup Initialize System + +Good (if only used once): + +.. code:: robotframework + + *** Settings *** + Suite Setup Run Keywords + ... Login To System AND + ... Add User AND + ... Activate Alarms AND + ... Check Balance + +Bad: + +.. code:: robotframework + + *** Settings *** + Suite Setup Login To System, Add User, Activate Alarms And Check Balance + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20Keywords + + +Documentation +============= + +Test suite documentation +------------------------ + +- Often a good idea to add overall documentation to test case files. + +- Should contain background information, why tests are created, notes about + execution environment, etc. + +- Do not just repeat test suite name. + + - Better to have no documentation if it is not really needed. + +- Do not include too much details about test cases. + + - Tests should be clear enough to understand alone. + - Duplicate information is waste and maintenance problem. + +- Documentation can contain links to more information. + +- Consider using test suite metadata if you need to document information + represented as name-value pairs (e.g. `Version: 1.0` or `OS: Linux`). + +- Documentation and metadata of the top level suite can be set from the + command line using `--doc` and `--metadata` options, respectively. + +Good: + +.. code:: robotframework + + *** Settings *** + Documentation Tests to verify that account withdrawals succeed and + ... fail correctly depending from users account balance + ... and account type dependent rules. + ... See http://internal.example.com/docs/abs.pdf + Metadata Version 0.1 + +Bad (especially if suite is named well like `account_withdrawal.robot`): + +.. code:: robotframework + + *** Settings *** + Documentation Tests Account Withdrawal. + + +Test case documentation +----------------------- + +- Test normally does not need documentation. + + - Name and possible documentation of the parent suite and test's own name + should give enough background information. + - Test case structure should be clear enough without documentation or other + comments. + +- Tags are generally more flexible and provide more functionality (statistics, + include/exclude, etc.) than documentation. + +- Sometimes test documentation is useful. No need to be afraid to use it. + +Good: + +.. code:: robotframework + + *** Test Cases *** + Valid Login + [Tags] Iteration-3 Smoke + Open Login Page + Input Username ${VALID USERNAME} + Input Password ${VALID PASSWORD} + Submit Credentials + Welcome Page Should Be Open + +Bad: + +.. code:: robotframework + + *** Test Cases *** + Valid Login + [Documentation] Opens a browser to login url, inputs valid username + ... and password and checks that the welcome page is open. + ... This is a smoke test. Created in iteration 3. + Open Browser ${URL} ${BROWSER} + Input Text field1 ${UN11} + Input Text field2 ${PW11} + Click Button button_12 + Title Should Be Welcome Page + + +User keyword documentation +-------------------------- + +- Not needed if keyword is relatively simple. + + - Good keyword, argument names and clear structure should be enough. + +- Important usage is documenting arguments and return values. + +- Shown in resource file documentation generated with Libdoc__ and editors + such as RIDE__ can show it in keyword completion and elsewhere. + +__ http://robotframework.org/robotframework/#built-in-tools +__ https://github.com/robotframework/RIDE + + +Test suite structure +==================== + +- Tests in a suite should be related to each other. + + - Common setup and/or teardown is often a good indicator. + +- Should not have too many tests (max 10) in one file unless they are + `data-driven tests`_. + +- Tests should be independent. Initialization using setup/teardown. + +- Sometimes dependencies between tests cannot be avoided. + + - For example, it can take too much time to initialize all tests separately. + - Never have long chains of dependent tests. + - Consider verifying the status of the previous test using the built-in + `${PREV TEST STATUS}` variable. + + +Test case structure +=================== + +- Test case should be easy to understand. + +- One test case should be testing one thing. + + - *Things* can be small (part of a single feature) or large (end-to-end). + +- Select suitable abstraction level. + + - Use abstraction level consistently (single level of abstraction principle). + - Do not include unnecessary details on the test case level. + +- Two kinds of test cases: + + - `Workflow tests`_ + - `Data-driven tests`_ + + +Workflow tests +-------------- + +- Generally have these phases: + + - Precondition (optional, often in setup) + - Action (do something to the system) + - Verification (validate results, mandatory) + - Cleanup (optional, always in teardown to make sure it is executed) + +- Keywords describe what a test does. + + - Use clear keyword names and suitable abstraction level. + - Should contain enough information to run manually. + - Should never need documentation or commenting to explain what the test does. + +- Different tests can have different abstraction levels. + + - Tests for a detailed functionality are more precise. + - End-to-end tests can be on very high level. + - One test should use only one abstraction level + +- Different styles: + + - More technical tests for lower level details and integration tests. + - "Executable specifications" act as requirements. + - Use domain language. + - Everyone (including customer and/or product owner) should always understand. + +- No complex logic on the test case level. + + - No for loops or if/else constructs. + - Use variable assignments with care. + - Test cases should not look like scripts! + +- Max 10 steps, preferably less. + +Example using "normal" keyword-driven style: + +.. code:: robotframework + + *** Test Cases *** + Valid Login + Open Browser To Login Page + Input Username demo + Input Password mode + Submit Credentials + Welcome Page Should Be Open + +Example using higher level "gherkin" style: + +.. code:: robotframework + + *** Test Cases *** + Valid Login + Given browser is opened to login page + When user "demo" logs in with password "mode" + Then welcome page should be open + +See the `web demo project `_ +for executable versions of the above examples. + +Data-driven tests +----------------- + +- One high-level keyword per test. + + - Different arguments create different tests. + - One test can run the same keyword multiple times to validate multiple + related variations + +- If the keyword is implemented as a user keyword, it typically contains + a similar workflow as `workflow tests`_. + + - Unless needed elsewhere, it is a good idea to create it in the same file + as tests using it. + +- Recommended to use the *test template* functionality. + + - No need to repeat the keyword multiple times. + - Easier to test multiple variations in one test. + +- Possible, and recommended, to name column headings + +- If a really big number of tests is needed, consider generating them based + on an external model. + +Example: + +.. code:: robotframework + + *** Settings *** + Test Template Login with invalid credentials should fail + + *** Test Cases *** USERNAME PASSWORD + Invalid Username invalid ${VALID PASSWORD} + Invalid Password ${VALID USERNAME} invalid + Invalid Both invalid invalid + Empty Username ${EMPTY} ${VALID PASSWORD} + Empty Password ${VALID USERNAME} ${EMPTY} + Empty Both ${EMPTY} ${EMPTY} + + *** Keywords *** + Login with invalid credentials should fail + [Arguments] ${username} ${password} + Input Username ${username} + Input Password ${password} + Submit Credentials + Error Page Should Be Open + +The `web demo project`_ contains an executable version of this example too. + + +User keywords +============= + +- Should be easy to understand. + + - Same rules as with workflow tests. + +- Different abstraction levels. + +- Can contain some programming logic (for loops, if/else). + + - Especially on lower level keywords. + - Complex logic in libraries rather than in user keywords. + + +Variables +========= + +- Encapsulate long and/or complicated values. + +- Pass information from them command line using the `--variable` option. + +- Pass information between keywords. + + +Variable naming +--------------- + +- Clear but not too long names. + +- Can use comments in variable table to document them more. + +- Use case consistently: + + - Lower case with local variables only available inside a certain scope. + - Upper case with others (global, suite or test level). + - Both space and underscore can be used as a word separator. + +- Recommended to also list variables that are set dynamically in the variable + table. + + - Set typically using BuiltIn keyword `Set Suite Variable`__. + - The initial value should explain where/how the real value is set. + +Example: + +.. code:: robotframework + + *** Settings *** + Suite Setup Set Active User + + *** Variables *** + # Default system address. Override when tested agains other instances. + ${SERVER URL} http://sre-12.example.com/ + ${USER} Actual value set dynamically at suite setup + + *** Keywords *** + Set Active User + ${USER} = Get Current User ${SERVER URL} + Set Suite Variable ${USER} + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Suite%20Variable + + +Passing and returning values +---------------------------- + +- Common approach is to return values from keywords, assign them to variables + and then pass them as arguments to other keywords. + + - Clear and easy to follow approach. + - Allows creating independent keywords and facilitates re-use. + - Looks like programming and thus not so good on the test case level. + +- Alternative approach is storing information in a library or using the BuiltIn + `Set Test Variable`__ keyword. + + - Avoid programming style on the test case level. + - Can be more complex to follow and make reusing keywords harder. + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Test%20Variable + +Good: + +.. code:: robotframework + + *** Test Cases *** + Withdraw From Account + Withdraw From Account $50 + Withdraw Should Have Succeeded + + *** Keywords *** + Withdraw From Account + [Arguments] ${amount} + ${STATUS} = Withdraw From User Account ${USER} ${amount} + Set Test Variable ${STATUS} + + Withdraw Should Have Succeeded + Should Be Equal ${STATUS} SUCCESS + +Not so good: + +.. code:: robotframework + + *** Test Cases *** + Withdraw From Account + ${status} = Withdraw From Account $50 + Withdraw Should Have Succeeded ${status} + + *** Keywords *** + Withdraw From Account + [Arguments] ${amount} + ${status} = Withdraw From User Account ${USER} ${amount} + [Return] ${status} + + Withdraw Should Have Succeeded + [Arguments] ${status} + Should Be Equal ${status} SUCCESS + + +Avoid sleeping +============== + +- Sleeping is a very fragile way to synchronize tests. + +- Safety margins cause too long sleeps on average. + +- Instead of sleeps, use keyword that polls has a certain action occurred. + + - Keyword names often starts with `Wait ...`. + - Should have a maximum time to wait. + - Possible to wrap other keywords inside the BuiltIn keyword + `Wait Until Keyword Succeeds`__. + +- Sometimes sleeping is the easiest solution. + + - Always use with care. + - Never use in user keywords that are used often by tests or other keywords. + +- Can be useful in debugging to stop execution. + + - `Dialogs library`__ often works better. + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Wait%20Until%20Keyword%20Succeeds +__ http://robotframework.org/robotframework/latest/libraries/Dialogs.html From a8102d8f1fd97cb82174fb550de8f0bfb9b9b716 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 23 Nov 2020 15:56:05 +0300 Subject: [PATCH 07/24] translate Naming section. --- HowToWriteGoodTestCases_RU.rst | 116 +++++++++++++++------------------ 1 file changed, 53 insertions(+), 63 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 53b0588..a449423 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -12,12 +12,12 @@ Введение ============ -- Это руководстов дает обобщенные советы по написания наборо тестов с использованием Robot +- Это руководство дает обобщенные советы по написания наборо тестов с использованием Robot Framework. - Детальное описание взаимодействия с тестируемыми системами выходит за рамки настоящего руководства. -- Важнейшим принципом написания тестов является его максимальная понятность для людей знакомых с предметной областью. +- Важнейшим принципом написания тестов является его максимальная понятность для людей, знакомых с предметной областью. - Обычно такие тесты еще и легко поддерживать. @@ -32,13 +32,13 @@ __ http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintainable-acceptance-test-suite -Именование +Выбор имен ========== Названия наборов тестов ----------------------- -- Названия наборов тестов должны быть описательными настолько, насколько это возможно. +- Названия наборов тестов должны полно описывать содержание. - Имена создаются автоматически на основе названий файлов или каталогов: @@ -56,69 +56,62 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - `IP_v4_and_v6` -> `IP v4 and v6` -Test case names ---------------- +Названия тестовых сценариев +---------------------------- -- Test names should be descriptive like the suite names. +- Имена тестов должны такими же описательными, как и названия наборов тестов. -- If a suite contains many similar tests and is well named, - test names can be shorter. +- Если набор тестов содержить много похожих тестов и имеет подходяещее название, то название входящих в него тестов можно сделать короче. -- Name is exactly the same as you specified in the test case file without any - conversion. +- Имя теста отображается в точности так, как вы его зададите в файле тестового сценария. -For example, if we have tests related to invalid login in a file -`invalid_login.robot`, these would be OK test case names: +Например, если у вас есть тесты, связанные с проверкой невалидного входа в систему в файле `невалидный_вход.robot`, то это будут подходящие имена: .. code:: robotframework *** Test Cases *** - Empty Password - Empty Username - Empty Username And Password - Invalid Username - Invalid Password - Invalid Username And Password + Пустой пароль + Пустое имя пользователя + Пустой пароль и имя пользователя + Неверное имя пользователя + Неверный пароль + Неверный пароль и имя пользователя -These names would be somewhat long: +А эти имена будут слегка длинными: .. code:: robotframework *** Test Cases *** - Login With Empty Password Should Fail - Login With Empty Username Should Fail - Login With Empty Username And Password Should Fail - Login With Invalid Username Should Fail - Login With Invalid Password Should Fail - Login With Invalid Username And Invalid Password Should Fail + Вход с пустым поролем не должен быть успешным + Вход с пустым именем пользователя не должен быть успешным + Вход с пустым именем пользователя и паролем не должен быть успешным + Вход с неверным поролем не должен быть успешным + Вход с неверным именем пользователя не должен быть успешным + Вход с невернымм именем пользователя и паролем не должен быть успешным -Keyword names -------------- +Названия ключевых слов +---------------------- -- Keyword names should be descriptive and clear. +- Название ключевого слова должно описывать выполняемое действие и быть ясными. -- Should explain what the keyword does, not how it does its task(s). +- Навзание должно описывать, **что** делает это ключевое слов, а не то, **как** оно это делает. -- Very different abstraction levels (e.g. `Input Text` or `Administrator - logs into system`). +- Может иметь разные уровни абстракции (например, `Ввод текста` или `Администратор входит в систему`). -- There is no clear guideline on whether a keyword should be fully title cased or have - only the first letter be capitalized. +- Нет четкого правил, которое бы определяло должны ли быть заглавными первые буквы во всех словах (title casing) или же заглавной должна быть только первая буква первого слова. - - Title casing is often used when the keyword name is short (e.g. `Input Text`). - - Capitalizing just the first letter typically works better with keywords - that are like sentences (e.g. `Administrator logs into system`). These - type of keywords are often higher level. + - Title casing обычно используется, если название короткое (например. `Ввод текста`). + - Заглавная буква в первом слове обычно работает лучше, если название похоже на законченное предложение (например, `Администратор входит в систему`). Обычно это ключевые слова более высокого уровня. -Good: +Правильно: .. code:: robotframework *** Keywords *** Login With Valid Credentials -Bad: +Не правильно: .. code:: robotframework @@ -126,53 +119,50 @@ Bad: Input Valid Username And Valid Password And Click Login Button -Naming setup and teardown -------------------------- +Выбор имен для процедур подготовки и завершения тестов +---------------------------------------------------------------- -- Try to use name that describes what is done. +- Старайтесь использовать имена, которые описывают то, что делает это ключевое слово. - - Possibly use an existing keyword. + - По возможности, используйте уже существующие ключевый слова. -- More abstract names are acceptable if a setup or teardown contains unrelated steps. +- Более обобщенные названия приемлемы, если эти процедуры содержать несвязанные шаги. - - Listing steps in name is duplication and a maintenance problem - (e.g. `Login to system, add user, activate alarms and check balance`). + - Перечисление шагов в названии приводит к дублированию и проблемам с поддержкой + (например, `Войти в систему, добавить пользователя, активировать оповещение и проверить баланс`). - - Often better to use something generic (e.g. `Initialize system`). + - Часто бывает, что луше использовать более общее описание (например, `Инициализировать систему`). -- BuiltIn keyword `Run Keywords`__ can work well if keywords implementing lower - level steps already exist. +- Подходящим может быть встроенное ключевое слово `Run Keywords`__ , если в процедуре используются готовые ключевые слова более низкого уровня. - - Not reusable so best used when the setup or teardown scenario is - needed only once. + - Этот способ не подходит для повторного использования, поэтому лучше использовать его, если эта процедура будет использоваться только в одном тесте. -- Everyone working with these tests should always understand what a setup or - teardown does. +- Всякий, кто работет с этим тестом, должен понимать, что эти процедуры делают. -Good: +Правильно: .. code:: robotframework *** Settings *** - Suite Setup Initialize System + Suite Setup Инициализировать систему -Good (if only used once): +Правльно (если используется только в одном месте): .. code:: robotframework *** Settings *** Suite Setup Run Keywords - ... Login To System AND - ... Add User AND - ... Activate Alarms AND - ... Check Balance + ... Войти в систему AND + ... Добавить пользователя AND + ... Активировать оповещение AND + ... Проверить баланс -Bad: +Не правильно: .. code:: robotframework *** Settings *** - Suite Setup Login To System, Add User, Activate Alarms And Check Balance + Suite Setup Войти в систему, добавить пользователя, активировать оповещение и проверить баланс __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20Keywords From de5b723f4c51a005204e991427959e6c98cebfac Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Tue, 24 Nov 2020 13:39:36 +0300 Subject: [PATCH 08/24] start translate Documentation section. --- HowToWriteGoodTestCases_RU.rst | 64 ++++++++++++++++------------------ 1 file changed, 31 insertions(+), 33 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index a449423..cf54993 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -111,7 +111,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai *** Keywords *** Login With Valid Credentials -Не правильно: +Неправильно: .. code:: robotframework @@ -131,13 +131,13 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Перечисление шагов в названии приводит к дублированию и проблемам с поддержкой (например, `Войти в систему, добавить пользователя, активировать оповещение и проверить баланс`). - - Часто бывает, что луше использовать более общее описание (например, `Инициализировать систему`). + - Часто бывает, что лучше использовать более общее описание (например, `Инициализировать систему`). -- Подходящим может быть встроенное ключевое слово `Run Keywords`__ , если в процедуре используются готовые ключевые слова более низкого уровня. +- Подходящим может быть использования встроенного ключевога слова `Run Keywords`__ , если в процедуре используются готовые ключевые слова более низкого уровня. - - Этот способ не подходит для повторного использования, поэтому лучше использовать его, если эта процедура будет использоваться только в одном тесте. + - Этот способ не подходит для повторного использования, поэтому лучше использовать его, если эта процедура будет использоваться только в одном месте. -- Всякий, кто работет с этим тестом, должен понимать, что эти процедуры делают. +- Всякий, кто работет с тестами, должен из названия понимать, что эти процедуры делают. Правильно: @@ -146,7 +146,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai *** Settings *** Suite Setup Инициализировать систему -Правльно (если используется только в одном месте): +Правильно (если используется только в одном месте): .. code:: robotframework @@ -157,7 +157,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai ... Активировать оповещение AND ... Проверить баланс -Не правильно: +Неправильно: .. code:: robotframework @@ -167,55 +167,53 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20Keywords -Documentation +Документация ============= -Test suite documentation ------------------------- +Документация наборов тестов +--------------------------- -- Often a good idea to add overall documentation to test case files. +- Часто бывает нелишним добавить к тестовым сценариям документацию по ним. -- Should contain background information, why tests are created, notes about - execution environment, etc. +- Документация должна содержать информцию о назначении тестов, среде выполнения и тому подобном. -- Do not just repeat test suite name. +- Не должнв повторять дословно названия набора тестов. - - Better to have no documentation if it is not really needed. + - Лучше вовсе не иметь документации, если она не нужна на самом деле. -- Do not include too much details about test cases. +- Не должна включать слишком много деталей тестовых сценариев. - - Tests should be clear enough to understand alone. - - Duplicate information is waste and maintenance problem. + - Тесты должны быть достаточно понятными для понимания сами по себе. + - Дублирующая информация это мусор и дополнительные проблемы с поддержкой тестов. -- Documentation can contain links to more information. +- Документация может содержать ссылки на дополнительную информацию. -- Consider using test suite metadata if you need to document information - represented as name-value pairs (e.g. `Version: 1.0` or `OS: Linux`). +- Рассмотрите возможностьи использования метаданных тестовых наборов, если вам требуется документировать иформацию предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). -- Documentation and metadata of the top level suite can be set from the - command line using `--doc` and `--metadata` options, respectively. +- Документация и метаданные для наборов тестов верхнего уровня может быть установлена с помощью опций командной строки `--doc` и `--metadata` соответсвенно. -Good: +Правильно: .. code:: robotframework *** Settings *** - Documentation Tests to verify that account withdrawals succeed and - ... fail correctly depending from users account balance - ... and account type dependent rules. - ... See http://internal.example.com/docs/abs.pdf - Metadata Version 0.1 + Documentation Тест проверки списания денег со счета пользователя. + ... Успех и отказ при проведении операции должен проходить + ... корректно, в зависимости от состояния баланса и правил + ... принятых для этого типа счета. + ... Подробнее смотри: http://internal.example.com/docs/abs.pdf + Metadata Версия 0.1 -Bad (especially if suite is named well like `account_withdrawal.robot`): +Неправильно (особенно если набор тестов уже имеет подходящее название вроде `account_withdrawal.robot`): .. code:: robotframework *** Settings *** - Documentation Tests Account Withdrawal. + Documentation Тест списания со счета. -Test case documentation ------------------------ +Документация наборов тестов +--------------------------- - Test normally does not need documentation. From 43decc1f9f784b4c8980a065806fe06cecafbd65 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 28 Nov 2020 11:59:27 +0300 Subject: [PATCH 09/24] translate Workflow Testing section. --- HowToWriteGoodTestCases_RU.rst | 187 ++++++++++++++++----------------- 1 file changed, 91 insertions(+), 96 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index cf54993..8b65b86 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -12,7 +12,7 @@ Введение ============ -- Это руководство дает обобщенные советы по написания наборо тестов с использованием Robot +- Это руководство дает обобщенные советы по написания наборов тестов с использованием Robot Framework. - Детальное описание взаимодействия с тестируемыми системами выходит за рамки настоящего руководства. @@ -44,7 +44,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Расширения файлов отбрасываются. - Символы подчеркивания преобразуются в пробелы. - - Если имя в нижнем регистре, то слова пишутся заглавными буквами. + - Если имя в нижнем регистре, то первые буквы в словах отображаются заглавными. - Имя может быть длинным, но слишком длинные имена могут не походит под ограничения файловой системы. @@ -212,43 +212,41 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 Documentation Тест списания со счета. -Документация наборов тестов ---------------------------- +Документация тестовых сценариев +------------------------------- -- Test normally does not need documentation. +- Обычно тестам не требуется документация. - - Name and possible documentation of the parent suite and test's own name - should give enough background information. - - Test case structure should be clear enough without documentation or other - comments. + - Название и документация родительского набора тестов должна давать достатчно общей инфрмации. + - Структура тестовго сценария долна быть достаточно ясной и без дополнительной документации или других комментариев. -- Tags are generally more flexible and provide more functionality (statistics, - include/exclude, etc.) than documentation. +- Использование тэгов обеспечивает большую гибкость и функциональность (ведение статистики, включение/выключение при запуске и т. д.), чем документация. -- Sometimes test documentation is useful. No need to be afraid to use it. +- Иногда документация к сценарим бывает полезна, не бойтесь использовать ее. -Good: +Правильно: .. code:: robotframework *** Test Cases *** - Valid Login - [Tags] Iteration-3 Smoke - Open Login Page - Input Username ${VALID USERNAME} - Input Password ${VALID PASSWORD} - Submit Credentials - Welcome Page Should Be Open + Валидный вход + [Tags] Итерация-3 Базовые + Открыть страницу входа + Ввести имя пользователя ${VALID USERNAME} + Ввести пароль ${VALID PASSWORD} + Отправить учетные данные + Должна быть открыта стартовая страница -Bad: +Неправильно: .. code:: robotframework *** Test Cases *** - Valid Login - [Documentation] Opens a browser to login url, inputs valid username - ... and password and checks that the welcome page is open. - ... This is a smoke test. Created in iteration 3. + Валидный вход + [Documentation] Открыть в браузере страницу входа, ввести валидные + ... имя пользователя и пароль. Убедиться что открылась + ... стартовая страница. + ... Это базовый тест. Создан во время 3-ей итерации. Open Browser ${URL} ${BROWSER} Input Text field1 ${UN11} Input Text field2 ${PW11} @@ -256,126 +254,123 @@ Bad: Title Should Be Welcome Page -User keyword documentation --------------------------- +Документация к пользовательским ключевым словам +----------------------------------------------- -- Not needed if keyword is relatively simple. +- Не требуется, если ключевые слова отностиельно простые. - - Good keyword, argument names and clear structure should be enough. + - Подходящего названия и имен аргументов, а также ясной структуры — должно быть вполне достаточно. -- Important usage is documenting arguments and return values. +- Важным может быть документирование аргументов и возвращяемых значений. -- Shown in resource file documentation generated with Libdoc__ and editors - such as RIDE__ can show it in keyword completion and elsewhere. +- Документация отображается в файлах ресурсов, генерируемых с помощью Libdoc__ , а редакторы такие как RIDE__ могут отображать ее при автодополнении имени ключевого слова и в других местах. __ http://robotframework.org/robotframework/#built-in-tools __ https://github.com/robotframework/RIDE -Test suite structure -==================== +Структура наборов тестов +======================== -- Tests in a suite should be related to each other. +- Тесты в наборе должны быть связаны между собой. - - Common setup and/or teardown is often a good indicator. + - Хороший признак этого — общие процедуры запуска/завершения тестов. -- Should not have too many tests (max 10) in one file unless they are - `data-driven tests`_. +- Набор не должен содержать слишком много тестов (максимум 10). Исключением может быть "`Тестирование на основе данных`_". -- Tests should be independent. Initialization using setup/teardown. +- Тесты должны быть независимыми. Инициализироваться через общие процедуры запуска/завершения тестов. -- Sometimes dependencies between tests cannot be avoided. +- Иногда зависмости тестов друг от друга невозможжно избежать. - - For example, it can take too much time to initialize all tests separately. - - Never have long chains of dependent tests. - - Consider verifying the status of the previous test using the built-in - `${PREV TEST STATUS}` variable. + - Например, им потребуется слишком много времени для инициализации по отдельности. + - Не стоит делать длинных цепочек из зависимых тестов. + - Для проверки статуса предыдущего тесто может пригодится переменная `${PREV TEST STATUS}`. -Test case structure -=================== +Структура тестовых сценариев +============================ -- Test case should be easy to understand. +- Тестовые сценарии должны быть простыми для понимания. -- One test case should be testing one thing. +- Один тест должен проверять одну вешь. - - *Things* can be small (part of a single feature) or large (end-to-end). + - Эта *вещь* может быть маленькой (часть какой-либо фукции) или большой (результат процесса). -- Select suitable abstraction level. +- Выбирайте подходящий уровень абстракции. - - Use abstraction level consistently (single level of abstraction principle). - - Do not include unnecessary details on the test case level. + - Используйте уровень абстракции единообразно (принцип одного уровня асбтракции). + - Не добавляте ненужные детали на уровень тестового сценария. -- Two kinds of test cases: +- Существует два типа тестовых сценариев: - - `Workflow tests`_ - - `Data-driven tests`_ + - `Workflow тестирование`_ + - `Тестирование на основе данных`_ -Workflow tests --------------- +Workflow тестирование +--------------------- -- Generally have these phases: +- Обычно оно включает три фазы: - - Precondition (optional, often in setup) - - Action (do something to the system) - - Verification (validate results, mandatory) - - Cleanup (optional, always in teardown to make sure it is executed) + - Предусловие (не обязательно, чаще в процедуре подготовки тестов) + - Действие (делает что-то с системой) + - Проверка (валидация результата, обязательная часть) + - Уборка (не обязательно, всегда делается в завершающей процедуре, чтобы быть уверенным, что действие будет выполнено) -- Keywords describe what a test does. +- Ключевые слова описывают, что делает тест. - - Use clear keyword names and suitable abstraction level. - - Should contain enough information to run manually. - - Should never need documentation or commenting to explain what the test does. + - Используйте "говорящие" названия ключевых слов и подходящий уровень абстракции. + - Они должны содержать достаточно информации, чтобы выполнить тест вручную. + - Не должны требовать дополнительной документации или комментариев для того чтобы обьяснить, что этот тест делает. -- Different tests can have different abstraction levels. +- Разные тесты могут иметь разный уровень абстракции. - - Tests for a detailed functionality are more precise. - - End-to-end tests can be on very high level. - - One test should use only one abstraction level + - Тесты для отдельных частей функциональности будут более детальными. + - End-to-end тесты могут имет самый высокий уровень абстракции. + - Один ест дост должен использовать только один уровень абстракции. -- Different styles: +- Разные стили: - - More technical tests for lower level details and integration tests. - - "Executable specifications" act as requirements. - - Use domain language. - - Everyone (including customer and/or product owner) should always understand. + - Более "технические" для тестирования низкоуровневых деталей и интеграции. + - "Испольняемые спецификации" действующие как требования. + - Используйте язык предметной области. + - Все (включая клиента и/или владельца продукта) всегда должны понимать о чем идет речь в тесте. -- No complex logic on the test case level. +- Никакой сложной логики на уровне тестовых сыенариев. - - No for loops or if/else constructs. - - Use variable assignments with care. - - Test cases should not look like scripts! + - Никаких конструкций типа циклов или условий. + - Используйте назначение переменных с осторожностью. + - Тестовый сцераий не должен выглядить как скрипт! -- Max 10 steps, preferably less. +- Максиму 10 шагов, а лучше меньше. -Example using "normal" keyword-driven style: +Пример использования "нормального" стиля ключевых слов: .. code:: robotframework *** Test Cases *** - Valid Login - Open Browser To Login Page - Input Username demo - Input Password mode - Submit Credentials - Welcome Page Should Be Open + Успешный вход в систему + Открыть страницу входа + Ввести имя пользователя demo + Ввести пароль mode + Отправить учетные данные + Открылась главная страница -Example using higher level "gherkin" style: +Пример с использванием высокоуровневого стиля "gherkin": .. code:: robotframework *** Test Cases *** - Valid Login - Given browser is opened to login page - When user "demo" logs in with password "mode" - Then welcome page should be open + Успешный вход в систему + Given браузер открыл страницу входа + When пользователь "demo" зашел с паролем "mode" + Then открылась главная страница -See the `web demo project `_ -for executable versions of the above examples. +Смотрите `web demo project `_ +что увидеть испольняемую версию этих примеров. -Data-driven tests ------------------ +Тестирование на основе данных +----------------------------- - One high-level keyword per test. From 62ab46a80fa1cf6d6810d81b0ca2b10a8403ea91 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sat, 28 Nov 2020 15:17:28 +0300 Subject: [PATCH 10/24] translate Data-driven Tests section. --- HowToWriteGoodTestCases_RU.rst | 58 ++++++++++++++++------------------ 1 file changed, 27 insertions(+), 31 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 8b65b86..9202504 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -177,7 +177,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 - Документация должна содержать информцию о назначении тестов, среде выполнения и тому подобном. -- Не должнв повторять дословно названия набора тестов. +- Не должна повторять дословно названия набора тестов. - Лучше вовсе не иметь документации, если она не нужна на самом деле. @@ -340,7 +340,7 @@ Workflow тестирование - Никаких конструкций типа циклов или условий. - Используйте назначение переменных с осторожностью. - - Тестовый сцераий не должен выглядить как скрипт! + - Тестовый сценарий не должен выглядить как скрипт! - Максиму 10 шагов, а лучше меньше. @@ -367,57 +367,53 @@ Workflow тестирование Then открылась главная страница Смотрите `web demo project `_ -что увидеть испольняемую версию этих примеров. +что увидеть исполняемую версию этих примеров. Тестирование на основе данных ----------------------------- -- One high-level keyword per test. +- Одно ключевое слово высокого уровня на тест. - - Different arguments create different tests. - - One test can run the same keyword multiple times to validate multiple - related variations + - Разные аргументы формируют разные тесты. + - Один тест может запускать одно и тоже ключевое слово несколько раз, чтобы проверить несколько связанных вариантов -- If the keyword is implemented as a user keyword, it typically contains - a similar workflow as `workflow tests`_. +- Если это ключевое слово реализовано как пользовательское ключевое слово, то оно обычно содержит последовательность операций, как и `Workflow тестирование`_ . - - Unless needed elsewhere, it is a good idea to create it in the same file - as tests using it. + - Пока не потребуется иное, лучше описывать его в том же файле, что и тест. -- Recommended to use the *test template* functionality. +- Рекомендуется использовать для этого *шаблоны тестов*. - - No need to repeat the keyword multiple times. - - Easier to test multiple variations in one test. + - Тогда вам не потребуется повторят ключевое слово несколько раз в одном тесте. + - Так легче в одном тест прогнать сразу несколько вариаций. -- Possible, and recommended, to name column headings +- Вы можете, и это рекомендуется, давать названия колонкам с данными. -- If a really big number of tests is needed, consider generating them based - on an external model. +- Если требуется действительно большое количество тестов, то рекомендуется генерировать их на основе внешних моделей. -Example: +Пример: .. code:: robotframework *** Settings *** - Test Template Login with invalid credentials should fail + Test Template Вход с неверными данными пользователя должен закончится сообщением об ошибке *** Test Cases *** USERNAME PASSWORD - Invalid Username invalid ${VALID PASSWORD} - Invalid Password ${VALID USERNAME} invalid - Invalid Both invalid invalid - Empty Username ${EMPTY} ${VALID PASSWORD} - Empty Password ${VALID USERNAME} ${EMPTY} - Empty Both ${EMPTY} ${EMPTY} + Неверное имя invalid ${VALID PASSWORD} + Неверный пароль ${VALID USERNAME} invalid + Оба неверные invalid invalid + Пустое имя ${EMPTY} ${VALID PASSWORD} + Пустой пароль ${VALID USERNAME} ${EMPTY} + Оба пустые ${EMPTY} ${EMPTY} *** Keywords *** - Login with invalid credentials should fail + Вход с неверными данными пользователя должен закончится сообщением об ошибке [Arguments] ${username} ${password} - Input Username ${username} - Input Password ${password} - Submit Credentials - Error Page Should Be Open + Ввести имя пользователя ${username} + Ввести пароль ${password} + Отправить учетные данные + Открылась страница с сообщением об ошибке. -The `web demo project`_ contains an executable version of this example too. +Упомянутый `web demo project`_ содержит исполняемую версию и этого примера. User keywords From 30b14158ee839073e4524d1feb9685cbb90e1318 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sun, 29 Nov 2020 19:15:34 +0300 Subject: [PATCH 11/24] translate all other section. --- HowToWriteGoodTestCases_RU.rst | 135 ++++++++++++++++----------------- 1 file changed, 66 insertions(+), 69 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 9202504..2a825d4 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -413,151 +413,148 @@ Workflow тестирование Отправить учетные данные Открылась страница с сообщением об ошибке. -Упомянутый `web demo project`_ содержит исполняемую версию и этого примера. +Вышеупомянутый `web demo project`_ содержит исполняемую версию и этого примера. User keywords ============= -- Should be easy to understand. +- Должны быть легкими для понимания. - - Same rules as with workflow tests. + - Правил такие же как для workflow тестов. -- Different abstraction levels. +- Разыне уровни абстракции. -- Can contain some programming logic (for loops, if/else). +- Могуть содержать прогрммную логику(циклы, условия). - - Especially on lower level keywords. - - Complex logic in libraries rather than in user keywords. + - Особенно в низкоуровневых ключевых словах. + - Сложную логику лучше размещать в библиотеках, а не в пользовательских ключевых словах. -Variables -========= +Переменные +========== -- Encapsulate long and/or complicated values. +- Прячут в себе длинные и/или сложные значения. -- Pass information from them command line using the `--variable` option. +- Позволяют передать данные из командной строки, используя опцию `--variable`. -- Pass information between keywords. +- Позволяют передат данные от одного ключевого слова другому. -Variable naming ---------------- +Наименование переменных +----------------------- -- Clear but not too long names. +- Понятные, но не слишком длинные имена. -- Can use comments in variable table to document them more. +- Можно использовать комментарии в таблицах переменных, для более подробного описания. -- Use case consistently: +- Используйте регистр букв единообразно: - - Lower case with local variables only available inside a certain scope. - - Upper case with others (global, suite or test level). - - Both space and underscore can be used as a word separator. + - Нижний регистр для локальных переменных доступных в ограниченной области. + - Вержний регистр для остальных (глобальных, или уровня тестового набора). + - В качества разделителя можно использовать, и пробелы, и символы подчеркивания. -- Recommended to also list variables that are set dynamically in the variable - table. +- Рекомендуется перечислять в таблице переменных и те переменные, значение которых опредеяется динамически - - Set typically using BuiltIn keyword `Set Suite Variable`__. - - The initial value should explain where/how the real value is set. + - Установка значения переменной обычно делается с помощьй встроенного ключевого слова `Set Suite Variable`__. + - Стартовое значение должно объяснять, где и как устанавливается реальное значение. -Example: +Приверр: .. code:: robotframework *** Settings *** - Suite Setup Set Active User + Suite Setup Задать активного пользователя *** Variables *** - # Default system address. Override when tested agains other instances. + # Адрес системы по умолчанию. Перезаписать при использовани на другом инстансе. ${SERVER URL} http://sre-12.example.com/ - ${USER} Actual value set dynamically at suite setup + ${USER} Актуализировать набор значение при подготовке тестовго набора *** Keywords *** - Set Active User - ${USER} = Get Current User ${SERVER URL} + Задать активного пользователя + ${USER} = Получить текущего пользователя ${SERVER URL} Set Suite Variable ${USER} __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Suite%20Variable -Passing and returning values ----------------------------- +Как получить и вернуть значение +--------------------------- -- Common approach is to return values from keywords, assign them to variables - and then pass them as arguments to other keywords. +- Обычный подход заключается в том чтобы вернуть значение из ключевого слова, присвоить его переменной и предать для использования другими ключевыми словами - - Clear and easy to follow approach. - - Allows creating independent keywords and facilitates re-use. - - Looks like programming and thus not so good on the test case level. + - Понятный и простой в использовании подход. + - Позволяет создавать независимые ключевые слова и облегачет их повторное использование. + - Выглядит как программирование и поэтому не очень хорош для использования на уровне тестовых наборов. -- Alternative approach is storing information in a library or using the BuiltIn - `Set Test Variable`__ keyword. +- Алтернативным является подход с сохранением данных в бибилотеке или использование встроенного ключевого слова + `Set Test Variable`__. - - Avoid programming style on the test case level. - - Can be more complex to follow and make reusing keywords harder. + - Позвоялет избежать программного стиля на уровне тестовых наборов. + - Может быть более сложным в реализации и может делать переиспользование ключевых слов более сложным. __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Test%20Variable -Good: +Правильно: .. code:: robotframework *** Test Cases *** - Withdraw From Account - Withdraw From Account $50 - Withdraw Should Have Succeeded + Списание со счета + Списать со счета $50 + Списание пршло успешно *** Keywords *** - Withdraw From Account + Списать со счета [Arguments] ${amount} - ${STATUS} = Withdraw From User Account ${USER} ${amount} + ${STATUS} = Списать со счета пользователя ${USER} ${amount} Set Test Variable ${STATUS} - Withdraw Should Have Succeeded + Списание пршоло успешно Should Be Equal ${STATUS} SUCCESS -Not so good: +Приемлимо, но похуже: .. code:: robotframework *** Test Cases *** - Withdraw From Account - ${status} = Withdraw From Account $50 - Withdraw Should Have Succeeded ${status} + Списание со счета + ${status} = Списать со счета $50 + Списание прошло успешно ${status} *** Keywords *** - Withdraw From Account + Списать со счета [Arguments] ${amount} - ${status} = Withdraw From User Account ${USER} ${amount} + ${status} = Списать со счета пользователя ${USER} ${amount} [Return] ${status} - Withdraw Should Have Succeeded + Списание прошло успешно [Arguments] ${status} Should Be Equal ${status} SUCCESS -Avoid sleeping -============== +Избегайте безусловных ожиданий +============================== -- Sleeping is a very fragile way to synchronize tests. +- Безусловное ожидание это очень ненадежный способ синхронизации тестов. -- Safety margins cause too long sleeps on average. +- Заложенное в них время время чаще всего оказывается избыточным. -- Instead of sleeps, use keyword that polls has a certain action occurred. +- Вместо безусловных ожиданий используйте опрос ожидаемого действия. - - Keyword names often starts with `Wait ...`. - - Should have a maximum time to wait. - - Possible to wrap other keywords inside the BuiltIn keyword - `Wait Until Keyword Succeeds`__. + - Такие ключевые слова обычно начинаются со слова `Wait ...`. + - Должны включить в число параметров время максимального ожидания. + - Можно также "обертывать" другие ключевые слова с помощью встроенного ключевого слова `Wait Until Keyword Succeeds`__. -- Sometimes sleeping is the easiest solution. +- Иногда безусловное ожидание это самое легкое решение. - - Always use with care. - - Never use in user keywords that are used often by tests or other keywords. + - Всегда используйте его с осторожностью. + - Никогда не используйте его в частоиспользуемых ключевых словах. -- Can be useful in debugging to stop execution. +- Может быть полезно при отладке, для принудителной остановки исполнения теста. - - `Dialogs library`__ often works better. + - Но `Dialogs library`__ обычно подходит для этого лучше. __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Wait%20Until%20Keyword%20Succeeds __ http://robotframework.org/robotframework/latest/libraries/Dialogs.html From ebbc3f00956b8be9ce5bfcea845cce6d0caf04ec Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Sun, 29 Nov 2020 19:30:55 +0300 Subject: [PATCH 12/24] style fix and typo. --- HowToWriteGoodTestCases_RU.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 2a825d4..78df146 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -482,17 +482,17 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 Как получить и вернуть значение --------------------------- -- Обычный подход заключается в том чтобы вернуть значение из ключевого слова, присвоить его переменной и предать для использования другими ключевыми словами +- Обычный подход заключается в том чтобы вернуть значение из ключевого слова, присвоить его переменной и передать для использования другими ключевыми словами. - - Понятный и простой в использовании подход. - - Позволяет создавать независимые ключевые слова и облегачет их повторное использование. - - Выглядит как программирование и поэтому не очень хорош для использования на уровне тестовых наборов. + - Это понятный и простой в использовании подход. + - Он позволяет создавать независимые ключевые слова и облегачет их повторное использование. + - Но выглядит как программный код и поэтому не очень хорош для использования на уровне тестовых наборов. - Алтернативным является подход с сохранением данных в бибилотеке или использование встроенного ключевого слова `Set Test Variable`__. - Позвоялет избежать программного стиля на уровне тестовых наборов. - - Может быть более сложным в реализации и может делать переиспользование ключевых слов более сложным. + - Может быть более сложным в реализации и делать повторное использование ключевых слов менее удобным. __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Test%20Variable @@ -539,9 +539,9 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 - Безусловное ожидание это очень ненадежный способ синхронизации тестов. -- Заложенное в них время время чаще всего оказывается избыточным. +- Заложенное в них время, чаще всего оказывается избыточным. -- Вместо безусловных ожиданий используйте опрос ожидаемого действия. +- Вместо безусловных ожиданий используйте периодический опрос (полллинг) ожидаемого действия. - Такие ключевые слова обычно начинаются со слова `Wait ...`. - Должны включить в число параметров время максимального ожидания. @@ -552,7 +552,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 - Всегда используйте его с осторожностью. - Никогда не используйте его в частоиспользуемых ключевых словах. -- Может быть полезно при отладке, для принудителной остановки исполнения теста. +- Могут быть полезны при отладке, для принудителной остановки исполнения теста. - Но `Dialogs library`__ обычно подходит для этого лучше. From a432c9f81f5d1c062e68ae49fa84ec5109e93988 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 30 Nov 2020 10:48:41 +0300 Subject: [PATCH 13/24] fix typos and errors. --- HowToWriteGoodTestCases_RU.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 78df146..dd8e278 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -124,7 +124,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Старайтесь использовать имена, которые описывают то, что делает это ключевое слово. - - По возможности, используйте уже существующие ключевый слова. + - По возможности, используйте уже существующие ключевые слова. - Более обобщенные названия приемлемы, если эти процедуры содержать несвязанные шаги. @@ -133,7 +133,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Часто бывает, что лучше использовать более общее описание (например, `Инициализировать систему`). -- Подходящим может быть использования встроенного ключевога слова `Run Keywords`__ , если в процедуре используются готовые ключевые слова более низкого уровня. +- Подходящим может быть использования встроенного ключевого слова `Run Keywords`__ , если в процедуре используются готовые ключевые слова более низкого уровня. - Этот способ не подходит для повторного использования, поэтому лучше использовать его, если эта процедура будет использоваться только в одном месте. @@ -188,7 +188,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 - Документация может содержать ссылки на дополнительную информацию. -- Рассмотрите возможностьи использования метаданных тестовых наборов, если вам требуется документировать иформацию предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). +- Рассмотрите возможностьи использования метаданных тестовых наборов, если вам требуется документировать информацию, предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). - Документация и метаданные для наборов тестов верхнего уровня может быть установлена с помощью опций командной строки `--doc` и `--metadata` соответсвенно. @@ -383,7 +383,7 @@ Workflow тестирование - Рекомендуется использовать для этого *шаблоны тестов*. - - Тогда вам не потребуется повторят ключевое слово несколько раз в одном тесте. + - Тогда вам не потребуется повторять ключевое слово несколько раз в одном тесте. - Так легче в одном тест прогнать сразу несколько вариаций. - Вы можете, и это рекомендуется, давать названия колонкам с данными. @@ -423,9 +423,9 @@ User keywords - Правил такие же как для workflow тестов. -- Разыне уровни абстракции. +- Могут иметь разные уровни абстракции. -- Могуть содержать прогрммную логику(циклы, условия). +- Могут содержать программную логику(циклы, условия). - Особенно в низкоуровневых ключевых словах. - Сложную логику лучше размещать в библиотеках, а не в пользовательских ключевых словах. @@ -438,7 +438,7 @@ User keywords - Позволяют передать данные из командной строки, используя опцию `--variable`. -- Позволяют передат данные от одного ключевого слова другому. +- Позволяют передать данные от одного ключевого слова другому. Наименование переменных @@ -451,15 +451,15 @@ User keywords - Используйте регистр букв единообразно: - Нижний регистр для локальных переменных доступных в ограниченной области. - - Вержний регистр для остальных (глобальных, или уровня тестового набора). - - В качества разделителя можно использовать, и пробелы, и символы подчеркивания. + - Верхний регистр для остальных (глобальных, или уровня тестового набора). + - В качестве разделителя можно использовать, и пробелы, и символы подчеркивания. - Рекомендуется перечислять в таблице переменных и те переменные, значение которых опредеяется динамически - Установка значения переменной обычно делается с помощьй встроенного ключевого слова `Set Suite Variable`__. - Стартовое значение должно объяснять, где и как устанавливается реальное значение. -Приверр: +Пример: .. code:: robotframework @@ -491,7 +491,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 - Алтернативным является подход с сохранением данных в бибилотеке или использование встроенного ключевого слова `Set Test Variable`__. - - Позвоялет избежать программного стиля на уровне тестовых наборов. + - Позволяет избежать программного стиля на уровне тестовых наборов. - Может быть более сложным в реализации и делать повторное использование ключевых слов менее удобным. __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Test%20Variable @@ -511,10 +511,10 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 ${STATUS} = Списать со счета пользователя ${USER} ${amount} Set Test Variable ${STATUS} - Списание пршоло успешно + Списание прошло успешно Should Be Equal ${STATUS} SUCCESS -Приемлимо, но похуже: +Приемлемо, но похуже: .. code:: robotframework @@ -552,7 +552,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 - Всегда используйте его с осторожностью. - Никогда не используйте его в частоиспользуемых ключевых словах. -- Могут быть полезны при отладке, для принудителной остановки исполнения теста. +- Могут быть полезны при отладке, для принудительной остановки исполнения теста. - Но `Dialogs library`__ обычно подходит для этого лучше. From 9477d11472db06839cbabdd1da0d57e63d1337b9 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 30 Nov 2020 11:48:18 +0300 Subject: [PATCH 14/24] Update README.rst add HowToWriteGoodTestCases_RU.rst file description. --- README.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/README.rst b/README.rst index 0b632e1..abaeeaf 100644 --- a/README.rst +++ b/README.rst @@ -5,3 +5,4 @@ This project documents general guidelines for writing good test cases using `Robot Framework `_. The how-to itself is in ``_ file. +``_ the translation to russian. From ef5502bcccc6a1dddaf2fff5ce66e33ddd832e32 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 30 Nov 2020 12:02:47 +0300 Subject: [PATCH 15/24] Update README.rst fix description. --- README.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.rst b/README.rst index abaeeaf..1e53866 100644 --- a/README.rst +++ b/README.rst @@ -5,4 +5,5 @@ This project documents general guidelines for writing good test cases using `Robot Framework `_. The how-to itself is in ``_ file. -``_ the translation to russian. + +``_ is the translation to Russian. From 9ca03173d3c3022dad06c3e898ae0340774036f2 Mon Sep 17 00:00:00 2001 From: Roman Date: Mon, 30 Nov 2020 18:05:46 +0300 Subject: [PATCH 16/24] Update HowToWriteGoodTestCases_RU.rst Fix typos --- HowToWriteGoodTestCases_RU.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index dd8e278..d6cb51e 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -12,7 +12,7 @@ Введение ============ -- Это руководство дает обобщенные советы по написания наборов тестов с использованием Robot +- Это руководство дает обобщенные советы по написанию наборов тестов с использованием Robot Framework. - Детальное описание взаимодействия с тестируемыми системами выходит за рамки настоящего руководства. @@ -46,7 +46,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Символы подчеркивания преобразуются в пробелы. - Если имя в нижнем регистре, то первые буквы в словах отображаются заглавными. -- Имя может быть длинным, но слишком длинные имена могут не походит под ограничения файловой системы. +- Имя может быть длинным, но слишком длинные имена могут не подходить под ограничения файловой системы. - В случае необходимости имя набора тестов может быть перезаписано из командной строки с использованием опции `--name`. @@ -61,7 +61,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Имена тестов должны такими же описательными, как и названия наборов тестов. -- Если набор тестов содержить много похожих тестов и имеет подходяещее название, то название входящих в него тестов можно сделать короче. +- Если набор тестов содержит много похожих тестов и имеет подходяещее название, то название входящих в него тестов можно сделать короче. - Имя теста отображается в точности так, как вы его зададите в файле тестового сценария. @@ -93,13 +93,13 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai Названия ключевых слов ---------------------- -- Название ключевого слова должно описывать выполняемое действие и быть ясными. +- Название ключевого слова должно описывать выполняемое действие и быть ясным. - Навзание должно описывать, **что** делает это ключевое слов, а не то, **как** оно это делает. - Может иметь разные уровни абстракции (например, `Ввод текста` или `Администратор входит в систему`). -- Нет четкого правил, которое бы определяло должны ли быть заглавными первые буквы во всех словах (title casing) или же заглавной должна быть только первая буква первого слова. +- Нет четкого правила, которое бы определяло должны ли быть заглавными первые буквы во всех словах (title casing) или же заглавной должна быть только первая буква первого слова. - Title casing обычно используется, если название короткое (например. `Ввод текста`). - Заглавная буква в первом слове обычно работает лучше, если название похоже на законченное предложение (например, `Администратор входит в систему`). Обычно это ключевые слова более высокого уровня. From fe4c0a885003f14298983b0c9429f455276e9d46 Mon Sep 17 00:00:00 2001 From: Roman Date: Mon, 30 Nov 2020 18:15:27 +0300 Subject: [PATCH 17/24] Update HowToWriteGoodTestCases_RU.rst Fix typos --- HowToWriteGoodTestCases_RU.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index d6cb51e..bc0dc70 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -95,7 +95,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Название ключевого слова должно описывать выполняемое действие и быть ясным. -- Навзание должно описывать, **что** делает это ключевое слов, а не то, **как** оно это делает. +- Название должно описывать, **что** делает это ключевое слово, а не то, **как** оно это делает. - Может иметь разные уровни абстракции (например, `Ввод текста` или `Администратор входит в систему`). @@ -188,7 +188,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 - Документация может содержать ссылки на дополнительную информацию. -- Рассмотрите возможностьи использования метаданных тестовых наборов, если вам требуется документировать информацию, предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). +- Рассмотрите возможности использования метаданных тестовых наборов, если вам требуется документировать информацию, предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). - Документация и метаданные для наборов тестов верхнего уровня может быть установлена с помощью опций командной строки `--doc` и `--metadata` соответсвенно. From 171c44aeb3c8bab1aed4c0dabe66ebaaa81d3437 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Tue, 1 Dec 2020 13:30:48 +0300 Subject: [PATCH 18/24] fix typo. --- HowToWriteGoodTestCases_RU.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index bc0dc70..ca40055 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -61,7 +61,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - Имена тестов должны такими же описательными, как и названия наборов тестов. -- Если набор тестов содержит много похожих тестов и имеет подходяещее название, то название входящих в него тестов можно сделать короче. +- Если набор тестов содержит много похожих тестов и имеет подходящее название, то название входящих в него тестов можно сделать короче. - Имя теста отображается в точности так, как вы его зададите в файле тестового сценария. From a01adeea98fe196acc1540346569911a83cc0e0c Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Tue, 1 Dec 2020 13:38:52 +0300 Subject: [PATCH 19/24] fix typo. --- HowToWriteGoodTestCases_RU.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index ca40055..4e00386 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -126,7 +126,7 @@ __ http://blog.codecentric.de/en/2010/07/how-to-structure-a-scalable-and-maintai - По возможности, используйте уже существующие ключевые слова. -- Более обобщенные названия приемлемы, если эти процедуры содержать несвязанные шаги. +- Более обобщенные названия приемлемы, если эти процедуры содержат несвязанные шаги. - Перечисление шагов в названии приводит к дублированию и проблемам с поддержкой (например, `Войти в систему, добавить пользователя, активировать оповещение и проверить баланс`). From 871e7a80aa5b1cfe0c497ae11bdbb52d978bec12 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Tue, 1 Dec 2020 13:50:39 +0300 Subject: [PATCH 20/24] fix typos. --- HowToWriteGoodTestCases_RU.rst | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 4e00386..9d4a271 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -175,7 +175,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 - Часто бывает нелишним добавить к тестовым сценариям документацию по ним. -- Документация должна содержать информцию о назначении тестов, среде выполнения и тому подобном. +- Документация должна содержать информацию о назначении тестов, среде выполнения и тому подобном. - Не должна повторять дословно названия набора тестов. @@ -217,7 +217,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 - Обычно тестам не требуется документация. - - Название и документация родительского набора тестов должна давать достатчно общей инфрмации. + - Название и документация родительского набора тестов должна давать достаточно общей инфрмации. - Структура тестовго сценария долна быть достаточно ясной и без дополнительной документации или других комментариев. - Использование тэгов обеспечивает большую гибкость и функциональность (ведение статистики, включение/выключение при запуске и т. д.), чем документация. @@ -257,11 +257,11 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 Документация к пользовательским ключевым словам ----------------------------------------------- -- Не требуется, если ключевые слова отностиельно простые. +- Не требуется, если ключевые слова относительно простые. - Подходящего названия и имен аргументов, а также ясной структуры — должно быть вполне достаточно. -- Важным может быть документирование аргументов и возвращяемых значений. +- Важным может быть документирование аргументов и возвращаемых значений. - Документация отображается в файлах ресурсов, генерируемых с помощью Libdoc__ , а редакторы такие как RIDE__ могут отображать ее при автодополнении имени ключевого слова и в других местах. @@ -280,7 +280,7 @@ __ https://github.com/robotframework/RIDE - Тесты должны быть независимыми. Инициализироваться через общие процедуры запуска/завершения тестов. -- Иногда зависмости тестов друг от друга невозможжно избежать. +- Иногда зависмости тестов друг от друга невозможно избежать. - Например, им потребуется слишком много времени для инициализации по отдельности. - Не стоит делать длинных цепочек из зависимых тестов. @@ -299,7 +299,7 @@ __ https://github.com/robotframework/RIDE - Выбирайте подходящий уровень абстракции. - Используйте уровень абстракции единообразно (принцип одного уровня асбтракции). - - Не добавляте ненужные детали на уровень тестового сценария. + - Не добавляйте ненужные детали на уровень тестового сценария. - Существует два типа тестовых сценариев: @@ -327,7 +327,7 @@ Workflow тестирование - Тесты для отдельных частей функциональности будут более детальными. - End-to-end тесты могут имет самый высокий уровень абстракции. - - Один ест дост должен использовать только один уровень абстракции. + - Один тест должен использовать только один уровень абстракции. - Разные стили: @@ -336,13 +336,13 @@ Workflow тестирование - Используйте язык предметной области. - Все (включая клиента и/или владельца продукта) всегда должны понимать о чем идет речь в тесте. -- Никакой сложной логики на уровне тестовых сыенариев. +- Никакой сложной логики на уровне тестовых сценариев. - Никаких конструкций типа циклов или условий. - Используйте назначение переменных с осторожностью. - Тестовый сценарий не должен выглядить как скрипт! -- Максиму 10 шагов, а лучше меньше. +- Максимум 10 шагов, а лучше меньше. Пример использования "нормального" стиля ключевых слов: @@ -421,7 +421,7 @@ User keywords - Должны быть легкими для понимания. - - Правил такие же как для workflow тестов. + - Правила такие же, как для workflow тестов. - Могут иметь разные уровни абстракции. @@ -488,7 +488,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20 - Он позволяет создавать независимые ключевые слова и облегачет их повторное использование. - Но выглядит как программный код и поэтому не очень хорош для использования на уровне тестовых наборов. -- Алтернативным является подход с сохранением данных в бибилотеке или использование встроенного ключевого слова +- Альтернативным является подход с сохранением данных в библиотеке или использование встроенного ключевого слова `Set Test Variable`__. - Позволяет избежать программного стиля на уровне тестовых наборов. From 04fb38009ca2be3122c4806d8b48fda375e1756d Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 11 Jan 2021 17:38:03 +0300 Subject: [PATCH 21/24] Fix translation. --- HowToWriteGoodTestCases_RU.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 9d4a271..dc821a9 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -479,14 +479,14 @@ User keywords __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Suite%20Variable -Как получить и вернуть значение +Как передать и вернуть значение --------------------------- - Обычный подход заключается в том чтобы вернуть значение из ключевого слова, присвоить его переменной и передать для использования другими ключевыми словами. - Это понятный и простой в использовании подход. - - Он позволяет создавать независимые ключевые слова и облегачет их повторное использование. - - Но выглядит как программный код и поэтому не очень хорош для использования на уровне тестовых наборов. + - Он позволяет создавать независимые ключевые слова и облегчает их повторное использование. + - Но, выглядит как программный код и поэтому не очень хорош для использования на уровне тестовых наборов. - Альтернативным является подход с сохранением данных в библиотеке или использование встроенного ключевого слова `Set Test Variable`__. From 866b84429fd9e86ddd59940b8831357ac8a92bbb Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 11 Jan 2021 17:43:31 +0300 Subject: [PATCH 22/24] fix typo --- HowToWriteGoodTestCases_RU.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index dc821a9..a4d85a3 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -190,7 +190,7 @@ __ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20 - Рассмотрите возможности использования метаданных тестовых наборов, если вам требуется документировать информацию, предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). -- Документация и метаданные для наборов тестов верхнего уровня может быть установлена с помощью опций командной строки `--doc` и `--metadata` соответсвенно. +- Документация и метаданные для наборов тестов верхнего уровня может быть установлена с помощью опций командной строки `--doc` и `--metadata` соответственно. Правильно: From 8aba57153d1192751939e3d5441f93e15bf2104a Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 11 Jan 2021 17:46:10 +0300 Subject: [PATCH 23/24] Fix typo --- HowToWriteGoodTestCases_RU.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index a4d85a3..85cc5bf 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -284,7 +284,7 @@ __ https://github.com/robotframework/RIDE - Например, им потребуется слишком много времени для инициализации по отдельности. - Не стоит делать длинных цепочек из зависимых тестов. - - Для проверки статуса предыдущего тесто может пригодится переменная `${PREV TEST STATUS}`. + - Для проверки статуса предыдущего теста может пригодится переменная `${PREV TEST STATUS}`. Структура тестовых сценариев From 19241d2a6efa54cf2648b13ce25bf67058ce7340 Mon Sep 17 00:00:00 2001 From: victorkaplunov Date: Mon, 11 Jan 2021 17:48:22 +0300 Subject: [PATCH 24/24] fix typo. --- HowToWriteGoodTestCases_RU.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst index 85cc5bf..ff2217d 100644 --- a/HowToWriteGoodTestCases_RU.rst +++ b/HowToWriteGoodTestCases_RU.rst @@ -292,7 +292,7 @@ __ https://github.com/robotframework/RIDE - Тестовые сценарии должны быть простыми для понимания. -- Один тест должен проверять одну вешь. +- Один тест должен проверять одну вещь. - Эта *вещь* может быть маленькой (часть какой-либо фукции) или большой (результат процесса).