Какво е тестване на модули? Определение, примери

по: Томас Хамилтън Томас Хамилтън
Hours Обновено

⚡ Умно обобщение

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

  • 🎯 Обективен: Целта е да се разкрият грешки в модула, а не да се демонстрира, че модулът работи.
  • ⚪ Ориентация: Техниката е до голяма степен „бяла кутия“, допълнена от случаи „черна кутия“, извлечени от спецификацията.
  • ⏩ Паралелността: Няколко модула могат да бъдат тествани едновременно, което скъсява общия тестов прозорец.
  • 🔗 Два метода: Модулите се комбинират или инкрементално, стъпка по стъпка, или неинкрементално в един проход.
  • 🧰 скеле: Драйверите предоставят тестови данни на модул, докато stub-овете заместват модулите, които той извиква.
  • 🆚 Собственост: Тестерите пишат модулни тестове след кодирането, докато разработчиците пишат модулни тестове по време на кодирането.
  • ⚠️ предизвикателства: Неинкременталната работа, неразбраните дублирани тестове и честото дебъгване поглъщат по-голямата част от усилията.
Прочетете повече

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

Какво е тестване на модули?

Тестване на модули е вид софтуерно тестване, което проверява отделни подпрограми, подпрограми, класове или процедури в дадена програма. Вместо да се тества цялата софтуерна програма наведнъж, модулното тестване препоръчва тестване на по-малките градивни елементи на програмата.

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

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

Защо да правите модулно тестване

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

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

Как се прави модулно тестване?

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

  • Спецификация за модула
  • Изходният код на модула

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

След като тестовите случаи са проектирани, следващата стъпка е комбиниране на модулите за тестване. Използваният метод е или частичното или неинкрементален метод.

  • Неинкрементален метод — всички модули се тестват независимо. Първо се комбинират всички модули и след това се тества цялата програма.
  • Инкрементален метод — всеки модул се тества първо и след това постепенно се добавя към тестваната колекция. Извършва се поетапно повторно тестване.
  • В рамките на инкременталното тестване има два подхода, отгоре надолу намлява отдолу нагоре тестване.
  • За да се изпълни модулът с избраните данни, е необходим драйвер за предоставяне на тестовите данни, наблюдение на изпълнението и записване на резултатите.

Изборът между двата метода е компромис между усилията за настройка и диагностицируемостта.

Аспект Инкрементален метод Неинкрементален метод
Съчетание Един модул наведнъж, добавен към тествана колекция Всички модули са комбинирани, след което са тествани заедно
Необходимо е скеле Още драйвери и заглавия, написани постепенно По-малко дублирани тестове, тъй като са налични реални модули
Изолиране на грешки Силен — неуспехът сочи към току-що добавения модул Слаб — повреда може да възникне отвсякъде
Най-подходящ за Големи компилации с много взаимодействащи модули Малки програми с малко модули и ниска степен на свързване

СВЪРЗАНИ СТАТИИ

Драйвери и заглушки в тестването на модули

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

  • драйвер — замества извикващия модул над тествания. Той предоставя тестовите данни, извиква модула, следи изпълнението и записва резултатите. Тестването отдолу нагоре зависи от драйверите, защото по-ниските модули са готови преди по-високите.
  • коляно — замества извикан модул под тествания. Приема повикването и връща фиксиран, известен отговор, така че тестваният модул да може да завърши пътя си. Тестването отгоре надолу зависи от заключващи се модули (stubs), защото модулите от по-горен ред са готови първи.

Разработеният случай прави сдвояването конкретно. Ако модул за изчисляване на плащане е завършен, докато екранът за плащане, който го извиква, не е, шофьорът подава към модула набор от общи суми на поръчката и записва това, което се връща. Ако услугата за търсене на данъци, която модулът извиква, също е незавършена, съобщение връща фиксирана данъчна ставка, така че изчислението все още се изпълнява. Нито едно от двете части на скелето не се изпраща; и двете се изхвърлят, след като пристигнат истинските модули, поради което тестът за неразбиране на двойките е посочен по-късно като повтарящ се проблем.

Примерни съвети за тестване на модули

Ето няколко съвета, които трябва да имате предвид, преди да извършите тестване на модули.

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

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

Единично тестване срещу модулно тестване

Двата термина се използват взаимозаменяемо в много екипи, но авторството и обхватът им се различават.

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

Тестване на модули срещу тестване на компоненти срещу интеграционно тестване

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

Аспект Тестване на модули Тестване на компоненти Интеграционно тестване
Под тест Една подпрограма, клас или процедура Един самостоятелен компонент с неговите непосредствени зависимости Интерфейсите между комбинираните модули
Обичаен собственик Тестер, след като кодът е написан тестер Тестер за интеграция
скеле Драйвери и мъничета Мънички за външни зависимости Прогресивно по-малко дублирани тестове
Разкрит дефект Логическа грешка вътре в модула Грешка в поведението на компонента Грешка в интерфейса и предаването на данни

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

Предизвикателства при тестването на модула

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

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

Въпроси и Отговори

Семейството xUnit покрива повечето езици за програмиране, като библиотеките за подражание предоставят заключителните елементи (stubs) и инструмент за покритие, показващ кои пътища са били достигнати. Изборът следва езика на модула, а не нивото на тестване.

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

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

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

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

Следвайте съществуващия код. Кодът „отгоре надолу“ е подходящ за проекти, при които първо се пише управляващата логика, а по-долните модули се „заглушават“; кодът „отдолу нагоре“ е подходящ за проекти, при които първо се записват помощни модули и драйверите ги извикват.

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

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

Обобщете тази публикация с: