Как быть в ситуации, когда необходимо не просто протестировать продукт, а продукт с множеством взаимосвязанных входных данных? Здесь нам на помощь опять приходит тест-дизайн.
Сегодня мы поговорим об еще одной технике составления тестов — техника попарного тестирования (не путать с парным тестированием) или, как ее еще называют, Pairwise testing.
Эта техника используется, когда нам необходимо комбинировать очень много различный вариантов входных данных. Цель ее состоит в том, чтобы сократить количество полученных тестов, но при этом сохранить качественное покрытие.
По традиции приведу определение из ISTQB:
Попарное тестирование (pairwise testing) — разработка тестов методом черного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Ее стоит использовать в том случае, когда входные данные связаны друг с другом. Точнее результат выполнения теста напрямую зависит от того, какие комбинации данных будут подаваться на входе.
Рассмотрим очень простой пример. Предположим, у нас есть форма с полями “Логин”, “Пароль” и кнопкой “Войти”.
Каждое поле может принимать два значения: пустое и заполненное. В обычной ситуации, когда результат работы формы не зависит от того, какие именно комбинации полей подаются на вход, нам достаточно провести всего три теста
Т.е. мы в наших тестах проверяем отдельно работу каждого поля, не задумываясь о том, что различные комбинации Логина/Пароля могут сломать систему. Но что, если у нас добавляется еще и зависимость полей? Тогда нам необходимо рассмотреть все возможные комбинации значений между полей. Для нашего примера это означает, что добавится еще один тест.
На первый взгляд выглядит достаточно просто, добавился всего один тест. Но давайте посмотрим на более реальном примере.
Опять же, даже здесь немного упростим проверку и выделим только самые базовые значения.
Таким образом общее количество тестов будет следующим: 2*2*2*2*2*2 = 64
Даже сейчас это большая цифра. Такое тестирование будет малоэффективным и потребует большое количество ресурсов. Вот здесь на помощь приходит техника попарного тестирования, которая позволяет сократить количество тестов во много раз.
Суть ее состоит в том, что мы берем только комбинации пар каждых значений, вместо комбинаций всех значений:
Вручную комбинировать каждую пару нет необходимости. Существуют программы, которые позволяют это сделать автоматически, достаточно только указать параметры и значения. Например, PICT, либо онлайн генераторы https://pairwise.teremokgames.com и т.д.
В нашем случае, после комбинации тестов с помощью попарного тестирования мы сократили количество проверок до 4-х
В каждом тесте мы проверяем сразу несколько пар комбинаций: E-mail — Никнейм, Никнейм — Пароль, Условия — Символы, E-mail — Пароль и т.д.
***
Подведем итог. Если мы столкнулись с тестированием механики, которая предусматривает различные комбинации входных данных, то в сокращении числа тестов нам как раз и поможет техника попарного тестирования.
И не забывайте пользоваться программами, которые избавят вас от ручного комбинирования.
Миф о комбинаторике в тестировании
Время на прочтение
8 мин
Количество просмотров 5.4K
Неважно, какие методологии, процессы, языки и фреймворки вы используете. В любом тестировании программного обеспечения всегда присутствует тест-дизайн, сужающий генеральную совокупность всех возможных проверок до какой-то реалистичной выборки. Тест-дизайн можно разбить на несколько уровней сложности, и где-то в середине пути мы встретимся с комбинацией данных в элементах системы. Но не везде упоминают, что используемая в тестировании комбинаторика очень ограничена в применении, об этом мы и поговорим в статье. С примерами!
Что есть комбинаторное тестирование
Комбинаторное тестирование — это метод тестирования программного обеспечения, который позволяет эффективно обнаруживать ошибки, связанные со взаимодействием параметров. Самый популярный вариант — попарное тестирование (pairwise). Pairwise основан на принципе, который гласит, что 98% всех ошибок возникают в результате влияния одного или двух параметров. Попарное тестирование позволяет исследовать все возможные комбинации значений для каждой пары параметров, что обеспечивает более широкое покрытие тестирования, чем тестирование каждого параметра в отдельности. Это позволяет обнаружить большинство ошибок в программном обеспечении и снизить количество дефектов, которые могут возникнуть в процессе эксплуатации программы. Для попарного тестирования используются алгоритмы, основанные на построении ортогональных массивов или на all-pairs алгоритме, которые опираются на теоретические исследования в области комбинаторных алгоритмов, алгоритмов дискретной математики и, в частности, латинских квадратов.
Как зародился миф
Вся эта уверенность основана на исследовании IEEE [1] и [2], в которых авторы анализировали выявленные ошибки в медицинских устройствах на основе их описания. В ходе исследования авторы рассмотрели 109 из 342 ошибок с достаточным уровнем детализации, чтобы определить необходимый уровень тестирования для выявления ошибки. А вот уже из этих 109 хорошо описанных дефектов только 3 требовали больше двух условий для проявления. Но нестыковка тут в том, что никто не анализировал сами входные параметры на связность, а рассматривали только входные данные без анализа выходных данных. Если мы будем смотреть на «правильный» выходной параметр, вывод может быть совсем иным. Этот выходной параметр может быть связан со входными параметрами, а нам необходимо тестировать пары входных параметров с парами выходных параметров: не связанных вообще, либо слабо связанных с входными. Но мы этого не знаем, ведь перед нами черный ящик.
А как все на самом деле
В конце 80-х годов для фармацевтической отрасли была написана система анализа DMAS (Data Management Analysis System). Приложение изначально написали на FORTRAN, а в 90-х годах переписали на C++ для использования в академической среде в проектах исследований и программной инженерии. DMAS использовалась химиками-аналитиками для обработки файлов данных, собранных из экспериментов с использованием жидкостной и газовой хроматографии. Всего в программе можно комбинировать 18 различных входных переменных. В исследовании [3] эту программу использовали для оценки влияния количества входных переменных на выходные параметры и результат можно видеть на рисунке ниже:
График показывает, что в промышленных и сложных системах с высокой вариативностью все самое интересное находится при комбинации 3 и более переменных. Ричард Кун в [2] и более поздних работах использует диаграмму зависимости суммарной доли ошибок в разных типах программного обеспечения, откуда видно, что для многих случаев 1-2 факторов недостаточно. И чем сложнее система, тем меньше ошибок может быть найдено попарным тестированием.
Сложность, как правило, означает и высокую цену ошибки. В исследовании [4] на примере проекта NASA более точно подсчитали, что для 3 и более факторов доля всех ошибок может составлять уже 50%. А 50% это не 98%, как в каноне.
Эффективность любого тестирования можно оценивать только на реальных данных с применением как альтернативных, так и разных комбинаторных техник. И проблема заключается в том, что данных мало и они всегда относятся к черному ящику. Недостаточно информации о характеристиках тестируемых систем, о профессионализме тестировщиков, о серьезности дефектов и требованиях, на основе которых их посчитали таковыми. Без знания о системе, без оценки сложности и трудоемкости тестирования нам остается сравнивать комбинаторные техники только со случайными выборками.
При комбинации 2 параметров уже после 10-40 попарных тестов на малых наборах данных покрытие случайной выборкой составляет в среднем 95% [5]. А при 160 попарных тестах с большими наборами данных эквивалентный набор случайных тестов оказывается всего на 30% больше [6]. К такому же выводу пришел и Джеймс Бах в [7], по сути назвав попарное тестирование «псевдоисчерпывающим». Из чего можно сделать вывод, что само количество комбинаций или тестовых наборов не является определяющим при выборе попарного тестирования. Бах явно указывает на это:
-
Попарное тестирование может обнаруживать некоторые ошибки при существенном сокращении числа тестов, по сравнению с тестированием всех возможных комбинаций, но не обязательно по сравнению с тестированием только тех комбинаций, которые имеют значение;
-
Попарные ошибки могут представлять собой большинство комбинаторных ошибок, а могут и не представлять, в зависимости от фактических зависимостей между переменными в продукте;
-
Некоторые попарные ошибки менее вероятны, чем те, которые происходят только при участии большего числа переменных, потому что входные данные не распределены случайно.
Как все-таки пользоваться комбинаторикой
Но если мы хотим комбинировать в тестах больше двух параметров, ситуация сильно меняется. Результаты экспериментов по сравнению адаптивного случайного и жадного комбинаторного тестирования в исследовании [8] для обнаружения ошибок в логике управления распределенной системы управления ядерной энергетикой показали:
-
Если количество наборов тестов относительно небольшое, то эффективность обнаружения ошибок при адаптивном случайном тестировании и жадном комбинаторном тестировании очень близка, хотя адаптивное случайное тестирование имеет преимущество;
-
При постепенном увеличении количества наборов тестов эффективность обнаружения ошибок при жадном комбинаторном тестировании улучшается;
-
Если тестовых ресурсов достаточно, эффективность обнаружения ошибок при жадном комбинаторном тестировании выше.
На этом графике показана разница значений F-меры между адаптивным случайным тестированием и комбинаторным тестированием со стратегией пошагового увеличения силы (числа параметров, которые могут взаимодействовать друг с другом) в системе предупреждения о трафике и избежания столкновений. F-мера (F-measure) — это метрика, которая используется в оценке качества алгоритмов классификации и информационного поиска. F-мера является гармоническим средним точности (precision) и полноты (recall).
Следовательно, выбор техники тестирования зависит преимущественно от наличия тестовых ресурсов:
-
Когда ресурсы для тестирования строго ограничены, и мы можем выполнить не все тест-кейсы, следует выбирать адаптивное случайное тестирование. Поскольку эффективность выявления ошибок у двух техник при небольшом количестве тест-кейсов сопоставима, а реализация адаптивного случайного тестирования проще;
-
Когда ресурсы для тестирования ограничены меньше и есть возможность использовать много тест-кейсов, мы выбираем технику комбинаторного тестирования, потому что эффективность обнаружения ошибок при большом количестве тест-кейсов оказывается выше.
Также можно использовать гибридную стратегию тестирования. Сначала используется техника адаптивного случайного тестирования для создания тестового набора, в котором количество тест-кейсов не превышает размера двухпараметрического тестового набора. Затем эти тест-кейсы используются для генерации комбинаторных тест-кейсов более высокого порядка до тех пор, пока тестовые ресурсы не будут исчерпаны. Стратегия тестирования, объединяющая сразу две техники, может улучшить эффективность обнаружения ошибок всего процесса тестирования.
И это возвращает нас к началу. Например, откуда мы знаем, связаны ли между собой все параметры или нет? Можно ли объединить какие-то параметры? Никакая комбинаторика не поможет, если мы забудем учесть неочевидные параметры, вроде сетевого соединения, настроек окружения или истории событий в качестве входных параметров функций. Более того, чтобы учесть все параметры, на которые мы можем повлиять, мы должны сначала исследовать программу и ее окружение. Так мы и приходим к исследовательскому тестированию. Иначе получится именно то, что и наблюдаем в жизни: программа вроде как протестирована, но ломается в неочевидных местах. А ведь существуют также и такие параметры, на которые повлиять сложно или вовсе невозможно.
С подобными ситуациями я неоднократно сталкивался в своей работе. У нас есть сервисы с довольно сложной логикой и внешними интеграциями. Особенность тестирования внешних интеграций заключается в том, что начинается как будто с белого ящика, но после хождения по граблям становится очевидно, что цвет ящика на самом деле был серым, а иногда и вовсе — черным. В одном из таких проектов, мы использовали API рекламной сети, и на первый взгляд там присутствовало множество параметров, которые можно было скомбинировать. Но в реальности все дефекты, как критичные, так и просто повлиявшие на time-to-market, оказались в такой плоскости, которую в простые тест-кейсы не поместишь. Вот некоторые из них:
-
Невозможность проверить все комбинации в dev-окружении. Возможности песочниц сильно ограничивают вариативность сложных переменных, а в проде мы уже ограничены общим ресурсом тестирования;
-
Нестабильность и непредсказуемость внешней системы обесценивает результат скриптового тестирования;
-
Юридические или персональные данные могут отдельно валидироваться внешней системой;
-
Многие технические детали отсутствуют в документации, а выяснение их через живых людей значительно увеличивает сроки и меняет любой предварительно созданный тестовый набор.
Заключение
Таким образом, комбинаторное тестирование может дать ожидаемый эффект только при комбинации трех и более независимых параметров в условиях избытка тестовых ресурсов, а попарное тестирование и вовсе неэффективно. В качестве итога я изобразил возможности применения комбинаторных техник в виде квадрантов в зависимости от сложности системы, количества возможных тестов и проверяемых в них комбинаций.
I квадрант. Сложная система, много параметров и тестов. Можно использовать n-way комбинаторику, если полно времени. Сначала придется анализировать и исследовать продукт, осознанно подбирать параметры, осознанно конфигурировать тесты. Скорее всего, количество тестов здесь будет обусловлено высокой вариативностью, можно использовать комбинаторику в качестве фильтра для более изысканных тестов. Но не рассчитывайте на высокую эффективность, вы все равно упустите какие-то параметры.
II квадрант. Простая система, много параметров и тестов. Кажется, что комбинаторика тут будет на своем месте. Только зачем? Если система такая простая, то и цена ошибки невелика, случайные или атомарные тесты могут оказаться проще и дешевле, чем 2-way. Если работаете с белым ящиком, то вы знаете о системе достаточно для использования более эффективных техник тест-дизайна В противном случае мы возвращаемся в I квадрант. Попробуйте автоматизировать все, что получится, а комбинаторные тесты можно использовать как фильтр.
III квадрант. Сложный продукт, мало параметров и тестов. Комбинаторика не сильно нужна, но ее можно использовать для дымового или приемочного тестирования. Вероятно, атомарные тесты будут удобнее.
IV квадрант.Простой продукт, мало параметров и тестов. Комбинаторику не используем.
В заключении напомню, что любая техника тест-дизайна может быть применима, но комбинаторика по сравнению с альтернативами имеет крайне узкую область применимости
Источники
-
Dolores R. Wallace, Richard Kuhn. Failure modes in medical device software: an analysis of 15 years of recall data // International Journal of Reliability Quality and Safety Engineering, 2001.
-
D. Richard Kuhn, Dolores R. Wallace, Albert M. Gallo Jr. Software Fault Interactions and Implications for Software Testing // IEEE Transactions on Software Engineering, 2004.
-
Patrick J. Schroeder, Pankaj Bolaki, Vijayram Gopu. Comparing the Fault Detection Effectiveness of N-way and Random Test Suites // International Symposium on Empirical Software Engineering, 2004.
-
B. Smith, M. S. Feather, and N. Muscettola. Challenges and Methods in Testing the Remote Agent Planner. // Proc. 5th Int’l Conf. on Artificial Intelligence Planning and Scheduling (AIPS 2000), 2000, pp. 254-263.
-
Siddhartha R. Dalal, Colin L. Mallows. Factor-Covering Designs for Testing Software, 1998.
-
Lee J. White. Regression Testing of GUI Event Interactions, 1996
-
James Bach, Patrick J. Schroeder. Pairwise Testing: A Best Practice That Isn’t, 2006.
-
Cheng Zong, Yanliang Zhang, Yao Yongming… A Comparison of Fault Detection Efficiency Between Adaptive Random Testing and Greedy Combinatorial Testing for Control Logics in Nuclear Industrial Distributed Control Systems // IEEE Access, 2017.
При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.
Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».
QA моделирует набор тестовых случаев (тест-кейсов), чтобы проверить, как приложение ведет себя в разных условиях. Задача специалиста – найти баланс и выявить максимальное количество ошибок при необходимом минимуме тестовых сценариев. При этом нужно проверить все наиболее важные кейсы, поскольку время тестирования ограничено.
Типы тестирования
Статическое тестирование, как следует из названия, не требует запускать программу или приложение и позволяет находить самые очевидные ошибки еще на ранних этапах создания продукта. Например, частью статического тестирования является проверка параметров ПО на соответствие требованиям технического задания, вычитка кода.
Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы:
-
Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе.
-
Техники черного ящика позволяют проверять работу продукта, не зная внутреннего устройства системы. При этом тестирование проводится на основе требований, указанных в спецификации проекта или в ТЗ.
-
Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду.
Этапы тестирования
1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски.
2. Непосредственно тестирование. Предварительно специалисты анализируют собранную ранее информацию, составляют список тестируемых функций, знакомятся с уже известными багами, если они есть, пишут тест-кейсы.
Еще раз подчеркнем: принципиально важно стремиться к минимально возможному числу тестов, при этом необходимо, чтобы сценарии находили наибольшее число высокоприоритетных дефектов.
3. Анализ результатов и составление отчетов.
При работе над созданием тестов QA-специалист ориентируется не только на документацию, но и на устные сведения от других QA, аналитиков, разработчиков, менеджеров проекта.
Техники тест-дизайна на примерах
Рассмотрим несколько основных методик, однако, будем помнить, что зачастую их используют в комплексе. Одной техники может быть недостаточно, поскольку она не обеспечит максимальный охват тестовых сценариев.
Эквивалентное разбиение
Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным.
Например, мы тестируем функциональность приложения, позволяющего покупать авиа- и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся ко льготным категориям.
У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.
QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.
Граничные значения
Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.
Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.
Таблица принятия решений
Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом.
Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.
Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.
Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.
Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.
Пример таблицы принятия решений
Попарное тестирование
Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев.
Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.
Pairwise testing: пример
Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:
| № | Браузер | Операционная система | Язык |
| 1 | Opera | Windows | RU |
| 2 | Google Chrome | Linux | RU |
| 3 | Opera | Linux | EN |
| 4 | Google Chrome | Windows | EN |
При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех.
Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.
Пример содержимого файла для программы PICT:
Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG
Пример попарного тестирования
Причина и следствие
Простая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта.
Примерный алгоритм использования техники:
1. Выделяем причины и следствия в спецификациях.
2. Связываем причины и следствия.
3. Учитываем «невозможные» сочетания причин и следствий.
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
5. Расставляем приоритеты.
Эта техника помогает:
-
Определить минимальное количество тестов для нахождения максимума ошибок.
-
Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ.
-
Найти возможные недочеты в логике описания приложения (что, в свою очередь, поможет улучшить документацию).
Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.
Предугадывание ошибок
Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.
Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:
- Что произойдет, если не ввести код?
- Что произойдет, если не ввести спецсимволы?
- Что произойдет, если ввести не цифры, а другие символы?
- Что произойдет, если ввести не четыре цифры, а другое количество?
Преимущества:
1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”.
Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами.
Итоги
Разумеется, этот список далеко не полон и дает только самое общее представление о принципах тестирования и техниках тест-дизайна. Например, исчерпывающее тестирование, покрывающее все возможные сценарии и обнаруживающее все ошибки, существует только в теории. Это связано с тем, что проверка всех параметров и состояний займет слишком много времени. Однако, чем опытнее QA-специалист, тем лучших результатов он может добиться, и для этого важно уметь правильно подбирать и комбинировать техники.
Понравилась статья?
Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.
Попарное тестирование (pairwise testing) — это метод тестирования программного обеспечения, который используется для уменьшения количества тестовых сценариев с минимальным вмешательством в качество. Представьте себе, что у нас есть несколько взаимодействующих функций или параметров, и мы хотим проверить их взаимодействие. Следовательно, pairwise тестирование состоит в проверке всех возможных комбинаций значений двух параметров одновременно.
Применяя pairwise тестирование, мы упрощаем процесс тестирования и уменьшаем количество тестовых сценариев, что обеспечивает быстрое тестирование без значительного влияния на качество. Далее мы рассмотрим пример pairwise тестирования.
Pairwise тестирование против тройного и более сложных комбинаций
При выборе метода тестирования важно понимать, почему именно попарное тестирование так популярно и почему другие методы, как, например, тройное или более сложные комбинации, не применяются так широко.
Эффективность попарного тестирования
Одно из основных преимуществ pairwise тестирования заключается в его эффективности. Согласно исследованиям, большинство ошибок в программном обеспечении обычно находятся в пределах взаимодействия двух компонентов. То есть, pairwise тестирование позволяет выявить значительное количество ошибок, используя меньшее количество тестовых случаев, по сравнению с более сложными комбинациями.
Экономия времени и ресурсов
Попарное тестирование значительно экономит время и ресурсы, так как количество тестовых случаев уменьшается по сравнению с тройными или более сложными комбинациями. Чем больше параметров включается в тестирование, тем больше тестовых случаев необходимо создать и выполнить. В результате увеличения количества комбинаций возрастает время и затраты на тестирование.
Соотношение стоимости и качества
Применение попарного тестирования обеспечивает оптимальное соотношение стоимости и качества. Это означает, что использование попарного тестирования позволяет достигнуть высокого уровня качества программного обеспечения с меньшими затратами по сравнению с другими методами.
Меньшая сложность тестирования
При попарном тестировании создание и анализ тестовых сценариев является менее сложным, чем при использовании тройного или более сложных комбинаций. Тестировщики могут быстрее разработать и оценить тестовые случаи, упрощая процесс тестирования. Более того, это позволяет сосредоточиться на взаимодействии между компонентами, где вероятность нахождения ошибок наивысшая.
Потрійне та більш складні комбінації можуть бути застосовані в окремих випадках, коли вимоги до якості програмного забезпечення є дуже високими, або коли досвід показує, що значна кількість помилок знаходиться в межах взаємодії трьох та більше компонентів. Однак, в загальному випадку, попарне тестування вважається найефективнішим методом тестування, який забезпечує оптимальне співвідношення вартості та якості програмного забезпечення.
Примеры попарного тестирования
Давайте на прикладах розберемо, як ми можемо використовувати попарне тестування.
Пример №1. Веб-приложение для заказа еды
Допустим, у нас есть веб-приложение для заказа еды, которое предлагает разные варианты для пользователя. Эти варианты включают:
- Тип кухни (украинская, итальянская, японская).
- Способ доставки (курьер, самовывоз).
- Оплата (наличными, картой).
Всего у нас есть 12 возможных комбинаций, которые могут возникнуть при взаимодействии этих параметров. Однако применение попарного тестирования позволяет уменьшить количество тестовых случаев без потери качества проверки.
Сначала создадим таблицу попарных комбинаций:
| Тип кухни | Способ доставки | Способ оплаты |
| Украинская | Курьер | Наличкой |
| Украинская | Самовывоз | Картой |
| Итальянская | Курьер | Картой |
| Итальянская | Самовывоз | Наличкой |
| Японская | Курьер | Наличкой |
| Японская | Самовывоз | Картой |
Применение попарного тестирования позволяет уменьшить количество тестовых случаев с 12 до 6, но при этом достаточно эффективно проверяет взаимодействие параметров. Это позволяет сэкономить время и ресурсы на проведение тестирования, а также упрощает анализ полученных результатов.
Пример №2. Тестирование мобильного приложения видеозвязи
Рассмотрим пример мобильного приложения для видеозвязи, которое имеет следующие настройки:
- Разрешение видео (720p, 1080p, 4K).
- Степень сжатия (высокая, средняя, низкая).
- Звук (включен, выключен).
Учитывая эти параметры, мы имеем 18 возможных комбинаций. Однако применение попарного тестирования позволяет уменьшить количество тестовых случаев, не утрачивая качество проверки.
Создадим таблицу попарных комбинаций:
| Разрешение | Степень сжатия | Звук |
| 720p | Высокая | Включен |
| 720p | Средняя | Выключен |
| 720p | Низкая | Включен |
| 1080p | Высокая | Выключен |
| 1080p | Средняя | Включен |
| 1080p | Низкая | Включен |
| 4K | Высокая | Включен |
| 4K | Средняя | Включен |
| 4K | Низкая | Выключен |
Применение парного тестирования сократило количество тестовых случаев с 18 до 9, обеспечив эффективную проверку взаимодействия параметров. Это позволяет сэкономить время и ресурсы на проведение тестирования, а также упрощает анализ полученных результатов.
Алгоритм тестирования: выбор правильной стратегии
При применении парного тестирования важно выбрать правильный алгоритм тестирования, который будет генерировать тестовые сценарии. Существует несколько алгоритмов, которые могут быть использованы, такие как ортогональные массивы и графовые алгоритмы.
Ортогональные массивы генерируют тестовые сценарии, которые оптимально покрывают пространство параметров, гарантируя высокое качество тестирования с минимальным количеством тестов. Ин-тайференс является эвристическим подходом, который генерирует тестовые сценарии на основе набора входных данных. Графовые алгоритмы, в частности алгоритм А*, используются для решения задачи генерации тестовых сценариев на основе графовых моделей.
Недостатки парного тестирования: все имеет свою цену
Парное тестирование, хоть и эффективное в большинстве ситуаций, имеет некоторые недостатки. Во-первых, этот метод не подходит для тестирования взаимодействия более чем двух параметров. Это может привести к тому, что некоторые ошибки не будут обнаружены.
Во-вторых, парное тестирование может быть неэффективным для тестирования систем с большим количеством параметров. В таких случаях может потребоваться использование других методов, таких как тестирование с покрытием утверждений или мутационное тестирование.
Инструменты для попарного тестирования: выбираем лучшее
Существует много инструментов, которые помогут вам применять попарное тестирование в вашем проекте. Некоторые из них включают:
- Pict — бесплатный инструмент от Microsoft, который позволяет генерировать тестовые сценарии на основе модели ввода, заданной пользователем. Pict поддерживает различные алгоритмы тестирования и имеет удобный синтаксис для описания модели.
- AllPairs — другой бесплатный инструмент для попарного тестирования, который работает с текстовыми файлами и генерирует комбинации входных данных для тестирования.
- Hexawise — коммерческий инструмент для попарного тестирования, который предлагает широкий спектр функций, включая генерацию тестовых сценариев, визуализацию результатов тестирования и интеграцию с системами управления испытаниями.
- ACTS — инструмент от NIST (Национальный институт стандартов и технологий США), который помогает генерировать попарные тестовые сценарии и поддерживает расширенные методы тестирования, такие как n-кратное тестирование.
Подводя итоги: стоит ли использовать попарное тестирование?
Попарное тестирование является эффективным методом тестирования программного обеспечения, который позволяет уменьшить количество тестовых сценариев без потери качества. Этот метод подходит для тестирования взаимодействия двух параметров и может быть использован в различных областях, от веб-приложений до систем реального времени.
Однако попарное тестирование имеет некоторые недостатки, которые стоит учитывать. Оно не подходит для тестирования взаимодействия более чем двух параметров.
Научиться всем методам и нюансам тестирования вы сможете на наших курсах QA.
Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером
Техники тест-дизайна
—
Рабочий процесс тестировщика
В этом уроке мы рассмотрим следующие темы:
- Тест-дизайн
- Техники тест-дизайна
- Классы эквивалентности
- Граничные значения
- Попарное тестирование
- Таблица принятия решений
- Диаграмма состояний и переходов
- Тестирование вариантов использования
- Доменное тестирование
Тест-дизайн
Определить весь процесс тестирования приложения – задача сложная даже для опытного тестировщика. В этом вопросе не существует четких правил, которые подскажут, как тестировать, какие тесты выполнять и в каких ситуациях. Чтобы справиться с этой неопределенностью, тестировщики придумали множество приемов, которые помогают решать эти вопросы и дают подсказки, помогающие направить тестирование в правильное русло и сократить сроки тестирования.
Тест-дизайн – это этап тестирования ПО. На нем проектируются и создаются тест-кейсы, которые будут соответствовать определенным заранее критериям качества и целям тестирования. Цель тест-дизайна — создать наборы тестовых случаев, обеспечивающих оптимальное тестовое покрытие.
Разработка тестов начинается после проведения исследования ПО, когда цели определены, а критерии тестирования заданы и выполняются.
Техники тест-дизайна
Техники тест-дизайна помогают:
- Исключить непродуктивные тест-кейсы и сократить общее количество кейсов
- Покрыть тестами как можно больше функциональности
- Провести все тесты и не пропустить ничего важного
Для работы с кодом (white-box) важны такие аспекты:
- Покрытие операторов
- Покрытие условий
- Покрытие путей
- Покрытие функций
- Покрытие вход/выход
- Покрытие значений параметров
В работе с требованиями (black-box) тестирование проходит иначе:
- Классы эквивалентности
- Граничные значения
- Попарное тестирование
- Таблица принятия решений
- Диаграмма состояний и переходов
- Тестирование вариантов использования
- Доменное тестирование.
Техники тест-дизайна на основании требований
Классы эквивалентности
Техника классов эквивалентности – это разделение диапазона возможных вводимых значений на группы эквивалентных по своему влиянию на систему. Эта техника помогает не только сокращать количество тестов, но и сохранять приемлемое тестовое покрытие.
Рассмотрим для примера перевод денег в банке. Размер комиссии зависит от суммы перевода:
- от 1 до 999 долларов включительно – 0%
- от 1000 до 4999 долларов включительно – 5%
- от 5000 долларов – 7%
Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются.
Попробуем выяснить, сколько требований будет в этом случае. В этом помогут классы эквивалентности:
- 1-999 => ожидаем комиссию 0%
- 1000-4999 => ожидаем комиссию 5%
- 5000-100000 => ожидаем комиссию 7%
Выбранные значения для проверки: 500, 2500, 7500.
- На значение 500 система отреагирует так же, как и на любое другое значение из первого диапазона
- На значение 2500 система отреагирует так же, как и на любое другое значение из второго диапазона
- На значение 7500 система отреагирует так же, как и на любое другое значение из третьего диапазона
Граничные значения
Граничные значения – это значения, в которых один класс эквивалентности переходит в другой. По своей сути это техника, которая дополняет технику классов эквивалентности.
Важно проверять граничные значения, потому что именно на границах чаще всего допускаются ошибки при написании кода и формулировании требований.
Например, неопытный программист при постановке «не больше 1000» может поставить значение <1000.
Вернемся к примеру с комиссией:
- от 1 до 999 долларов включительно – 0%
- от 1000 до 4999 долларов включительно – 5%
- от 5000 долларов – 7%
Максимальная сумма перевода – 100000 долларов, при этом дробные числа не учитываются. Вспомним классы эквивалентности:
- 1-999 => ожидаем комиссию 0%
- 1000-4999 => ожидаем комиссию 5%
- 5000-100000 => ожидаем комиссию 7%
Граничные значения: 1, 999, 1000, 4999, 5000, 100000.
С учетом классов эквивалентности и граничных значений выбираем значения для проверки:
1, 500, 999, 1000, 2500, 4999, 5000, 7500, 100000.
Попарное тестирование (pairwise)
Попарное тестирование – техника тест-дизайна, при которой тест-кейсы создаются так, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Достаточно проверить комбинации пар входных параметров, потому что ошибки чаще всего находятся именно на перекрестке двух параметров. Исключения бывают, но они достаточно редкие.
Рассмотрим пример. Возьмем наушники с такими характеристиками:
- Тип подключения (беспроводной или проводной)
- Микрофон (включен или выключен)
- Подсветка (включена или выключена)
Полный перебор даст нам восемь тест-кейсов. Это 2 в третьей степени, потому что у каждого из трех параметров может быть всего два значения:
| # | Тип подключения | Микрофон | Подсветка |
|---|---|---|---|
| 1 | Проводной | Включен | Включена |
| 2 | Проводной | Включен | Выключена |
| 3 | Проводной | Выключен | Включена |
| 4 | Проводной | Выключен | Выключена |
| 5 | Беспроводной | Включен | Включена |
| 6 | Беспроводной | Включен | Выключена |
| 7 | Беспроводной | Выключен | Включена |
| 8 | Беспроводной | Выключен | Выключена |
Как правило, подобных характеристик в реальном мире куда больше, что неизбежно увеличивает количество тест-кейсов.
При попарном тестировании достаточно проверить лишь пары значений. При успешном выполнении тестов на 97% мы можем быть уверены, что проверяемая функциональность работает корректно.
- 1 нет, нет, нет -> нет, нет, нет -> нет, нет, нет (00, 00, 00)
- 2 да, да, нет ->да, да, нет -> да, да, нет (11, 10, 10)
- 3 нет, да, да -> нет, да, да -> нет, да, да (01, 11, 01)
- 4 да, нет, да -> да, нет, да -> да, нет, да (10, 01, 11)
При трех параметрах, каждый из которых имеет 3 значения, количество вариантов полного перебора – 27 (три в третьей)
Применив pairwise, количество тест-кейсов сведётся к 9.
| # | Тип подключения | Микрофон | Подсветка |
|---|---|---|---|
| 1 | Беспроводной | Выключен | Выключена |
| 2 | Проводной | Включен | Выключена |
| 3 | Беспроводной | Включен | Включена |
| 4 | Проводной | Выключен | Включена |
Таблица принятия решений
Таблица решений или матрица решений — способ компактного представления модели со сложной логикой; инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте.
Это взаимосвязь между множеством условий и действий.
Таблица принятия решений содержит следующие элементы:
- Условия — список возможных условий
- Варианты — комбинация из выполнения и/или невыполнения условий этого списка
- Действия — список возможных действий (вариантов исхода)
Например, кредит выдаётся людям, удовлетворяющим трём условиям:
- Возраст: 18-60 лет
- Гражданство: Россия
- Стаж работы: более 5 лет ИЛИ средняя месячная зарплата за год больше 100 тысяч рублей
| Условие | Значение 1 | Значение 2 | Значение 3 | Значение 4 |
|---|---|---|---|---|
| Возраст 18-60 | да | да | да | нет |
| Гражданство РФ | да | да | да | да |
| Стаж больше 5 лет | да | нет | да | да |
| ЗП выше 100 тысяч рублей | нет | да | да | да |
| Действие | ||||
| Кредит одобрен | да | да | да | нет |
Диаграмма состояний и переходов
Таблица переходов представляет собой все возможные комбинации начальных и конечных состояний. Она включает в себя действительные и недействительные переходы, инициирующие события, защитные условия и результирующие действия.
Диаграммы состояний и переходов показывают только действительные переходы и исключают недействительные переходы.
Состояние А ——переход—–> Состояние Б
Тестирование вариантов использования
Тестирование вариантов использования определяется как метод тестирования программного обеспечения, который помогает идентифицировать тестовые случаи, охватывающие всю систему, от транзакции к транзакции от начала до конечной точки.
Вариант использования или юз-кейс – это описание конкретного использования системы субъектом или пользователем
Юз-кейсы содержат следующие сведения:
- Кто использует сайт или приложение
- Что пользователь хочет сделать
- Какие шаги делает пользователь, чтобы совершить определенное действие
- Как сайт или приложение реагируют на действия пользователя
Доменное тестирование
Доменное тестирование (domain analysis) — методика разработки тестов, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно.
Доменное тестирование применяется для сокращения количества проводимых тестов без потери качества тестирования.
Очень часто классы эквивалентности, относящиеся к позитивным проверкам, можно проверять совместно.
Возьмем для примера такие требования:
- Размер файла: до 200 МБ
- Имя файла: от 5 до 24 символов, только латиница
- Форматы файлов: только изображения
В этом случае нужны такие проверки:
- Загрузить файл менее 200 МБ
- Загрузить файл с именем hexlet
- Загрузить файл с расширением .jpg
Можно заменить одной проверкой:
- Загрузить файл менее 200 МБ, с именем hexlet.jpg
Обратите внимание, что с негативными проверками так делать нельзя. При этом некоторые негативные проверки также можно исключать за счет несовместимости значений двух параметров.