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

  1. Форум тестировщиков
  2. → Тестирование
  3. → Тест-дизайн и ручное тестирование
Фотография

Зависимые тесты

Автор lumer, 19 дек 2004 09:55

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

#1 lumer

lumer

    Новый участник

  • Members
  • Pip
  • 7 сообщений
  • Город:Perm

Отправлено 19 декабря 2004 - 09:55

(я здесь новичок, просьба сильно не пинать)

Сегодня задали мне резонный вопрос по тестированию: как протестировать контекстный поиск в списке компаний, если на эту таблицу предварительно можно наложить тучу фильтров (имя = Юкос, дата = не более года итп)?

Причем речь идет именно о тестировании ручками ака "черный ящик". Если делать тесты "в лоб", то придется для 5 разновидностей фильтров (можно их комбинировать) делать (2^5)х(число тестовых условий фильтрации)х(число контекстных строк). Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?
  • 0

#2 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 19 декабря 2004 - 22:01

В подобных ситуациях, как правило, тестируют некоторое ограниченное число возможных комбинаций. В зависимости от степени критичности контекстного поиска для тестируемого приложения количество проверяемых комбинаций варьируется от 1 до ... Я на практике никогда больше 3 случайным образом выбранных комбинаций не проверял - всегда хватало. Такой поиск обычно или сразу работает или не работает вовсе.
  • 0
Дмитрий Шевченко

HP Software

#3 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 20 декабря 2004 - 07:12

Я обычно делаю так:
1. Относительно разновидностей фильтров - обязательно - по одному фильтру, все вместе
потом НА СКОЛЬКО ХВАТИТ ВРЕМЕНИ - все возможные сочетания

2. Относительно значений в фильтрах - обычно первого и последнего в списке всегда хватает. Все остальное - опять же на сколько позволяет время.

Итого: обязательных тестов - (5+1)*2 = 12
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#4 Doveangel

Doveangel

    Постоянный участник

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 20 декабря 2004 - 08:25

Мне кажется что тут внутренняя проблема. Либо при инсталляции проблема появилась -либо в версии. Так что лучше работать в обход - хотя бы даже вызовом скрипта в скрипте. Если вы хотите красивый разбитый лог, то можете записать отдельные скрипты - а потом в менеджере на каждый скрипт написать тест-кейс - и запустить папку на Run - по очереди выполняться все скрипты.
  • 0

#5 Doveangel

Doveangel

    Постоянный участник

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 20 декабря 2004 - 08:34

сорри)) не туда написала.
Упс))

Напишу и сюда :P

Я бы сделала так- конечно протестила бы сначала все фильтры по отдельности - для проверки их функционирования по всем полям. А потом бы проверила 3 случая- выбор данных по первым полям всех фильтров (т.е. задание условий только в первых полях фильтров), потом по средним и наконец по последним. Если фильтры работают сами по себе исправно- то этих тест-кейсов должно хватить
  • 0

#6 PavelB

PavelB

    Постоянный участник

  • Members
  • PipPipPip
  • 169 сообщений
  • Город:Санкт-Петербург

Отправлено 20 декабря 2004 - 09:44

Вообще, когда мало времени, то стоит, по-моему, случайные комбинации вводить.
Метод Монте-Карло, как известно, даёт скорость сходимости к решению 1/vN (v - квадратный корень, N - число испытаний). Поэтому под этим скрывается непросто идея от нечего делать, но и теоретически обоснованное решение, приводящее к правильному ответу.

Ну а так, на граничных значениях стоит всё проверить. Например, не используя один из фильтров. Или пустое где-нибудь вводить.
  • 0

#7 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 20 декабря 2004 - 15:09

Если делать тесты "в лоб", то придется для 5 разновидностей фильтров (можно их комбинировать) делать (2^5)х(число тестовых условий фильтрации)х(число контекстных строк). Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?

Pairwise Testing for Dummies
  • 0
Andrey Yegorov. Изображение

#8 lumer

lumer

    Новый участник

  • Members
  • Pip
  • 7 сообщений
  • Город:Perm

Отправлено 20 декабря 2004 - 15:22

Pairwise Testing for Dummies

Статья хорошая, только смущает одно:

у них не протестили вариант с прыжком 150-фунтового товарища с 60-см высоты на асфальт. Пружинка-то как раз при таких условиях и сломается... :P
  • 0

#9 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 21 декабря 2004 - 07:10

Отличная статья!

Данный подход еще называют тестированием ортогональных массивов.

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

Цитата из книги Л Тамре.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#10 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 21 декабря 2004 - 07:13

Там еще хорошие примеры есть :)
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#11 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 21 декабря 2004 - 08:01

... а вообще-то 384 теста -- это ерунда, не руками же их прогонять ...
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#12 Doveangel

Doveangel

    Постоянный участник

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 21 декабря 2004 - 08:17

Да-кстате как это мы сразу не посоветовали)) напишите скрипт!))
  • 0

#13 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 21 декабря 2004 - 15:03

... а вообще-то 384 теста -- это ерунда, не руками же их прогонять ...

Если каждый из них занимает хотя бы 5 минут... После автоматизации...
384 * 5 = 1920 минут = 32 часа.

Да, за неделю перед релизом их можно прогнать.
Но вот как smoke test их все использовать это уже чересчур.
  • 0
Andrey Yegorov. Изображение

#14 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 21 декабря 2004 - 15:08

Да, за неделю перед релизом их можно прогнать.

А если релизы каждую неделю :)
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#15 Doveangel

Doveangel

    Постоянный участник

  • Members
  • PipPipPip
  • 221 сообщений
  • ФИО:Дроздова Анжелика
  • Город:Беларусь

