Сообщений в теме: 20

[One1L]

Какие проверки вы производите при автоматическом функциональном тестировании веб приложения? Я понимаю, что эти проверки сильно зависят от конкретного кейса. Возьмем например аутентификацию. Мой тест проверяет:

• код ответа сервера
• наличие панели пользователя
• правильность текущего урла

Мне кажется, что этих проверок не достаточно. 

[Little_CJIOH]

Не достаточно для чего?

 

Похоже кто-то пропустил этап тест-дизайна, иначе откуда такой вопрос?

[One1L]

Не достаточно для чего?

 

Похоже кто-то пропустил этап тест-дизайна, иначе откуда такой вопрос?

Такой вопрос возник из-за того, что как-то просто все получается.

[Freiman]

Такой вопрос возник из-за того, что как-то просто все получается.

Сколько тестов вы написали?
Как долго вы их поддерживаете?

[Spock]

да вроде почти хватает проверок чтобы проверить только аутентификацию плюс отображение имени пользователя на вебе

 

1. код ответа - либо 200, либо разные ошибки в разных случаях

2а. в успешном случае: панель пользователя "добро пожаловать, <Имя Фамилия>" и тут же проверка что правильные имя и фамилия

2б. в случае неудачи проверка что отображается ошибка входа, что панели пользователя нет

3. в успешном случае урл на дефолтовый ландинг пейдж, в случае неудачи опять на логин

 

 

Такой вопрос возник из-за того, что как-то просто все получается.

проверок мало и простые(это просто), а кейсов для функционального тестирования должно быть много (это сложно)

[One1L]

 

Такой вопрос возник из-за того, что как-то просто все получается.

Сколько тестов вы написали?
Как долго вы их поддерживаете?

 

Только начал покрывать проект тестами

[Spock]

примеры кейсов:

правильный логин, правильный пароль

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

правильный логин, пустой пароль

правильный логин, пароль от другого пользователя

несуществующий логин, существующий пароль

несуществующий логин, несуществующий пароль

несуществующий логин, пустой пароль

пустой логин, существующий пароль

пустой логин, несуществующий пароль

пустой логин, пустой пароль

разные кейсы на пробелы до и после имени пользователя, до и после пароля. тут же символы возврата, табуляции и т.п.

имя пользователя из одного пробела, то же с паролем. из многих пробелов

кейсы на все специальные символы в имени пользователя и пароле

кейсы на национальные символы в имени пользователя и пароле, плюс иероглифы и т.п.

максимальная длина имени пользователя, максимальная длина +1 имени пользователя

максимальная длина пароля, максимальная длина +1 пароля

минимальная длина имени пользователя, минимальная длина -1 имени пользователя

минимальная длина пароля, минимальная длина -1 пароля

 

ну и так далее

[Spock]

ещё большая разница тестируем ли страничку логина или нет, ведь на ней будут валидаторы

 

а пользователь или просто сервис может коннектится сразу на УРЛ аутентификации, без веб-формы, и соответственно может слать туда больше разных данных без валидации интерфейсом

 

а если тестируем веб-форму тоже - тогда её валидатор должен быть таким же как и валидатор бак-энда, ну или не таким же но чтобы они вместе хорошо работали

[Freiman]

Только начал покрывать проект тестами

Значит, еще все впереди! 

Скоро начнутся проблемы со стабильностью.

После N тестов начнется ад с их поддержкой и обновлением

[cpmBugHunter]

 

имя пользователя из одного пробела, то же с паролем. из многих пробелов

кейсы на все специальные символы в имени пользователя и пароле

кейсы на национальные символы в имени пользователя и пароле, плюс иероглифы и т.п.

максимальная длина имени пользователя, максимальная длина +1 имени пользователя

максимальная длина пароля, максимальная длина +1 пароля

минимальная длина имени пользователя, минимальная длина -1 имени пользователя

минимальная длина пароля, минимальная длина -1 пароля

Я прошу прощения за нубский вопрос... А вот эти кейсы - они тоже к логину относятся? Я-то грешным делом подобные им у себя в регистрацию закинул 

[Freiman]

Я прошу прощения за нубский вопрос... А вот эти кейсы - они тоже к логину относятся?

Правильный вопрос. Не относятся.
Да и вообще, я не уверен, что вот это вот всё необходимо автоматизировать.

[Spock]

 

 

Правильный вопрос. Не относятся.
Да и вообще, я не уверен, что вот это вот всё необходимо автоматизировать. 

ну ок, смотрим:

 

кейс на спец-символ "?" в имени пользователя, тестируем регистрацию пользователя через РЕСТ:

1. зарегистрировать пользователя с "?" в имени пользователя через РЕСТ

2. проверить как создался пользователь

 

