Тестируйте не числом, а умением
#1
Отправлено 22 июля 2010 - 05:21
Оригинал: Test Smarter, Not Harder
Эта статья о комбинаторных методах построения тестов первоначально была написана для developer.* в марте 2006 года. Недавняя статья на Dailytech обращает внимание на одно очень интересное исследование о новых методах генерации многомерных комбинаций (четверок и более), выполненное Лабораторией информационных технологий Национального института стандартов и технологий США (NIST, the National Institute of Standards and Technology). Данная переработанная и дополненная версия статьи учитывает эти результаты.
Введение
В первой части исследуется проблема обеспечения хорошего покрытия тестами входных данных сложного программного обеспечения. Во второй части обсуждаются подходы к решению этой проблемы (включая выявленные в исследовании NIST). В третьей части анализируются подходы к улучшению «лучшего» решения, описанного во второй части.
Мы поговорим о способах снижения цены, которую приходится платить за обеспечение высокого качества тестирования. Более конкретно, мы обсудим техники, удешевляющие создание и поддержку набора регрессионных тестов.
Мы начнем с обсуждения проблемы, а затем обсудим подходы к построению тестов, дающие все большую эффективность по более низкой цене. Надеемся, что вам понравится статья и будем рады услышать от вас отзывы и дополнения.
Читать дальше...
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#2
Отправлено 22 июля 2010 - 07:17
А использовали ли вы какие-нибудь способы для учета порядка ввода?
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#3
Отправлено 22 июля 2010 - 07:30
Доклад Александра Барановского на SQA-7 "Метод всех пар, или как не убиться тестируя комбинации"
Рассказ Марины Широчкиной на июльской встрече питерского клуба про "Domain-естирование" (вторая половина, начиная с 44-го слайда, посвящена комбинаторным методам)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#4
Отправлено 25 июля 2010 - 18:50
1. пары имеет смысл составлять, если существует зависимость параметров?
2. программа pict - а где искать?
3. а как получать при этом оракул?
Нельзя ли подробный пример на пальцах?
#6
Отправлено 27 июля 2010 - 01:44
Ткни пальцем - ты о чём?Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#7
Отправлено 27 июля 2010 - 06:45
Мы ищем N-mode дефекты в порядке ввода M элементов, поэтому, видимо, выбираем все возможные комбинации N элементов из M.Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!
Мне этот подход вообще показался странным. Если у нас есть просто набор параметров и их обработка в виде 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
Пример крайне упрощен, разумеется.
Автор же статьи, как я понимаю, "зависимостью" параметров называет ситуацию, когда определенная комбинация этих параметров вызывает дефект в коде приложения.
#8
Отправлено 27 июля 2010 - 10:11
Что происходит - и так видно. Вопрос в том, из чего следует второе предложение из цитаты статьи:Мы ищем N-mode дефекты в порядке ввода M элементов, поэтому, видимо, выбираем все возможные комбинации N элементов из M.Кстати, должен признаться, что в статье возможно есть ошибка -- я хоть убей не могу понять, почему дополнительный параметр, предназначенный для учета порядка ввода, должен принимать C(M,N) значений, а не N!
Другими словами, почему этот дополнительный параметр будет принимать именно столько значений.Мы можем учесть порядок действий, рассматривая его как дополнительный входной параметр. Он будет принимать столько значений, сколько существует подмножеств заданного размера N.
В общем случае у нас получается M!
В случае, если мы учитываем только порядок в парах получается N!
И у автора до представления, что мы используем порядок в качестве дополнительного параметра шла речь о порядке в этих группах по N элементов.
После же, судя по всему, он стал говорить о порядке следования этих групп. Отсюда и сочетание из M по N
#9
Отправлено 27 июля 2010 - 15:09
Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.
в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.
#10
Отправлено 27 июля 2010 - 15:31
к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.
в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.
Пример:
Мы тестируем некий графический редактор. С его помощью можно нарисовать прямоугольник с разными параметрами линий контура и параметрами заливки.
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. Мне такое решение данной (конкретной) проблемы кажется наиболее рациональным.
#11
Отправлено 27 июля 2010 - 15:55
Я проще делаю, ко множеству значений добавляю параметр NA и создаю правило типак сожалению, "спокойно" - нельзя. Если есть 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. Мне такое решение данной (конкретной) проблемы кажется наиболее рациональным.
IF Border="No Line" then Dashed="NA" and BorderWidth="NA" итд
Alexey
#12
Отправлено 27 июля 2010 - 16:27
к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.
в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.
заметьте, я не говорил, что можно использовать не думая. ;)
иногда проще разбить на части. иногда удобнее описать модель/правила в коде - меньше ручной работы при изменении бизнес-логики.
все Вами описанное выливается в 1 строчку кода, которую будет проще понять, чем 2 независимых генератора тестов (из моего опыта, YMMV).
посмотрите на http://sourceforge.n...s/example2.2.py (из http://engineering.m.../allpairs.aspx) как на пример задания фильтра просто в коде.
в pict можно задать sub-models в дополнение к constraints.
все можно сделать 'спокойно' - сосредоточившись на том, *какие* тесты генерировать, а не на том *как* их генерировать.
#13
Отправлено 27 июля 2010 - 16:31
Я проще делаю, ко множеству значений добавляю параметр NA и создаю правило типа
IF Border="No Line" then Dashed="NA" and BorderWidth="NA" итд
я тоже ;)
только нужно еще в обратную сторону ограничить - если любое из Dashed/... =="NA", то остальные могут быть только "NA" и Border может быть только "no line".
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных