Home

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

Любой тест состоит из последовательности шагов и набора параметров, которые необходимы для выполнения теста. Так, для создания архива при помощи программы архиватора необходимо не только выбрать данные для архивации и инициировать создание архива, но и определиться с тем, какого типа данные архивируются и где они расположены. В этом примере выбор данных и создание архива будут являться шагами (сценарием), а тип данных и их расположение – параметрами. Один и тот же сценарий может выполняться с различными параметрами – в результате возникает закономерный вопрос, какие параметры и когда использовать. Сегодня мы рассмотрим одну из важных сторон этого вопроса: комбинирование параметров.

Тесты можно разделить на два типа:

1. На проверку одного параметра
2. На проверку взаимодействия нескольких (двух и более) параметров

Целью статьи является рассмотрение этих двух типов тестов, преимуществ и недостатков их использования друг перед другом. Они могут напомнить о видах тестирования, модульном и интеграционном, однако поскольку взаимодействие параметров возможно в рамках одного модуля (интеграционное тестирование подразумевает проверку взаимодействия между модулями), я предлагаю использовать иную терминологию: «простой» и «комбинаторный» тест.

Рассмотрим тесты этих двух типов на примере программы-архиватора. При создании архива участвует множество параметров, это как настройки самой программы, так и факторы внешней среды, такие как расположение архива на диске, типы архивируемых данных и пр. Представим часть из них (упростим пример) в виде таблицы:

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

В качестве примера простого и комбинаторного теста можем использовать:

1. Простой тест «Создание самораспаковывающегося архива»
2. Комбинаторный тест «Создание самораспаковывающегося архива с высокой степенью сжатия»

Так при каких же параметрах выполняется упомянутый тест? С одной стороны, на этапе бизнес-анализа у программы выявляются настройки “по умолчанию”. С другой - значения параметров внешней среды тоже могут быть назначены “по умолчанию”, исходя из представлений о “базовой операции” программы.

Представим, что мы сформулировали для себя эти значения (значения по-умолчанию выделены в таблице выше), тогда при виде названия теста “Создание самораспаковывающегося архива” мы четко знаем с какими характеристиками создается архив: какие настройки программы использовались, какого типа файлы и на каком носителе архивировались.

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

1. Нет, не станем – ведь целью этого теста было убедиться, что самораспаковывающийся архив в принципе может быть создан программой.
2. Да, станем – ведь соответствие степени сжатия может отличаться для самораспаковывающегося архива. В случае если мы проверили что средняя степень сжатия для «ручного» архива действительно средняя, это не гарантирует что для SFX будет так же.

Комплексным тест делают не только и не столько комбинации входных параметров, а то, какие проверки в нем выполняются

Зачем это надо

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

• собственного предыдущего опыта,
• имеющихся у него документации к системе и принципах ее работы,
• от архитекторов/разработчиков программы

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

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

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

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

Построение отчетности по комбинированным тестам

Отчетность о состоянии продукта может строиться по двум основным подходам:

1. Построение отчетности на основе багов: при формировании отчетности используются данные баг-трекера об имеющихся ошибках. Этот подход не накладывает на нас ограничений при проектировании тестов.
2. Построение отчетности на основе результатов прогонов тестов: при формировании отчетности используются данные о результатах прогона тестов. В этом случае от нас требуется информативность результатов прогонов тестов.

Почему без дополнительных мер, результаты прогона комплексных тестов будут не информативны? Потому что в случае если комбинировались независимые параметры, а тест прошел с ошибкой – глядя на результат прогона мы не сразу узнаем что именно привело к ошибке, какой из комбинируемых параметров «не работает».

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

Выводы:

Преимущества комбинирования входных параметров:

• Проверка рисков
• Уменьшение трудоемкости регрессионного тестирования

Недостатки комбинирования входных параметров:

• Возможные неудобства построения отчетности о состоянии продукта
• Необходимость выполнять «лишнее» тестирование при проверке отдельной функциональной части

И помните -- не стоит злоупотреблять комбинаторными тестами: слишком большое число параметров «не по умолчанию», неизбежно приведет к затрудненной локализации.

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