Сегодня поговорим о такой тематике, как тестирование вычислительного ПО.
Нет, речь пойдет не про задачу «протестировать калькулятор», которую часто задают на собеседовании на позицию Manual QA.
Вспоминать ряды Фурье мы сегодня тоже не будем.
Порассуждаем в общем. О подходах.
1. Тестирование методом черного ящика.
Тут вроде бы все понятно.
Мы не знаем ничего о том, какие алгоритмы заложены в основу нашего продукта.
Всё, что мы можем, — задать на вход какие-то значения, — и получить что-то на выходе.
Далее — результат сравнить с какими то известными нам данными или просто удостовериться, что результат получен.
Проблема: трудности диагностирования и выявления ошибок
Например,
мы знаем, что мы можем ввести на вход числа «2» и «3».
Должны получить на выходе «5».?
А что, если мы получили значение на выходе «5.000000000000001»?
Значит ли это, что программа выполнена верно?
Если присутствует ошибка, то какая — ошибка округления, ошибка вычисления, ошибка алгоритма?
2. Тестирование методом белого ящика.
Мы ничего не боимся, — даже посмотреть исходные коды.
Мы нашли модули вычисления.
Здесь мы можем проверить, на сколько корректно выполняются циклы, выполнены ли все условия,
как обрабатываются нули, нет ли прямого деления на ноль, нет ли в коде ошибок округления или отбрасывания дробной части.
Кстати, хороший сервис для поиска области определения и граничных значений различных функций и выражений — https://www.wolframalpha.com/
Проблема сузилась, но остается прежней.
Получив на выходе «5.000000000000001», мы сможем разве что отсечь ошибки округления.
Правильны ли вычисления и сам алгоритм, — уверенно сказать мы не можем.
3. Прототипирование.
На данном этапе мы поняли, что для понимания того, какой результат мы должны получить на выходе, мы должны понимать суть алгоритма.Для достоверного тестирования мы должны иметь точную таблицу соответствий исходных и получаемых значений, что в условиях реального мира практически невозможно ввиду
огромного количества вариаций.
Да и сами исходные данные могут быть гораздо сложнее тех, что мы представили в примере. Это могут быть таблицы, списки координат, матрицы, сложноструктурированные xml файлы, выгрузки из БД и т.д.
Поэтому мы возможно попробуем где-то воспроизвести необходимые вычисления.
Тем саым мы вплотную подошли к этапу имитационного моделирования.
4. Имитационное моделирование, эксперимент.
Если мы знаем, как построен алгоритм, мы можем попытаться воспроизвести его отдельно, без инфраструктуры всего приложения или языка программирования.
Часто для данных целей используют Python в связи с его возможностями из библиотек и удобством для разработки.
Далее подадим поток данных, аналогичный потоку основного прилоежния, и сравним результаты на выходе. Часто анализ результатов позволяет выявить не только дефекты реализации, но и логики алгоритма.
Подход применим не только для софтверных продуктов, но также и любых другх сложных систем.
Какой бы метод или совокпуность методов вы ни выбрали для тестирования своих вычислительных алгоритмов, всегда следует помнить о том, что ожидаемый результат должен быть макисмально понятен и точен, любое противоречие даже в тысячных долях процента или числа может стоить кому-то миллиардов.
