[БЕЗ_ЗВУКА] В
этом видео мы поговорим о тестировании и отладке решений заданий по
программированию в нашем курсе «Белый пояс по C++».
Сейчас мы в теории рассмотрим принципы, которые применяются для тестирования
и отладки, а в следующем видео рассмотрим их применение на конкретном примере.
Итак, наша цель научиться самостоятельно выбираться вот из таких ситуаций.
То есть вы написали решение заданий по программированию,
оно у вас компилируется, оно у вас работает, проходит на ваших тестах.
Но когда вы посылаете его в тестирующую систему, она его не принимает.
И мы с вами сейчас должны научиться, что делать в этом случае.
Самое главное — не надо отчаиваться, если тестирующая система говорит,
что в вашей программе ошибка, то она там почти наверняка есть.
И ваша задача — ее найти и исправить.
Поэтому что делать, если ваше решение не принимается тестирующей системой?
В первую очередь, нужно внимательно перечитать условие задачи.
Это нужно, чтобы убедиться, что вы действительно решаете правильную задачу,
что вы не упустили никакой важной детали в условии задачи.
Если же вы прочитали условие и видите, что все нормально, вы решаете ту задачу,
которую мы от вас требуем, то вторым шагом необходимо убедиться,
что программа корректно работает на примерах, которые даны в условии.
Ну потому что, если хотя бы один пример у вас отрабатывает неправильно, то ваше
решение наверняка неправильное и точно не будет принято тестирующей системой.
Кроме того, примеры являются частью условия задачи и демонстрируют
различные варианты входных данных, на которых ваше решение будет тестироваться.
При этом важно отметить, что примеры не покрывают все возможные ситуации,
которые могут быть во входных данных.
Поэтому то, что ваше решение проходит все примеры,
не гарантирует то, что оно абсолютно правильное.
Это просто лишний этап контроля.
Хорошо.
Теперь давайте представим, что наше решение
корректно работает на примерах, но не принимается тестирующей системой.
То есть вы его проверили на примерах, отправите в тестирующую систему,
а она вам говорит что-то вроде того, что вы видите на экране.
То есть она пишет, что ваше решение выдало неправильный ответ на в данном
случае десятом тесте из 16, и больше никакой полезной информации вам не дает.
Она не говорит, на каком входе ваше решение сломалось.
И я здесь хочу отметить, что это сделано намеренно,
то есть мы специально настроили тестирующую систему так,
чтобы она не показывала те тесты, на которых ваше решение падает.
Почему мы так сделали?
Мы хотим этим приблизить вас к реальным условиям.
Потому что в реальной практике очень часто бывает, что вы видите,
ваша программа работает неправильно.
Но у вас нет никакой информации о том,
почему, что является источником ее неправильного поведения,
на каких данных она ведет себя неправильно.
И вам, чтобы эту ошибку исправить,
нужно искать в первую очередь саму причину ошибки.
Вот мы таким образом, не сообщая вам тест,
на котором ваше решение падает, мотивируем вас также начать изучать свою программу,
отлаживать ее в поисках того места, где она написана неправильно.
И что же надо делать, когда тестирующая система не сообщает вам тест?
Вам необходимо перейти к тестированию своего кода.
То есть начать формировать какие-то тесты и проверять,
что ваша программа на этих тестах работает корректно.
При этом тестирование не надо выполнять хаотично,
то есть придумывать два-три каких-то примера,
запустить и убедиться, что ваша программа работает.
К этому вопросу нужно подойти фундаментально.
Когда вы переходите к тестированию своей задачи,
необходимо разработать план тестирования.
Как это делать?
Нужно проанализировать задачу, проанализировать ее условие и понять,
какие классы входных данных в этой задаче есть.
Когда мы это поняли,
мы формируем по одному тесту на каждый класс входных данных.
При этом обязательно нужно учесть крайние случае.
То есть, например, если вам на входе дан какой-то набор объектов,
например, набор строк, то нужно обязательно протестировать вашу программу,
проверить, как она ведет себя, когда набор строк пустой, то есть там нет строк,
или там всего одна строка.
Или другой пример, если сказано,
что на входе подается не более ста строк, то нужно обязательно проверить,
как ваша программа ведет себя, когда ей дано ровно сто строк.
Почему так надо делать?
Потому что очень часто ошибки возникают при обработке этих крайних случаев.
И когда вы, значит, сформулировали план тестирования, подготовили набор тестов,
то вы по одному тесту подаете на вход своей программе и проверяете,
что она на эти тесты выдает ожидаемые результаты.
При этом отправлять свое решение на проверку в тестирующую
систему стоит только тогда, когда оно прошло все тесты из вашего плана.
Ну, естественно, если хоть один тест она не прошла, то, скорее всего,
такой тест у нас тоже есть, и мы снова не примем ваше решение.
Поэтому если какой-то тест упал,
то надо начать выяснять причину и исправлять свою программу.
Сейчас мы все это обсудили достаточно абстрактно на таком теоретическом уровне.
А в следующем видео мы рассмотрим, как это делать на примере конкретной задачи.
Шишков Илья Ивановичкандидат технических наук
Полднев Антон Вячеславович
Парамонов Евгений Анатольевич
Лежанкин Иван Андреевич
