Технологии функционального тестирования web-приложений

Здравствуйте.
Для обзора требуется рассмотреть существующие подходы (технологии) автоматизированного тестирования web-приложений (построение теста + воспроизведение). Прошу дополнить список, представленный ниже:

1. Capture & Playback (другие названия – Record & Playback, Capture & Replay)
http://citforum.ru/S...g/func_testing/
2. KeywordDriven
http://www.sqa-test.com/w_paper1.html
3. UniTesK
http://citforum.ru/S...g/func_testing/

Привет! Если честно, не очень понял какая стоит перед вами задача.

Могу рассказать как проводилось тестирование веб-приложения на одной из моих предыдущих работ (>3-х лет назад дело было).
1. Перво-наперво использовалось ручное тестирование. Для него был составлен большой набор тест-кейзов, больше похожих на юзер-сценарии.
2. Подход Record & Play.
Тул писал сам. Таргет браузер продукта был IE. Все было жестко заточено на IE. Похоже тул работал так как описано здесь http://www.openqa.org/selenium/ - т.е. iframe+javascript. Весь engine приходилось складывать на сервак, чтобы обойти security policy. Сохранялось все в виде *.js файлов. Автоматизировались ручные сценарии из пункта 1. Особенно те области, который были более-менее стабильны.
3. HttpUnit - http://httpunit.sourceforge.net/ по мере разработки ПО, часть работы была автоматизирована с помощью HttpUnit тестов. Выполнялись при билде. Писались отчасти девелоперами, отчасти QA.
3а. JUnit - т.к. ПО шевелилось на сервлетах, то разработчики писали JUnit тесты на серверную часть. QA команда к этому отношения не имела.
4. Потом под конец еще стали использовать что-то типа JsUnit. Опять же реализацию framework'а писал сам. Похоже есть готовое решение http://sourceforge.n...rojects/jsunit/ - но я им не пользовался, т.к. давно не занимаюсь тестированием веб-апликух.
Типа все.
Сейчас, по прошествии времени, я бы еще добавил бы к этому кое-что. Например, проверку получающихся HTML-ных страничек с помощью таких инструментов как tidy(http://www.w3.org/People/Raggett/tidy/) и linklint(http://www.linklint.org/) и еще CSS проверял бы.
И самое главное - я бы сразу попытался создать некий формализованный мета-язык описания тест-кейзов (или найти говое решение), который позволил бы проводить как ручное, так и автоматическое тестирование базируясь на одних и тех же исходных данных

Здравствуйте.
Для обзора требуется рассмотреть существующие подходы (технологии) автоматизированного тестирования web-приложений (построение теста + воспроизведение). Прошу дополнить список, представленный ниже:

1. Capture & Playback (другие названия – Record & Playback, Capture & Replay)
http://citforum.ru/S...g/func_testing/
2. KeywordDriven
http://www.sqa-test.com/w_paper1.html
3. UniTesK
http://citforum.ru/S...g/func_testing/

Судя по тому, что вы привели в ссылках, это типы фреймворков. И они не особо привязываются к конкретной технологии.
Если вам нужен более расширенный список, то я его могу дополнить. Известные мне подходы:
1) Record & Play - основан на возможности средств автоматизации тестирования автоматически генерировать код
2) Functional Decomposition - в основе лежит разбиение всех компонент фреймворка по функциональному признаку на бизнес-функции (реализуют/проверяют бизнес-функциональность приложения), user-defined функции (вспомагательные функции, которые еще имеют привязку к тестируемому приложению или к конкретному проекту), утилиты (функции общего назначения, не привязанные к конкретному приложению, технологии, проекту).
3) Data-driven - основан на том, что к некоторому тесту или группе тестов привязывается источник данных и этот тест или набор тестов циклически выполняется для каждой записи из этого источника данных. Вполне может применяться в комбинации с другими подходами
4) Keyword-driven - представляет собой фактически движок для обработки посылаемых ему команд, а сами инструкции выносятся во внешний источник данных
5) Object-driven - основан на том, что основные ходовые части фреймворка реализованы в виде объектов (там может быть много вариаций), что позволяет собирать тесты по кирпичикам
6) Model-based - основан на том, что тестируемое приложение (или его части) описывается в виде некоторой поведенческой модели.