Отправлено 21 декабря 2004 - 15:13

Если каждый из них занимает хотя бы 5 минут...

5 минут - это очень много.. конечно можно задержки такие поставить, что будет час теститься.. но можно и за 10 секунд прогнать)
  • 0

#16 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 21 декабря 2004 - 15:55

сценарий из жизни:

программа (на самом деле подсистема программы) получает preview различных графических файлов.
Поддерживаемых форматов почти 30.
У каждого формата есть свои ньюансы - compession level, layers, colors, subformats, has preview embedded (inside or in resource fork), multipage or not и т.д.

Есть кучка настроек - max preview sizes, preview compression level, configuration of how to get preview и т.д.

у большинства файлов превью выдирается быстро, но есть ряд файлов (e.g. very large TIFFs) для которых этот процесс занимает час.

Еще базу нужно сконфигурировать. Проверить результаты.

Тест выполняется не через GUI, так что замечание про "задержки" мы отметем с негодованием как неорганизованное © надеюсь известен.

Релизы каждую неделю просто утомят заказчика (updates of antivarus bases I would not call 'releases').

Так что на каждом билде все тесты гонять - это слишком.
  • 0
Andrey Yegorov. Изображение

#17 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 872 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 21 декабря 2004 - 18:04

... а вообще-то 384 теста -- это ерунда, не руками же их прогонять ...

Если каждый из них занимает хотя бы 5 минут... После автоматизации...
384 * 5 = 1920 минут = 32 часа.

Да, за неделю перед релизом их можно прогнать.
Но вот как smoke test их все использовать это уже чересчур.

На каждый аргумент можно найти контраргумент. Особенно добавив новых деталей. Речь шла просто про 384 теста, а про 5 минут на каждый и про то, что это smoky test -- это Вы, милостивый государь, домыслили.

Да, иногда и 10 тестов могут выполняться очень долго. Приведу и другой пример, не умозрительный, а вполне реальный. Как все, конечно, знают ;), мы разрабатываем инстументы тестирования на основе моделей. Есть у нас компилятор языка, на котором описываются модели, это расширение языка программирования. Так вот, для парсера, например, генерируется почти 400000 тестов, и при этом генерация и выполнение вместе взятые занимают меньше часа (машина P4-2700, 512 Mb). Есть и более тяжеловесные с точки зрения объёма тестирования подсистемы, например, для анализатора результатов, который на вход получает трассы в формате XML, общий объём генерируемых тестов (трасс) занимает более 4 Gb, мы их даже не генерируем заранее -- сгенерировали тест, выполнили, удалили, и так несколько часов подряд.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#18 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 21 декабря 2004 - 18:26

Речь шла просто про 384 теста

"сферический конь в вакууме". B)

тогда и 500000000 тестов минимизировать не нужно. В теории и так все хорошо.

Позаолю себе напомнить "оригинальную" постановку вопроса:

Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?


Давайте базироваться на конкретных use-cases, как то:

100000 возможных тестов со средним временкм выполнения каждого < 1 sec.

или: 500 тестов со средним временем выполнения каждого 30 min.

или 100 тестов со средним временем выполнения 5 минут но невозможностью автоматизации.

Давайте добавим информации о том, что произойдет при ошибке - город останется без света или пользователь "испытает легкое неудобство" :unsure:

А потом для конкретного случая обсудим best practicies and methods.

Иначе можно долго спорить. :)
  • 0
Andrey Yegorov. Изображение

#19 lumer

lumer

    Новый участник

  • Members
  • Pip
  • 7 сообщений
  • Город:Perm

Отправлено 22 декабря 2004 - 11:31

Всем спасибо, основные мысли я понял :)

Просто так прокомментирую, что каждый из этих гипотетических тестов на тестовой БД средних размеров выполнялся бы 1-5 секунд максимум.

Итого: примерно 1800 сек или полчаса. А скорее всего и в минут 5-10 уложилось бы.
  • 0

#20 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 23 декабря 2004 - 14:52

(я здесь новичок, просьба сильно не пинать)

Сегодня задали мне резонный вопрос по тестированию: как протестировать контекстный поиск в списке компаний, если на эту таблицу предварительно можно наложить тучу фильтров (имя = Юкос, дата = не более года итп)?

Причем речь идет именно о тестировании ручками ака "черный ящик". Если делать тесты "в лоб", то придется для 5 разновидностей фильтров (можно их комбинировать) делать (2^5)х(число тестовых условий фильтрации)х(число контекстных строк). Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?

Я бы построил работу следующим образом. Разбил бы все тесты на две большие группы: тестирование каждого фильтра в отдельности и комплексно.

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

Такой подход к подготовке тестов основывается на подходе группировки характерных тестовых данных в различные классы. Затем тестируются только критичные данные для конкретного класса.

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

2. Здесь не обойтись без дополнительной информации о работе фильтров. Необходимо выяснить у разработчиков по какому принципу происходит фильтрация информации. Это может быть или пересечение, или объединение или еще бог весть как. :)

Далее, строим матрицу тестов исходя из того же принципа классовости ( и в тестировании не обойтись без классового подхода :P ): одно среднее и граничные условия фильтрации. Для каждого вида фильтра оно может быть своим, но общая сумма тестов наверняка будет меньше 384. B)
  • 0
Гринкевич Сергей
Обратно в Тест-дизайн и ручное тестирование

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

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

Реклама на портале
  1. Форум тестировщиков
  2. → Тестирование
  3. → Тест-дизайн и ручное тестирование
  4. Политика Конфиденциальности
  5. Правила форума ·