Меню

Що таке дані тесту? Методи підготовки даних тесту на прикладі

what is test data test data preparation techniques with example

Спробуйте Наш Інструмент Для Усунення Проблем

Дізнайтеся, що таке дані тесту та як підготувати дані тесту для тестування:

У поточний епос про революційний ріст інформації та технологій тестери зазвичай відчувають значне споживання тестових даних у життєвому циклі тестування програмного забезпечення.

Тестери не лише збирають / підтримують дані з існуючих джерел, але й генерують величезні обсяги тестових даних, щоб забезпечити їхній якісний внесок у доставку продукту для реального використання.

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

Що таке дані тесту - Підготовка даних тесту

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

Що ви дізнаєтесь:

Що таке дані тестів і чому це важливо

Посилаючись на дослідження, проведене IBM у 2016 році, пошук, управління, підтримка та формування даних тесту охоплюють 30% -60% часу тестувальників. Безперечні докази того, що підготовка даних є трудомістким етапом тестування програмного забезпечення.

Середній час, проведений тестерами на TDM

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

Тим не менш, у багатьох різних дисциплінах є факт, що більшість науковців з обробки даних витрачають 50% -80% часу на розробку своєї моделі на впорядкування даних. А тепер, враховуючи законодавство, а також інформацію, що ідентифікує особу (ІПІ), залучення тестувальників стає надзвичайно гідним у процесі тестування.

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

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

Чому ми зараз не згадуємо про тестові дані? Коли ми починаємо писати наші тестові кейси для перевірки та перевірки заданих функцій та розроблених сценаріїв програми під тестом, нам потрібна інформація, яка використовується як вхід для виконання тестів для виявлення та виявлення дефектів.

шаблон автоматичного тесту для селену

І ми знаємо, що ця інформація повинна бути точною та повною для усунення помилок. Це те, що ми називаємо тестовими даними. Щоб зробити його точним, це можуть бути імена, країни тощо ..., не є конфіденційними, де дані, що стосуються контактної інформації, SSN, історії хвороби та інформації про кредитні картки, мають конфіденційний характер.

Дані можуть бути у будь-якій формі, наприклад:

  • Дані тестування системи
  • Дані тестування SQL
  • Дані тесту продуктивності
  • Дані тесту XML

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

Даними можуть бути будь-які вхідні дані для програми, будь-який файл, який завантажується програмою, або записи, прочитані з таблиць бази даних.

Підготовка належних вхідних даних є частиною тестового налаштування. Як правило, тестери називають це a підготовка дослідного зразка . На тестовому стенді всі вимоги до програмного та апаратного забезпечення встановлюються з використанням заздалегідь визначених значень даних.

Якщо у вас відсутній систематичний підхід до побудови даних написання та виконання тестових кейсів тоді є ймовірність пропустити деякі важливі тестові кейси. Тестери можуть створювати власні дані відповідно до потреб тестування.

Не покладайтесь на дані, створені іншими тестерами, або на стандартні виробничі дані. Завжди створюйте новий набір даних відповідно до ваших вимог.

Іноді неможливо створити абсолютно новий набір даних для кожної збірки. У таких випадках ви можете використовувати стандартні виробничі дані. Але не забудьте додати / вставити власні набори даних у цю існуючу базу даних. Одним з найкращих способів створення даних є використання існуючих зразків даних або тестового стенду та додавання нових даних тестового кейсу кожного разу, коли ви отримуєте той самий модуль для тестування. Таким чином ви можете створити вичерпний набір даних за період.

Випробування джерел даних

Тестери вважають, що однією із сфер генерації тестових даних є вимога до джерела даних для підмножини. Наприклад, у вас понад мільйон клієнтів, і вам потрібна тисяча з них для тестування. І ці зразки даних повинні узгоджуватися та статистично відображати відповідний розподіл цільової групи. Іншими словами, ми повинні знайти потрібну людину для тестування, що є одним з найкорисніших методів тестування випадків використання.