Это все решения, которые просто представляют собой реализацию определенного движка для автоматических тестов и к конкретной технологии они не привязаны. У каждого подхода есть плюсы и минусы. Вообще, на последнем слете тестировщиков в Москве доклад по данной теме делал Михаил Давыдов (здесь на форуме он скрывается под ником Mike). Если вас эта тема все еще интересует, то можете обратиться к нему, может он и проконсультирует.

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

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

мало того, что всю контору спалил, так еще и стрелы перевел

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

мало того, что всю контору спалил, так еще и стрелы перевел

Ну а зачем боянить, если об этом человек не так давно в популярной форме все изложил?

Привет! Если честно, не очень понял какая стоит перед вами задача.

Привет! Проектирую инструмент автоматизации тестирования web. Существующие технологии (подходы) нужны для того, чтобы не написать написанное и написать актуальное. За ценный опыт особая благодарность

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

Здравствуйте. Вы правильно меня поняли, под ТЕХНОЛОГИЕЙ автоматизации я понимал ПОДХОД к автоматизации. Благодарю за ценные дополнения

Привет! Если честно, не очень понял какая стоит перед вами задача.

Привет! Проектирую инструмент автоматизации тестирования web. Существующие технологии (подходы) нужны для того, чтобы не написать написанное и написать актуальное. За ценный опыт особая благодарность

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

Насчет технологий. Посмотрите на существующие тулы, причем желательно не только на брендах остановиться, но и на опенсорсах. Можно посмотреть, как они реализованы, как устроены, какие языки используют. Последнее немаловажно, поскольку можно выбрать некоторый существующий язык и среду разработки и сделать для них определенные надстройки (например Rational Functional Tester - это фактически надстройка над Эклипс и код пишется на Яве), а можно проектировать свой язык для тестов. Во втором случае нужно тогда рассмотреть еще и реализации в других языках и определить, чего нехватает, как спроектирована библиотека там.

Помимо этого имеет смысл рассмотреть, какие компоненты сред разработки уже существуют в имеющихся средствах автоматизации тестирования. Например, полезно рассмотреть, как в разных средствах реализована работа с оконными объектами (если планируется работать на уровне ГУИ), какие дополнительные удобные штуки там есть (например, в некоторых средствах можно отфильтровать объекты, которые нам не нужны для работы). Также не забудте посмотреть решения для записи/воспроизведения действий, так как если эту фишку нецелесообразно применять в разработке тестов на постоянной основе, то как минимум для изучения и для получения хоть как-то работающего кода это весьма удобное решение

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

Привет! Проектирую инструмент автоматизации тестирования web. Существующие технологии (подходы) нужны для того, чтобы не написать написанное и написать актуальное. За ценный опыт особая благодарность

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

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

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

Если вы хотите задействовать Keyword-driven, то было бы неплохо снабдить язык конструкциями, которые могли бы вычислять код на лету, как например в JavaScript есть функция eval, в 4Test-е - EvaluateString. Или же можно снабдить систему некоторым визуальным компонентом, который бы мог подсоединять источник данных, содержащий команды, а также предоставить интерфейс для возможности добавления новых ключевых слов (например, ключевое слово резервируется в системе, а ему соответствует некоторая функция и при запуске теста по ключевым словам вызываются соответствующие функции). Или же спроектируйте систему изначально для этого подхода (посмотрите, как это сделано в Selenium)

Хотите сделать что-то наподобие Model-based - добавьте визуальных составляющих. Просто читая код, трудно представить все взаимосвязи, которые есть, поэтому там куда нагляднее сделать визуализацию.

