Pairwise тестирование. Почему, зачем и как?

[REDkiy]

Pytest вполне умеет декартово произведение. Да и в целом вымучивать из себя промты когда задача имеет математическое решение токое себе.

Не совсем понятно что делать если часть полей обязательные, а часть нет. В целом статья бесполезная.

[nesterovaas]

Спасибо за комментарий!

Pytest с parametrize умеет декартово произведение, но это полный перебор, а pairwise как раз нужен, чтобы от него уйти: в примерах я как раз это и разобрала. Если нужны попарные наборы прямо в коде, можно сгенерировать их, например, через PICT и передать в parametrize.

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

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

[REDkiy]

Был рад увидеть ваш комментарий. После отправки своего комментария, я решил было, что занимаюсь некромантией.

Не вижу никаких проблем в полном переборе, pairwise будет просто подмножеством и всё. Потом потребуется 3wise, 4wise и тп. Так что смысл уходить от этого по факту теряется. Сложности будут если поля взаимоисключающие, но тут скорее вопрос почему вообще возникла эта ситуация? В крайнем случае можно сделать немного грязно, если взаимоисключающие поля есть, то сделать список исключений для этих пар полей и просто в тесте его пропускать, а сам список отдать в другой тест, чтобы этот список исключений мучить там.

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

На самом деле тестировщик я довольно своеобразный, я применяю TDD и это сказывается на подходах к тестированию.

[nesterovaas]

Спасибо за интерес к теме:)

В автотестах с TDD полный перебор обычно оправдан: кейсы дешёвые и быстрые. Pairwise нужен, когда каждый кейс дорогой (ручное тестирование, UI, e2e) или параметров много: например, 10 параметров по 5 значений - это почти 10 миллионов комбинаций. Насчёт 3wise, 4wise и тп.: в том же PICT это задаётся параметром. В любом случае решение о покрытии стоит принимать исходя из рисков, иногда pairwise будет достаточно и полный перебор излишен.

А идея со словарём для обязательных полей интересная, возьму на заметку)

[REDkiy]

Не совсем согласен, в реальности у нас происходит сильное уменьшение объёмов тестирования, разделение тестов да и просто включение логики - что имеет смысл тестировать.

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

Ещё ситуация которая эту историю сильно разгружает - обязательные поля. Хоть одно обязательное поле есть всегда, чаще их от 3 до 5. То есть фактически мы уменьшаемся по количеству комбинаций на десятки процентов. И всё это вместе даёт по моему опыту 300-1500 позитивных комбинаций, плюс штук 20-30 тестов на негативные истории.

Если честно, то я считаю, что ручное тестирование, которое дублирует автоматизацию это скорее поражение, так как стремятся тестировать руками всё подряд вместо тщательного контроля того, что недоступно автоматизации. Например при выборе правильного интерфейса тестирования, мы можем процентов на 99 закрыть автоматизацией тестирование API, но тестировщики руками упорно продолжают слать строки в целочисленные поля. Или ещё хуже тестируют руками бекенд через фронтенд. И как итог вместо того, чтобы добавить к автоматизации кейсы ручного тестирования, задачи дублируются. На самом деле тут причина не в том, что специалисты тестирования тупые, а в том, что системы очень часто не проектируются под возможность тестирования. И яркое этому подтверждение появление такой позиции как SDET. Так как приходится ещё и в разработке шарить, чтобы создать дополнительную нашлёпку, чтобы автотесты вобще возможны были.