Управление ошибками, отладка, тестирование

Спецсеминар "Разработка свободного ПО": http://uucode.com/oss2004/. 13-я лекция, 4 декабря 2004.

Отвлечения

"Mars Rescue Mission Challenge" <http://www.frank-buss.de/marsrescue/index.html> Есть карта. Провести корабль через препятствия и успешно посадить. Варианты оптимизации: кратчайший путь, меньше горючего, и т.д. Sponsored by Dr. Dobb's Journal

"День встраиваемых технологий Microsoft" в Санкт-Петербурге. <http://www.msembedded.ru/seminar_15_12.htm> 15 декабря

Забавно: <http://www.ntg.nl/eurotex/Raichle.pdf> Is TEX (easily) extendible? The answer is: No! There are many reasons: ...; tex.web is 600 pages of documented source code.

Paul Tchistopolskii, "как находиться на рынке труда вечно" <http://groups.google.com/groups?selm=ummcu6b9oap62a%40corp.supernews.com>

Управление ошибками

Ошибки бывают в любой программе. И в TeX'е тоже. Поэтому надо уметь с ними обращаться.

Обязательно нужна bugzilla или что-нибудь подобное. <http://www.bugzilla.org/>

На примере bugzill'ы. В нём заведены разделы (проекты и продукты). Кто-то (пользователь, другой разработчик и т.д.) находит нужный раздел и вводит сообщение об ошибке. Появился bug в статусе "NEW".

У каждого бага есть свой владелец. Когда bug is "new", он автоматически назначается кому нужно ("assigned to"). Bug можно (и часто нужно) reassign.

Жизненный цикл бага и прочие коментарии.

Bug Status:

Resolutions:

Severity:

Priority:

Список "NEW" рассылается каждый день по почте.

Есть список непофиксенных багов. Можно посмотреть этот списко для любого разработчика.

Системы "всё-в-одном" не очень эффективны: нужно именно отслеживание ошибок, а не интеграция с cvs и прочим. Возможно превращение cvs в нечто типа TODO. Это нормально, но для отслеживания TODO нужны отдельные инструменты.

Сообщения об ошибках должны быть "хорошие". Это означает много чего. См., например, help от bugzilla. Или:

"Painless Bug Tracking" <http://joelonsoftware.com/articles/fog0000000029.html>

Every good bug report needs exactly three things.

  1. Steps to reproduce,
  2. What you expected to see, and
  3. What you saw instead.

Плохой report? пользователь: вытащить клещами. Коллега: послать на !#$.

Важно: не принимать bug reports иными путями кроме как bugzilla.

Если bug исправлен, надо чтобы он не появился снова в новой версии. Возвратное тестирование, cvs и другие инструменты.

Почему надо иметь тестеров. "Top Five (Wrong) Reasons You Don't Have Testers" <http://joelonsoftware.com/articles/fog0000000067.html>

Отладка

Если планируется отладка, то: "gcc -g", optimization off. Отладчик: gdb. У gdb есть есть GUI-обёртка "ddd'. Команды gdb:

Если есть so-части, то вначале "break main", затем "run", и затем уже нужные "break".

Можно подключиться к уже запущенному процессу.

Если был coredump и остался core, то можно так: :

$ gdb core prog,

посмотреь stack trace, понять, где это случилось, а иногда и почему.

Разнообразные методы отладки (многое взято из "практика программирования" Кернингана, Пайка).

log4j и аналоги. логгеры, иерархия логгеров, уровни отладки, аппендеры.

Тестирование

Без автоматического тестирования жить нельзя.

Надо начинать делать как можно раньше.

Для каждой ошибки надо писать тест.

Упрощает внесение исправлений (даёт уверенность) Есть понятие "unit testing". Всё эти хорошо рассказывается в книгах по XP.

Иногда бывают ошибки в тестах

Стрессовое тестирование

Автоматическая генерация входных данных

Что тестировать:

Производительность

Преждевременная оптимизация есть корень всех зол.

Оптимизировать надо только узкие места.

Есть профилировщики

Лучше всего обычно: улучшить алгоритм и структуры данных.