Как правильно писать UI тесты?
От: FreddieM  
Дата: 08.06.12 05:18
Оценка:
Уважаемые форумчане, обращаюсь за советом. Хочу попробовать использовать такие фреймворки как selenium для функционального тестирования. Есть вопросы по этому поводу.
1. Почему вы используете подобное тестирование, можно ли его избежать если при разработке использовать такие шаблоны как mvc и т.п. Например, закодить те же самые сценарии путем вызова методов контроллера? Или еще как...
2. Как быть с запуском подобного рода тестов, разработчик долго ждать не будет. 
3. Как правильно тестировать длительные бизнес-процессы, состоящие из большого количества шагов? Проходить всегда все? Писать скрипты с данными, чтобы можно было начать с нужного шага?
Re: Как правильно писать UI тесты?
От: boot  
Дата: 08.06.12 05:41
Оценка: -1
Здравствуйте, FreddieM, Вы писали:

FM>Уважаемые форумчане, обращаюсь за советом. Хочу попробовать использовать такие фреймворки как selenium для функционального тестирования. Есть вопросы по этому поводу.


Особенности разработки какие?
Хочу использовать насос, что подскажете?

FM>1. Почему вы используете подобное тестирование, можно ли его избежать если при разработке использовать такие шаблоны как mvc и т.п. Например, закодить те же самые сценарии путем вызова методов контроллера? Или еще как...


Selenium не используем, не подходит.

FM>2. Как быть с запуском подобного рода тестов, разработчик долго ждать не будет. 


То то и оно, и отдельного спеца держать нужно.

FM>3. Как правильно тестировать длительные бизнес-процессы, состоящие из большого количества шагов? Проходить всегда все? Писать скрипты с данными, чтобы можно было начать с нужного шага?


Исключения умеете использовать? Если использовать правильно, их достаточно.
Жизнеспособность прямо пропорциональна простоте!
Re: Как правильно писать UI тесты?
От: MasterZiv СССР  
Дата: 08.06.12 09:37
Оценка:
On 06/08/2012 09:18 AM, FreddieM wrote:

Под UI что имелось в виду ?
Posted via RSDN NNTP Server 2.1 beta
Re: Как правильно писать UI тесты?
От: xk Россия  
Дата: 12.06.12 15:21
Оценка:
Здравствуйте, FreddieM, Вы писали:

Используем selenium, точнее только функцию geteval, всё остально написали сами вокруг неё. Вообщем-то довольны.

FM>1. Почему вы используете подобное тестирование, можно ли его избежать если при разработке использовать такие шаблоны как mvc и т.п. Например, закодить те же самые сценарии путем вызова методов контроллера? Или еще как...


К сожалению у нас всё написано на ASP.NET Web Forms, поэтому у нас все тестируется функционально. Насколько я понимаю в MVC многие тесты можно написать юнитно на контроллер, но не все. К примеру нужно функционально тестировать, если у вас много JavaScript-кода на клиенте, т.е. богатый пользовательский интерфейс.

FM>2. Как быть с запуском подобного рода тестов, разработчик долго ждать не будет. 


У нас порядка 3,5к функциональных тестов, гоняют их кластер из 10 штук TeamCity-агентов в течении ~30 минут.
На самом деле кластера два, один гоняет стабильную ветку, второй текующую разработку.

FM>3. Как правильно тестировать длительные бизнес-процессы, состоящие из большого количества шагов? Проходить всегда все? Писать скрипты с данными, чтобы можно было начать с нужного шага?


В зависимости от ситуации. Какие-то тесты прогоняют процессы от и до, некоторые выставляют себе какие-то предусловия в БД и т.д.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re: Как правильно писать UI тесты?
От: Aikin Беларусь kavaleu.ru
Дата: 23.06.12 18:26
Оценка:
Здравствуйте, FreddieM, Вы писали:

FM>Хочу попробовать использовать такие фреймворки как selenium для функционального тестирования.

Это цель? Врядли. Скорее это способ ее достижения.
Или может: "чтобы было меньше багов". Тогда советую ознакомиться: Тестирование: Ручное или Автоматизированное?. Может вам достаточно выделеного тестера который все делает вручную.
Или же: "Выделенный тестер у нас есть, но он не успевает. Хочем автоматизировать его работу". Тогда да, selenium тут хорош.

Цели могут быть самые разные. Способы их досяжения тоже. И, возможно, в вашем конкретном случае вариант с селениумом будет далеко не лучшим.
Вот у меня команда из 3х человек. 2 программера и тестер. Он справляется кликая мышкой. Было бы хорошо если бы у нас были автотесты? Бесспортно. Так может напишем их? Нет, -- затрат много, профита мало

Все что было выше, это так "на подумать". Можно на это не отвечать


FM> Есть вопросы по этому поводу.

FM>1. Почему вы используете подобное тестирование, можно ли его избежать если при разработке использовать такие шаблоны как mvc и т.п. Например, закодить те же самые сценарии путем вызова методов контроллера? Или еще как...
Проверяются все компоненты системы. От работы с базой/внешними сервисами, до того что видит пользователь. А то что видит пользователь это, на самом деле, самое важное. Контроллер может правильно сформировать модель для отображения, а потом вью неправильно ее показать. Все. Функция не работает. Это баг.

FM>2. Как быть с запуском подобного рода тестов, разработчик долго ждать не будет. 

Не будет так не будет. Это так важно?
Или может важно чтобы была информация о том все ли тесты прошли к релизу (завтра, через час)? Тогда пусть эти тесты выполняет CI сервер

FM>3. Как правильно тестировать длительные бизнес-процессы, состоящие из большого количества шагов? Проходить всегда все? Писать скрипты с данными, чтобы можно было начать с нужного шага?

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

Поэтому если вы заинтересованы в эдаком "страже" корректности процесса и вас не смущает потратить несколько минут/часов/дней на локализацию проблемы, то однозначно тест сразу на весь процесс (хотя если тесты запускаются хотя бы раз в день, то можно посмотреть что же за этот день менялось в коде).
Если же это основной процесс системы и меняется каждый день (соответственно ломается через день ), то можно подумать о втором варианте.

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.