Поддерживаемые технологии.
#1
Отправлено 06 октября 2003 - 14:39
Под технологиями будем понимать — организованная совокупность процессов, элементов, устройств и методов, используемых для обработки информации. К примеру технологии .NET, CORBA, OLE, COM, DCOM, COM+ и т.д.
Под поддержкой технологий инструментарием тестирования будем понимать возможность записи и воспроизведения тестовых скриптов, которые будут производить тестовые вызовы элементов программного кода выполненных в стандартах той или иной технологии.
Следует оговориться, что уровень поддержки той или иной технологии существенно различается на уровне реализации тестовых скриптов. К примеру, большинство производителей инструментальных средств тестирования реализуют возможность записи и воспроизведения скриптов иммитирующих действия пользователя по отношению к пользовательскому интерфейсу, то есть поддерживаются возможности выбора из набора графического интерфейса программы определённого элемента (контрола) и передачи ему фокуса с последующим выполнением нажатия. Такая поверхностная поддержка, конечно, производит впечатление на потенциального заказчика (довольно эффектно выглядит к примеру автоматическое заполнение многостраничных форм регистрации за несколько секунд, даже с генерацией случайных данных из заданного диапазона), но без возможности непосредственной работы с объектной моделью приложения, этот функционал остаётся лиш красивым дополнениям к системе автоматизированного тестирования, чем её основой.
Суть поддержки той или иной технологии инструментом тестирования состоит в возможности работать через средства инструмента с обьектной моделью приложения, вызовами процедур и методов из тестовых скриптов, генерации вводимых данных на основе анализа диапазона передаваемых параметров.
Говоря неформальным языком, поддерживаемой можно считать такую технологию, при работе с которой инструмент как минимум «видит» обьектную модель приложения, выполненного согласно стандартов технологии.
Если в описании инструмента заявлено, что с его помощью можно проводить тестирование приложений выполненных с поддержкой практически всех технологий, следует внимательно уточнять уровень этой самой поддержки, потому что в большинстве случаев компания разработчик имеет в виду именно запись/воспроизведение иммитационных сценариев. Такая поддержка никоим образом не охватывает непосредственно тестирование серверных компонентов или сервисов приложений, выполняющих бизнесс-логику приложений. Также практически невозможно оценить в целом уровень производительности приложений моделируя пользовательскую нагрузку иммитацией реальных действий пользователя через пользовательский интерфейс.
_____________
Критика привествуется.
Редактор портала www.it4business.ru
#2
Отправлено 07 октября 2003 - 06:57
- Поддержка технологий каким именно инструментарием имеется в виду? Тулзы для функционального тестирования ("от интерфейса), вроде WR, Robot или SilkTest, например, в принципе не расчитаны на тестирование серверных компонентов.
- Вы уверены, что тулу для функционального тестирования надо что-то ещё кроме
. Собственно они именно для этого и предназначены - для тестирования "черного ящика" методом эмуляции действий пользователя. Да, для анализа "отклика" программы на действия пользователя очень полезно иметь доступ к объектной модели приложения и иметь возможность считывать некотрые свойства объекта. Тут я совершенно согласен. А вот зачем, например вызывать методы объектов приложения иметь возможность переписывать свойства объектов мне непонятно. Эти тулзы предназначены для автоматизации ручных тестов "черного ящика", а в ручную все эти возможности недоступны.возможности записи и воспроизведения скриптов иммитирующих действия пользователя по отношению к пользовательскому интерфейсу
- Не упомянуты средства для нагрузочного и Unit тестирования, которые, собственно и должны использоваться для тестирования серверной части приложений, а так же для тестирования всего того, что недоступно через пользовательский интерфейс (это про Unit тестирование).
Майк.
#3
Отправлено 07 октября 2003 - 09:32
Тормозил нещадно - разбираемся.Вчера пытался ответить, но сайт очень тормозил
Почему инструментарий функционального тестирования это тестирование интерфейса? К примеру если я пищу скрипт который бегает по интерфейсам COM обьекта и проверяет дают ли ему где нужно доступ - это не функциональное тестирование? Это тестирование функциональности обьекта (интерфейса пользователя тут и близко нет).Тулзы для функционального тестирования ("от интерфейса)
Я не ограничиваюсь в тестировании тестированием UI - посему это нужно в первую очередь мне, а потом уже компании чей тул я покупаю.Вы уверены, что тулу для функционального тестирования надо что-то ещё кроме
Не согласный. Пример выше. Если это тул для функционального тестирования (даже не автоматизированного), то он должен мне давать возможность потестить не только функционал пользовательсткого интерфейса.Собственно они именно для этого и предназначены - для тестирования "черного ящика" методом эмуляции действий пользователя
Опять таки при иммитации действий пользователя, я хочу чтобы в дропдауне каждый раз выбирался случайный элемент (кол-во элементов дроп дауна каждый раз разное (из БД к примеру)) - записываю только клики и не работая с моделью контрола я этого не сделаю. А нужно. А для этого нужно уметь видеть обьектную модель. Где я не прав?
Вот затем я и использую инструмент, чтобы они были доступны.А вот зачем, например вызывать методы объектов приложения иметь возможность переписывать свойства объектов мне непонятно. Эти тулзы предназначены для автоматизации ручных тестов "черного ящика", а в ручную все эти возможности недоступны
Доступ к свойствам я описал - я хочу узнать сколько элементов в дроп дауне и выбрать самое большое значение, для этого мне нужно получить значения из контрола, сортировки, выборка, позиционирование на нужный элемент списка и только потом клик. Как это сделать на интерфейсе?
Я в этом отрывке статьи говорил исключительно о поддерживаемых технологиях, а не о типах тестов. Типы тестов описаны ранее. Вот тут можно ознакомится.Не упомянуты средства для нагрузочного и Unit тестирования, которые, собственно и должны использоваться для тестирования серверной части приложений, а так же для тестирования всего того, что недоступно через пользовательский интерфейс (это про Unit тестирование).
http://tester.com.ua...tick_analis.htm
За критику спасибо - очень помогает разобраться.
Редактор портала www.it4business.ru
#4
Отправлено 07 октября 2003 - 09:50
Приведём пример:
Есть форма с элементом выпадающий список. Количество элементов списка определяется количество записей в таблице базы данных и есть динамически изменяемая величина. Значения элементов списка представляют, к примеру числовые данные. Список отсортирован не по величине значений, а по дате последнего изменения этого значения. Задача: при выполнении тестового скрипта выбрать из выпадающего списка максимальное (или минимальное) значение. Напомним что списко не отсортирован по величине, и выбрать первый или последний элемент, координаты которого можно рассчитать не получится. Кроме того количество элементов списка также величина динамическая - выбор последнего элемента затруднён. Нужно получить список всех значений из списка, заполнить ими массив, отсортировать, найти нужное значение. Обратиться к элементу список, споцизионироваться на нужный элемент (задача не просто решаемая перемещением курсора мышки на определённую кординату), иммитировать нажатие. Без возможности доступа к обьектной модели элемента такая задача не решается в приемлимые сроки. Как результат встречаются скрипты которые в подобной ситуации просто выбирают какое-то (неуправляемое) значение. Общая картина работы такого тестового скрипта напонимнает тыкание слепого в интерфейс пользователя, чем заполнение формы тестовыми данными.
Редактор портала www.it4business.ru
#5
Отправлено 07 октября 2003 - 09:55
Такой скрипт лучше писать на чём-нибудь вроде VB Scripta, тул для функционального тестирования тут не нужен. Вы же не забиваете гвозди пассатижами? К сожалению, чем более универсален тул, тем хуже он годится для выполнения каждой отдельной задачи. Я - за специализацию.К примеру если я пищу скрипт который бегает по интерфейсам COM обьекта и проверяет дают ли ему где нужно доступ - это не функциональное тестирование? Это тестирование функциональности обьекта (интерфейса пользователя тут и близко нет).
Опять таки при иммитации действий пользователя, я хочу чтобы в дропдауне каждый раз выбирался случайный элемент (кол-во элементов дроп дауна каждый раз разное (из БД к примеру)) - записываю только клики и не работая с моделью контрола я этого не сделаю. А нужно. А для этого нужно уметь видеть обьектную модель. Где я не прав?
А я и не говорил, что тул не должен видеть объектную модель. Должен, конечно. И, кстати, WR (да и Robot) для всех технологий которые он поддерживает позволяет получать все необходимые свойства объектов для выполнения задачи которую вы описали (про комбобокс и базу данных).
Я в этом отрывке статьи говорил исключительно о поддерживаемых технологиях, а не о типах тестов. Типы тестов описаны ранее.
IMHO, нельзя рассматривать степень поддержки технологий для всех видов инструментария сразу. Для разных задач нужна разная поддержка, нельзя весь инструментарий валить в одну кучу.
Майк.
#6
Отправлено 07 октября 2003 - 12:10
То есть купить нечто за N или M сотен долларов (если не тысяч как в случае с рашионалом), предварительно вырвав эти деньги из бюджета отдела, а потом что то руками дописывать вне системы? Увольте.К сожалению, чем более универсален тул, тем хуже он годится для выполнения каждой отдельной задачи. Я - за специализацию.
Конечно для описаной мной задачи хватит и ВБ - сейчас так и делаем - но дело в том,то сам ВБ скрипт выполняется из тестовой среды. (на самом деле мы просто записываем скрипт прохода по пользовательсткому интерфейсу ТестКомплитом, после чего берём себя в мои суровые руки и правим записанный на ВБ скрипт руками, для достижения поставленных задач, если бы тест комплит не видел обьектной модели сами понимаете куда бы мы получили доступ)
Полностью согласен, Mike.IMHO, нельзя рассматривать степень поддержки технологий для всех видов инструментария сразу. Для разных задач нужна разная поддержка, нельзя весь инструментарий валить в одну кучу.
Статья как называется? "Разработка критериев анализа систем автоматизации тестирования." Я пытаюсь разобраться с критериями по которым можно будет оценить тул. До самой оценки (свалки в одну кучу) дело пока не дошло. Валить в кучу и не прийдётся, когда будет чёткое ограничение тулов по какой-то классификации и набору критериев.
Редактор портала www.it4business.ru
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных