Обзор – ‘Login’ объект или нет?
by Dima

С одной стороны, “Login” конечно же объект Recruiting, но с другой стороны без него никак не обойтись другим объектам приложения. Как быть?

Точнее будет сказать, что “Account” это объект, а “Login” это функциональная его часть. Посольку мы не создавали в приложении объект “Account”, то конечно же мы можем его и не тестировать. Мы можем этого не делать ещё и потому,что всё равно не сможем написать полный набор тестов для него.

Если мы будем рассматривать “Account” как отдельный объект, можно сравнить действия, которые с ним можно произвести, с действиями над другими объектами.

Если провести параллели, то регистрация учётной записи это добавление, тогда как логин это по сути поиск. Ну а редактирование или удаление такой записи обычно находится где-нибудь в настройках учётной записи, прячущихся где-нибудь за Settings или Profile в UI.

Так что полный набор тестов для объекта “Account” в общем случае должен включать – регистрацию, логин, логаут, редактирование профиля, включая восстановление пароля, а также удаление регистрационной записи.

Несмотря на все это я за то чтобы завести себе объект “Аccount” и тестировать его в том объёме в каком мы можем это сделать, а именно логин и логаут.

Только надо будет ещё решить, как тогда выполнять логин для тестирования основных объектов (Websites,Candidates, Positions). Наверное, всё-таки будет удобнее, если тестированием логина/аккаунта будет заниматься специальный класс тестов, а остальные классы для выполнения логина будут пользоваться простым специальным методом – как и раньше.

На заметку параллелизатору тестов – если открыты два браузера, то логин в одном позволяет не выполнять логин во втором, и если в первом сделан логаут, то второй оказывается тоже разлогиненным.
Разные браузеры и, наверное, браузеры на разных машинах могут работать независимо.

А вообще, что можно протестировать при логине?

1) неправильный логин или пароль

Проверяем как возможность зайти с правильными, так и невозможность зайти с неправильными данными.
Думаем, этот момент стоит отметить. Если попробовать залогиниться, не заполнив хотя бы одно из полей (User Name или Password), то обычного сообщения об ошибке (Your login attempt has failed и т.д.) не появляется. Пользователь просто остается на странице Login.

2) попытка зайти не введя ни имя пользователя ни пароль

Экстремальный вариант пункта 1. Если бы нужно было давать тестам яркие запоминающиеся имена – я бы назвал его “тестом Котовского”.

3) сделать логаут сразу после логина

Этот тест навеян презентацией “YouTube – GTAC 2008 Automated Model-Based Testing of Web Applications” в которой между 9 и 11 минутами демонстрируют баг на сайте United Airlines

4) истёкшая сессия

Цепочка – зашли, ввели, ждём пока не должен наступить тайм-аут, пытаемся сохраниться, сравниваем желаемое и действительное. Ускорить тестирование можно выставив значение тайм-аута в минимально допустимое значение.

5) попытка зайти с не зарегистрированного IP адреса

Достаточно редкий подход, используемый SalesForce, который к тому же достаточно тяжело протестировать. Однажды я ждал такое электронное письмо, которое должен был подтвердить, около двух часов.

Сделаем 1-3, 4 – долго ждать, 5 – очень специфично.

Про login “… немало песен сложено, Я спою тебе, спою ещё одну.”
Что так сердце растревожено – Верные друзья (1954)


1) неправильный логин или пароль

Print this post | Home

One comment

  1. Alexei Lupan says:

    Что можно протестировать при логине? Например: “Тестируем поля логин/пароль“.