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

Программирование на Python для тестировщиков
онлайн, начало 23 октября
Тестирование безопасности
онлайн, начало 28 октября
Школа для начинающих тестировщиков
онлайн, начало 22 октября
Автоматизатор мобильных приложений
онлайн, начало 28 октября
Фотография

Тестируйте не числом, а умением


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

#1 barancev

barancev

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

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


Отправлено 22 июля 2010 - 05:21

Автор: Scott Sehlhorst
Оригинал: Test Smarter, Not Harder

Эта статья о комбинаторных методах построения тестов первоначально была написана для developer.* в марте 2006 года. Недавняя статья на Dailytech обращает внимание на одно очень интересное исследование о новых методах генерации многомерных комбинаций (четверок и более), выполненное Лабораторией информационных технологий Национального института стандартов и технологий США (NIST, the National Institute of Standards and Technology). Данная переработанная и дополненная версия статьи учитывает эти результаты.

Введение

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

Мы поговорим о способах снижения цены, которую приходится платить за обеспечение высокого качества тестирования. Более конкретно, мы обсудим техники, удешевляющие создание и поддержку набора регрессионных тестов.

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

Читать дальше...
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#2 barancev

barancev

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

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


Отправлено 22 июля 2010 - 07:17

Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!

А использовали ли вы какие-нибудь способы для учета порядка ввода?
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#3 barancev

barancev

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

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


Отправлено 22 июля 2010 - 07:30

Ещё на ту же тему из недавнего:

Доклад Александра Барановского на SQA-7 "Метод всех пар, или как не убиться тестируя комбинации"
Рассказ Марины Широчкиной на июльской встрече питерского клуба про "Domain-естирование" (вторая половина, начиная с 44-го слайда, посвящена комбинаторным методам)
  • 0

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#4 galogenIt

galogenIt

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

  • Members
  • PipPipPip
  • 192 сообщений
  • ФИО:Эдуард

Отправлено 25 июля 2010 - 18:50

Алексей, видимо я туплю сильно от жары. Но чего-то не врубился как составляются пары.

1. пары имеет смысл составлять, если существует зависимость параметров?

2. программа pict - а где искать?

3. а как получать при этом оракул?

Нельзя ли подробный пример на пальцах?
  • 0
С уважением, Эдуард!

#5 novak

novak

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

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 25 июля 2010 - 19:02

2. программа pict - а где искать?

Например, на сайте microsoft
  • 0

#6 Natalya Rukol

Natalya Rukol

    Гуру

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 27 июля 2010 - 01:44

Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!

Ткни пальцем - ты о чём?
  • 0

#7 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 659 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 27 июля 2010 - 06:45

Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!

Мы ищем N-mode дефекты в порядке ввода M элементов, поэтому, видимо, выбираем все возможные комбинации N элементов из M.

А использовали ли вы какие-нибудь способы для учета порядка ввода?

Мне этот подход вообще показался странным. Если у нас есть просто набор параметров и их обработка в виде F(a, b, c) - мы ищем N-mode дефекты для данного набора параметров, и как сюда укладывается порядок ввода, я не понимаю. Мы же не можем вызвать F( c, a, b )?

Если же мы добавляем порядок ввода, то реально мы тестируем не F( a, b, c ), а что-то вроде F( f1( a ), f2( b, c ) ), и эта задача должна решаться другим способом (наверное).

1. пары имеет смысл составлять, если существует зависимость параметров?

Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.

Пример на пальцах. У нас есть веб-приложение, которое мы хотим протестировать на разных конфигурациях. Допустим, конфигурация у нас = (ОС клиента, браузер клиента, веб-сервер). Возьмем для простоты два браузера, две ОС и 2 веб-сервера. Для полного тестирования нам нужно 2*2*2 = 8 конфигураций. Применяя метод пар, получаем 4 теста:
OS	  Browser   Server

Win	 IE		Apache
Win	 FF		IIS
Linux   IE		IIS
Linux   FF		Apache

Казалось бы этого достаточно (все пары параметров покрываются). На самом же деле у нас OS и браузер - зависимые параметры, и третий тест является вырожденным. Если этого не учесть, и просто выкинуть данный тест, мы потеряем пары Linux-IIS и IE-IIS, которые более ни в одном тесте не покрываются. Добавив зависимость в модель, получаем другой набор тестов:
OS	  Browser	Server

Linux   FF		 IIS
Linux   FF		 Apache
Win	 IE		 IIS
Win	 IE		 Apache
Win	 FF		 Apache

Пример крайне упрощен, разумеется.

Автор же статьи, как я понимаю, "зависимостью" параметров называет ситуацию, когда определенная комбинация этих параметров вызывает дефект в коде приложения.
  • 0