І ці зразки даних повинні узгоджуватися та статистично відображати відповідний розподіл цільової групи. Іншими словами, ми повинні знайти потрібну людину для тестування, що є одним з найкорисніших методів тестування випадків використання.

Крім того, в процесі існують певні екологічні обмеження. Одним із них є картографування ідентифікаційних даних. Оскільки конфіденційність є суттєвою перешкодою, тестувальникам потрібно класифікувати дані ІПС.

Тестові інструменти управління даними призначені для вирішення згаданої проблеми. Ці інструменти пропонують політику на основі стандартів / каталогу, який вони мають. Хоча це не надто безпечні вправи. Він все ще пропонує можливість перевірки того, що хтось робить.

Щоб не відставати від вирішення поточних і навіть майбутніх викликів, нам завжди слід задавати питання типу Коли / з чого починати проведення МТР? Що слід автоматизувати? Скільки інвестицій слід виділити компаніям для тестування в галузі постійного розвитку людських ресурсів та використання новіших інструментів TDM? Починати тестування з функціонального чи нефункціонального тестування? І набагато більш імовірні питання як вони.

Нижче наведено деякі найпоширеніші проблеми тестування джерел даних:

  • Команди можуть не мати належних знань та навичок інструментів генератора тестових даних
  • Охоплення тестових даних часто є неповним
  • Менша чіткість вимог до даних, що охоплюють специфікації обсягу на етапі збору
  • Тестувальні групи не мають доступу до джерел даних
  • Затримка у наданні розробниками виробничих даних до тестерів
  • Дані виробничого середовища можуть бути не повністю придатними для тестування на основі розроблених бізнес-сценаріїв
  • Великі обсяги даних можуть знадобитися за короткий проміжок часу
  • Залежності / комбінації даних для перевірки деяких бізнес-сценаріїв
  • Тестери витрачають більше часу, ніж потрібно для спілкування з архітекторами, адміністраторами баз даних та спеціалістами з управління даними для збору даних
  • В основному дані створюються або готуються під час виконання тесту
  • Кілька програм і версій даних
  • Цикли безперервного випуску для кількох програм
  • Законодавство про догляд за персональною ідентифікаційною інформацією

На білому полі тестування даних розробники готують виробничі дані. Саме тут 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

Створення ручних даних для тестування програми Open EMR

Зробимо крок уперед до створення ручних даних для тестування програми Open EMR для даних категорій набору даних.

1) Немає даних: Тестер перевіряє URL-адресу програми Open EMR та функції «Пошук або додавання пацієнта» без надання даних.

два) Дійсні дані: Тестер перевіряє URL-адресу програми Open EMR та функцію «Шукати або додати пацієнта», надаючи дійсні дані.

3) Недійсні дані: Тестер перевіряє URL-адресу програми Open EMR та функцію «Шукати або додати пацієнта», надаючи недійсні дані.

4) Нелегальний формат даних: Тестер перевіряє URL-адресу програми Open EMR та функцію «Шукати або додати пацієнта», надаючи недійсні дані.

Тестові дані для 1-4 категорій набору даних:

Зразки даних тесту 2

5) Набір даних граничного стану: Він полягає у визначенні вхідних значень для меж, які знаходяться як всередині, так і поза даними значеннями як дані.

6) Набір даних розділу еквівалентності: Це техніка тестування, яка ділить ваші вхідні дані на вхідні значення дійсних та недійсних.

Дані тесту для 5гота 6гокатегорії наборів даних, що стосується імені користувача та пароля Open EMR:

Відкрити дані тесту EMT 3

7) Набір даних таблиці рішень: Це техніка для визначення ваших даних за допомогою комбінації входів для отримання різних результатів. Цей метод тестування чорних ящиків допомагає зменшити ваші зусилля щодо перевірки кожної комбінації даних тесту. Крім того, ця методика може забезпечити вам повне покриття тесту.

Будь ласка, дивіться нижче набір даних таблиці рішень для імені користувача та пароля програми Open EMR.

Дані таблиці рішень 4

