Меню

Таблиця перевірки поля (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 років досвіду в області тестування програмного забезпечення.

Повідомте нас, якщо у вас виникнуть запитання.

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^