Димните и санитарните тестове започват веднага след пускането на следващата версия на проекта. За много млади тестери този процес изглежда като абсолютен хаос. разпознавате ли се Тогава тази статия е за вас. Сега ще разгледаме определенията за изпитване на дим и санитарно изпитване и ще покажем разликите между тях с лесни за разбиране примери.

Изпитване на дим:

Извършва се тестване на дим, за да се гарантира, че получената конструкция е подходяща за тестване. Нарича се още проверка „нулев ден“.

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

Санитарно изследване:

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

Пример за по-добро разбиране на разликата между дим и санитарен тест:

Има проект, за който е планирано първоначално пускане. Екипът за разработка пуска компилацията за тестване и екипът за тестване започва работа. Първият тест е тестът за способности. Трябва да разберете дали можете да работите с тази версия или не. Това е тестване на дим. Ако екипът даде зелена светлина за по-нататъшна работа с компилацията, тя се изпраща на по-дълбоки етапи на тестване. Нека си представим, че компилацията има три модула: „Вход“, „Администратор“ и „Служител“. Екип от тестери проверява функционалността само на основните функции на всеки модул, без да навлиза в подробности. Това ще бъде санитарно изследване.

Още няколко разлики между дим и санитарен тест:

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

Кирил Флягин, дизайнер на игри, QA Lead

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

  • Тест за дим на жаргон файл (английски)

Фондация Уикимедия.

2010 г.

    Вижте какво е "тест за дим" в други речници:тест за дим

    Вижте какво е "тест за дим" в други речници:- съществително Метод за тестване за течове в дренажни тръби или комини чрез вкарване на гъст дим, често чрез използване на димна бомба Основен запис: дим … Полезен английски речник - Тест, направен за определяне на пълнотата на изгаряне...

    Вижте какво е "тест за дим" в други речници:Речник на автомобилните термини

    - 1. съществително a) Тест за течове, включващ издухване на дим в тръба или тръба. б) Предварителен тест на новоконструирано електронно оборудване, състоящ се просто от прилагане на електрическа енергия, за да се уверите, че няма грубо окабеляване... ... УикиречникИзпитване на дим

    - 1. съществително a) Тест за течове, включващ издухване на дим в тръба или тръба. б) Предварителен тест на новоконструирано електронно оборудване, състоящ се просто от прилагане на електрическа енергия, за да се уверите, че няма грубо окабеляване... ... Уикиречник- е термин, използван във водопроводните инсталации, ремонта на духови инструменти, електрониката, разработката на компютърен софтуер и развлекателната индустрия. Отнася се за първия тест, направен след ремонт или първо сглобяване, за да се осигури известна увереност, че тестваната система ще... ... Wikipedia

    - bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. E bezeichnet den ersten… … Deutsch Wikipediaдим

    - е събирането на пренасяни във въздуха твърди и течни частици и газове [SFPE Handbook of Fire Protection Engineering], отделяни, когато даден материал е подложен на... … WikipediaТестови пакет

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

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

Практиката, използвана например в Microsoft и някои други компании за разработка на софтуер, е ежедневното изграждане на програма, която се допълва от димни тестове. Всеки ден, след като всеки файл е асемблиран, свързан и комбиниран в изпълнима програма, самата програма се подлага на доста прост набор от тестове, целта на които е да се види дали програмата "пуши" по време на работа. Тези тестове се наричат ​​димни тестове. Най-често този процес е доста добре автоматизиран (или трябва да бъде).

ПРЕДИМСТВА. Този прост процес осигурява няколко значителни предимства.

Минимизиране на риска по време на интеграция

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

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

Намаляване на риска от некачествен софтуерен продукт

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

Помощ при диагностициране на грешки

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

Подобрен морал

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

Използване на ежедневни компилации и димни тестове

Ето някои подробности за този принцип.

Ежедневно изграждане на приложение

