Меню

Какво са тестовите данни? Изпробвайте техниките за подготовка на данните с пример

what is test data test data preparation techniques with example

Опитайте Нашия Инструмент За Премахване На Проблемите

Научете какво са тестови данни и как да подготвите тестови данни за тестване:

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

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

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

Какво са тестови данни - Подготовка на тестови данни

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

Какво ще научите:

Какво представляват тестовите данни и защо е важно

Позовавайки се на проучване, проведено от IBM през 2016 г., търсенето, управлението, поддържането и генерирането на тестови данни обхващат 30% -60% от времето на тестерите. Безспорно е доказателство, че подготовката на данни е отнемаща време фаза на тестване на софтуера.

Средно време, прекарано на тестерите в TDM

Фигура 1: Средно време, прекарано на тестерите в TDM

Въпреки това е факт в много различни дисциплини, че повечето изследователи на данни отделят 50% -80% от времето за разработване на своя модел в организиране на данни. И сега, като се има предвид законодателството, както и личната информация (PII), тестването на тестерите е изключително прилично в процеса на тестване.

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

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

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

генератор на случайни числа 0-1

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

Данните могат да бъдат във всякаква форма като:

  • Данни за системни тестове
  • SQL тестови данни
  • Данни от теста за ефективност
  • XML test data

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

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

Подготовката на правилни входни данни е част от тестовата настройка. По принцип тестерите го наричат ​​a подготовка на тестово място . В тестовата лаборатория всички софтуерни и хардуерни изисквания се задават с помощта на предварително дефинираните стойности за данни.

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

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

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

Тествайте предизвикателствата пред източника на данни

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

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

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

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

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

Някои от най-често срещаните предизвикателства на тестовия източник на данни са посочени по-долу:

  • Екипите може да нямат адекватни знания и умения за инструменти за генериране на тестови данни
  • Покритието на тестовите данни често е непълно
  • По-малко яснота в изискванията за данни, обхващащи спецификациите на обема по време на фазата на събиране
  • Екипите за тестване нямат достъп до източниците на данни
  • Забавяне в предоставянето на производствени данни за достъп до тестерите от разработчици
  • Данните от производствената среда може да не са напълно използваеми за тестване въз основа на разработените бизнес сценарии
  • Може да са необходими големи обеми данни за кратък период от време
  • Зависимости / комбинации от данни за тестване на някои от бизнес сценариите
  • Тестерите прекарват повече време от необходимото за комуникация с архитекти, администратори на бази данни и администратори за събиране на данни
  • Данните се създават предимно по време на изпълнението на теста
  • Множество приложения и версии на данни
  • Цикли на непрекъснато освобождаване в няколко приложения
  • Законодателство, което да се грижи за лична идентификационна информация (PII)

От бялата страна на тестването на данните разработчиците подготвят производствените данни. Това е мястото, където QA трябва да работи на базата на допир с разработчиците за по-нататъшно покритие на AUT. Едно от най-големите предизвикателства е да се включат всички възможни сценарии (100% тестов случай) с всеки възможен отрицателен случай.

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

Стратегии за подготовка на тестови данни

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

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

Стратегии за управление на тестови данни (TDM)

Фигура 2: Стратегии за управление на тестови данни (TDM)

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

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

Можем да приложим следните стратегии, обработващи процеса на TDM:

  1. Данни от производствената среда
  2. Извличане на SQL заявки, които извличат данни от съществуващите бази данни на клиента
  3. Инструменти за автоматично генериране на данни

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

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

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

Тествайте дейности за генериране на данни

Фигура 3: Тествайте дейности за генериране на данни

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

Повредени тестови данни

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

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

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

  1. Като резервно копие на вашите данни
  2. Върнете променените данни в първоначалното им състояние
  3. Разделяне на данни между тестерите
  4. Поддържайте администратора на хранилището за данни актуализиран за всяка промяна / модификация на данни

Как да запазите данните си непокътнати във всяка тестова среда?

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

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

Тестови данни за теста за ефективност

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

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

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

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

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

Проектирайте данните си, като вземете предвид следните категории:

1) Няма данни: Изпълнете тестовите си случаи на празни или данни по подразбиране. Вижте дали се генерират правилни съобщения за грешка.

