Перейти к содержимому

Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 5

#1 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 06 октября 2003 - 14:39

Поддерживаемые технологии.
Под технологиями будем понимать — организованная совокупность процессов, элементов, устройств и методов, используемых для обработки информации. К примеру технологии .NET, CORBA, OLE, COM, DCOM, COM+ и т.д.
Под поддержкой технологий инструментарием тестирования будем понимать возможность записи и воспроизведения тестовых скриптов, которые будут производить тестовые вызовы элементов программного кода выполненных в стандартах той или иной технологии.
Следует оговориться, что уровень поддержки той или иной технологии существенно различается на уровне реализации тестовых скриптов. К примеру, большинство производителей инструментальных средств тестирования реализуют возможность записи и воспроизведения скриптов иммитирующих действия пользователя по отношению к пользовательскому интерфейсу, то есть поддерживаются возможности выбора из набора графического интерфейса программы определённого элемента (контрола) и передачи ему фокуса с последующим выполнением нажатия. Такая поверхностная поддержка, конечно, производит впечатление на потенциального заказчика (довольно эффектно выглядит к примеру автоматическое заполнение многостраничных форм регистрации за несколько секунд, даже с генерацией случайных данных из заданного диапазона), но без возможности непосредственной работы с объектной моделью приложения, этот функционал остаётся лиш красивым дополнениям к системе автоматизированного тестирования, чем её основой.
Суть поддержки той или иной технологии инструментом тестирования состоит в возможности работать через средства инструмента с обьектной моделью приложения, вызовами процедур и методов из тестовых скриптов, генерации вводимых данных на основе анализа диапазона передаваемых параметров.
Говоря неформальным языком, поддерживаемой можно считать такую технологию, при работе с которой инструмент как минимум «видит» обьектную модель приложения, выполненного согласно стандартов технологии.
Если в описании инструмента заявлено, что с его помощью можно проводить тестирование приложений выполненных с поддержкой практически всех технологий, следует внимательно уточнять уровень этой самой поддержки, потому что в большинстве случаев компания разработчик имеет в виду именно запись/воспроизведение иммитационных сценариев. Такая поддержка никоим образом не охватывает непосредственно тестирование серверных компонентов или сервисов приложений, выполняющих бизнесс-логику приложений. Также практически невозможно оценить в целом уровень производительности приложений моделируя пользовательскую нагрузку иммитацией реальных действий пользователя через пользовательский интерфейс.


_____________
Критика привествуется.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#2 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 07 октября 2003 - 06:57

