Robot Framework: Как отличить тестовый случай FAIL из-за сбоя ключевого слова в обычном шаге теста по сравнению с ошибкой в ​​шаге проверки

Question

Любая библиотека в Robot Framework имеет две категории ключевых слов.Ключевые слова для выполнения обычного шага тестирования (например, Click Button) и ключевые слова, которые проверяют определенную вещь (например, Table Column Should Contain).Последние ключевые слова обычно содержат слово «должен».

Я предполагаю, что Robot Framework ставит статус PASS или FAIL только для выполненных тестовых случаев в отчете.Как определить, что тестовые случаи FAIL не пройдены из-за ключевых слов шага теста, а не из-за ключевых слов проверки теста?

Например, тестовый пример калькулятора нажимает кнопки 2, +, 2, =, а затем проверяет ответ 4 как часть последнегоключевое слово (например, Should Be Equal As Numbers).Если произойдет сбой при неудачном нажатии какой-либо кнопки, я буду считать ее «Не удалось выполнить фактическую проверку» (мой сценарий обработки результатов здесь не будет регистрировать ошибку).Однако, если это не удается во время фактической проверки результата, то это допустимая ошибка, связанная с контрольным примером (мой сценарий обработки результатов может предпринять соответствующие действия, такие как регистрация ошибки).

Если нет методов для генерациифайл результатов в соответствии с моим требованием (статусы PASS, FAIL и, возможно, FAIL_TO_VERIFY), затем я ищу метод для обработки результата или ведения журнала xml для определения типа ошибки (FAIL vs FAIL_TO_VERIFY) для каждого тестового случая FAIL.

PS: Я уже разобрался в части регистрации ошибок в моем скрипте обработки результатов.Поэтому считайте, что это выходит за рамки вышеуказанного вопроса.

Answer 1

Единственное, что робот предоставляет в этом отношении, - это выдача уникальной ошибки для ключевых слов, которые не были выполнены во время настройки теста.Если ваши тесты разработаны таким образом, что вы всегда выполняете кучу настроек, а затем проверок, это будет делать то, что вы хотите.

Однако, по моему опыту, большинство тестов не такие.Часто у теста будет некоторая настройка, некоторые проверки, и затем больше шагов, а затем больше проверок.Лучшие практики говорят, что не следует писать подобные тесты, но иногда это неизбежно (или, по крайней мере, неудобно)

Один из возможных обходных путей - создать собственное ключевое слово с именем «verify», которое работает как «run keyword», нооборачивает ключевое слово в блок try / catch, а затем устанавливает тег или записывает в журнал или возвращает настраиваемое сообщение об ошибке.

ваш тест может выглядеть следующим образом:

*** Test cases ***
Example
    open browser  http://example.com  chrome
    click button  submit
    verify   page title should be  Hello, world
    verify   page should contain   Welcome, internet visitor!

The *Затем ключевое слово 1010 * запустит ключевое слово, и если произойдет ошибка, оно перехватит его, а затем выдаст новую ошибку, такую ​​как ""verification failed for "page title should be Hello, world": <actual error>

. Вы также можете установить в тесте такой тег, как" validation-failed ", когдаэто ключевое слово дает сбой. После этого вы получите в отчете хорошую статистику, показывающую, сколько тестов имеет этот тег (и, следовательно, сколько тестов провалилось из-за ошибок проверки).

Answer 2

Можете ли вы проверить это ключевое слово Зарегистрировать ключевое слово для запуска при отказе в selenium2library, это ключевое слово позволит выполнить любое другое ключевое слово, когда ваши ключевые слова slenium2library не пройдут.так что вы можете назвать свое ключевое слово сообщения об ошибках здесь