2) Валиден набор от данни: Създайте го, за да проверите дали приложението функционира според изискванията и дали валидните входни данни са правилно записани в база данни или файлове.

3) Невалиден набор от данни: Подгответе невалиден набор от данни, за да проверите поведението на приложението за отрицателни стойности, буквено-цифрови входове.

4) Нелегален формат на данните: Направете един набор от данни за нелегален формат на данните. Системата не трябва да приема данни в невалиден или незаконен формат. Също така проверете дали се генерират правилни съобщения за грешка.

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

6) Наборът от данни за тестване на производителност, товар и стрес: Този набор от данни трябва да бъде голям по обем.

По този начин създаването на отделни набори от данни за всяко условие на теста ще осигури пълно покритие на теста.

Данни за тестване на черна кутия

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

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

Методи за проектиране на данни в черна кутия

Фигура 4: Методи за проектиране на данни в черна кутия

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

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

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

Пример за тестови данни за отворен EMR AUT

За настоящия ни урок имаме Open EMR като тествано приложение (AUT).

=> Моля, намерете връзка за приложението Open EMR тук за справка / практика.

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

( ЗАБЕЛЕЖКА : Щракнете върху всяко изображение за увеличен изглед)

събиране на изисквания за тестови данни 1

Създаване на ръчни данни за тестване на отворено приложение EMR

Нека пристъпим към създаването на ръчни данни за тестване на приложението Open EMR за дадените категории данни.

1) Няма данни: Тестерът потвърждава URL адреса на приложението Open EMR и функциите „Търсене или добавяне на пациент“, без да дава данни.

2) Валидни данни: Тестерът проверява URL адреса на приложението на EMR и функцията „Търсене или добавяне на пациент“ с предоставяне на валидни данни.

3) Невалидни данни: Тестерът потвърждава URL адреса на приложението EMR и функцията „Търсене или добавяне на пациент“ с предоставяне на невалидни данни.

4) Нелегален формат на данните: Тестерът потвърждава URL адреса на приложението EMR и функцията „Търсене или добавяне на пациент“ с предоставяне на невалидни данни.

Тестови данни за 1-4 категории набори от данни:

Проби от тестови данни 2

5) Набор от данни за гранично състояние: Той е да се определят входни стойности за граници, които са или вътре или извън дадените стойности като данни.

6) Набор от данни за еквивалентност на дяла: Това е техниката на тестване, която разделя входящите данни на входните стойности на валидни и невалидни.

Тестови данни за 5тии 6тикатегории данни, което е за потребителско име и парола на Open EMR:

Отворете EMT данните за теста 3

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

Моля, вижте по-долу данните от таблицата с решения за потребителското име и паролата на приложението Open EMR.

sql интервю въпроси и отговори за тестери

Данни от таблицата за решения 4

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

  • Брой на комбинацията = Брой условия 1 Стойности * Брой условия 2 Стойности
  • Брой комбинации = 2 ^ Брой верни / неверни условия
  • Пример: Брой комбинации - 2 ^ 2 = 4

8) Набор от данни за тест за преход: Това е техниката на тестване, която ви помага да потвърдите прехода на състоянието на тестваното приложение (AUT), като предоставите на системата входни условия.

Например, ние влизаме в приложението Open EMR, като предоставяме правилното потребителско име и парола при първия опит. Системата ни дава достъп, но ако въведем грешни данни за вход, системата отказва достъп. Тестването за преход на държавата потвърждава колко опити за влизане можете да направите преди Open EMR да се затвори.

Таблицата по-долу показва как отговарят или правилните, или неправилните опити за влизане

Данни за опити за влизане 5

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

Пример, Open EMR Login:

Данни от теста за неуспех 6

Прочетете също => Техники за управление на данни

Свойства на добри тестови данни

Като тестер трябва да тествате модула ‘Резултати от изпитите’ на уебсайта на университет. Помислете, че цялото приложение е интегрирано и е в състояние „Готово за тестване“. „Модул за изпит“ е свързан с модули „Регистрация“, „Курсове“ и „Финанси“.

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