Сase! Вчера пытался ответить, но сайт очень тормозил :( . Собственно, немножко критики :) :
- Поддержка технологий каким именно инструментарием имеется в виду? Тулзы для функционального тестирования ("от интерфейса), вроде WR, Robot или SilkTest, например, в принципе не расчитаны на тестирование серверных компонентов.
- Вы уверены, что тулу для функционального тестирования надо что-то ещё кроме

возможности записи и воспроизведения скриптов иммитирующих действия пользователя по отношению к пользовательскому интерфейсу

. Собственно они именно для этого и предназначены - для тестирования "черного ящика" методом эмуляции действий пользователя. Да, для анализа "отклика" программы на действия пользователя очень полезно иметь доступ к объектной модели приложения и иметь возможность считывать некотрые свойства объекта. Тут я совершенно согласен. А вот зачем, например вызывать методы объектов приложения иметь возможность переписывать свойства объектов мне непонятно. Эти тулзы предназначены для автоматизации ручных тестов "черного ящика", а в ручную все эти возможности недоступны.
- Не упомянуты средства для нагрузочного и Unit тестирования, которые, собственно и должны использоваться для тестирования серверной части приложений, а так же для тестирования всего того, что недоступно через пользовательский интерфейс (это про Unit тестирование).
  • 0
Best regards,
Майк.

#3 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 07 октября 2003 - 09:32

Вчера пытался ответить, но сайт очень тормозил

Тормозил нещадно - разбираемся.

Тулзы для функционального тестирования ("от интерфейса)

Почему инструментарий функционального тестирования это тестирование интерфейса? К примеру если я пищу скрипт который бегает по интерфейсам COM обьекта и проверяет дают ли ему где нужно доступ - это не функциональное тестирование? Это тестирование функциональности обьекта (интерфейса пользователя тут и близко нет).

Вы уверены, что тулу для функционального тестирования надо что-то ещё кроме

Я не ограничиваюсь в тестировании тестированием UI - посему это нужно в первую очередь мне, а потом уже компании чей тул я покупаю.

Собственно они именно для этого и предназначены - для тестирования "черного ящика" методом эмуляции действий пользователя

Не согласный. Пример выше. Если это тул для функционального тестирования (даже не автоматизированного), то он должен мне давать возможность потестить не только функционал пользовательсткого интерфейса.
Опять таки при иммитации действий пользователя, я хочу чтобы в дропдауне каждый раз выбирался случайный элемент (кол-во элементов дроп дауна каждый раз разное (из БД к примеру)) - записываю только клики и не работая с моделью контрола я этого не сделаю. А нужно. А для этого нужно уметь видеть обьектную модель. Где я не прав?

А вот зачем, например вызывать методы объектов приложения иметь возможность переписывать свойства объектов мне непонятно. Эти тулзы предназначены для автоматизации ручных тестов "черного ящика", а в ручную все эти возможности недоступны

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

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

Я в этом отрывке статьи говорил исключительно о поддерживаемых технологиях, а не о типах тестов. Типы тестов описаны ранее. Вот тут можно ознакомится.
http://tester.com.ua...tick_analis.htm

За критику спасибо - очень помогает разобраться.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#4 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 07 октября 2003 - 09:50

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

#5 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 07 октября 2003 - 09:55

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

Такой скрипт лучше писать на чём-нибудь вроде VB Scripta, тул для функционального тестирования тут не нужен. Вы же не забиваете гвозди пассатижами? К сожалению, чем более универсален тул, тем хуже он годится для выполнения каждой отдельной задачи. Я - за специализацию.

Опять таки при иммитации действий пользователя, я хочу чтобы в дропдауне каждый раз выбирался случайный элемент (кол-во элементов дроп дауна каждый раз разное (из БД к примеру)) - записываю только клики и не работая с моделью контрола я этого не сделаю. А нужно. А для этого нужно уметь видеть обьектную модель. Где я не прав?


А я и не говорил, что тул не должен видеть объектную модель. Должен, конечно. И, кстати, WR (да и Robot) для всех технологий которые он поддерживает позволяет получать все необходимые свойства объектов для выполнения задачи которую вы описали (про комбобокс и базу данных).

Я в этом отрывке статьи говорил исключительно о поддерживаемых технологиях, а не о типах тестов. Типы тестов описаны ранее.


IMHO, нельзя рассматривать степень поддержки технологий для всех видов инструментария сразу. Для разных задач нужна разная поддержка, нельзя весь инструментарий валить в одну кучу.
  • 0
Best regards,
Майк.

#6 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 07 октября 2003 - 12:10

Выложил новую редакцию этой части статьи

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

То есть купить нечто за N или M сотен долларов (если не тысяч как в случае с рашионалом), предварительно вырвав эти деньги из бюджета отдела, а потом что то руками дописывать вне системы? Увольте.
Конечно для описаной мной задачи хватит и ВБ - сейчас так и делаем - но дело в том,то сам ВБ скрипт выполняется из тестовой среды. (на самом деле мы просто записываем скрипт прохода по пользовательсткому интерфейсу ТестКомплитом, после чего берём себя в мои суровые руки и правим записанный на ВБ скрипт руками, для достижения поставленных задач, если бы тест комплит не видел обьектной модели сами понимаете куда бы мы получили доступ)

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

Полностью согласен, Mike.
Статья как называется? "Разработка критериев анализа систем автоматизации тестирования." Я пытаюсь разобраться с критериями по которым можно будет оценить тул. До самой оценки (свалки в одну кучу) дело пока не дошло. Валить в кучу и не прийдётся, когда будет чёткое ограничение тулов по какой-то классификации и набору критериев.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных