А как Вы обрабатываете Exceptions и Errors?
#1
Отправлено 13 августа 2015 - 11:21
#2
Отправлено 13 августа 2015 - 12:00
Спросить у него что он понимает под словом читабельный.
У вас в отчетах будут нормально прописаны ошибки - таково-то элемента нет, неудачный клик и т.п..
Если он хочет читать сообщения по-русски, то скажите, что разработка теста по времени увеличится на 40 процентов, т.к. вам придётся каждое действие обрабатывать и самому формировать сообщения об ошибке (трай-катч).
#3
Отправлено 13 августа 2015 - 12:10
Читабельный значит, что можно посмотреть на ошибку и понять что произошло. Наверное должно быть что-то типа "Save button is absent on merchandise creation Page"
Стек трейс для менеджера не понятен.
#4
Отправлено 13 августа 2015 - 12:38
Может ему кукумбер в одно место вставить нужен?...
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#5
Отправлено 13 августа 2015 - 12:38
В проверках, в основном, можно формировать шаблон сообщения об ошибке, тогда вы сможете делать такие сообщения.
#6
Отправлено 13 августа 2015 - 13:18
Может ему кукумбер
в одно место вставитьнужен?...
Ну зачем так?!)))))))
А если серьйозно, как в своих селениум проектах Вы обрабатываете Exceptions и Errors?
#7
Отправлено 13 августа 2015 - 14:02
Как Вы в своих проектах обрабатываете Exceptions и Errors?
Error - это очень серьёзная проблема, например, проблема с JVM(VirtualMachineError --- InternalError, OutOfMemoryError и т.п.), поэтому его никак не обработаешь.
А так смотрю в stacktrace
#8
Отправлено 13 августа 2015 - 16:31
А с какой целью ему их вообще читать?
Я пока никак не обрабатываю - тест упал, видно какой, видно какая ошибка, скрин есть
оффтоп: кстати, для чего нужен этот тест-менеджер? (учитывая что стек трейс для него что-то непонятное)
#9
Отправлено 13 августа 2015 - 17:46
А с какой целью ему их вообще читать?
Я пока никак не обрабатываю - тест упал, видно какой, видно какая ошибка, скрин есть
оффтоп: кстати, для чего нужен этот тест-менеджер? (учитывая что стек трейс для него что-то непонятное)
1) А с какой целью ему их вообще читать?
Я не в праве задавать такие вопросы. А если серьезно, он тоже хочет контролировать процесс автоматизации и видеть "понятные" результаты.
2)оффтоп: кстати, для чего нужен этот тест-менеджер? (учитывая что стек трейс для него что-то непонятное)
Тест-менеджер отлично знает проект, принимает участие в ручном тестировании сам и подсказывает другим, ответственный за весь процесс тестирования в целом. Но вот с языками программирования у менеджера не особо, вот и просить понятные результаты
#10
Отправлено 13 августа 2015 - 20:12
ПриветКак Вы в своих проектах обрабатываете Exceptions и Errors? Есть ли какая-то общепринятая техника (типа PageObject для разработки тестов) ?Я лично могу обойтись и stacktrace, я не гордый.Но мой тест-менеджер теперь хочет читать репорты по автотестам сам (он не пишет автотесты). И просит сделать их более читабельными. Я ума не приложу как это сделать?.Автотесты запускаются с использованием selenide, а репорты будут генерится, наверное, при помощи Allure.
Привет!
Вам не нужно никак обрабатывать ошибки в тестах. Любой нормальный запускальщик тестов (будь то JUnit, TestNG или любой другой) сам ловит все ошибки и показывает их в отчёте.
В случае с Selenide тем более не надо, т.к. Selenide сообщает обо всех падениях максимально подробно, типа, "такой-то элемент должен быть видимым, а он невидимый". Или "У такого-то элемента должен быть текст Маша, а у него текст Петя".
Какого-то специального фреймворка для репортов вам тоже не нужно. Все классические билд-системы и CI (Jenkins, Maven, Ant, Gradle и пр.) умеют генерировать отчёты о прохождении тестов. Allure нужен только в том случае, если вы хорошо понимаете, что вам нужно, и стандартного отчёта вам не хватает (лично я вообще не верю, что такое бывает). Грубо говоря, если хотите добавить в отчёты красивые картинки.
#11
Отправлено 17 августа 2015 - 15:51
Читабельный значит, что можно посмотреть на ошибку и понять что произошло. Наверное должно быть что-то типа "Save button is absent on merchandise creation Page"
Стек трейс для менеджера не понятен.
Подобные отчёты лишь создают иллюзию понятности.
Предположим, что в отчёте появилась вышеуказанная строчка. Можно ли из неё понять, что в действительности произошло?
В результате предыдущего действия открылась неправильная страница? Открылась правильная страница, но на ней не появилась нужная кнопка? Страница правильная, кнопка есть, но у неё поменялся локатор? А может быть, наоборот, это в тестах кто-то нечаянно "сломал" локаторы? А может быть сервер по какой-то причине ушёл на перезагрузку, и внезапно открылась страница с сообщением типа "подождите, пока сервер перезагрузится"?
А если он не способен понять причину (именно причину!) возникшего сбоя в работе тестов -- что же тогда подразумевается под "понятностью"?
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#12
Отправлено 18 августа 2015 - 05:51
Я видимо чего-то не понимаю. Репорты на "человеческом" языке со скринтошами, которые может "читать" любой участник команды -- это иллюзия?Подобные отчёты лишь создают иллюзию понятности.
Или речь про то, что если тест "поломается", он все-равно его не починит? Так вроде такого условия от ТС не было.
#13
Отправлено 18 августа 2015 - 07:59
Отчёты на "человеческом" языке (со скриншотами или без них) создают иллюзию "понятности". Такие отчёты могут дать ответ на вопрос "что сломалось", но я не считаю это "понятностью". Потому что на самом деле всех интересует ответ на вопрос "почему сломалось".
Это не означает, что не надо добавлять в отчёты трассировку шагов сценария и скриншоты. Почему бы и нет. Красивый отчёт и техническому специалисту приятен. И он вполне может повышать понятность, особенно если говорить про скриншоты.
Но для нетехнических специалистов обычно достаточно ограничиться информацией о том, какие тесты упали. Вот на этом уровне отчёт должен быть "понятным". Понятные названия тестов, понятная структура тестового набора, понятная привязка к спецификации и/или к частям тестируемой программы. Эту информацию менеджер сможет использовать для оценки текущего состояния -- сколько тестов упало, в каких модулях, кого нужно привлечь к решению проблемы, сколько времени это может занять.
Информация о том, в какой конкретно строчке упал тест -- избыточная. Ничего разумного тест-менеджер, не являющийся техническим специалистом, с этой информацией скорее всего сделать не сможет.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#14
Отправлено 18 августа 2015 - 14:08
Это не означает, что не надо добавлять в отчёты трассировку шагов сценария и скриншоты. Почему бы и нет. Красивый отчёт и техническому специалисту приятен. И он вполне может повышать понятность, особенно если говорить про скриншоты.
Так почему вы не допускаете, что тест-менеджер топик-стартера, который не брезгует ручным тестированием, хочет просто видеть шаги и скриншоты в репорте, что бы была хоть какая-то возможность интерпретировать результаты? А не просто смотреть на "красный" тестСПонятнымНазваниемКоторыйПокрываетТребование#x, в котором кроме NoSuchFrameException: //iframe[1] больше никакой информации нету.
#15
Отправлено 18 августа 2015 - 14:44
Так почему вы не допускаете, что тест-менеджер топик-стартера, который не брезгует ручным тестированием, хочет просто видеть шаги и скриншоты в репорте, что бы была хоть какая-то возможность интерпретировать результаты? А не просто смотреть на "красный" тестСПонятнымНазваниемКоторыйПокрываетТребование#x, в котором кроме NoSuchFrameException: //iframe[1] больше никакой информации нету.
Вот поэтому я и предлагаю обсудить, что значит "понятность"? Ну узнает он, на каком именно шаге упал тест. И что? Как именно менеджер собирается использовать полученную информацию?
С моей точки зрения, "хочет просто видеть" это ещё недостаточное обоснование для того, чтобы тратить дополнительные усилия на изготовление красивого отчёта.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#16
Отправлено 19 августа 2015 - 06:07
Вот поэтому я и предлагаю обсудить, что значит "понятность"? Ну узнает он, на каком именно шаге упал тест. И что? Как именно менеджер собирается использовать полученную информацию?
Давайте на примерах, так как я все еще не понимаю к чему вы клоните.
Test Result Report
1. Navigate to http://someurl 2. Type 'lenin' into 'User Name' text field 3. Type '123' into 'Password' text field 4. Click 'Login' button 5. Verify title is 'Velcom' -> Error: expected 'Velcom', actual '' _screenshot_
#17
Отправлено 19 августа 2015 - 07:50
Как по мне так это лишняя информация. Подробное логирование может быть полезно для того, чтобы дебажить код, но в репорте зачем видеть это? Важно видеть прошёл тест или нет, а почему не прошёл, так это как правило видно из ошибки, которая выбрасывается TestNG.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных