Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Тестирование и качество


Информационный Канал Subscribe.Ru

Тестер :: Лаборатория
Серия: Лабораторные исследования.
Анонс:

www.KlubOK.net — материалы об управлении и маркетинге
    1. Все, что Вы хотели знать о практической стороне СМК.
    2. Управленческий консалтинг
    3. Интернет и маркетинг
    4. Новая торговля.
Новости проекта KlubOK.net на Subscribe.ru:
Спешите! С января 2004 года контент проекта будет платным

Лабораторное исследование:
Разработка критериев анализа систем автоматизации тестирования.

План.
  1. Поддерживаемые процессы тестирования.
  2. Поддерживаемые типы тестов.
  3. Поддерживаемые технологии.
  4. Интеграция с системами разработки.
  5. Техническая и документальная поддержка компанией разработчиком.
  6. Обучение и сертификация персонала, работающего с набором инструментов и/или методологией.
  7. Представительство компании-разработчика в странах ближнего зарубежья.


3. Поддерживаемые технологии.


Под технологиями будем понимать — организованную совокупность процессов, элементов, устройств и методов, используемых для обработки информации. К примеру, технологии .NET, CORBA, OLE, COM, DCOM, COM+ и т.д.

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

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

Приведём пример: Есть форма с элементом выпадающий список. Количество элементов списка определяется количество записей в таблице базы данных и есть динамически изменяемая величина. Значения элементов списка представляют, к примеру числовые данные. Список отсортирован не по величине значений, а по дате последнего изменения этого значения. Задача: при выполнении тестового скрипта выбрать из выпадающего списка максимальное (или минимальное) значение. Напомним что список не отсортирован по величине, и выбрать первый или последний элемент, координаты которого можно рассчитать не получится. Кроме того, количество элементов списка также величина динамическая - выбор последнего элемента затруднён. Нужно получить список всех значений из списка, заполнить ими массив, отсортировать, найти нужное значение. Обратиться к элементу список, споцизионироваться на нужный элемент (задача не просто решаемая перемещением курсора мышки на определённую координату), имитировать нажатие. Без возможности доступа к объектной модели элемента такая задача не решается в приемлемые сроки. Как результат встречаются скрипты которые в подобной ситуации просто выбирают какое-то (неуправляемое) значение. Общая картина работы такого тестового скрипта напоминает тыканье слепого в интерфейс пользователя, чем заполнение формы тестовыми данными.

Суть поддержки той или иной технологии инструментом тестирования состоит в возможности работать через средства инструмента с объектной моделью приложения, вызовами процедур и методов из тестовых скриптов, генерации вводимых данных на основе анализа диапазона передаваемых параметров. Говоря неформальным языком, поддерживаемой можно считать такую технологию, при работе с которой инструмент как минимум “видит” объектную модель приложения, выполненного согласно стандартов технологии.

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

Отдельно хотелось бы оговорить специализированные инструменты, которые поддерживают технологии работы с данными, серверные компоненты и сервера баз данных. В целом картина на рынке таких инструментов отличается от состояния дел на рынке инструментов для тестирования функциональности. Суть таких инструментов, не только создать нагрузку на сервер базы данных (для этого существует отдельный класс так называемых нагрузочных и стрессовых инструментов), с тем чтобы зафиксировать время отклика и/или выполнения того или иного запроса или вызова. Средства которые поддерживают технологию какой-то определённой СУБД (Oracle, Informix, DB2, MS SQL) должны обладать не только функционалом вызова к примеру хранимых процедур, или подобной функциональностью, которая будет создавать нагрузку и анализировать поведения сервера, но в идеале и проводить анализ конфигурации серверного окружения, структур и схем хранения данных, контроль за следованием стандартам обращений к данным с тем. Результатом работы такого средства может служить сгенерированный набор аналитических данных на основе которых сервер или окружение будет конфигурироваться под конкретную архитектуру базы данных и возможно настраиваться согласно выбранной технологии реализации клиентского приложения.

Указанные требования накладывают существенные ограничения на функциональность подобных средств. Зачастую компания производитель поддерживает на глубоком уровне только одну конкретную СУБД, разработка инструмента ведётся в тесной интеграции с компанией разработчиком самой СУБД с учётом особенностей архитектуры и технологических решений. Инструментарий получается довольно узкоспециализированный и дорогостоящий, его применения оправдано в случае внедрения долгосрочных промышленных систем автоматизации или систем повышенной отказоустойчивости.
__________________________________
Статья публикуется по мере создания на сервере Тестер,
по адресу: http://tester.com.ua/lab/lab_mining_yardstick_analis.htm

С уважением, автор проекта Тестер,
Панкратов Вячеслав.
URL: http://pankratov.org.ua
Email: caset@tester.com.ua

 
www.Tester.com.ua


http://subscribe.ru/
E-mail: ask@subscribe.ru
Отписаться
Убрать рекламу

В избранное