Ръководство за начинаещи за тестване: Грешка при обработка на казуси

Когато създавате сложни софтуерни парчета, независимо от езика, започвате да забелязвате модел в навиците си за тестване. Едни и същи подобни проблеми ще възникнат при различните платформи или проекти. Независимо дали създавате друга проста демонстрация със списък със задачи за разговор или създавате изчерпателен back-end за стартиране на PaaS, започват да се появяват същите общи модели.

Има шест случая, които трябва да бъдат тествани, които ще осветят изненадващ брой проблеми. Те не са предназначени да бъдат изчерпателни или пълен собствен набор от тестове. По-скоро те са лесна за запомняне подгрупа от общи парадигми за тестване, които могат да се прилагат за всеки език, рамка или среда.

Тези случаи са незабавно полезни в два аспекта на ежедневните програми за кодиране: отстраняване на грешки при възникване на специфични проблеми и при създаването на тестовия пакет за кодова база. Те са предназначени да бъдат общи, абстрактни форми на тестване, които ще осветят някои от най-често срещаните проблеми, пред които са изправени младите разработчици.

Те ще бъдат полезни само по заобиколен начин при функционално програмиране. Функционалното програмиране заобикаля много от най-простите видове грешки, описани по-долу. Така или иначе е полезно да се имат предвид тези видове абстрактни гранични случаи, тъй като те осигуряват предпазна ограда срещу лоши практики в кода.

Шестте теста са както следва:

  • Нула
  • Едно
  • Две
  • Две до макс-1
  • макс
  • макс. + 1

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

Нула

Нула се използва за означаване на всякаква форма на нулево въвеждане, независимо дали това е недефинирано, нулево, празен масив или просто действителното число 0. Може би най-често срещаната и проста форма на грешка е препращането към нулева стойност и тя винаги е подложена на тестване. Просто тествайте функция, крайна точка или качете с нулев вход и проверете дали тя се държи според очакванията.

Едно

Един, като Zero, е най-основната форма на генерирания единичен тест. Функцията се тества с първия валиден, нормален вход. Това е най-полезно за регресионно тестване. При бъдещи повторения на кода този тест бързо ще покаже дали програмата (или процесът) работи както се очаква.

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

Две

Две не е просто за тестване на индекс на масив 2 или за това дали вашият алгоритъм работи с 2 входа. Той също така обхваща това, което се случва, когато стартирате един и същ код два пъти.

Ако някой направи заявка DELETE HTTP два пъти подред към един и същ ресурс, какво се случва? Ако функцията за сортиране с персонализиран компаратор бъде извикана два пъти подред, поведе ли се според очакванията?

Две е интересно число, защото за първи път валидният код, който работи, когато се извика веднъж, може да покаже странични ефекти при многократно изпълнение. Направете малка промяна на функциите, които сме тествали по-горе.

Това се свежда до модификации на състоянието и разбиране на поведението на дадена функция. Ако всичко, което имаме, е името на функцията, тогава този код се държи точно както се очаква. Имате променлива, наречена 0, извиквате функцията setVarToOne и след това твърдите, че тя е равна на единица.

На пръв поглед това се държеше точно както се очакваше. Тестването му с идеята за две обаче ще открои по-дълбоки проблеми с кода. Ще го тествате, като го извикате два пъти и твърдите, че и в двата случая mVar е равен на 1.

Две до макс-1

Две до max-1 е проверката на здравословното състояние. Той е много подобен на теста One, но има фина разлика. Това би трябвало да е средностатистически случай - не най-простият или ясен или най-лесният за четене. Просто средностатистически случай, който може би не е особено прост, но това е доста често .

Макс

Max е доста ясен: той просто тества границите на вашето приложение, особено около дефинирани максимални константи.

Ако имате проста реализация на свързан списък, може да си представите, че имате привидно безкраен брой разрешени вмъквания. В действителност има горна граница - независимо дали това е INT_MAX, броят на файловите дескриптори, които вашата операционна система може да има, или просто количеството памет или дисково пространство, разпределено за вашата програма.

При някои обстоятелства Макс може да изглежда като невъзможен тест, тъй като не е известен макс за каквото и да тествате. Целта в тези случаи обаче е от друго естество: да се тества стрес за вашата кандидатура.

Например възможно е дадена част от подадените от потребителя данни да се намали и да премине през функции, докато достигне цикъл, който сте дефинирали. Ако тези данни са, да речем, INT_MAX, може да отнеме пренебрежимо малко време, за да завърши вашият код. По-лошо, това може да хвърли кода ви в състояние, което не спира. Това могат да бъдат фини проблеми, които възникват едва след като кодът ви влезе в производство, така че е важно да ги хванете по време на фазата на тестване.

Макс + 1

Max + 1 е тест, който се използва най-вече за проверка на стандартите или правилата, въведени от програмиста. Това включва тестване на каквото и да е до теоретичната граница + епсилон.

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

Ако имате максимален размер на файла за качване от 2mb, опитайте да качите файл с размер 2mb + 1b. Ако имате ограничение за броя на записите в потребителски каталог, уверете се, че проверката се извършва както от страна на клиента, така и отсървърна страна.

Заключение

Както бе споменато по-горе, това не е пълна картина на това какви трябва да бъдат вашите рутинни процедури за отстраняване на грешки или тестване. Това просто осигурява солидна, обща базова линия, която трябва да надхвърли всеки специфичен пакет за тестване или рамка.

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