Как писать скрипты..завязываться на UI или бизнес логику

Все, что касается автоматизированного тестирования...

Модератор: YuriY

Как писать скрипты..завязываться на UI или бизнес логику

Сообщение lesha » 18 мар 2008, 13:53

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

Приложение позволяет создать/удалить учетную запись пользователя. Есть список всех пользоватлей, кнопочка Добавить пользователя, кнопка Удалить пользователя. Фреймвор может выглядеть так:
Вариант(1):
- ДобавитьПользователя(имя, фамилия, мейл)
- УдалитьПользователя(мейл)
- ПроверкаЕстьЛиПользовательВСписке(мейл)

Вариант(2):
- НайтиПользоватлеяВСпискеПоМейлу(мейл) #вернет позицию пользоватлея в списке
- УдалитьПользователя(номерПозиции) # поставит галочку возле пользователя и кликнет удалить
- ВвестиДанныеВПоле(поле, строка) # с помощь этой функции будем заполнять форму создания пользователя

Может у кого-то есть опыт..и он готов им поделится?)) Или еще есть вариант по-лучше?
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19

Сообщение wishaway » 18 мар 2008, 15:56

Я не силен в автоматизированном тестировании, но попробую написать свою точку зрения.

Первый вариант, как мне кажется, должен проводиться на стадии юнит-тестирования. То есть искуственное дергание функций с целью их проверки при различных данных. Соответственно, по всем правилам: делать тесты, проверять покрытие, собирать тесты в тест-сьюты и т.п.

Второй вариант более подходит для проверки не функционала, а интерфейса. То есть, если есть Java-script, AJAX, либо проверка в разных браузерах, что может внести свою лепту в корректность работы, то такими тестами можно посмотреть, где происходят сбои, и потом уже вручную понять их причину.

Все ИМХО :)
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Сообщение lesha » 18 мар 2008, 17:03

Спасибо.. Забыл действительно написать цель.. Основная цель - все-таки функциональное тестирование. И с позиции этой цели рассматривается будущая сруктура скриптов.

Я вот что думал... Первый вариант, если честно, мне нравится больше :). Вот почему: тестовые скрипты тогда будут достаточно читабильны. Т.е. почти случай тестирования ключевыми словами: Залогиниться() -> Открыть Спсиок Пользователей()-> СоздатьПользователя() -> ПроверитьЕстьЛиПользователь(). Во втором случае скрипты будут сложнее, и более похожи на записанные с помощью рекордера. Но, возможно, более гибкими и устойчивыми к изменениям.


Интересен также вопрос о поддержки кода певого и второго вариантов.. Идеи?
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19

Сообщение arvex » 19 мар 2008, 12:01

lesha писал(а):Я вот что думал... Первый вариант, если честно, мне нравится больше :). Вот почему: тестовые скрипты тогда будут достаточно читабильны. Т.е. почти случай тестирования ключевыми словами: Залогиниться() -> Открыть Спсиок Пользователей()-> СоздатьПользователя() -> ПроверитьЕстьЛиПользователь(). Во втором случае скрипты будут сложнее, и более похожи на записанные с помощью рекордера. Но, возможно, более гибкими и устойчивыми к изменениям.


Интересен также вопрос о поддержки кода певого и второго вариантов.. Идеи?

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

Но я считаю по своему, хоть и небольшому пока опыту автоматизации тестирования, что сила заключается в комбинации этих двух методов, так называемая "золотая середина".

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

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

Под модульностью понимается вызов одних функций из других; или использование результата выполнения одних функций как входных данных для других.

Что я имею ввиду под многоуровневой структурой скриптов? А я имею ввиду следующее.

На самом высоком уровне (уровень Test Case) мы выполняем действия с приложением вызывая асооциативно понятные функции:

- ДобавитьПользователя(имя, фамилия, мейл)
- ПроверкаЕстьЛиПользовательВСписке(мейл)
- УдалитьПользователя(мейл)

Можно представить, что под этими функциями на уровне интерфейса понимаются вполне конкретные действия (такие действия, которые тестировщик выполняет, если ему скажут, например, надо проверить "Добавление Пользователя").
Например, "ВызватьФормуСоздания()", "ЗаполнитьФормуСоздания()", "ЗасабмититьФорму()"

Т.е. получается, что функция ДобавитьПользователя(имя, фамилия, мейл) будет соответственно вызывать функции на один уровень ниже, а именно:
- "ВызватьФормуСоздания()"
- "ЗаполнитьФормуСоздания(имя, фамилия, мейл)"
- "ЗасабмититьФорму()"

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

В данном случае функция "ВызватьФормуСоздания()" может выполнять уже элементарые действия такие как НажатьНаКнопку(), ПерейтиПоСсылке() и т.д.

Т.е. получается такая структура:

Код: выделить все
ДобавитьПользователя(имя, фамилия, мейл){
   ВызватьФормуСоздания();
   ЗаполнитьФормуСоздания(имя, фамилия, мейл);
   ЗасабмититьФорму();
}
   
   ВызватьФормуСоздания(){
      ПерейтиПоСсылке("members");
      НажатьНаКнопку("add_member");
   }
   ЗаполнитьФормуСоздания(имя, фамилия, мейл){
   ....
   }
   ЗасабмититьФорму(){
   ....
   }



ПроверкаЕстьЛиПользовательВСписке(мейл){
....
}

УдалитьПользователя(мейл){
....
}


Что мы получаем в результате такого построения скриптов?
С одной стороны, на самом высоком уровне, да и на нижних скрипты достаточно читабильны и понятны, а с другой - при такой структуре скрипты являются гибкими и устойчивыми.

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

