Меню

Таблица за валидиране на полета (FVT): Техника за проектиране на тестове за валидиране на полета

field validation table

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

Въведение в техниката за проектиране на теста за полева проверка (FVT):

В този цифров свят, „КАЧЕСТВО“ е терминът, който се използва по-широко във всяка индустрия.

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

Основната цел на всяка организация е да обслужва бизнеса с добро качество.

Как може да се гарантира качеството? Единственият отговор на това е тестването. Тестването е единственият ключов фактор, с който можем да гарантираме качество.

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

Общ преглед

Успехът на тестването се разпространява в различни фази на Жизнен цикъл на софтуерния тест (STLC) . Но най-важното е колко ефективно тестовите случаи са предназначени за тестване на приложение или софтуер?

Таблица за проверка на полето

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

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

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

Основният принцип или основната идея на тази техника е да покаже как тя може да се използва за проектиране или писане на оптимални тестови случаи с максимално покритие на теста.

Въведение в FVT

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

Може ли да се измери качеството на софтуера?

Да, тестването играе основна роля, за да се гарантира качеството на проект или приложение.

Как да се гарантира дали тестовите случаи осигуряват 100% покритие на теста?

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

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

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

Какво е таблица за проверка на полето (FVT)

  • Това е една от техниките за тестово проектиране за валидиране на полета в приложение.
  • Тази техника се използва главно за всички видове приложения, където се изисква проверка на полето.

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

Понякога може да остане незабелязано или поради липса на концентрация или осведоменост на тестерите някои полета в приложението може да не са напълно валидирани.

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

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

какво представляват метаданните при съхранението на данни

Роля на тестер

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

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

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

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

Прилагане на FVT

# 1) Първо, стандартната или обща таблица трябва да бъде създадена за различни типове данни, както е показано по-долу. Това е еднократна дейност. Помислете за всички валидни и невалидни входове.

Тип данниВалидни входове

Невалидни входове
Цели числа или числа• Само числа
• По-малко от границата (N)
• Въведете стойността в рамките на лимита (N + 1) / 2		• Повече от ограничението (N + 1)
• Числа с точност
• Числа в експоненциална форма
• Отрицателни цели числа
• Само азбуки
• Числа + Азбуки
• Числа + Специални символи
• Unicode символи, напр. U + 0000, U + 0001
Струна• Само азбуки
• Само числа
• Само специални символи
• Числа + Азбуки
• Числа + Специални символи
• Азбуки + Специални символи
• По-малко от границата (N)
• Въведете стойността в рамките на лимита (N + 1) / 2		• Повече от ограничението (N + 1)
• Unicode символи, напр. U + 0000, U + 0001
Дата• Проверете дали инструментът за избор на дата присъства или не
• Проверете дали полето за дата не може да се редактира
• Уверете се, че при щракване с десния бутон върху полето за дата опцията за поставяне трябва да бъде деактивирана и опцията за копиране трябва да бъде активирана
• Уверете се, че след щракване върху датата в календара тя трябва да се покаже в полето за дата
• Изберете високосна година и проверете дните през месец февруари
• Изберете не високосна година и проверете дните през месец февруари
• Уверете се, че календарът има възможност за избор на всяка година, месец (комбинирано поле, падащ списък, връзки и т.н.)
• Уверете се, че в инструмента за избор на дата присъства бутон за изчистване, за да премахнете избраната дата

Таблица 1: Стандартна или обща таблица за проверка на полето

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

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

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

Специфична за приложение таблица за проверка на полето

Таблица 2: Таблица, специфична за приложението за проверка на полето

Предимства на FVT

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

Заключение

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

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

За автора:

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

Уведомете ни, ако имате някакви въпроси.

PREV Урок | СЛЕДВАЩ урок

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

^