видове изпитване (видове тестове)

видове изпитване (Видове изпитване)

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

Единичните тестове. Тяхната задача - да се тества един модул логика в пълна изолация - както от околната среда и от другите модули. При това не трябва да бъде един клас, може да е тяхната малка агломерация - например, в случай на един основен клас и няколко помощни пакети-частно класове.
С цел да се отдели тест модул (SUT, система под тест) от други модули (DOC, зависима-на клас) и от външната среда, обикновено се притекат на помощ на макет рамки, които заместват всичко останало на манекен Dummy (библиотека списък може да бъде намерено в долната). Например, ако имаме анализатора HTML страници, не е нужно той да се качи на един истински сайт, изтеглете страница и да даде, ние може да спести някъде тази страница, за да се тества и непрекъснато се използва по време на тестването. В този случай, в класа на достъп до външни ресурси Мока и връща желаното съдържание, когато поиска SUT.
Защо те са важни? Тъй като те могат да тестват всичко - всяко условие в класа, като всеки цикъл на всеки метод. Тези тестове обикновено са най-много.
Има един вид класификация, описан в XUnit тестови структури (кратко обяснение може да се намери в блога Фаулър). Моето лично мнение - тези имена са засмукани от пръст и да ги използвате, не е необходимо. Терминология в тестването и толкова объркан, а след това се появяват Dummy, Fake, Мок, които са твърде близо в семантичен смисъл да ги разглеждаме сериозно като средство за комуникация. И нивото на единица тестване, и така твърде ниска, за Moki трябваше да бъде разделен на видове. В моята практика, тези условия са необходими само по време на интервюта.

Компонент тестове. Терминът не се използва толкова често, но наистина ми хареса. В този случай, той се отнася до компонентите на системата. Не е нужно да изпълните целия заявлението. Обикновено в нашите приложения, ние споделяме всичко в слоеве. Компоненти такива тестове може да се инициализира всички слоеве външни ресурси Мока и тестват парче логика. Положителните страни на тези тестове: а) тестът не е класа, но реално същество логика б) много бързо в сравнение с теста на системата. тестове Идеален компонент - тези, в които всички външни ресурси са ограничени, но понякога е по-лесно да напусне нещо, например, ако този поток с помощта на JMS в рамките на едно приложение, самите JMS може да бъде оставено (заменяйки я с ActiveMQ например), докато използването на външни системи имат вече Мока, в противен случай ние ще ги тества и в този случай, твърде много време ще бъдат изразходвани за подкрепа.
Понякога е посочено тест като модулен компонент. Е, истината е компонент можете да се обадите нещо толкова спретнато с този термин.

тестове за интеграция (Тест системна интеграция, SIT). Този термин е най-претоварените от всички интеграционни тестове могат да бъдат наречени в следните случаи: когато само на външен ресурс; Когато се използват агломерационни класове (в този случай, компонент); Когато стартирате всички приложения и т.н. Дайте на хората причина те наричат ​​този тест интеграцията. Опитвам се да не се използва възможността на този термин, но са семантично съответните случаи: това е, когато вие всъщност тестване на интеграция с други системи. Пример: Приложение А очаквайте в приложение Б и приложение В. дърпа всички тези системи могат да комуникират през различни протоколи: JAX-RS, JAX-WS, JMS, Protobuf, ние трябва да се провери това съобщение, защото, от една страна може да се промени на протокола в а от друга страна, той е останал същият, а след това на заявлението като цяло не функционира. Всъщност това и прави тестове за интеграция, те тестват точки на контакт системи. Имайте предвид, че те не трябва да се тества самия бизнес логиката, в противен случай отново ще тества няколко приложения, и не е нужно това хемороиди.

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

Само няколко думи, въпреки че по-горе, ортогонален (защото те могат да бъдат едновременно и система например), но това е много използван:

Здрав разум Тестове - основни системни изпитания, за да се определи дали приложението е оперативно и всички. Удобен за използване при всяка deploe автоматизирано за да се определи дали дадено приложение да се изпълнява успешно. Тя включва проверка само най-най-основните функции на системата. Ето един пример изпълнение написан на Python - тя просто ще разпита началната страница, ако това отговаря на HTTP 200/201, стартирано приложение средства, ако има кодове за грешки означават, доставка и монтаж на сайта е изпаднал в Jenkins'e трябва да отбележат в червено.

Story приемни изпитвания. Когато формира на изискванията, може да се определи най-тестове (а понякога дори и само за да ги напиша), които ще определят дали функционалните отговаря на изискванията, подадени. Много готино, ако клиентът го пише себе си, но тази възможност е рядкост. Ако тези тестове не преминават, а след това тази функция не се изпълнява. Това е много удобно да пиша такива тестове под формата на някои Предвид състояние. когато правиш нещо ново. След това ние откриваме една нова държава.

Потребителски приемни изпитвания - е, когато sadite реални потребители (които дават достъп на клиента) и да поиска poklikat, чакащи за обратна връзка. Това е фазата, в която можете да определите или дори дали е искал от клиента.

тестване регресия (регресия тестове). Вашите приемни изпитвания, след като я обслужват, и си функция на предаването на автомобила ще могат да продължат да служат под формата на регресивни тестове. Тези тестове определят дали старото не е счупена функционалност при изпълнение на нови функции или след рефакториране. Значението на тези тестове не може да се надценява. Ако ги автоматизирате, вие ще бъдете в състояние да направи чести издания. Не е като едно и също автоматизирано регресия, ще трябва ръчно да тествате много преди всяко освобождаване. Автоматизирана регресия позволява да се чувстват уверени човек :)

Заредете тестове. Определете как приложението ви функционира под стрес и всъщност какъв товар да могат да издържат. Сравнително сложни тестове, особено като се има предвид, че самата натоварването - многолик нещо. Можете да тествате възможностите Максимално натоварване (когато заявлението оставя за постоянно), но повечето от нас се интересуват от капацитета (даде бонбони за тези, които го преведе на български :)) (например броят на сделките в секунда.) - броят на едновременни операции, в които молбата ще се държи задоволително (първоначално сте поставени на прага, например, всяка страница не трябва да отнеме повече време, за да се зареди от 1 секунда).

Изпитвания на издръжливост (дълголетие тестове) - подтип на стрес-тестове. Характеризира се с това, че ти просто сложи си заявление по постоянните средните реклами натоварване месец или го рестартирате. Тези тестове помагат за определянето на, например, ако имате течове с памет.

Библиотеките Преглед за изпитване:

JUnit. TestNG да стартирате тестовете и резултатите от теста. То е като Groovy Junit, можете да го слушате в една от тези сесии JTalks.

Mockito. EasyMock - най-популярната библиотека за създаване на mokov

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

Awaitility - позволява удобно да се работи в случаите, когато е необходимо да се изчака отговора за известно време. Веднага казвам, че не е много ефективен, много по-ефективно да се използват някои обратни повиквания.

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

JBehave. Краставици (Ruby) - позволява рамки, за да опише тестовете във формата, дадена / Когато / Тогава (т.нар Спецификация пример). В опита от първите, които казват, че нещо, което на практика не е толкова лесно, по-подробно в преглед на JBehave.