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

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

• Част от описанието на входа може да бъде в състояние на базата данни. т.е. ДДТ в функционалност ще включва настройка на базата данни. Това състояние може да бъде взета от SQL сметище, и е възможно да се създаде програма за Java (втори метод е по-лесно да се поддържа). Вижте примери 4 и 6.
• Част от продукцията състояние справка отново може да бъде състояние на базата данни. Но това се случва, че всичко е много по-сложно, и ние трябва да се провери не само държавни, но серия от разговори, събитие, а дори и контекст след всяко повикване в рамките на системата, а след това е добра идея би било да се изгради повикване дърво по време на теста за почистване. т.е. сеч желания в правилния формат (например, XML или JSON), а след това и референтните данни ще бъдат проверени преди дървото за повикване. Между другото, на дървото справка повикване може да се запише в първия тестването им, а след това ръчно да проверите. той - е правилен, а след това - вече го използват за тестване. Виж Примери 3 и 7.

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

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

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

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

Бих искала да отбележа, че в определен подход за използване, Рамкови тестове роботи могат да бъдат много DDT ориентирани, и дават много ползи.

Най-простата форма на ДДТ - параметрични тестове в JUnit, при използване на доставчиците на данни, за да се тества набори от данни, са на разположение за тестване.

ДДТ - не е панацея, но внимателно прилагане на правилните места и помага много.

Откъде знаеш, че когато трябва да се създаде DDT

Как да създадете DDT

В повечето случаи е достатъчно да се направи една линия над основния тест и да организирате данните и сравняване позоваването изход, а също и да се реализират ОТЧИТАНЕ - от сеч, или други средства.

Но в нетривиални случаи е възможно да се изгради архитектурата около необходимостта от създаване на ДДТ. Виж Примери 3 и 7.

Задача. Превод на дигитален запис на низ. Например 134 345 ще бъде "сто тридесет и четири хиляди триста четиредесет и пет". * Имайте предвид, деклинацията - в окончания на разликата (например, две и две).

• Алгоритъмът трябва да работи за произволен брой на голям брой съответно стойностите на бита - един милион, хиляда милиарда, и т.н. - трябва да бъдат взети от справочника, например текстов файл.
• Бъдете сигурни, за да се създаде основа на набраните данни Test (I, като потребител, трябва да може да влиза няколко набора 1. Брой 2.pravilny бенчмарк резултати на теста независимо разглежда всички набори и казва, че не е вярно), което доказва, че си алгоритъм работи правилно. Използвайте JUnit.
• Ако е възможно, се прилага за освобождение на Палестина.

Задача. Прилагане на HTML анализатора от нулата. Това означава, че за реализиране на нова линия в DOM.

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

Второ инженер на първия ден да направи първия тест единица, която ще тества най-простия случай - празен низ или празен етикет , или нещо по-просто. И всеки ден, той ще хвърли нови страни, разширяване на техния код. Логично би увийте на ДДТ в, и нека целия екип, мениджъри и тестери да хвърлят различни версии на HTML, и референтния резултат (например, на DOM дървото на предмети, които могат да бъдат написани на първия манш на този алгоритъм и проверени ръчно). При този подход на натрупаните дела, промени в алгоритъма и логиката не свалят предишните серии от данни, както и че е възможно да се разбере ясно това, което вече е реализирано. Освен това, наборът от входни данни и референтни стойности могат да бъдат групирани в папки, подпапки и по този начин се създаде парсерът документация.

3. Подходът, който се използва в платформата за тестване за автоматизация на тестване XML2Selenium

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

XML2Selenium в състояние да преминете през изпитанията, написани на XML формат, както и прилагането тест Web UI (вътре ние използваме Селен / Уеб Driver).

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

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

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

4. Подходът, използван в един проект за качване на данни тестване

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

Решението е да се използва ДДТ. Входните параметри са сметището на базата данни в XML формат. Референтна стойност - преди това е показала разтоварване файл известен безспорна. По този начин, на теста е намален, за да създадете различни версии на базата данни, както и за проверка на референтните файлове, както и създаването на такива тестове.

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

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

5. недвижими проекта - тестване на обработката на грешки в комплекс граматиката

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

Този XML имаше доста сложен синтаксис, и нашият екип е независима от разработчика на задния. Ние трябваше да се предпазят от неправилно XML, ние трябваше да започне изграждането на UI, само когато 100% ясно, че XML е вярна.

За това се използва ДДТ. Ние сме създали огромен брой опции XML входни, включително неправомерно, неправилна, и проверка на наличието на необходимите изключения се хвърлят с правилните послания.

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

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

6. Изпитване на комплекс за сваляне на данни. Изолирането на логически съхранени процедури

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

Както в Пример 4 с сметище за данни, ние използвахме на ДДТ и като входни параметри, използвани 1) състоянието на базата данни (ние използвахме сметище в SQL формат) и 2) на файл, за да бъде изтеглен. Като референтна стойност, затова използваме XLS файл, който представлява съдържанието имаме нужда от таблици в базата данни, след качване.

Всички грешки, което се случва често, ние бяхме поставени в DDT.

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

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

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

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

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