Меню

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

build verification testing complete guide

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

Какво е тестване за проверка на компилация (BVT)?

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

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

Тестване за проверка на компилация (BVT тестване)

BVT също се нарича Тестване на дим или изгражда тестове за приемане (НДНТ)

New Build се проверява главно за две неща:

  • Проверка на компилация
  • Изграждане на приемане

Някои основи на BVT:

най-доброто приложение за изтегляне на музика за android
  • Това е подгрупа от тестове, които проверяват основните функционалности.
  • BVT обикновено се изпълняват при ежедневни компилации и ако BVT не успее, компилацията се отхвърля и нова компилация се пуска след приключване на корекциите.
  • Предимството на BVT е, че спестява усилията на тестовия екип да създаде и тества компилация, когато основната функционалност е нарушена.
  • Проектирайте BVT достатъчно внимателно, за да покриете основната функционалност.
  • Обикновено BVT не трябва да работи повече от 30 минути.
  • BVT е вид Тестване на регресия , направено при всяка нова компилация.

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

Каква е основната задача в Build Release? Очевидно файлът „чекиране“, т.е. да включва всички нови и модифицирани файлове на проекти, свързани със съответните компилации. 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 процеса, моля, споделете го с нашите читатели в коментарите по-долу.

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

^