#8 novak

novak

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

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 27 июля 2010 - 10:11

Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!

Мы ищем N-mode дефекты в порядке ввода M элементов, поэтому, видимо, выбираем все возможные комбинации N элементов из M.

Что происходит - и так видно. Вопрос в том, из чего следует второе предложение из цитаты статьи:

Мы можем учесть порядок действий, рассматривая его как дополнительный входной параметр. Он будет принимать столько значений, сколько существует подмножеств заданного размера N.

Другими словами, почему этот дополнительный параметр будет принимать именно столько значений.
В общем случае у нас получается M!
В случае, если мы учитываем только порядок в парах получается N!
И у автора до представления, что мы используем порядок в качестве дополнительного параметра шла речь о порядке в этих группах по N элементов.
После же, судя по всему, он стал говорить о порядке следования этих групп. Отсюда и сочетание из M по N
  • 0

#9 dlg99

dlg99

    Специалист

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

Отправлено 27 июля 2010 - 15:09

Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.


в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.
  • 0
Andrey Yegorov. Изображение

#10 Freiman

Freiman

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 567 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 27 июля 2010 - 15:31

Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.


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

к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.

Пример:
Мы тестируем некий графический редактор. С его помощью можно нарисовать прямоугольник с разными параметрами линий контура и параметрами заливки.
Fill = {NoFill, SolidFill, GradientFill, TextureFill}
Border = {No Line, SolidColorLine, GradientColorLine}
BorderWidth = {1..10}
CompoundType = {Simple, Double, Triple, Thick-Thin}
Dashed = {Solid, Dot, Dash, LongDash}
Если Border = No Line, то параметры BorderWidth, CompoundType, Dashed вообще не будут влиять на результат, нет линии - нет параметров.
И даже это упрощенный вариант..

Вероятно, в таких случаях имеет смысл создавать 2 подмножества. К примеру, проверяем Border без варианта NoLine, и со всеми параметрами, а потом параметр Fill с параметром Border = NoLine. Мне такое решение данной (конкретной) проблемы кажется наиболее рациональным.
  • 0

#11 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 27 июля 2010 - 15:55

к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.

Пример:
Мы тестируем некий графический редактор. С его помощью можно нарисовать прямоугольник с разными параметрами линий контура и параметрами заливки.
Fill = {NoFill, SolidFill, GradientFill, TextureFill}
Border = {No Line, SolidColorLine, GradientColorLine}
BorderWidth = {1..10}
CompoundType = {Simple, Double, Triple, Thick-Thin}
Dashed = {Solid, Dot, Dash, LongDash}
Если Border = No Line, то параметры BorderWidth, CompoundType, Dashed вообще не будут влиять на результат, нет линии - нет параметров.
И даже это упрощенный вариант..

Вероятно, в таких случаях имеет смысл создавать 2 подмножества. К примеру, проверяем Border без варианта NoLine, и со всеми параметрами, а потом параметр Fill с параметром Border = NoLine. Мне такое решение данной (конкретной) проблемы кажется наиболее рациональным.

Я проще делаю, ко множеству значений добавляю параметр NA и создаю правило типа
IF Border="No Line" then Dashed="NA" and BorderWidth="NA" итд
  • 0
Regards,
Alexey

#12 dlg99

dlg99

    Специалист

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

Отправлено 27 июля 2010 - 16:27

Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.


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

к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.


заметьте, я не говорил, что можно использовать не думая. ;)

иногда проще разбить на части. иногда удобнее описать модель/правила в коде - меньше ручной работы при изменении бизнес-логики.
все Вами описанное выливается в 1 строчку кода, которую будет проще понять, чем 2 независимых генератора тестов (из моего опыта, YMMV).

посмотрите на http://sourceforge.n...s/example2.2.py (из http://engineering.m.../allpairs.aspx) как на пример задания фильтра просто в коде.
в pict можно задать sub-models в дополнение к constraints.
все можно сделать 'спокойно' - сосредоточившись на том, *какие* тесты генерировать, а не на том *как* их генерировать.
  • 0
Andrey Yegorov. Изображение

#13 dlg99

dlg99

    Специалист

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

Отправлено 27 июля 2010 - 16:31

Я проще делаю, ко множеству значений добавляю параметр NA и создаю правило типа
IF Border="No Line" then Dashed="NA" and BorderWidth="NA" итд


я тоже ;)
только нужно еще в обратную сторону ограничить - если любое из Dashed/... =="NA", то остальные могут быть только "NA" и Border может быть только "no line".
  • 0
Andrey Yegorov. Изображение


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



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

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

Яндекс.Метрика
Реклама на портале