Привет.

Или же спроектируйте систему изначально для этого подхода (посмотрите, как это сделано в Selenium)

А где можно посмотреть как сделанно в Selenium?
/cорри за оффтоп

Привет.

Или же спроектируйте систему изначально для этого подхода (посмотрите, как это сделано в Selenium)

А где можно посмотреть как сделанно в Selenium?
/cорри за оффтоп

Гугл мог бы вам помочь. Посмотрите здесь. В частности интерес представляет
Selenium Core
Selenium IDE
Selenium RC
На данном сайте много документации к данному решению. В целом очень удобная штука для веб-приложений, причем она кроссплатформенная, что иногда крайне полезно.

Подход к автоматизации (архитектура, фреймворк, ...) зависит не столько от технологии (Web) сколько от целей, которые вы ставите. Сначала надо понять, чего вы хотите получить, и только потом отвечать на вопрос - как...

UniTesK - это не подход. Это бренд, под которым вышло несколько инструментов для model-based тестирования. Эти инструменты не заточены под тестирование через GUI, и в общем-то для этого не предназначены.

Что касается доклада по фреймворкам, то презентация к нему доступна: http://www.slideshar...aieutic/-128269

UniTesK - это не подход. Это бренд, под которым вышло несколько инструментов для model-based тестирования. Эти инструменты не заточены под тестирование через GUI, и в общем-то для этого не предназначены.

Благодарю за слайды, Mike.
UniTesK - это подход (см. офиц. статьи от авторов). UniTesK используется для тестирования и gui и web (см. статьи ИСП РАН на intuit.ru).
Инструменты UniTesK не заточены под тестирование gui, верно. Но предназначены. Единственный минус перед другими подходами (или как Вам удобнее фреймворками) только в сложности. Что будет преодолено этим самым "затачиванием".

UniTesK - это не подход. Это бренд, под которым вышло несколько инструментов для model-based тестирования. Эти инструменты не заточены под тестирование через GUI, и в общем-то для этого не предназначены.

Благодарю за слайды, Mike.
UniTesK - это подход (см. офиц. статьи от авторов). UniTesK используется для тестирования и gui и web (см. статьи ИСП РАН на intuit.ru).
Инструменты UniTesK не заточены под тестирование gui, верно. Но предназначены. Единственный минус перед другими подходами (или как Вам удобнее фреймворками) только в сложности. Что будет преодолено этим самым "затачиванием".

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

Технология UniTesK – это технология разработки функциональных тестов на основе моделей, которые используются для оценки корректности поведения целевой системы3 и автоматической генерации последовательностей воздействий, далее называемых тестовыми последовательностями

Подход - это набор практик. А технология - это уже некоторая реализация, которая поддерживает некоторые подходы.

Опять же, подход != фреймворк.

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

Если вы все-таки хотите что-то подобное сделать (типа средства автоматизации тестирования), то как-то разложите по полочкам эти вещи. Если брать с точки зрения реализации данной системы, то:
1) Технология - это фактически движок системы
2) Подход - это идея, на основе которой строится движок и определяются концепции написания програмного кода в данной системе
3) Фреймворк - это библиотека уже реализованных компонент, которые уже можно использовать при написании тестовых процедур

Вот примерно так.

Кстати, такой вопрос топик-стартеру. А вы с какими-то уже существующими подобными системами работали? Просто, для разработки подобной штуки весьма полезен опыт работы с аналогичными системами, чтоб понимать, что удобнее, а что нет.

...
Подход - это набор практик. А технология - это уже некоторая реализация, которая поддерживает некоторые подходы.

Опять же, подход != фреймворк.

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

Если вы все-таки хотите что-то подобное сделать (типа средства автоматизации тестирования), то как-то разложите по полочкам эти вещи. Если брать с точки зрения реализации данной системы, то:
1) Технология - это фактически движок системы
2) Подход - это идея, на основе которой строится движок и определяются концепции написания програмного кода в данной системе
3) Фреймворк - это библиотека уже реализованных компонент, которые уже можно использовать при написании тестовых процедур

