Универсальный закон жизни ― увеличение точности в 10 раз требует увеличения стоимости в 100 раз. Это верно для микроскопов, верно для телескопов, для чего угодно, в частности ― для тестирования.
Однажды в одну светлую голову пришла мысль ― а зачем тестировать всё на 100%, если можно срезать углы, оттестировать на 98% и потратить на порядок меньше ресурсов. Это был день рождения метода попарного тестирования, пусть никто и не знает, когда он наступил.
Зато известны более формальные даты рождения метода.
Во-первых, всеобъемлющее исследование ортогонального массива на основе тестирования электронной почтовой системы было опубликовано AT и T в 1992 году. Оно гласит, что проверка комбинаций пар входных значений из 422 тест-кейсов обнаружила на 28% дефектов больше, чем оригинальный план разработки из 1 000 тест-кейсов, и заняла на 50% меньше ресурсов.
Во-вторых, в 2002 году Ричард Кун и Майкл Рейли проанализировали отчёты об ошибках из браузера и веб-сервера с открытым исходным кодом и пришли к выводу, что с помощью определённых комбинаций значений в тест-кейсах можно было бы покрыть более 95% изучаемых ошибок, и особой разницы между браузером и сервером для этого подхода нет.
И в-третьих, Долорес Уоллес и уже известный нам Ричард Кун опубликовали исследование, проведенное Национальным институтом стандартов и технологий над ошибками ПО в отозванных медицинских устройствах, собиравшимися на протяжении 15 лет, в котором пришли к выводу, что 98% дефектов могли быть обнаружены с помощью проверки комбинаций пар входных значений.
Если подытожить, от 90 до 98% ошибок возникают при конфликте именно пар входных данных или неверной интерпретации одного входного параметра системой, что тоже покрывается парами входных значений. И получается, что ошибки, источником которых является комбинация трёх и более конкретных входных параметров, составляют всего 2–10%. Отсюда вытекают логичный вывод и метод попарного тестирования.
Метод попарного тестирования хорош ещё и тем, что он ― метод чёрного ящика. Если вдруг вы не знаете, что это такое, то не очень понятно, зачем вы это всё читаете, но на всякий случай: метод чёрного ящика подразумевает, что вы не знаете, как система устроена внутри. Это чёрный ящик ― кладёте туда что-то, вытаскиваете обратно, смотрите на результат.
Есть методы белого ящика, где нужно знать, как всё работает, ну а тут нам достаточно тестов накидать и всё проверить.
Вообще, относительно популярных алгоритмов попарного тестирования два:
- алгоритм, основанный на построении ортогональных массивов,
- алгоритм всех пар, или all-pairs.
Разница между ними заключается в том, что ортогональный никто не использует. Точнее, его используют, только область применения довольно узкая ― его сравнивают с алгоритмом всех пар, потому что иначе сравнивать его было бы не с чем. Иными словами, его можно смело проигнорировать, что мы и сделаем. Желающие узнать о нём поподробнее могут ознакомиться с научно-популярным циклом «Ортогональная вселенная» Грега Игана, где в свойственной для автора лёгкой манере понятным языком объясняются интересные математические концепции.
А вот алгоритм всех пар нужно хотя бы разок разобрать вручную. Хотя можно конечно не заморачиваться тем, как это всё работает, и просто копипастить данные туда-сюда из специальных сервисов. В конце концов, миллионы людей работают именно так и даже получают за это зарплату. Но если мы хотим немного подняться над уровнем мартышки, пытающейся настучать Шекспира, или разработчиком, оперирующим копипастой со стэковерфлоу (что в принципе одно и то же), то придётся немного задуматься.
Итак, допустим, у нас есть входные данные, как на картинке.
Нам важны поля «Отправитель», «Мобильный телефон», «Информация об отправлениях», «Количество получателей», «Количество мест», «Контрагент» и «Доп. информация», они и будут нашими параметрами, записываем их в таблицу.
Следующий шаг: определить значения для этих параметров. Для этого полезно использовать эквивалентные классы и граничные значения или варианты использования, чтобы урезать количество значений для каждого параметра.
В нашем случае для параметра «Отправитель» у нас выбор из пользователей, я их разделил на два значения, когда пользователь является заявителем (авторизованным пользователем) и когда не является заявителем. В итоге получаем «Заявитель» и «Не Заявитель».
Идем дальше, параметр «Мобильный телефон» разделяем на два значения: либо поле заполнено, либо не заполнено. Для простоты напишем «Присутствует» и «Отсутствует».
- «Информация об отправлениях» ― «Есть файл» или «Нет файла»;
- «Количество получателей» ― «1», «3» или «Все»;
- «Количество мест» ― «1» или «10»;
- «Контрагент» ― «КСЕ» или «ДЧЛ»;
- «Доп. Информация» ― «Есть» или «Нету».
В итоге должна получиться вот такая таблица. Это таблица входных данных.
Итого: семь параметров, шесть по 2 значения, один ― 3. Всего 192 возможные комбинации. Чтобы не проверять все 192, всё и затевается. Следите за руками.
Второй шаг: отсортировать по убыванию количества значений. В количестве получателей у нас значений 3, в остальных ― 2, сортируем примерно так.
И третий шаг: вручную или специальным инструментом составляем таблицу с парными комбинациями.
Итак, теорию мы изучили, входные данные мы подготовили, дело за малым — собственно всё сделать. Как? Об этом ― в следующей серии.