diff --git a/HowToWriteGoodTestCases_RU.rst b/HowToWriteGoodTestCases_RU.rst new file mode 100644 index 0000000..ff2217d --- /dev/null +++ b/HowToWriteGoodTestCases_RU.rst @@ -0,0 +1,560 @@ +.. 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` + + +Названия тестовых сценариев +---------------------------- + +- Имена тестов должны такими же описательными, как и названия наборов тестов. + +- Если набор тестов содержит много похожих тестов и имеет подходящее название, то название входящих в него тестов можно сделать короче. + +- Имя теста отображается в точности так, как вы его зададите в файле тестового сценария. + +Например, если у вас есть тесты, связанные с проверкой невалидного входа в систему в файле `невалидный_вход.robot`, то это будут подходящие имена: + +.. code:: robotframework + + *** Test Cases *** + Пустой пароль + Пустое имя пользователя + Пустой пароль и имя пользователя + Неверное имя пользователя + Неверный пароль + Неверный пароль и имя пользователя + +А эти имена будут слегка длинными: + +.. code:: robotframework + + *** Test Cases *** + Вход с пустым поролем не должен быть успешным + Вход с пустым именем пользователя не должен быть успешным + Вход с пустым именем пользователя и паролем не должен быть успешным + Вход с неверным поролем не должен быть успешным + Вход с неверным именем пользователя не должен быть успешным + Вход с невернымм именем пользователя и паролем не должен быть успешным + + +Названия ключевых слов +---------------------- + +- Название ключевого слова должно описывать выполняемое действие и быть ясным. + +- Название должно описывать, **что** делает это ключевое слово, а не то, **как** оно это делает. + +- Может иметь разные уровни абстракции (например, `Ввод текста` или `Администратор входит в систему`). + +- Нет четкого правила, которое бы определяло должны ли быть заглавными первые буквы во всех словах (title casing) или же заглавной должна быть только первая буква первого слова. + + - Title casing обычно используется, если название короткое (например. `Ввод текста`). + - Заглавная буква в первом слове обычно работает лучше, если название похоже на законченное предложение (например, `Администратор входит в систему`). Обычно это ключевые слова более высокого уровня. + +Правильно: + +.. code:: robotframework + + *** Keywords *** + Login With Valid Credentials + +Неправильно: + +.. code:: robotframework + + *** Keywords *** + Input Valid Username And Valid Password And Click Login Button + + +Выбор имен для процедур подготовки и завершения тестов +---------------------------------------------------------------- + +- Старайтесь использовать имена, которые описывают то, что делает это ключевое слово. + + - По возможности, используйте уже существующие ключевые слова. + +- Более обобщенные названия приемлемы, если эти процедуры содержат несвязанные шаги. + + - Перечисление шагов в названии приводит к дублированию и проблемам с поддержкой + (например, `Войти в систему, добавить пользователя, активировать оповещение и проверить баланс`). + + - Часто бывает, что лучше использовать более общее описание (например, `Инициализировать систему`). + +- Подходящим может быть использования встроенного ключевого слова `Run Keywords`__ , если в процедуре используются готовые ключевые слова более низкого уровня. + + - Этот способ не подходит для повторного использования, поэтому лучше использовать его, если эта процедура будет использоваться только в одном месте. + +- Всякий, кто работет с тестами, должен из названия понимать, что эти процедуры делают. + +Правильно: + +.. code:: robotframework + + *** Settings *** + Suite Setup Инициализировать систему + +Правильно (если используется только в одном месте): + +.. code:: robotframework + + *** Settings *** + Suite Setup Run Keywords + ... Войти в систему AND + ... Добавить пользователя AND + ... Активировать оповещение AND + ... Проверить баланс + +Неправильно: + +.. code:: robotframework + + *** Settings *** + Suite Setup Войти в систему, добавить пользователя, активировать оповещение и проверить баланс + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Run%20Keywords + + +Документация +============= + +Документация наборов тестов +--------------------------- + +- Часто бывает нелишним добавить к тестовым сценариям документацию по ним. + +- Документация должна содержать информацию о назначении тестов, среде выполнения и тому подобном. + +- Не должна повторять дословно названия набора тестов. + + - Лучше вовсе не иметь документации, если она не нужна на самом деле. + +- Не должна включать слишком много деталей тестовых сценариев. + + - Тесты должны быть достаточно понятными для понимания сами по себе. + - Дублирующая информация это мусор и дополнительные проблемы с поддержкой тестов. + +- Документация может содержать ссылки на дополнительную информацию. + +- Рассмотрите возможности использования метаданных тестовых наборов, если вам требуется документировать информацию, предоставленную в виде пар ключ-значение (например `Версия: 1.0` или `OS: Linux`). + +- Документация и метаданные для наборов тестов верхнего уровня может быть установлена с помощью опций командной строки `--doc` и `--metadata` соответственно. + +Правильно: + +.. code:: robotframework + + *** Settings *** + Documentation Тест проверки списания денег со счета пользователя. + ... Успех и отказ при проведении операции должен проходить + ... корректно, в зависимости от состояния баланса и правил + ... принятых для этого типа счета. + ... Подробнее смотри: http://internal.example.com/docs/abs.pdf + Metadata Версия 0.1 + +Неправильно (особенно если набор тестов уже имеет подходящее название вроде `account_withdrawal.robot`): + +.. code:: robotframework + + *** Settings *** + Documentation Тест списания со счета. + + +Документация тестовых сценариев +------------------------------- + +- Обычно тестам не требуется документация. + + - Название и документация родительского набора тестов должна давать достаточно общей инфрмации. + - Структура тестовго сценария долна быть достаточно ясной и без дополнительной документации или других комментариев. + +- Использование тэгов обеспечивает большую гибкость и функциональность (ведение статистики, включение/выключение при запуске и т. д.), чем документация. + +- Иногда документация к сценарим бывает полезна, не бойтесь использовать ее. + +Правильно: + +.. code:: robotframework + + *** Test Cases *** + Валидный вход + [Tags] Итерация-3 Базовые + Открыть страницу входа + Ввести имя пользователя ${VALID USERNAME} + Ввести пароль ${VALID PASSWORD} + Отправить учетные данные + Должна быть открыта стартовая страница + +Неправильно: + +.. code:: robotframework + + *** Test Cases *** + Валидный вход + [Documentation] Открыть в браузере страницу входа, ввести валидные + ... имя пользователя и пароль. Убедиться что открылась + ... стартовая страница. + ... Это базовый тест. Создан во время 3-ей итерации. + Open Browser ${URL} ${BROWSER} + Input Text field1 ${UN11} + Input Text field2 ${PW11} + Click Button button_12 + Title Should Be Welcome Page + + +Документация к пользовательским ключевым словам +----------------------------------------------- + +- Не требуется, если ключевые слова относительно простые. + + - Подходящего названия и имен аргументов, а также ясной структуры — должно быть вполне достаточно. + +- Важным может быть документирование аргументов и возвращаемых значений. + +- Документация отображается в файлах ресурсов, генерируемых с помощью Libdoc__ , а редакторы такие как RIDE__ могут отображать ее при автодополнении имени ключевого слова и в других местах. + +__ http://robotframework.org/robotframework/#built-in-tools +__ https://github.com/robotframework/RIDE + + +Структура наборов тестов +======================== + +- Тесты в наборе должны быть связаны между собой. + + - Хороший признак этого — общие процедуры запуска/завершения тестов. + +- Набор не должен содержать слишком много тестов (максимум 10). Исключением может быть "`Тестирование на основе данных`_". + +- Тесты должны быть независимыми. Инициализироваться через общие процедуры запуска/завершения тестов. + +- Иногда зависмости тестов друг от друга невозможно избежать. + + - Например, им потребуется слишком много времени для инициализации по отдельности. + - Не стоит делать длинных цепочек из зависимых тестов. + - Для проверки статуса предыдущего теста может пригодится переменная `${PREV TEST STATUS}`. + + +Структура тестовых сценариев +============================ + +- Тестовые сценарии должны быть простыми для понимания. + +- Один тест должен проверять одну вещь. + + - Эта *вещь* может быть маленькой (часть какой-либо фукции) или большой (результат процесса). + +- Выбирайте подходящий уровень абстракции. + + - Используйте уровень абстракции единообразно (принцип одного уровня асбтракции). + - Не добавляйте ненужные детали на уровень тестового сценария. + +- Существует два типа тестовых сценариев: + + - `Workflow тестирование`_ + - `Тестирование на основе данных`_ + + +Workflow тестирование +--------------------- + +- Обычно оно включает три фазы: + + - Предусловие (не обязательно, чаще в процедуре подготовки тестов) + - Действие (делает что-то с системой) + - Проверка (валидация результата, обязательная часть) + - Уборка (не обязательно, всегда делается в завершающей процедуре, чтобы быть уверенным, что действие будет выполнено) + +- Ключевые слова описывают, что делает тест. + + - Используйте "говорящие" названия ключевых слов и подходящий уровень абстракции. + - Они должны содержать достаточно информации, чтобы выполнить тест вручную. + - Не должны требовать дополнительной документации или комментариев для того чтобы обьяснить, что этот тест делает. + +- Разные тесты могут иметь разный уровень абстракции. + + - Тесты для отдельных частей функциональности будут более детальными. + - End-to-end тесты могут имет самый высокий уровень абстракции. + - Один тест должен использовать только один уровень абстракции. + +- Разные стили: + + - Более "технические" для тестирования низкоуровневых деталей и интеграции. + - "Испольняемые спецификации" действующие как требования. + - Используйте язык предметной области. + - Все (включая клиента и/или владельца продукта) всегда должны понимать о чем идет речь в тесте. + +- Никакой сложной логики на уровне тестовых сценариев. + + - Никаких конструкций типа циклов или условий. + - Используйте назначение переменных с осторожностью. + - Тестовый сценарий не должен выглядить как скрипт! + +- Максимум 10 шагов, а лучше меньше. + +Пример использования "нормального" стиля ключевых слов: + +.. code:: robotframework + + *** Test Cases *** + Успешный вход в систему + Открыть страницу входа + Ввести имя пользователя demo + Ввести пароль mode + Отправить учетные данные + Открылась главная страница + +Пример с использванием высокоуровневого стиля "gherkin": + +.. code:: robotframework + + *** Test Cases *** + Успешный вход в систему + Given браузер открыл страницу входа + When пользователь "demo" зашел с паролем "mode" + Then открылась главная страница + +Смотрите `web demo project `_ +что увидеть исполняемую версию этих примеров. + +Тестирование на основе данных +----------------------------- + +- Одно ключевое слово высокого уровня на тест. + + - Разные аргументы формируют разные тесты. + - Один тест может запускать одно и тоже ключевое слово несколько раз, чтобы проверить несколько связанных вариантов + +- Если это ключевое слово реализовано как пользовательское ключевое слово, то оно обычно содержит последовательность операций, как и `Workflow тестирование`_ . + + - Пока не потребуется иное, лучше описывать его в том же файле, что и тест. + +- Рекомендуется использовать для этого *шаблоны тестов*. + + - Тогда вам не потребуется повторять ключевое слово несколько раз в одном тесте. + - Так легче в одном тест прогнать сразу несколько вариаций. + +- Вы можете, и это рекомендуется, давать названия колонкам с данными. + +- Если требуется действительно большое количество тестов, то рекомендуется генерировать их на основе внешних моделей. + +Пример: + +.. code:: robotframework + + *** Settings *** + Test Template Вход с неверными данными пользователя должен закончится сообщением об ошибке + + *** Test Cases *** USERNAME PASSWORD + Неверное имя invalid ${VALID PASSWORD} + Неверный пароль ${VALID USERNAME} invalid + Оба неверные invalid invalid + Пустое имя ${EMPTY} ${VALID PASSWORD} + Пустой пароль ${VALID USERNAME} ${EMPTY} + Оба пустые ${EMPTY} ${EMPTY} + + *** Keywords *** + Вход с неверными данными пользователя должен закончится сообщением об ошибке + [Arguments] ${username} ${password} + Ввести имя пользователя ${username} + Ввести пароль ${password} + Отправить учетные данные + Открылась страница с сообщением об ошибке. + +Вышеупомянутый `web demo project`_ содержит исполняемую версию и этого примера. + + +User keywords +============= + +- Должны быть легкими для понимания. + + - Правила такие же, как для workflow тестов. + +- Могут иметь разные уровни абстракции. + +- Могут содержать программную логику(циклы, условия). + + - Особенно в низкоуровневых ключевых словах. + - Сложную логику лучше размещать в библиотеках, а не в пользовательских ключевых словах. + + +Переменные +========== + +- Прячут в себе длинные и/или сложные значения. + +- Позволяют передать данные из командной строки, используя опцию `--variable`. + +- Позволяют передать данные от одного ключевого слова другому. + + +Наименование переменных +----------------------- + +- Понятные, но не слишком длинные имена. + +- Можно использовать комментарии в таблицах переменных, для более подробного описания. + +- Используйте регистр букв единообразно: + + - Нижний регистр для локальных переменных доступных в ограниченной области. + - Верхний регистр для остальных (глобальных, или уровня тестового набора). + - В качестве разделителя можно использовать, и пробелы, и символы подчеркивания. + +- Рекомендуется перечислять в таблице переменных и те переменные, значение которых опредеяется динамически + + - Установка значения переменной обычно делается с помощьй встроенного ключевого слова `Set Suite Variable`__. + - Стартовое значение должно объяснять, где и как устанавливается реальное значение. + +Пример: + +.. code:: robotframework + + *** Settings *** + Suite Setup Задать активного пользователя + + *** Variables *** + # Адрес системы по умолчанию. Перезаписать при использовани на другом инстансе. + ${SERVER URL} http://sre-12.example.com/ + ${USER} Актуализировать набор значение при подготовке тестовго набора + + *** Keywords *** + Задать активного пользователя + ${USER} = Получить текущего пользователя ${SERVER URL} + Set Suite Variable ${USER} + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Suite%20Variable + + +Как передать и вернуть значение +--------------------------- + +- Обычный подход заключается в том чтобы вернуть значение из ключевого слова, присвоить его переменной и передать для использования другими ключевыми словами. + + - Это понятный и простой в использовании подход. + - Он позволяет создавать независимые ключевые слова и облегчает их повторное использование. + - Но, выглядит как программный код и поэтому не очень хорош для использования на уровне тестовых наборов. + +- Альтернативным является подход с сохранением данных в библиотеке или использование встроенного ключевого слова + `Set Test Variable`__. + + - Позволяет избежать программного стиля на уровне тестовых наборов. + - Может быть более сложным в реализации и делать повторное использование ключевых слов менее удобным. + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Test%20Variable + +Правильно: + +.. code:: robotframework + + *** Test Cases *** + Списание со счета + Списать со счета $50 + Списание пршло успешно + + *** Keywords *** + Списать со счета + [Arguments] ${amount} + ${STATUS} = Списать со счета пользователя ${USER} ${amount} + Set Test Variable ${STATUS} + + Списание прошло успешно + Should Be Equal ${STATUS} SUCCESS + +Приемлемо, но похуже: + +.. code:: robotframework + + *** Test Cases *** + Списание со счета + ${status} = Списать со счета $50 + Списание прошло успешно ${status} + + *** Keywords *** + Списать со счета + [Arguments] ${amount} + ${status} = Списать со счета пользователя ${USER} ${amount} + [Return] ${status} + + Списание прошло успешно + [Arguments] ${status} + Should Be Equal ${status} SUCCESS + + +Избегайте безусловных ожиданий +============================== + +- Безусловное ожидание это очень ненадежный способ синхронизации тестов. + +- Заложенное в них время, чаще всего оказывается избыточным. + +- Вместо безусловных ожиданий используйте периодический опрос (полллинг) ожидаемого действия. + + - Такие ключевые слова обычно начинаются со слова `Wait ...`. + - Должны включить в число параметров время максимального ожидания. + - Можно также "обертывать" другие ключевые слова с помощью встроенного ключевого слова `Wait Until Keyword Succeeds`__. + +- Иногда безусловное ожидание это самое легкое решение. + + - Всегда используйте его с осторожностью. + - Никогда не используйте его в частоиспользуемых ключевых словах. + +- Могут быть полезны при отладке, для принудительной остановки исполнения теста. + + - Но `Dialogs library`__ обычно подходит для этого лучше. + +__ http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Wait%20Until%20Keyword%20Succeeds +__ http://robotframework.org/robotframework/latest/libraries/Dialogs.html diff --git a/README.rst b/README.rst index 0b632e1..1e53866 100644 --- a/README.rst +++ b/README.rst @@ -5,3 +5,5 @@ This project documents general guidelines for writing good test cases using `Robot Framework `_. The how-to itself is in ``_ file. + +``_ is the translation to Russian.