Офіс в Україні: +38 (063) 50 74 707

Офіс у США: +1 (212) 203-8264

Ручне тестування

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

Мобільне тестування

Оптимізуйте свої мобільні додатки для бездоганної роботи на всіх пристроях і платформах за допомогою наших комплексних послуг з мобільного тестування.

Автоматизоване тестування

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

Функціональне тестування

Вдосконалюйте основний функціонал вашого додатку за допомогою наших послуг з функціонального тестування

ПЕРЕГЛЯНУТИ ВСІ ПОСЛУГИ

Головна » Збірка (в BTS)

Збірка (в BTS)

У контексті систем відстеження помилок (BTS) термін ” збірка ” означає конкретну версію програмного додатку або системи, яка генерується після внесення командою розробників низки змін до коду, оновлень або виправлень помилок. Збірка зазвичай відстежується в BTS, щоб пов’язати проблеми, дефекти або запити на функції з конкретними ітераціями програмного забезпечення. У тестуванні програмного забезпечення збірки мають важливе значення, оскільки вони є відправною точкою для виявлення та усунення помилок в контексті поточного стану, функціональності та версії програмного забезпечення.

Ключові аспекти “збірки” в системах відстеження помилок (BTS)

  1. Контроль версій: кожна збірка являє собою версію програмного забезпечення, яка містить зміни коду, виправлення помилок або покращення. Цим збіркам присвоюються унікальні ідентифікатори, які зазвичай називають номерами збірок або номерами версій, які допомагають тестувальникам і розробникам відстежувати, в якій саме ітерації програмного забезпечення виникла проблема. Наприклад, збірка може бути позначена як “Збірка 102” або “Версія 1.2.3”.
  2. Прив’язка помилок до збірок: важливою частиною відстеження помилок у BTS є прив’язка дефектів (або помилок) до конкретних збірок. Кожна помилка, про яку повідомляється в системі, може бути пов’язана зі збіркою, в якій вона була виявлена, що допомагає відстежити помилку до її джерела і зрозуміти, які зміни її спричинили. Це важливо для налагодження та регресійного тестування, оскільки дозволяє команді розробників точно знати, які зміни (у відповідній збірці) могли призвести до дефекту.
  3. Інформація про збірку в BTS: коли про помилку повідомляється в BTS, зазвичай записуються деталі збірки, в якій було виявлено проблему. Інформація може включати в себе наступне:
    • Ідентифікатор/версія збірки: Конкретний ідентифікатор або версія збірки.
    • Середовище збірки: Середовище, в якому було розгорнуто збірку, наприклад, операційні системи, версії браузерів або конфігурації обладнання.
    • Примітки до випуску: Примітки, що описують зміни або виправлення, включені до цієї конкретної збірки.
    • Дата збірки: Дата і час, коли було створено збірку, що допомагає зрозуміти графік змін.
    • Статус розгортання: Чи перебуває збірка на стадії розробки, тестування або виробництва.
  4. Перевірка та тестування збірки: системи відстеження помилок часто відстежують, чи існує помилка в конкретній збірці і чи виправлена вона в наступних збірках. Після застосування виправлення в конкретній збірці тестувальники повторно перевіряють виправлення в наступних збірках. Наприклад, якщо про помилку було повідомлено у “Збірці 102”, тестувальники перевірять, чи вона все ще присутня у “Збірці 103” після застосування виправлення.
  5. Примітки до збірки та релізу: BTS може містити посилання на примітки до релізу для конкретних збірок, що дозволяє тестувальникам, розробникам та зацікавленим сторонам бачити, які зміни були внесені між збірками. У цих примітках до релізу детально описані виправлення помилок, нові функції та будь-які інші зміни у збірці, що допомагає командам зрозуміти контекст, в якому були внесені або вирішені помилки.

Приклад використання “Build” у системі відстеження помилок (BTS)

  • Звіт про помилку: тестувальник виявив помилку в програмному забезпеченні, коли кнопка входу в систему не реагує в останній версії.
  • Внесення помилки: тестувальник реєструє помилку в BTS, прив’язуючи її до “Build 2.3.1”. Система записує всі відповідні деталі, включаючи кроки для відтворення, очікувану поведінку, фактичну поведінку і версію збірки.
  • Розслідування: команда розробників розглядає проблему і визначає, що вона була спричинена нещодавньою зміною в коді інтерфейсу користувача у збірці 2.3.1.
  • Виправлення помилки: розробник виправляє проблему в наступній збірці, “Збірка 2.3.2”, і пов’язує звіт про помилку з цією збіркою, щоб вказати на виправлення.
  • Перевірка: тестувальники перевіряють, чи виправлено ваду у збірці 2.3.2, і закривають звіт про ваду в BTS, відзначаючи успішне виправлення і прив’язуючи його до виправленої збірки.

Related Terms