Основна част от ежедневното сглобяване е сглобяването на последната завършена част. Джим Маккарти, пишещ в Dynamics of Software Development (Microsoft Press, 1995), нарече ежедневното изграждане на проект сърцето на проекта. Ако няма сърдечен ритъм, няма проект, той е мъртъв. По-малко образно, Майкъл Кузумано и Ричард У. Селби описват ежедневното изграждане като синхронизиращ импулс на проекта (Microsoft Secrets, The Free Press, 1995). Всеки разработчик пише код по свой собствен начин и кодът може да надхвърли общоприетата рамка за проекта - това е нормално, но с всяко излагане на синхронизиращ импулс кодът се връща към стандарта. Като настоявате за разработване, използвайки непрекъснато импулса за синхронизиране, вие предотвратявате напълно излизането на проекта от синхронизация.

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

Проверка за неуспешно изграждане

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

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

Добрата конструкция е тази, която има поне:

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

Ежедневни димни тестове

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

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

Изпитването на дим трябва да бъде разработено на същото ниво като проекта. В началото димните тестове ще проверяват нещо просто, като например дали даден проект може да произведе съобщение „Здравей, свят!“. С развитието на системата тестовете за дим стават по-задълбочени. Времето, изразходвано за първите димни тестове, се изчислява за няколко секунди, но с нарастването на системата времето, необходимо за димни тестове, също се увеличава. В края на проекта тестването на дим може да продължи с часове.

Дефиниране на група за изграждане

При повечето проекти има конкретно лице, което отговаря за прегледа на ежедневната компилация на системата и извършването на димни тестове. Тази работа е част от задълженията на този служител, но при големи проекти може да има повече такива служители и тази работа е тяхна основна отговорност. Например екипът за изграждане на проекта Windows NT 3.0 имаше четирима души (Паскал Закари, Showstopper!, Свободната преса, 1994).

Добавете ревизия към компилация само ако има смисъл

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

Въведете система от санкции за неиздаване на следваща компилация (пускане на неработеща компилация).

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

Подчертайте малките глоби висока степеннеобходимостта от наблюдение на качеството на монтажа на системата. При някои проекти разработчиците, по чиято вина сборката се провали, получават близалки за освобождаване на повредена сборка. Съответен знак виси на вратата на офиса на такъв разработчик, докато той не поправи монтажа (при условие, че разработчиците имат отделни офиси :)). При други проекти виновните разработчици трябва да носят фалшиви кози рога или да внесат определена сума в „морален фонд“ (примери са взети от истинската история на компанията).

Но за някои проекти се въвеждат по-сериозни санкции. Например разработчиците на Microsoft, работещи по проекти с висок приоритет (Windows NT, Windows 95, Excel), носеха пейджъри и, ако беше открит одит, те трябваше да докладват на работа. Дори ако повреда или грешка е открита в 3 сутринта.

Сглобете системата и я „изпушете“ дори под налягане

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

Кой печели от този процес? Някои разработчици протестират срещу ежедневните компилации, оправдавайки протестите си с непрактичността на тази дейност и голямата инвестиция във времето. Но всички сложни системи напоследък бяха подложени на ежедневно сглобяване и тестване на дим. Към момента на издаването му, Microsoft Windows NT 3.0 съдържаше 5,6 милиона реда в 40 000 файла. Пълното изграждане отне 19 часа и беше извършено на множество компютри. Въпреки това разработчиците успяха да сглобят системата всеки ден. Като професионален екип, екипът за разработка на NT дължи голяма част от успеха си на ежедневното си изграждане. Тези разработчици, които работят върху по-малко сложни проекти и следователно не се възползват от ежедневния процес на изграждане, трябва да обмислят измислянето на някои разумни обяснения.

Здравей, Хабр! Веднъж на нашия вътрешен семинар моят ръководител, ръководителят на отдела за тестване, започна речта си с думите „не е необходимо тестване“. Всички в залата млъкнаха, някои дори се опитаха да паднат от столовете си. Той продължи мисълта си: без тестване е напълно възможно да се създаде сложен и скъп проект. И най-вероятно ще работи. Но си представете колко по-уверени ще се почувствате, като знаете, че продуктът работи както трябва.

В Badoo изданията се случват доста често. Например, сървърната част, заедно с десктоп мрежата, се пускат два пъти на ден. Така че знаем от първа ръка, че сложното и бавно тестване е пречка за развитието. Бързото тестване е благословия. И така, днес ще говоря за това как се организира тестването на дим в Badoo.

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

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

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

