Lead QA Engineer в Intellias
  • Автоматическая генерация тестов: подходы и инструменты

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

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

  • Автоматическая генерация тестов: подходы и инструменты

    Алгоритм, безусловно, не один. Pairwise — не алгоритм, а то, что хочется получить, результат. Способов его достижения, т.е. алгоритмов, которые позволяют получить такой результат, более одного. Потому и сравнивают их эффективность. Вот, например, pairwise algorithm challenge.

  • Автоматическая генерация тестов: подходы и инструменты

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

  • Автоматическая генерация тестов: подходы и инструменты

    В том-то и проблема, что посчитать количество вариантов, конечно же, дело нехитрое, как и получить их все. Только очень затратное по времени, о чем и писала выше. Неважно, какие именно инструменты тут применять. Вы действительно будете сначала применять полный перебор, а потом вычёркивать лишнее при тестировании корректности пароля? Количество всех возможных вариантов при ограничении в 7-15 символов и, скажем 100 разрешенных — 100^7 + 100^8 + ... + 100^15 — очень большое число. Легко автоматизировать полный перебор, вот только выполнение кода займет безумное количество времени.

    На счёт полных таблиц принятия решений. Конечно, если воспринимать технику — лишь как способ получения всех возможных комбинаций параметров, так можно делать. Имхо, правда, комбинаторные техники и инструменты подходят для этого лучше: тот же PICT, как и многие другие, позволяет строить тесты на основании любых комбинаций параметров, не только каждый с каждым. Можно все со всеми сделать, задав это требование в модели. Но все же, как мне кажется, decision table — в первую очередь про правила взаимодействия параметров и результаты, а не про полный перебор. Техника весьма полезна для систем принятия решений, рекомендательных систем. Тысячи параметров с десятками значений, десятки тысяч правил, сотни результатов. Не обошлась бы без нее на таком размере модели, в классическом контексте — правил. А сложность полного перебора — слишком, чудовищно велика здесь.

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

    И немного запуталась: Вы предлагаете в конце получить-таки все комбинации и потом их анализировать (

    Следующим будет анализ полученных данных, а затем шаг № 3 — их упорядочивание.

    ), а в середине, что

    Я говорил не о том, что надо все-все варианты выявить а затем посвятить сто жизней их проверке.

    Каково же Ваше решение, когда количество комбинаций настолько велико, что получать их все же нецелесообразно, как в примерах выше? Возможно, не понимаю определение «правильно сделанной комбинаторики», которую Вы упоминаете выше. Что значит — правильная? Вы упоминаете инструменты, которые применяете для этой цели. Не могли бы Вы описать алгоритмы их работы? Это, думаю, хорошо объяснит идею правильности комбинаторики.

  • Автоматическая генерация тестов: подходы и инструменты

    Именно этому и удивлялась выше, в случае, где достаточно 21 теста. ) Полагаю, алгоритм PICT избыточен.

    Формулу же легко проверить, это и попыталась сделать примером с 10 параметрами выше.

  • Автоматическая генерация тестов: подходы и инструменты

    1122
    1212
    2121
    1212
    2121
    1212
    2121
    1212
    2121
    1212

    Примерно так? Каждый тест — отдельная колонка, каждая строка — соответствующий параметр, 1 и 2 — бинарные значения (просто так, вместо нолика )).
    Тогда, 1 первого параметра встречается с 1 второго параметра в тесте номер один, а с 2 второго параметра — в тесте номер два. Аналогично, 1 первого параметра встречается с 1 третьего параметра в тесте номер два, с 2 — в тесте номер один. И т.п.

    Тест в данном случае представляет собой не пару, а десятку значений, поскольку в Вашем условии десять бинарных параметров. Таким образом, получим 4 теста (каждый из которых — десять бинарных значений), где встречаются все пары значений для всех возможных пар параметров.

    Возможно, неверно поняла задачу? Речь не о pairwise, а о полном комбинаторном покрытии? В этом случае, конечно же, 4 теста будет недостаточно, полный перебор можно получить за 2^10 (1024) теста.

  • Автоматическая генерация тестов: подходы и инструменты

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

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

    Что касается decision tables, насколько мне известно, для их создания нужны известные (из требований или доменных знаний, другого тест-дизайна, пр.) зависимости между параметрами, в этом, собственно, и состоит их идея. Потому мне кажется неоправданным применять их для поиска «неопределенных» комбинаций. Сфера применения техники другая.

    Что же касается полной комбинаторики, т.е. всех возможных комбинаций, и стоимости такого тестирования, очень легко проиллюстрировать сложность применения этого подхода для мало-мальски большой модели на примере оценки сложности задачи подбора пароля (и несостоятельности brute force в инструментах по подбору паролей).

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

  • Автоматическая генерация тестов: подходы и инструменты

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

  • Автоматическая генерация тестов: подходы и инструменты

    Pairwise и decision table, как по мне, имеют достаточно разную сферу применения (поиск зависимостей, которых быть не должно, и подтверждение зависимостей, которые должны иметь место).

    Логика тестирования именно пар основана на предположении, что ошибка возникает на стыке двух, но не более, значений. Почему так — достаточно просто объяснить, даже тимлид справится. ;) Ошибки в целом распределены нормально, т.е. согласно т.н. bell curve (тут, например есть картинка). Картинку можно интепретировать так: пик кривой (если по оси 0Х принять модуль количества одновременно заданных значений, вызывающих ошибку, а по оси 0Y — количество собственно ошибок) приходится, конечно, на один параметр (т.е. ошибки, которые находятся классами эквивалентности и граничными значениями — техниками, рассматривающими каждый параметр по отдельности). Следовательно, на стыке двух значений возникает предположительно меньше ошибок, на стыке трех — еще меньше, и т.п. Если на график добавить кривую роста количества тестов при усилении комбинаторной модели (т.е. учитывать не пары, а тройки, четверки и т.п.), легко увидеть, что целесообразность делать тесты резко падает: слишком большая разница будет между количеством тестов (экспоненциальный рост) и количеством предположительно найденных ошибок. Что и делает тестирование на больше чем парах параметров неоправданно дорогостоящим (по времени и ресурсам, даже с учетом автоматизации как создания, так и прохождения тестов). Насколько я знакома с комбинаторикой, именно эта идея и лежит в основе pariwise. Ну, и еще одно простое соображение: для ошибок на стыке нескольких значений нужно написать больше кода, чем для конкретного одного значения. )

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

    Извиняюсь за длинную телегу в ответ на простой и, возможно, риторический вопрос

    Но в чëм смысл тестировать Chrome ru android и НЕ тестировать Chrome en win?

    , а также перед теми, для кого все вышенаписанное — откровения кэпа (сдерживать графоманию иногда трудно ;)).

  • Автоматическая генерация тестов: подходы и инструменты

    О. Круто и внезапно. Спасибо за наблюдение! Интересно, почему в первый раз 22 теста, достаточно, конечно же, 21 для этой модели.

  • Автоматическая генерация тестов: подходы и инструменты

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

  • Автоматическая генерация тестов: подходы и инструменты

    Тоже. ) Реализаций довольно много разных. Под разные ЯП в том числе.