Руководство по тестированию для новичков: обработка крайних случаев ошибок

При создании сложных программных продуктов, независимо от языка, вы начинаете замечать закономерность в своих привычках тестирования. Одни и те же похожие проблемы будут возникать на разных платформах или в разных проектах. Независимо от того, создаете ли вы еще одну простую демонстрацию списка дел для выступления или проектируете комплексную серверную часть для стартапа PaaS, начинают появляться одни и те же общие шаблоны.

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

Эти случаи сразу же полезны в двух аспектах ежедневных процедур кодирования: для отладки конкретных проблем по мере их возникновения и для создания набора тестирования для базы кода. Они задуманы как общие абстрактные формы тестирования, которые проливают свет на некоторые из наиболее распространенных проблем, с которыми сталкиваются молодые разработчики.

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

Шесть тестов заключаются в следующем:

  • Нуль
  • Один
  • Два
  • От двух до макс-1
  • Максимум
  • макс + 1

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

Нуль

Ноль используется для обозначения любой формы нулевого ввода, будь то неопределенный, нулевой, пустой массив или просто фактическое число 0. Вероятно, наиболее распространенной и простой формой ошибки является ссылка на нулевое значение, и она всегда требует тестирования. Просто протестируйте функцию, конечную точку или загрузку с нулевым входом и убедитесь, что они работают должным образом.

Один

Единица, как и Ноль, является самой базовой формой обобщенного одиночного теста. Функция тестируется с первым действительным нормальным вводом. Это наиболее полезно для регрессионного тестирования. В будущих итерациях кода этот тест быстро покажет, работает ли программа (или процесс) должным образом.

Одно тестирование дает вам основу для успеха, будь то успешная аутентификация в конечной точке администратора, допустимая загрузка файла или правильная модификация массива.

Два

Два - это не просто проверка индекса массива 2 или того, работает ли ваш алгоритм с двумя входами. Это также касается того, что происходит, когда вы запускаете один и тот же код дважды.

Что произойдет, если кто-то дважды подряд отправит HTTP-запрос DELETE к одному и тому же ресурсу? Если функция сортировки с настраиваемым компаратором вызывается дважды подряд, ведет ли она себя должным образом?

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

Все сводится к модификации состояния и пониманию поведения функции. Если все, что у нас есть, это имя функции, то этот код ведет себя именно так, как ожидалось. У вас есть переменная с именем 0, вы вызываете функцию setVarToOne, а затем утверждаете, что она равна единице.

На первый взгляд, все произошло именно так, как ожидалось. Однако его тестирование с учетом идеи «Два» выявит более глубокие проблемы с кодом. Вы бы протестировали его, вызвав его дважды и заявив, что в обоих случаях mVar равно 1.

От двух до макс-1

Два до макс-1 - это проверка работоспособности. Он очень похож на тест One, но есть небольшая разница. Это должен быть средний вариант использования - не самый простой, понятный или легкий для чтения. Просто средний вариант использования, который, возможно, не особенно прост, но довольно распространен .

Максимум

Max довольно прост: он просто проверяет пределы вашего приложения, особенно в отношении определенных максимальных констант.

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

При некоторых обстоятельствах Макс может показаться невозможным испытанием, потому что нет известного максимума для того, что вы тестируете. Однако в этих случаях цель другого характера: провести стресс-тестирование вашего приложения.

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

Макс + 1

Max + 1 - это тест, который в основном используется для проверки стандартов или правил, установленных программистом. Это включает в себя тестирование чего-либо до теоретического предела + эпсилон.

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

Если у вас максимальный размер загружаемого файла 2 МБ, попробуйте загрузить файл размером 2 МБ + 1 МБ. Если у вас есть ограничение на количество записей в каталоге пользователей, убедитесь, что проверка выполняется как на стороне клиента, так и на стороне клиента.на стороне сервера.

Вывод

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

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