marshinov 29 апр 2013 в 22:04

Автоматизация тестирования Web-приложений

13 мин

107K

.NET*Тестирование IT-систем*Веб-разработка*

Туториал

+19

Комментарии 21

SamSol 29 апр 2013 в 22:50

Как бы проверить оба варианта (а лучше все три, тот что с DSL тоже) на десятке живых программистов?
И оценить такие параметры:
— Время затраченное на понимание упавшего теста
— время на исправление теста, например чтобы проверялось второе место
— количество заблуждений после знакомства с тестом

marshinov 29 апр 2013 в 23:01

У меня есть статистика только о себе. DSL обычно отлаживается за несколько минут. Чаще всего причина ложных срабатываний: локаторы.
Если все свалено в одну кучу, то без ~~бутылки~~ отладчика не разберешься. На это может уйти от 10 минут до часа. Понимание логики такого теста сравнимо с постижением дзэн.

AGrebinchukov 30 апр 2013 в 05:56

Я испол'зую немного проще связку: SpecFlow + Watin + ООП. Общие методы доступа к Элементам страницы инкапсулированы в сервис-классы. На выходе получаю MSTest. Достаточно легко отлаживать. Запускается все с помощью TeamCity. Тесты називаю Acceptance Tests. Unit Testing для бизнес логики и JavaScript никто не отменял. Есть вопрос, зачем используете TeamCity когда есть TFS?

Пример теста:

Scenario: Uncomplete an existing Expense Claim
        Given I have opened "Expense Claim List" screen
        And I have sorted "Expense Claim List" grid by "Completed" column
	And I have clicked "first" row on "Expense Claim List"
	And I have "un-checked" the "Complete" tickbox on header
	When I click "Save" button
	Then the "Expense Claim successfully saved." success message should appear
	And the "Expense Claim Detail" grid "should" be editable

Renius 30 апр 2013 в 06:50

# language: ru
@javascript
Функционал: Управление записями на осмотр
  Предыстория:
    Допустим я создал компанию
    Допустим есть пользователь
    Допустим пользователь принадлежит этой компании
    Допустим я создал schedule на завтра для этой компании

  Сценарий: Отображение списка записей на осмотр
    Пусть я залогинился
    Если я зайду на '/schedules'
    То я должен увидеть 'Антон'
        И я должен увидеть '###'
        И я должен увидеть '+7 ### ###-##-##'
    Если я нажму на '#edit_schedule'
    То я должен увидеть 'Текущая'

marshinov 30 апр 2013 в 09:36

Недавно обсуждали похожу ситуацию. Договорились в таких случаях делать проверку одним шагом

То я должен увидеть имя: Антон, телефон: ****, не знаю, что у вас во втором пункте: ***
В этом случае, если тест упадет, вы получите больше информации. Например, вы видите не «Антон», а «Вася». Это значит, что кто-то сменил имя пользователя или это ошибка приложения, которая выдала не того юзера?
Это не противоречит принципу «проверять одну вещь за один раз». Просто «одна вещь» = профиль пользователя.

marshinov 30 апр 2013 в 09:28

TeamCity сейчас используем в тестовом режиме: сравниваем. Есть несколько преимуществ:

«из коробки» тест-ранер показывает информацию горзадо удобнее, чем ТФС
тим-сити работает быстрее
тим-сити крутится на отдельной машине и не путается с CI-билдами и выкладками, можно было бы ограничиться дополнительным билд-агентом, если бы не пункт 1

Сейчас разбираемся с новыми фишками 2012 ТФС-а. Включим тесты в отчеты, посмотрим, что получится.

oddmanout 21 мая 2013 в 11:13

Интересно было бы почитать о миграции с TFS на TC. Переезд базы кода. И результаты сравнения в целом.

marshinov 21 мая 2013 в 12:19

Мы не мигрировали. TFS используется для nightly builds, CI builds, прогона unit-test'ов, выкладок на окружения. TeamCity стоит на отдельной машине и используется только для прогона системных тестов. Получилось быстрее и удобнее, чем выносить билд-агент TFS на отдельную машину. Тесты не путаются с остальными билдами, привязали SpecFlow-отчеты. Получилось довольно удобно. Сравнивать TFS и TeamCity не корректно. Тут надо говорить о связке, скажем, GIT + Jira +TeamCity VS TFS. Вообще есть плюсы и минусы и там и там. У TFS самое слабое место — это чудовищный VCS. Ждем релиза с GIT (пока доступен только в облаке).

Renius 30 апр 2013 в 06:43

Чтобы проверялось второе место, нужно писать два теста

LeshaL 30 апр 2013 в 08:56

Не совсем.
Можете передать ожидаемую позицию результата и немного подправить метод CheckResults.

Автору респект, разложено по полочкам. Мог бы — плюсанул.

SamSol 30 апр 2013 в 09:17

например чтобы проверялось второе место

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

mxm 30 апр 2013 в 13:52

Автору респект, разложено по полочкам. Мог бы — плюсанул.

lavice 30 апр 2013 в 14:39

Отличная статья, вы молодец. Не ожидал на Хабре настолько подробной статьи по автоматизации тестирования, не самая популярная тут тема.
Я занимался разработкой подобного фреймворка на похожем стеке (без SpecFlow и c MbUnit вместо NUnit). От SpecFlow отказались по причине проблем с распараллеливанием тестов, т.к. он только с костылями это умеет делать. Вам не критична параллелизация тестов, или вы нашли хорошее решение?

marshinov 30 апр 2013 в 15:44

С параллелизмом есть еще веб-драйвер, который может «зависнуть». Как вариант делать через remote, но там тоже есть свои прелести.
Мы решили разбивать тесты на сборки «по-интересам»: есть одна сборка для смоуков, дальше по компонентам системы. Каждую сборку можно запустить параллельно. На предыдущем проекте не заморачивались с параллелизмом, на этом, возможно будем. Я подумаю об этом, когда тесты будут выполняться 6-8 часов.

Dennisb 30 апр 2013 в 17:47

Спасибо за статью.
Вы можете выложить код рассмотренного примера?

marshinov 30 апр 2013 в 22:39

Пока нет. Вы можете достаточно просто воссоздать этот пример с помощью copy+paste, alt+enter и nuget. Возможно, в будущем фреймворк уйдет в open source.

oddmanout 21 мая 2013 в 11:17

Нет ли планов использовать PhantomJS WebDriver? Есть надежда, что он должен быть быстрее и надёжнее не headless драйверов, но пока не было возможности проверить.

marshinov 21 мая 2013 в 12:21

У нас есть поддержка Phantom. Кое-где работает лучше, но есть свои глюки. Пока лучшие показатели дал Firefox. Самое удивительное, что он может работать в non-interactive environment, т.е. при прогоне тестов окна браузера на билд-машине не видно.

De-Korg 24 ноя 2021 в 15:46

спустя столько лет вернулся пересмотреть статью

"Гайдлайн автоматизатора" - все валидно, все совпадает с моим опытом с полей, как раз в свое время искал что-то такое )

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

marshinov 24 ноя 2021 в 16:30

У нас, кстати, SpecFlow тоже не пошел. Таблички контрольных примеров хорошо идут, но в гугло-доках. Как вариант их вместо SpecFlow подтягивать, но там очень много проблем с инфобезом и много еще чем.

marshinov 24 ноя 2021 в 16:27

del

Зарегистрируйтесь на Хабре, чтобы оставить комментарий