Като тестер може да си помислите, че „Проектирането на тестови случаи е достатъчно предизвикателно, защо тогава да се притеснявате за нещо толкова тривиално като тестовите данни“. Целта на този урок е да ви запознае с тестовите данни, тяхното значение и да даде практически съвети и трикове за бързо генериране на тестови данни. И така, нека да започнем!
Какво представляват тестовите данни при тестване на софтуер?
Тестови данни при тестване на софтуер е входът, даден на софтуерна програма по време на изпълнението на теста. Той представлява данни, които влияят или са засегнати от изпълнението на софтуера по време на тестване. Данните от теста се използват както за положителни тестове, за да се провери дали функциите дават очаквани резултати за дадени входове, така и за отрицателни тестове, за да се тества способността на софтуера да обработва необичайни, изключителни или неочаквани входове.
Лошо проектираните данни за тестване може да не тестват всички възможни тестови сценарии, които ще попречат на качеството на софтуера.
Какво е генериране на тестови данни? Защо тестовите данни трябва да се създават преди изпълнението на теста?
Всички знаят, че тестването е процес, който произвежда и консумира големи количества данни. Данните, използвани при тестването, описват началните условия за тест и представляват средата, чрез която тестерът влияе върху софтуера. Това е решаваща част от повечето функционални тестове.
В зависимост от вашата среда за тестване може да се наложи да СЪЗДАВАТЕ тестови данни (Повечето пъти) или поне да идентифицирате подходящи тестови данни за вашите тестови случаи (дали тестовите данни вече са създадени).
Обикновено тестовите данни се създават в синхрон с тестовия случай, за който са предназначени.
Тестови данни могат да бъдат генерирани -
- Ръчно
- Масово копиране на данни от производството в тестовата среда
- Масово копиране на тестови данни от стари клиентски системи
- Автоматизирани инструменти за генериране на тестови данни
Обикновено примерни данни трябва да се генерират, преди да започнете изпълнението на теста, защото е трудно да се справите с управлението на тестовите данни в противен случай. Тъй като в много тестови среди създаването на тестови данни отнема множество предварителни стъпки или много отнемащи време конфигурации на тестовата среда. . Също така, ако генерирането на тестови данни е направено, докато сте във фаза за изпълнение на теста, може да надвишите крайния срок за тестване.
По-долу са описани няколко вида тестване, заедно с някои предложения относно нуждите им от данни за тестване.
Тестови данни за тестване на бяла кутия
В White Box Testing управлението на тестовите данни се извлича от директно изследване на кода, който ще се тества. Данните от теста могат да бъдат избрани, като се вземат предвид следните неща:
- Желателно е да се покрият колкото се може повече клонове; данни за тестване могат да бъдат генерирани така, че всички клонове в изходния код на програмата да бъдат тествани поне веднъж
- Тестване на пътя: всички пътища в изходния код на програмата се тестват поне веднъж - може да се направи подготовка на тестови данни, за да обхване възможно най-много случаи
- Отрицателно API тестване:
- Данните за тестване могат да съдържат невалидни типове параметри, използвани за извикване на различни методи
- Данните за тестване могат да се състоят в невалидни комбинации от аргументи, които се използват за извикване на методите на програмата
Тестови данни за тестване на производителността
Тестване на производителността е видът тестване, който се извършва, за да се определи колко бързо системата реагира при определено натоварване. Целта на този тип тестване не е да се открият грешки, а да се премахнат тесните места. Важен аспект на тестването на производителността е, че наборът от използвани примерни данни трябва да бъде много близо до „реални“ или „активни“ данни, които се използват при производството. Възниква следният въпрос: „Добре, добре е да тествате с реални данни, но как да получа тези данни?“ Отговорът е доста ясен: от хората, които знаят най-добре - клиентите . Те може да са в състояние да предоставят някои данни, които вече имат, или, ако нямат съществуващ набор от данни, може да ви помогнат, като предоставят обратна информация относно това как могат да изглеждат данните от реалния свят. В случай, че сте впроект за тестване на поддръжка, можете да копирате данни от производствената среда в тестовото легло. Добра практика е да се анонимизират (разбъркват) чувствителни клиентски данни като номер на социално осигуряване, номера на кредитни карти, банкови данни и др., Докато се прави копието.
Тестови данни за тестване на сигурността
Тестването на сигурността е процес, който определя дали информационната система защитава данните от злонамерено намерение. Наборът от данни, които трябва да бъдат проектирани, за да се тества напълно софтуерната сигурност, трябва да обхваща следните теми:
- Поверителност: Цялата информация, предоставена от клиенти, се съхранява в строга поверителност и не се споделя с външни страни. Като кратък пример, ако приложението използва SSL, можете да проектирате набор от тестови данни, които да проверяват дали криптирането е направено правилно.
- Почтеност: Определете дали информацията, предоставена от системата, е вярна. За да проектирате подходящи тестови данни, можете да започнете, като разгледате задълбочено дизайна, кода, базите данни и файловите структури.
- Удостоверяване: Представлява процеса на установяване на самоличността на потребител. Данните за тестване могат да бъдат проектирани като различна комбинация от потребителски имена и пароли и целта му е да провери дали само упълномощените лица имат достъп до софтуерната система.
- Упълномощаване: Разказва какви са правата на конкретен потребител. Данните за тестване могат да съдържат различна комбинация от потребители, роли и операции, за да се провери дали само потребители с достатъчни привилегии могат да изпълняват определена операция.
Тестови данни за тестване на черна кутия
При тестване в черна кутия кодът не се вижда от тестера. Вашите функционални тестови случаи могат да съдържат данни от тестове, отговарящи на следните критерии -
- Няма данни : Проверете отговора на системата, когато не са подадени данни
- Валидни данни : Проверете отговора на системата, когато са изпратени валидни тестови данни
- Невалидни данни : Проверете реакцията на системата при подаване на невалидни тестови данни
- Недопустим формат на данните : Проверете реакцията на системата, когато тестовите данни са в невалиден формат
- Набор от данни за гранично състояние : Тестови данни, отговарящи на условията за гранични стойности
- Набор от данни за еквивалентност на дялове: Тествайте данните, отговарящи на вашите дялове за еквивалентност.
- Набор от данни на таблицата за решения: Тествайте данните, които отговарят на вашата стратегия за тестване на таблицата с решения
- Набор от данни за преход на състоянието: Тестови данни, отговарящи на вашата стратегия за тестване на прехода на държавата
- Данни от теста за използване : Тествайте данните в синхрон с вашите случаи на употреба.
Забележка : В зависимост от софтуерното приложение, което ще бъде тествано, можете да използвате някои или всички от горепосочените тестови данни за създаване
Автоматизирани инструменти за генериране на тестови данни
За да генерирате различни набори от данни, можете да използвате гама от автоматизирани инструменти за генериране на тестови данни. По-долу са дадени някои примери за такива инструменти:
DTM Test Data generator е напълно персонализирана помощна програма, която генерира данни, таблици (изгледи, процедури и т.н.) за тестване на база данни (тестване на производителността, тестване на качеството, тестване на натоварване или тестване на използваемостта).
Datatect е генератор на SQL данни от Banner Software, генерира разнообразни реалистични тестови данни в ASCII плоски файлове или директно генерира тестови данни за RDBMS, включително Oracle, Sybase, SQL Server и Informix.
Заключение
В заключение, добре проектираните данни за тестване ви позволяват да идентифицирате и коригирате сериозни недостатъци във функционалността. Изборът на избрани данни за изпитване трябва да бъде преоценен във всяка фаза на многофазен цикъл на разработване на продукта. Така че, винаги го наблюдавайте.