Как видно, например, если изменится расположение формы создания мемберов, то вносятся изменения только в функцию ВызватьФормуСоздания(), после этого все остальные функции остаются работоспособны.

Единственным минусом такого подхода, является то, что для ускорения написания скриптов нам мало в чем поможет автоматический Record script (все надо руками писать).

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

Прошу комментарии...
arvex
Admin
 
Сообщений: 44
Зарегистрирован: 29 янв 2008, 23:34
Откуда: Kharkov

Сообщение lesha » 23 мар 2008, 14:41

Arvex, спасибо за такой развернутый ответ. Идея нравится. От завязки на GUI не куда не деться, но ее можно хорошо спрять :) Вот только не совсем понятно до какого уровня писать такие скрипты. Не погрязнем ли мы в написании этих скриптов...потратив кучу времени. Возможно, если время жизни скриптов будет большое, то такой вариант наиболее предпочтительный.
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19

Сообщение wishaway » 24 мар 2008, 12:37

lesha писал(а):Вот только не совсем понятно до какого уровня писать такие скрипты. Не погрязнем ли мы в написании этих скриптов...потратив кучу времени.


Это как раз и есть основной вопрос при выборе автоматизированного тестирования. Именно из-за нехватки временных ресурсов многие и предпочитают ручное тестирование.

Насколько я понимаю, Панкратов тоже сторонник ручного тестирования...

Автоматизированное тестирование может иметь место только при длительных проектах и только при хорошо организованной модели разработки ПО. ИМХО, ниже CMMI level 3 этого делать не стоит (ну или хорошо поставленного процесса по RUP или Agile).

На нашей фирме нет автоматизированного тестирования.

Но решает каждый сам. Поэтому стоит автоматизировать или нет - в этом вопросе никто не поможет, пока не вникнет во внутреннюю работу вашей фирмы.
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Сообщение arvex » 24 мар 2008, 13:26

wishaway писал(а):Автоматизированное тестирование может иметь место только при длительных проектах и только при хорошо организованной модели разработки ПО.


...с этим нельзя не согласиться.

"...при хорошо организованной модели разработки ПО" + определенных подходах и методике применения автоматизированного тестирования под эту модель.

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

Но я думаю можно выработать какие-то общие правила, рекоммендации, подходы и т.д. для внедрения и целесообразности применения автоматизированного тестирования в типовых проектах при типовой культуре разработки ПО.

Тема остается открытой...
Пишите свои идеи...
arvex
Admin
 
Сообщений: 44
Зарегистрирован: 29 янв 2008, 23:34
Откуда: Kharkov

Сообщение Rom@ka » 26 мар 2008, 18:40

Вот решил поделиться мыслями и идеями, по поводу фреймворка.

Почему бы при написании фреймворка не предоставлять функции как основанные на бизнес логике, так и более низко уровневые. Я так понимаю, фреймверк пишется для того, чтобы на его основании потом составлять автоматические тесты. Функции написанные по бизнес логике дают практически готовые решения, а более низкоуровневые - гибкость при возникновении ситуаций, когда бизнес функции не позволяют реализовать и проверить какое-то действие.
Но стоит учитывать, что автоматический тест - это программа, а как известно, в любой программе есть баги.
Из личного опыта, могу сказать, что 2-3 уровней вложенности более чем достаточно для написания фреймверков, иначе затраты на его поддержание в актуальном состоянии того не стоят, быстрее проверить ручным тестированием, если проект активный и имеется тенденция изменения UI.
Лучшими кандидатами на автоматизацию являются регрешин тесты и функциональные тесты с большой матрицей входных параметров и особо не завязанных на UI.
Исходя из того, что мы в итоге хотим получить, то можно определить и сложность фреймверка. Если цель – это поверхностный регрешин или санити тесты, то не стоит усложнять фреймверк, практически любое средство автоматизации поддерживает descriptive programming, позволяющее в какой-то мере отвязаться от небольших изменений в UI, но оно не позволяет учитывать гениальные мысли девелоперов и проджект менеджеров.
Rom@ka
Newcomer
 
Сообщений: 2
Зарегистрирован: 26 мар 2008, 15:47
Откуда: Донецк

Сообщение lesha » 06 апр 2008, 16:39

YuRock подкинул интересную ссылку по этой теме. Радует что информация в этой статье не далека то практики :)

http://www.sqa-test.com/method.html
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19

Сообщение lesha » 06 апр 2008, 16:46

Rom@ka писал(а):Вот решил поделиться мыслями и идеями, по поводу фреймворка.

Почему бы при написании фреймворка не предоставлять функции как основанные на бизнес логике, так и более низко уровневые. Я так понимаю, фреймверк пишется для того, чтобы на его основании потом составлять автоматические тесты. Функции написанные по бизнес логике дают практически готовые решения, а более низкоуровневые - гибкость при возникновении ситуаций, когда бизнес функции не позволяют реализовать и проверить какое-то действие.


В общем-то исходя из моего оптыа так всегда и получается, что готовая реализация скрипта дейсвительно состоит из функций более высого и низкого уровней. Наверное в силу особенностей тест-кейсов и в силу некоторого компромиса между качеством кода и верменем написания это и происходит. Для регерссионных тестов это было приемлемо.
Багов действительно хватает :) Превые два полных рабочих прогона выявляли дотсаточно много багов и неточностей. Могу сказать, что примерно из 100 кейсов 10-20 зайфейлились именно из-за ошибок в коде скриптов.
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19


Вернуться в Автоматизированное тестирование | Automated Testing

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron