qulix
  • русский
    • english

Наши клиенты

  • Крок
  • Helmes
  • S&T
  • BSC
  • DevHouse
  • Interface
  • Сиа Сервис
  • Active
  • MobiFly
  • Ajilon
  • Alcatel
  • AT consulting
  • FreeTracking
  • Alternative Soft
  • Nvision
  • Orange
  • Aimes
  • Wayfinder
  • Wildlife Conservation Society
  • Aplana
  • CM Consult
  • Unicef

Мы в соцсетях

twitter facebook

Клиенты о нас

«Наше сотрудничество с преподавателями Qulix QA длится уже четыре года, их дисциплинированность, отличная подготовка и творческий подход в работе со слушателями курсов, вызывают уважение. Отдельное спасибо за разработку и постоянное совершенствование эффективных программ обучения, которые являются популярными и получают отличные отзывы.»
Ольга Занегина
Администратор учебного центра
читать полностью

Клиенты о нас

«Независимый контроль качества – это критически важное условие успешной реализации сложных комплексных систем, которые разрабатывает наша компания. На протяжении нескольких лет мы активно сотрудничаем с Qulix QA в области обеспечения качества и экспертного независимого тестирования наших программных решений. Благодаря нашему сотрудничеству мы уверены, что поставляем нашим заказчикам программные продукты, обладающие высокой стабильностью и качеством.»
Борис Носков
Генеральный директор
читать полностью

Клиенты о нас

«Мы благодарны Qulix за быструю реакцию на наши запросы и качественное тестирование. Всегда приятно сотрудничать с профессиональной командой.»
Наталья Жильцова
Руководитель отдела обеспечения качества ПО
читать полностью

Тестирование, управляемое данными (Data-Driven Testing)

Методология Data Driven применяется в автоматизации тестирования ПО, представляет собой тестирование, выполнение и верификация которого производится на основе данных, которые хранятся в центральном хранилище данных или БД (т.е. внешних данных).

Роль БД могут выполнять ODBC-ресурсы, csv или xls файлы и т.д. В этом фреймворке переменные используются как для входных значений, так и для выходных проверочных значений: в тестовом скрипте обычно закодированы навигация по приложению, чтение источников данных, ведение логов тестирования. Таким образом, логика, которая будет выполнена в скрипте, также зависит от данных.

Рассмотрим Data Driven Testing на практике, например, стоит задача протестировать страницу логина.

Необходимо провести автоматизацию трех простых тест-кейсов:

  • Пользователь вводит корректные (хранящиеся в базе) имя пользователя/пароль;
  • Пользователь вводит неверные (данных нет в базе) имя пользователя/пароль;
  • Пользователь вводит неверные имя пользователя/пароль (данные не удовлетворяют условиям валидации).

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

Пулы данных можно представлять в любом формате, как правило, это пары ключ-значение. Это значительно сокращает затраты как на разработку новых тест кейсов, так и на поддержку существующих. Безусловно, наибольший эффект от data driven подхода наблюдается при тестировании форм ввода, т.к. один управляющий скрипт может проверить практически любую форму с любыми данными.

Основными признаками data driven подхода являются:

  • Данные вынесены из скрипта во внешний файл/БД;
  • Один и тот же тест кейс используется с различными данными – данное условие является обязательным. Зачастую можно увидеть, что все данные находятся вне скриптов, но при этом фактически каждый тест кейс с точки зрения кода абсолютно уникален;
  • Повторное использование одних и тех же пулов данных.
    • Повторное использование данных;
    • Простота разработки тестов;
    • Более высокая эффективность по сравнению с «чистым» record-replay: один тестовый скрипт автоматизирует множество тест-кейсов.
  • К достоинствам data driven подхода относятся:

    Недостатки

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

© 2010 Все права защищены. Использование любых материалов сайта допускается только с разрешения администрации Qulix QA. Вы можете связаться с нами по электронной почте или любым удобным для Вас способом