Данните, споменати в тестовите случаи, трябва да бъдат правилно подбрани. Точността на графата „Действителни резултати“ на документа „Тест“ зависи преди всичко от данните от теста. И така, стъпката за подготовка на входните тестови данни е значително важна. По този начин ето моето изложение за „Тестване на DB - стратегии за подготовка на тестови данни“.

Свойства на тестовите данни

Данните от теста трябва да бъдат избрани точно и трябва да притежават следните четири качества:

1) Реалистично:

По реалистичен начин това означава, че данните трябва да са точни в контекста на сценариите от реалния живот. Например, за да тествате полето „Възраст“, ​​всички стойности трябва да са положителни и да са 18 или повече. Съвсем очевидно е, че кандидатите за прием в университета обикновено са на 18 години (това може да бъде определено по различен начин от гледна точка на бизнес изискванията).

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

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

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

2. Практически валидни:

Това е подобно на реалистичното, но не е същото. Това свойство е по-свързано с бизнес логиката на AUT напр. стойност 60 е реалистична в областта на възрастта, но практически невалидна за кандидат на магистърска програма или дори магистърска програма. В този случай валиден диапазон ще бъде 18-25 години (това може да бъде определено в изискванията).

3. Универсален за покриване на сценарии:

какво е .swf файл

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

Г-н# Student_ID Идентификатор на програмата Идентификационен номер на курса Клас
един BCS-Fall2011-Morning-01 BCS-F11 CS-401 ДА СЕ
две BCS-Пролет2011-Вечер-14 BCS-S11 CS-401 B +
3 MIT-Fall2010-следобед-09 MIT-F10 CS-401 ДА СЕ-
... ... ... ... ...

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

добри данни от теста

4. Изключителни данни (ако е приложимо / изисква се):

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

Друго добро обяснение и пример за изключителния набор от данни се вижда на изображението по-долу:

Изключителни данни

За вкъщи:

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

Техники за подготовка на тестови данни

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

Има само два начина за изготвяне на тестови данни:

Метод # 1) Вмъкване на нови данни

Вземете чиста DB и вмъкнете всички данни, както е посочено във вашите тестови случаи. След като всичките ви необходими и желани данни са въведени, започнете да изпълнявате тестовите си случаи и попълнете колоните „Предаване / неуспех“, като сравните „Действителен изход“ с „Очакван изход“. Звучи просто, нали? Но чакай, не е толкова просто.

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

  • Празен екземпляр на базата данни може да не е наличен
  • Въведените данни от теста може да са недостатъчни за тестване на някои случаи като тестване на производителността и натоварването.
  • Вмъкването на необходимите тестови данни в празна DB не е лесна работа поради зависимостите на таблицата на базата данни. Поради това неизбежно ограничение вмъкването на данни може да се превърне в трудна задача за тестера.
  • Вмъкването на ограничени данни от теста (само според нуждите на теста) може да скрие някои проблеми, които биха могли да бъдат намерени само с големия набор от данни.
  • За вмъкване на данни може да са необходими сложни заявки и / или процедури и за това ще е необходима достатъчна помощ или помощ от разработчика (ите) на DB.

Горепосочените пет въпроса са най-критичните и най-очевидните недостатъци на тази техника за подготовка на тестови данни. Но има и някои предимства:

  • Изпълнението на TC става по-ефективно, тъй като DB има само необходимите данни.
  • Изолирането на грешки не изисква време, тъй като в БД присъстват само данните, посочени в тестовите случаи.
  • По-малко време, необходимо за тестване и сравняване на резултатите.
  • Безпроблемен процес на тестване

Метод # 2) Изберете примерна подгрупа от реални данни на DB

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

За вкъщи:

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

В последния раздел нека направим и кратка обиколка на подходите за генериране на данни. Тези подходи са полезни, когато трябва да генерираме нови данни.

Подходи за генериране на тестови данни:

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

За вкъщи:

Има 4 подхода за генериране на тестови данни:

  1. Наръчник,
  2. автоматизация,
  3. впръскване на данни в края,
  4. и инструменти на трети страни.

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

Заключение

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

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

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

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

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

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

Част II - Втората част на този урок е на ' Тествайте генерирането на данни с онлайн инструмента GEDIS Studio ”.

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

Препоръчително четене

^