Розрахунок комбінацій, виконаний у таблиці вище, описаний для вашої детальної інформації, як показано нижче. Це може вам знадобитися, коли ви робите більше чотирьох комбінацій.

  • Кількість комбінацій = Кількість умов 1 Значення * Кількість умов 2 Значення
  • Кількість комбінацій = 2 ^ Кількість істинних / помилкових умов
  • Приклад: Кількість комбінацій - 2 ^ 2 = 4

8) Набір даних тестування стану переходу: Саме техніка тестування допомагає підтвердити перехід стану випробовуваного додатка (AUT), надаючи системі вхідні умови.

Наприклад, ми входимо в програму Open EMR, надаючи правильне ім’я користувача та пароль з першої спроби. Система надає нам доступ, але якщо ми вводимо неправильні дані для входу, система забороняє доступ. Тестування переходу стану перевіряє, скільки спроб входу можна зробити до закриття Open EMR.

У наведеній нижче таблиці вказано, як відповідають правильні або неправильні спроби входу

Вхідні спроби тестових даних 5

9) Дата тестування випадку використання: Це метод тестування, який визначає наші тестові випадки, що фіксують наскрізне тестування певної функції.

Приклад, Відкрити вхід в EMR:

Дані тесту на успішність 6

Також читайте => Методи управління даними даних

Властивості хороших тестових даних

Як тестувальник ви повинні протестувати модуль „Результати іспиту” веб-сайту університету. Вважайте, що ціла програма інтегрована і перебуває у стані „Готовий до тестування”. „Модуль іспиту” пов’язаний із модулями „Реєстрація”, „Курси” та „Фінанси”.

Припустимо, що у вас є достатня інформація про програму, і ви створили вичерпний перелік сценаріїв тестування. Тепер вам доведеться розробити, задокументувати та виконати ці тестові кейси. У розділі «Дії / кроки» або «Тестові входи» тестових випадків вам доведеться вказати прийнятні дані як вхідні дані для тесту.

Дані, зазначені у тестових випадках, повинні бути правильно підібрані. Точність стовпця „Фактичні результати” Документа про тестування в першу чергу залежить від даних тесту. Отже, етап підготовки вхідних тестових даних є суттєво важливим. Отже, ось мій виклад 'Тестування БД - Стратегії підготовки даних до тесту'.

Властивості даних тесту

Дані тесту повинні бути підібрані точно, і вони повинні мати наступні чотири якості:

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

Реалістично, це означає, що дані повинні бути точними в контексті реальних сценаріїв. Наприклад, для тестування поля «Вік» усі значення повинні бути позитивними та 18 або вище. Цілком очевидно, що кандидатам на вступ до університету, як правило, виповнилося 18 років (це може бути визначено по-різному з точки зору бізнес-вимог).

Якщо тестування проводиться з використанням реалістичних даних тесту, це зробить додаток більш надійним, оскільки більшість можливих помилок можна захопити за допомогою реалістичних даних. Ще однією перевагою реалістичних даних є їх повторне використання, що економить наш час та зусилля для створення нових даних знову і знову.

Коли ми говоримо про реалістичні дані, я хотів би познайомити вас з концепцією золотого набору даних. Золотий набір даних - це той, який охоплює майже всі можливі сценарії, що виникають у реальному проекті. Використовуючи GDS, ми можемо забезпечити максимальне охоплення тестуванням. Я використовую GDS для тестування регресії в своїй організації, і це допомагає мені перевірити всі можливі сценарії, які можуть виникнути, якщо код потрапляє у робочу коробку.

На ринку доступно багато інструментів для генерації тестових даних, які аналізують характеристики стовпців та визначення користувачів у базі даних, і на основі них вони генерують реалістичні тестові дані для вас. Мало хороших прикладів інструментів, що генерують дані для тестування баз даних Генератор даних DTM , Генератор даних SQL і Мокару .

2. Практично дійсне:

Це схоже на реалістичне, але не те саме. Ця властивість більше пов'язана з бізнес-логікою AUT, наприклад значення 60 є реалістичним у віковому полі, але практично недійсним для кандидата випускних чи навіть магістерських програм. У цьому випадку допустимим діапазоном буде 18-25 років (це може бути визначено у вимогах).

3. Універсальний для охоплення сценаріїв:

що таке .swf файл

В одному сценарії може бути кілька наступних умов, тому вибирайте дані проникливо, щоб охопити максимальні аспекти одного сценарію з мінімальним набором даних, наприклад Створюючи дані тесту для модуля результатів, не враховуйте лише випадок із звичайними студентами, які плавно завершують свою програму. Зверніть увагу на студентів, які повторюють один і той же курс і належать до різних семестрів чи навіть різних програм. Набір даних може виглядати так:

Містер# Student_ID Ідентифікатор_програми Ідентифікатор курсу Оцінка
1 BCS-осінь2011-ранок-01 BCS-F11 CS-401 ДО
два BCS-Весна2011-Вечір-14 BCS-S11 CS-401 B +
3 MIT-осінь2010-полудень-09 MIT-F10 CS-401 ДО-
... ... ... ... ...

Може існувати ще кілька цікавих та хитрих під-умов. Наприклад обмеження років на здобуття дипломної програми, проходження необхідного курсу для реєстрації курсу, максимум ні. курсів, які студент може записати на один семестр і т. д. Переконайтеся, що мудро охоплюєте всі ці сценарії кінцевим набором даних.

хороші дані тесту

4. Виняткові дані (якщо застосовується / потрібно):

Можуть існувати певні виняткові сценарії, які трапляються рідше, але вимагають підвищеної уваги, коли трапляються, наприклад проблеми, пов’язані зі студентами-інвалідами.

Ще одне гарне пояснення та приклад виняткового набору даних видно на зображенні нижче:

Виняткові дані

Винос:

Тестові дані відомі як добрі тестові дані, якщо вони є реалістичними, дійсними та універсальними. Додатковою перевагою є те, що дані також охоплюють виняткові сценарії.

Методи підготовки даних тесту

Ми коротко обговорили важливі властивості тестових даних, а також розробили, наскільки важливим є вибір тестових даних під час тестування бази даних. Тепер обговоримо ' методи підготовки даних тестів ' .

Існує лише два способи підготовки даних тесту:

Спосіб No1) Вставити нові дані

Отримайте чисту БД і вставте всі дані, як зазначено у ваших тестових випадках. Після введення всіх необхідних та бажаних даних починайте виконувати тестові кейси та заповнюйте стовпці «Передача / невдача», порівнюючи «Фактичний результат» із «Очікуваний результат». Звучить просто, правда? Але почекайте, це не так просто.

Нижче наведено кілька основних та критичних проблем:

  • Порожній екземпляр бази даних може бути недоступним
  • Вставлених даних тесту може бути недостатньо для тестування деяких випадків, таких як тестування продуктивності та навантаження.
  • Вставка необхідних тестових даних у порожню БД непроста робота через залежності таблиці бази даних. Через це неминуче обмеження вставка даних може стати важким завданням для тестувальника.
  • Вставка обмежених даних тесту (лише відповідно до потреб тесту) може приховати деякі проблеми, які можна було знайти лише за допомогою великого набору даних.
  • Для вставки даних можуть знадобитися складні запити та / або процедури, і для цього буде необхідна достатня допомога або допомога розробника (ів) БД.

Вищезазначені п’ять питань є найбільш критичними та найбільш очевидними недоліками цієї техніки для підготовки даних тесту. Але є й деякі переваги:

  • Виконання TC стає ефективнішим, оскільки БД має лише необхідні дані.
  • Виділення помилок не вимагає часу, оскільки в БД присутні лише дані, зазначені у тестових випадках.
  • Менше часу, необхідного для тестування та порівняння результатів.
  • Безкоштовний процес тестування

Спосіб No2) Виберіть зразок підмножини даних із фактичних даних БД