Вот примерно так.

В моем понятии так:
1) Методология (methodology) - теоритечиская основа, зачастую абстрактная идея чего-либо, например тестирования чего-го как-то.
2) Технология (technology) - практическое применение какой-либо методологии в той или иной области. Не реализация, а конкретная идея.
3) Подход (approach) - понятие того как применить технологию в конкретном случае, например подход к тестированию какого-го конкретного компонента системы. Или подход к созданию чего-либо основываясь на той или иной технологии.
4) Фрэймворк (framework) - конкретная реализация технологии, которой можно воспользоваться в рамках подхода, дабы достичь цели.

Например: методология - юнит-тестирование, технология - хUnit, подход - TDD на основе юнит-тестов, фрэймворк - jUnit, NUnit etc.

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

Технология UniTesK – это технология разработки функциональных тестов на основе моделей, которые используются для оценки корректности поведения целевой системы3 и автоматической генерации последовательностей воздействий, далее называемых тестовыми последовательностями

Подход - это набор практик. А технология - это уже некоторая реализация, которая поддерживает некоторые подходы.

Здравствуйте.
А почему Вы не привели название одной из основных статей про UniTesK "Подход UniTesK к разработке тестов достижения и перспективы" [http://www.citforum....sting/unitesk/] и не написали "Технология или как вам, Евгений, удобно, подход как и любое слово интерпретируется человеком в силу его ума и фантазии, и, в общем то, подход и технология - близкие понятия и единого международного стандарта, в котором эти понятия определяются нет (есть)"?

Кстати, такой вопрос топик-стартеру. А вы с какими-то уже существующими подобными системами работали? Просто, для разработки подобной штуки весьма полезен опыт работы с аналогичными системами, чтоб понимать, что удобнее, а что нет.

Здравствуйте. Работал с различными инструментами, которые поддерживают, здесь аккуратно, пункты 1, 2, 3, которые определены мною в самом начале топика. Но, вдруг, есть 4, 5, 6 ..., что я еще не видел?

...
Подход - это набор практик. А технология - это уже некоторая реализация, которая поддерживает некоторые подходы.

Опять же, подход != фреймворк.

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

Если вы все-таки хотите что-то подобное сделать (типа средства автоматизации тестирования), то как-то разложите по полочкам эти вещи. Если брать с точки зрения реализации данной системы, то:
1) Технология - это фактически движок системы
2) Подход - это идея, на основе которой строится движок и определяются концепции написания програмного кода в данной системе
3) Фреймворк - это библиотека уже реализованных компонент, которые уже можно использовать при написании тестовых процедур

Вот примерно так.

В моем понятии так:
1) Методология (methodology) - теоритечиская основа, зачастую абстрактная идея чего-либо, например тестирования чего-го как-то.
2) Технология (technology) - практическое применение какой-либо методологии в той или иной области. Не реализация, а конкретная идея.
3) Подход (approach) - понятие того как применить технологию в конкретном случае, например подход к тестированию какого-го конкретного компонента системы. Или подход к созданию чего-либо основываясь на той или иной технологии.
4) Фрэймворк (framework) - конкретная реализация технологии, которой можно воспользоваться в рамках подхода, дабы достичь цели.

Например: методология - юнит-тестирование, технология - хUnit, подход - TDD на основе юнит-тестов, фрэймворк - jUnit, NUnit etc.

Здравствуйте. Благодарю, кажется похоже на правду. Я обязательно поисследую этот вопрос и отвечу конструктивно

[http://www.citforum....sting/unitesk/] и не написали "Технология или как вам, Евгений, удобно, подход как и любое слово интерпретируется человеком в силу его ума и фантазии, и, в общем то, подход и технология - близкие понятия и единого международного стандарта, в котором эти понятия определяются нет (есть)"?

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