кейс на спец-символ "?" в имени пользователя, тестируем регистрацию пользователя через веб-интерфейс:

1. зарегистрировать пользователя с "?" в имени пользователя через веб-интерфейс

2. проверить как создался пользователь

 

кейс на спец-символ "?" в имени пользователя, тестируем аутентификацию через РЕСТ-сервис:

1. в подготовке теста регистрируем пользователя с "?" в имени пользователя

2. аунтентифицируем пользователя созданного на подготовке, через РЕСТ

3. проверяем

 

кейс на спец-символ "?" в имени пользователя, тестируем аутентификацию через веб-интерфейс:

1. в подготовке теста регистрируем пользователя с "?" в имени пользователя

2. аунтентифицируем пользователя созданного на подготовке, через веб-интерфейс

3. проверяем

 

 

 

Да и вообще, я не уверен, что вот это вот всё необходимо автоматизировать. 

да вроде надо автоматизировать, слишком много кейсов руками делать, да ещё и через 2 интерфейса каждый.

[Spock]

 

 

Я прошу прощения за нубский вопрос... А вот эти кейсы - они тоже к логину относятся?

к логину не относятся, правильно - в логине надо проверять возможность зайти в систему

 

 

 

Возьмем например аутентификацию

вот - в первом посте было указано что тестируем аутентификацию, это именно на неё тесты. что любой правильный пользователь может аутентифицироваться в системе, а любой неправильный будет отклонён

[Spock]

примеры кейсов на "вопросик"

 

?user, password

us?er, password

user?, password

user, ?password

user, pass?word

user, password?

?, password

user, ?

?, ?

????, password

user, ??????

????, ??????

максимальная длина логина состоящая из "?", максимальная длина пароля состоящая из "?"

[Snap]

 

примеры кейсов:

правильный логин, пароль от другого пользователя

несуществующий логин, существующий пароль

несуществующий логин, несуществующий пароль

Интересно, подобные кейсы у вас находили ошибки хоть раз? )

[Spock]

 

 

Интересно, подобные кейсы у вас находили ошибки хоть раз? )

хаха, такие конечно не находили :) такие вот "теоретические тесты"

 

ещё один похожий:

"правильный логин в поле пароля, правильный пароль в поле логина"

 

 

 

несуществующий логин, существующий пароль

этот рассчитан на достаточно серьёзную ошибку в коде, когда пароль "матчится" одновременно или даже перед логином. например неправильный sql запрос типа "найти подходящий пароль и логин, вернуть TRUE при нахождении" - если не будет "найти ОБА и логин и пароль" - тот этот код найдёт пароль в базе и потом впустит пользователя без проверки правильности логина!

 

то есть в систему можно ввести любое имя пользователя и попробовать подобрать любой один пароль из базы - и получишь доступ 

[Spock]

 

 

правильный логин, пароль от другого пользователя

проверка может вернуть TRUE на логине, и тоже вернуть TRUE на пароле, ведь они оба есть в базе, то есть при баге можно зайти в систему. А если система ещё к тому же аутентифицирует по паролю - то загрузишься в чужой аккаунт

 

 

 

несуществующий логин, несуществующий пароль

ну этот вообще стандартный кейс на обработку ошибок. должен вернуть правильную ошибку

[Little_CJIOH]

 

 

примеры кейсов:

правильный логин, пароль от другого пользователя

несуществующий логин, существующий пароль

несуществующий логин, несуществующий пароль

Интересно, подобные кейсы у вас находили ошибки хоть раз? )

По сети ходит бородатый анекдот про "Пароль ХХХ уже используется пользователем YYY" и я верю что это реальный кейс.

а "?", ".", "%" и "*" могут обрабатываться как wildcard и там возможно много веселых кейсов типа

% : password логинится в любого пользователя имеющего палоль  password

% : % логинится в произвольного пользователя или в первого в базе, который, внезапно, с вероятностью 95% будет иметь админские привелегии.

[Freiman]

а "?", ".", "%" и "*" могут обрабатываться как wildcard и там возможно много веселых кейсов типа
% : password логинится в любого пользователя имеющего палоль  password
% : % логинится в произвольного пользователя или в первого в базе, который, внезапно, с вероятностью 95% будет иметь админские привелегии.

Все может быть :)
Но другой вопрос - надо ли это запихивать в автоматизированное функциональное тестирование?

[Spock]

 

 

Все может быть :)
Но другой вопрос - надо ли это запихивать в автоматизированное функциональное тестирование? 

ну если спец-символы в логинах и паролях не запихивать в автоматизированное функциональное тестирование - то куда запихивать?

 

или просто надеяться что все спец-символы будут работать и в логинах и паролях во всех интерфейсах? что разрешённые спец-символы будут работать а запрещённые будут отклонены с правильной ошибкой?