Меню

Повне керівництво з тестування перевірки складання (тестування BVT)

build verification testing complete guide

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

Що таке тестування перевірки збірки (BVT)?

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

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

Тестування перевірки складання (тестування BVT)

BVT також називається Тестування диму або будує перевірку прийнятності (НДНТ)

Нова збірка перевіряється в основному на дві речі:

  • Перевірка збірки
  • Прийняття збірки

Деякі основи BVT:

  • Це підмножина тестів, які перевіряють основні функціональні можливості.
  • BVT, як правило, запускаються на щоденних збірках, і якщо BVT не вдається, збірку відхиляють, а нову збірку випускають після завершення виправлення.
  • Перевага BVT полягає в тому, що він економить зусилля команди випробувачів для налаштування та тестування збірки при порушенні основних функціональних можливостей.
  • Розробляйте BVT досить ретельно, щоб охопити основні функціональні можливості.
  • Зазвичай BVT не повинен працювати більше 30 хвилин.
  • BVT - це різновид Регресійне тестування , зроблені для кожного нового збірки.

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

Яке головне завдання у версії Build? Очевидно, файл 'реєстрація', тобто включити всі нові та змінені файли проекту, пов'язані з відповідними збірками. BVT був введений в першу чергу для перевірки початкової працездатності збірки, тобто для перевірки: чи всі нові та змінені файли включені до випуску, усі формати файлів правильні, кожна версія файлу та мова, прапори, пов'язані з кожним файлом.

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

Які тестові кейси слід включати до BVT?

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

етапи життєвого циклу розвитку системи з прикладами

Ось кілька простих порад для включення Тестові кейси у вашому BVT Automation Suite:

  • До BVT включайте лише критичні тестові випадки.
  • Усі тестові випадки, включені до BVT, повинні бути стабільними.
  • Усі тестові випадки мали знати очікуваний результат.
  • Переконайтеся, що всі включені критичні тестові випадки функціональності є достатніми для охоплення тестів додатків.

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

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

Наприклад, Тестові кейси, які слід включити до програми BVT for Text editor (Лише деякі зразки тестів):

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

Це декілька зразків тестових випадків, які можна позначити як „критичні”, і для кожної незначної або серйозної зміни у застосуванні ці основні критичні тестові випадки слід виконувати. Це завдання легко виконати BVT.

Костюми автоматизації BVT потрібно підтримувати та модифікувати час від часу. Наприклад включати тестові приклади в BVT, коли доступні нові стабільні модулі проекту.

Що станеться, коли запуститься BVT Suite?

Скажімо, набір тестів автоматизації верифікації побудови, виконаний після будь-якої нової збірки.
# 1) Результат виконання BVT надсилається на всі ідентифікатори електронної пошти, пов’язані з цим проектом.
# два) Власник BVT (особа, яка виконує та підтримує набір BVT) перевіряє результат BVT.
# 3) Якщо BVT не вдається, тоді власник BVT діагностує причину несправності.
# 4) Якщо причиною несправності є дефект збірки, вся відповідна інформація з журналами відмов надсилається відповідним розробникам.
# 5) Розробник на своїх первинних діагностичних відповідях команді про причину несправності. Чи справді це помилка? А якщо це помилка, то яким буде його сценарій виправлення помилок.
# 6) Після виправлення помилки ще раз виконується тестовий пакет BVT, і якщо збірка проходить BVT, збірка передається тестовій групі для подальшої деталізації функціональності, продуктивності та інших тестів.

Цей процес повторюється для кожної нової збірки.

Чому BVT або Build не вдалося?

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

Поради щодо успіху BVT:

# 1) Витратьте значний час на написання сценаріїв тестів BVT.
# два) Запишіть якомога більше детальної інформації, щоб діагностувати результат проходження або невдачі BVT. Це допоможе команді розробників налагодити і швидко дізнатися причину несправності.
# 3) Виберіть стабільні тестові кейси для включення до BVT. Що стосується нових функцій, якщо новий критичний тестовий файл послідовно передається в іншій конфігурації, рекламуйте цей тестовий варіант у своєму наборі BVT. Це зменшить ймовірність частих збоїв збірки через нові нестабільні модулі та тестові приклади.
# 4) Автоматизуйте процес BVT наскільки це можливо. Від процесу випуску збірки до результату BVT - автоматизуйте все.
# 5) Заявіть певні штрафи за зрив складання ;-) Підійдуть деякі шоколадні цукерки або спільна кава-вечірка від розробника, який порушує збірку.

Висновок

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

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

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

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

заміна потокового фільму сайту для фільму 4k

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

^