Відстеження помилок за допомогою bugzilla

Відео: Як налаштувати 404 помилку? Андрій Осипов TV # 90

Інструмент, який буде розглянутий, є невід`ємною частиною циклу розробки і поширення програмного забезпечення. Призначення Bugzilla - це відстеження помилок в ПЗ і одночасно відстеження запитів на зміни.


Перш ніж розглядати систему стеження за вадами Bugzilla (https://bugzilla.org), я визначу її основні поняття і коротко розгляну необхідні компоненти робочого процесу в розробці ПЗ.

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

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

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




Крім цього, збір помилок може бути автоматизований - тоді користувачеві в разі аварійного завершення роботи програми достатньо буде дати згоду на відправку даних про помилку розробнику. Наприклад, Firefox в разі аварійного завершення роботи відображає діалог, в якому пропонується відправити необхідну інформацію про проблему (відомості про систему і дамп пам`яті в момент виникнення помилки).

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




Таким чином, можна виділити основні завдання системи відслідковування помилок:
- Реєстрація помилки - приміщення записи в список нових помилок.
- Фільтрація помилок - виділення важливих і незначних помилок, угруповання і т.п.
- Визначення відповідального за виправлення помилки особи.
- Відстеження стану помилки - в процесі розгляду, виправлення, тестування, або помилка виправлена.
- Пошук по базі помилок.

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

Тепер настав час розглянути систему Bugzilla версії 3.2.3 (це не останній стабільний реліз Bugzilla, однак оскільки автор не заглиблюється в специфіку, все написане актуально і для гілки 3.4.x.), яка розроблена спільнотою Mozilla.org (http: // mozilla .org) і активно їм використовується, а також побачити можливості, які пропонує дана система своїм користувачам.

---

Мрієте про iPad mini, на якому так само можна використовувати Bugzilla? Тоді Вас напевно зацікавить Яблучний Конкурс (https://apple2014.smoservice.ru) від SMOservi. Все, що від Вас потрібно - стати клієнтом даного сервісу. І тоді, хто знає, можливо саме Ви станете щасливим володарем новенького iPad!