Це здійсненна і більш практична техніка підготовки даних тесту. Однак це вимагає надійних технічних навичок і вимагає детальних знань про схему баз даних та SQL. У цьому методі вам потрібно скопіювати та використовувати виробничі дані, замінивши деякі значення полів фіктивними значеннями. Це найкраща підмножина даних для вашого тестування, оскільки вона представляє виробничі дані. Але це може бути нездійсненним постійно через проблеми безпеки та конфіденційності даних.

Винос:

У наведеному вище розділі ми обговорювали вище методики підготовки даних тестів. Коротше кажучи, є дві методики - або створити свіжі дані, або вибрати підмножину з уже існуючих даних. І те, і інше потрібно виконувати таким чином, щоб вибрані дані забезпечували охоплення різних сценаріїв тестування, в основному дійсного та недійсного тесту, тесту продуктивності та нульового тесту.

В останньому розділі ми також коротко оглянемо підходи до створення даних. Ці підходи корисні, коли нам потрібно генерувати нові дані.

Підходи до створення тестових даних:

  • Генерування даних тесту вручну: При цьому підході тестові дані вводяться тестувальниками вручну відповідно до вимог тестового випадку. Це час, який займає процес, а також схильний до помилок.
  • Автоматизоване генерування тестових даних: Це робиться за допомогою засобів генерації даних. Головною перевагою такого підходу є його швидкість і точність. Однак це коштує дорожче, ніж генерація тестових даних вручну.
  • Введення внутрішніх даних : Це робиться за допомогою запитів SQL. Цей підхід може також оновити наявні дані в базі даних. Це швидко і ефективно, але його слід застосовувати дуже обережно, щоб існуюча база даних не пошкодилася.
  • Використання сторонніх інструментів : На ринку доступні інструменти, які спочатку розуміють ваші сценарії тестування, а потім генерують або вводять дані відповідно, щоб забезпечити широке охоплення тестуванням. Ці інструменти точні, оскільки їх налаштовано відповідно до потреб бізнесу. Але вони досить дорогі.

Винос:

Існує 4 підходи до тестування даних:

  1. Довідник,
  2. автоматизація,
  3. внутрішнє введення даних,
  4. та сторонні інструменти.

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

Висновок

Створення повних даних тестування програмного забезпечення відповідно до галузевих стандартів, законодавства та базових документів реалізованого проекту є одним із основних обов'язків тестувальників. Чим більше ми ефективно керуємо тестовими даними, тим більше ми можемо застосовувати продукти без помилок для реальних користувачів.

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

Нам завжди потрібно придумувати запитання щодо пошуку інноваційних та економічно вигідніших методів аналізу та вибору методів тестування, включаючи використання інструментів для генерації даних. Широко доведено, що добре розроблені дані дозволяють ідентифікувати дефекти програми під час випробування на кожній фазі багатофазної SDLC.

Нам потрібно бути креативними та брати участь разом із усіма учасниками як у нашій спритній команді, так і поза нею. Будь ласка, поділіться своїми відгуками, досвідом, питаннями та коментарями, щоб ми могли продовжувати наші технічні дискусії, щоб продовжувати максимізувати наш позитивний вплив на AUT шляхом управління даними.

Підготовка належних тестових даних є основною частиною “налаштування середовища тестового проекту”. Ми не можемо просто пропустити тест, сказавши, що повні дані не доступні для тестування. Випробувач повинен створити власні дані тестування додатково до існуючих стандартних виробничих даних. Ваш набір даних повинен бути ідеальним з точки зору вартості та часу.

Будьте творчими, використовуйте власні навички та судження, щоб створювати різні набори даних, а не покладатися на стандартні виробничі дані.

Частина II - Друга частина цього підручника на ' Тестуйте генерацію даних за допомогою Інструменту GEDIS Studio Online '.

Ви стикалися з проблемою неповних даних тесту для тестування? Як вам це вдалося? Будь ласка, поділіться своїми порадами, досвідом, коментарями та питаннями для подальшого збагачення цієї теми обговорення.

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

^