Home

Автор: Александр Федоров

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

Описание метода

Представьте себе, что вам нужно протестировать систему с большим числом параметров, влияющих на её работу. Ярким примером такого рода может быть конфигурационное тестирование: например проверка работы системы под различными операционными системами или работа сайта в различных браузерах. Кто знает, какое сочетание параметров приведет к сбою? Каждый тестировщик знает, что все комбинации не проверить. К примеру, для проверки всех сочетаний 10 параметров с 10 значениями каждый, потребуется 10,000,000,000 тестов, в то время как метод перебора пар позволяет реализовать сравнимое по качеству тестирование (учитывая количество и критичность найденных в результате багов) используя всего 177 тестов.

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

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

Рассмотрим как происходит оптимизация. Возьмем для примера таблицу параметров и значений следующего вида:

Переберем значения первого параметра со вторым (строки №1-4), первого с третьим (строки №5-8) и второго с третьим (строки №9-12). Удалив повторяющиеся наборы параметров (выделены серым), получим следующую таблицу тестов:

Зеленым выделены уникальные пары всех параметров в таблице. Теперь начинается самое интересное, значения выделенные белым не являются необходимыми для перебора всех пар в таблице, поэтому могут быть заменены на любое другое значение. Поэтому заменив их, мы можем оптимизировать тесты, добавив проверку пар из 5, 6 и 7 строк во вторую и третью строки, получим:

Как видно из примера выше, оптимизация даже такого малого набора параметров не так проста как могло бы показаться. При этом сложность задачи возрастает пропорционально росту числа параметров. Однако эта задача решаема, в чем мы убедимся в последствии.

Применение

Как показывает опыт, метод эффективен лишь на поздних этапах разработки, либо дополненный основными функциональными тестами. Например, если вы проводите конфигурационное тестирование, то прежде чем использовать парное тестирование следует убедиться, что основной сценарий функционирует на всех операционных системах с параметрами по умолчанию (что-то типа BVT). Это значительно облегчит локализацию будущих багов, ведь при парном тестировании в одном тесте фигурирует множество параметров со значениями не по умолчанию, каждый из которых может стать причиной сбоя и его локализация в этом случае весьма затруднительна. А в случае провала BVT следует отказаться от использования метода парного тестирования, так как многие тесты будут провальными, а исключение даже одного теста влечет за собой потерю как правило нескольких пар и смысл использования метода теряется.

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

Для того чтобы воспользоваться методом необходимо выполнить несколько простых шагов:

1. Определиться с функциональностью, которую будем проверять

Как говаривал Козьма Прутков "Нельзя объять необъятное", поэтому прежде всего необходимо разделить функциональность на части: компоненты, функции, сценарии. Функциональность небольшой программы, например по записи дисков, упрощенно можно представить в виде всего двух сценариев: запись диска, стирание диска. Выбираем запись диска и переходим к следующему шагу.

2. Исследовать выбранный сценарий и выявить его параметры и их значения

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

Упрощенно, параметры и их значения при записи диска можно представить в виде:

Вы наверняка обратили внимание, что параметр «Скорость записи» имеет значения, недопустимые для “DVD”, как же быть?. У этой маленькой задачки, есть несколько вариантов решения, одно из которых – это разделить таблицу на две. Стоит учитывать, что на практике параметров в этом сценарии гораздо больше, и несостыковок, было бы значительно больше.

Итак, поделив таблицу по типу носителя получим:

CD

DVD

При выборе параметров и значений помните, что негативные тесты не стоит включать в таблицу – в одном тесте может проверяться несколько пар, а в случае негативного теста будет выполнена проверка лишь одного параметра, в результате некоторые пары могут остаться непроверенными. По этой причине в нашем примере отсутствуют значения объёма данных, равные нулю и превышающие объем диска. Если мы их добавим, то в результате использования метода можем получить кейс в котором на нулевом объёме данных будет проверяться к примеру пара Файловой системы ISO и начала мультисесии. В результате, успешно убедившись в корректной обработке попытки записи пустого диска, мы упустим проверку пары ISO-начать мультисесию.

На этом этапе важно следовать поговорке: семь раз отмерь, один отрежь. Ведь если после создания тестов обнаружится что вы упустили какой-либо параметр или его значение, и вы захотите инкрементально дополнить тестовое покрытие – количество тестов увеличиться несопоставимо больше, доле упущенных параметров. Забегая вперед скажу, что для нашего примера с записью DVD методом перебора пар мы получим 17 тестов. Решив дополнить исходную таблицу всего одним значением, например скоростью записи DVD 32х, мы увеличим общее число тестов на 8, так как в стремление сохранить целостность метода будем вынуждены перебирать это значение со всеми значениями других параметров. Целесообразно дополнить тестовое покрытие одним-двумя тестами на проверку нового значения составленными вручную, либо заново создать таблицу, как это описано в следующем шаге.

3. Применить алгоритм, составляющий оптимальное число тестов с полным перебором пар.

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

В результате, взяв таблицу с параметрами для DVD, получим перечень тестов:

«~» означает что вместо указанного значения может быть использовано любое, так как оно не составляет пары в данном тесте.

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

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

В приложении к статье вы найдете составлению мною инструкцию к программе.

Итого

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

Остается только попробовать!

Инструкция по использованию Allpairs.

В качестве входных данных для программы используется .txt файл с таблицей параметров, столбцы которой разделены табуляцией. Для создания такого файла удобнее всего использовать MS Excel – там есть возможность сохранять “текстовые файлы с разделителями табуляции (*.txt)”.

Имея исходный файл, необходимо запустить консоль и набрать там строку вида:

C:\allpairs.exe C:\so.txt > C:\re.txt

Где:

• C:\allpairs.exe - полный путь к приложению allpairs.exe
• C:\so.txt – путь к исходному файлу с таблицей параметров
• C:\re.txt - путь и имя файла, который будет создан в результате работы программы

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

Pairings – количество уникальных пар в тест-кейсе

Pairing details – перечень всех пар всех параметров

Appearances – количество раз, сколько та или иная пара фигурирует в кейcах

Cases – номера кейcов, где фигурирует данная пара

Сайт разработчика: http://www.satisfice.com/tools.shtml

Обсудить в форуме