Нека да разгледаме един прост пример. Предварителната версия на нашето приложение се намира на bryak.com (всички прилики с реални сайтове са случайни). Подготвихме и качихме нова версия там за тестване. Какво трябва да проверите първо? Бих започнал с проверка дали приложението все още се отваря. Ако уеб сървърът ни отговори „200“, тогава всичко е наред и можем да започнем да проверяваме функционалността.

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

Първият ни тест за дим

В Badoo сървърната страна е написана предимно на PHP. По очевидни причини в него са написани модулни тестове. Така че вече имаме PHPUnit. За да не умножаваме ненужно технологиите, решихме да напишем димни тестове и на PHP. Освен PHPUnit ще ни трябва клиентска библиотека за работа с URL адреси (libcurl) и PHP разширение за работа с нея - cURL.

По същество тестовете просто правят заявките, от които се нуждаем, към сървъра и проверяват отговорите. Всичко е свързано с метода getCurlResponse() и няколко вида твърдения.

Самият метод изглежда така:

Публична функция getCurlResponse($url, масив $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ очакван_отговор = '200 OK') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if (isset( $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) if ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data']) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line); ) ако ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy) ']);
) if (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ( $user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, $user_agent);

curl_setopt($ch, CURLOPT_AUTOREFERER, 1);

$отговор = curl_exec($ch);

Публична функция testStartPage() ( $url = ‘bryak.com’; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Този тест отнема по-малко от секунда. През това време проверихме дали началната страница отговаря с „200“ и има елемент body. Със същия успех можем да тестваме произволен брой елементи на страницата, продължителността на теста няма да се промени значително.

Предимствата на такива тестове:

  • скорост – тестът може да се изпълнява толкова често, колкото е необходимо. Например, за всяка промяна на кода;
  • не изискват специален софтуер или хардуер за работа;
  • те са лесни за писане и поддръжка;
  • те са стабилни.
Относно последната точка. Имам предвид не по-малко стабилен от самия проект.

Упълномощаване

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

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

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

Отворете тази страница във всеки браузър и отворете инспектора. Въведете потребителските данни и изпратете формуляра.

В инспектора се появи заявка, която трябва да симулираме в теста. Можете да видите какви данни, в допълнение към очевидните (вход и парола), се изпращат на сървъра. Това е различно за всеки проект: може да бъде отдалечен токен, данни от бисквитки, получени по-рано, потребителски агент и т.н. Всеки от тези параметри ще трябва първо да бъде получен в теста, преди да се генерира заявка за оторизация.

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

В отговор на такава заявка сървърът ще ни върне бисквитки, които ще добавим към следващи заявки, за да тестваме оторизираните страници.

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

Публична функция testAuthPage() ( $url = ‘bryak.com’; $cookies = $this->getAuthCookies(‘ [имейл защитен]', '12345'); $response = $this->getCurlResponse($url, [‘cookies’ => $cookies]);
$this->assertHTMLPresent("

", $response, "Грешка: тестът не може да намери основния елемент на страницата."); )
Както виждаме, добавен е метод, който получава бисквитка за оторизация и просто я добавя към следваща заявка. Самият метод се изпълнява доста просто:

Публична функция getAuthCookies($email, $password) ( // проверка дали бисквитката вече е получена If (array_key_exist($email, self::$known_cookies)) ( return self::$known_cookies[$email]; ) $url = self::DOMAIN_STAGING '/auth_page_adds'; $url, ['post_data' => $ post_data]); $this->parseCookiesFromResponse($response); // запазване на cookies за по-нататъшно използване
Методът първо проверява дали даден имейл (във вашия случай може да е логин или нещо друго) има предварително получена авторизационна бисквитка. Ако има, той го връща. Ако не, той прави заявка към страницата за оторизация (например bryak.com/auth_page_adds) с необходимите параметри: потребителски имейл и парола. В отговор на тази заявка сървърът изпраща заглавки, сред които са бисквитките, които ни интересуват. Изглежда нещо подобно:

HTTP/1.1 200 OK Сървър: nginx Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Връзка: keep-alive Set-Cookie: name=value; expires=сряда, 30 ноември 2016 г. 10:06:24 GMT; Максимална възраст=-86400; път=/; домейн=bryak.com
От тези заглавки, използвайки прост регулярен израз, трябва да получим името на бисквитката и нейната стойност (в нашия пример тя е име=стойност). Нашият метод, който анализира отговора, изглежда така:

Анализ на неуспешни тестове

От горното следва, че такъв тест е набор от заявки към сървъра. Правим заявка, манипулираме отговора, правим следваща заявка и т.н. В главата ми се прокрадва мисъл: ако такъв тест се провали на десетата заявка, може да не е лесно да разбера причината за неуспеха му. Как да опростите живота си?

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

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

Например нашият тест се провали, защото не можа да намери част от HTML на страницата:

Връзка
Отиваме до нашия колектор и отваряме съответната страница:

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

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

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

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

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

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

Резултати

включено в моментаИмаме *open TimCity* уау, вече 605 теста. Всички тестове, ако не се изпълняват паралелно, преминават за малко по-малко от четири минути.

През това време се уверяваме, че:

  • нашият проект се отваря на всички езици (от които имаме повече от 40 в производство);
  • за основните държави се показват правилните форми на плащане със съответния набор от методи на плащане;
  • основните API заявки работят правилно;
  • целевата страница за пренасочвания работи правилно (включително към мобилен сайт с подходящ потребителски агент);
  • всички вътрешни проекти се показват правилно.
Тестовете на Selenium WebDriver за всичко това биха изисквали в пъти повече време и ресурси.

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

- , за да потвърдите функционалността на приложението или коректността на корекцията на дефекта:Изпитване на дим

- (Тестване на дим)Регресионно тестване

- (Регресионно тестване)Тестване на компилацията

- (Тест за проверка на компилация)Санитарно тестване или проверка на последователност/функционалност

(Тестване за здравина) Концепциятестване на дим идва от инженерната среда. При въвеждане в експлоатация на ново оборудване („хардуер“) се счита, че тестът е успешен, ако от инсталацията не излиза дим. В областта на софтуерното тестване е насочено към повърхностна проверка на всички модули на приложението за работоспособност и наличие на бързо открити критични и блокиращи дефекти. Въз основа на резултатите от димния тест се прави заключение дали продуктът е приет или не.инсталирана версия

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

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

Самият термин „регресионно тестване“, в зависимост от контекста на употреба, може да има различни значения. Сам Канер, например, описа 3 основни типарегресионно тестване:

- Регресия на грешки– опит да се докаже, че коригираната грешка всъщност не е коригирана.

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


- Регресия на страничния ефект– опит да се докаже, че скорошна промяна в код или данни е повредила други части на разработваното приложение.

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

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

(Регресионно тестване)Тестът за проверка на компилация е тестване, насочено към определяне на съответствието на издадената версия с критериите за качество, за да започне тестването. По отношение на своите цели той е аналогичен на Smoke Testing, насочен към приемане на нова версия за по-нататъшно тестване или работа. Може да проникне по-дълбоко, в зависимост от изискванията за качество на пуснатата версия.

Тестване на инсталацията –насочени към проверка на успешна инсталация и конфигурация, както и актуализиране или деинсталиране на софтуер. IN настоящ моментНай-честата инсталация на софтуер е с помощта монтажници (специални програми, които също изискват подходящо тестване). В реални условия може да няма инсталатори. В този случай ще трябва да инсталирате софтуера сами, като използвате документация под формата на инструкции или readme файлове, които описват стъпка по стъпка всички необходими действия и проверки. В разпределени системи, където приложението е разположено във вече работеща среда, прост набор от инструкции може да не е достатъчен. За да направите това, често се пише план за инсталиране (план за внедряване), който включва не само стъпки за инсталиране на приложението, но и стъпки за връщане към предишна версия, в случай на повреда. Самият план за инсталиране също трябва да премине през процедура на тестване, за да се избегнат проблеми при пускане в реална експлоатация. Това е особено вярно, ако инсталацията се извършва на системи, където всяка минута престой е загуба на репутация и голямо количествосредства, например: банки, финансови компанииили дори банерни мрежи. Следователно тестването на инсталацията може да се нарече едно от най-важните задачиотносно осигуряването на качеството на софтуера.

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