Проверка этих отчетов всегда выявляет множество «вложенных» ошибок, поскольку они просто дублируют существующие, а в некоторых случаях даже не содержат ошибок для этой конкретной части программного обеспечения. Важной частью любой системы отчетов об ошибках является то, как она управляет временем существования каждой ошибки. обычно делятся на три фазы: начальную «фазу открытия», «фазу фиксации/уничтожения» и «фазу закрытия/захоронения». фаза».
Первая фаза
Начальная фаза — это когда ошибка впервые появляется в системе, после чего следуют различные типы сортировки, в ходе которых ошибка проверяется и принимается.
Различные системы поддерживают обнаружение ошибок по-разному, но ключевое решение заключается в том, разрешено ли пользователям сообщать об ошибках непосредственно в систему контроля ошибок. Поначалу это привлекательная идея, но, как я уже упоминал, большинство пользователей не очень хорошо умеют сообщать об ошибках.
Выбор этого маршрута обычно приводит к закрытию ряда отчетов об ошибках на этом этапе, поскольку они не могут быть проверены ни пользователем, ни пользователем. проверяя или даже сообщая об ошибке, иначе они не будут приняты (например, «Мы больше не поддерживаем Internet Explorer 4 ни на одной платформе и никогда не поддерживали ее на других платформах». Мак»).
В рамках этого процесса необходимо будет собрать свидетельства об ошибке и включить их в отчет об ошибке, а также присвоенный ему уровень серьезности, который в некоторых случаях может определяться голосованием («Действительно ли нам нужно исправить этот?").
Открытая ошибка
Как только ошибка будет обнаружена, ее необходимо будет передать человеку или группе, которые собираются ее исправить. Процесс исправления может сильно различаться, но для него придется использовать те инструменты, которые мы уже используем: среды разработки, системы контроля исходного кода и наборы тестов.
Давайте не будем забывать, что тестирование является важной частью исправления ошибок.
Давайте не будем забывать, что тестирование является важной частью исправления, и поэтому нам понадобится какой-то способ передать этот отчет об ошибке тестировщику, чтобы убедиться, что он устранен. В какой-то момент ошибка будет устранена, и тогда потребуется ее закрытие, при котором изменения будут объединены и применены по мере необходимости к любым другим связанным системам.
Итак, каковы были наши критерии при выборе собственной системы отчетов об ошибках? По разным причинам мы не были заинтересованы в том, чтобы пользователи могли вносить ошибки непосредственно в нашу систему — мы собираемся использовать другой путь.
Далее нам нужно было, чтобы система отчетов об ошибках работала с нашей существующей системой контроля исходного кода — Subversion. Наконец, было бы хорошо, если бы система отчетов об ошибках могла в некоторой степени интегрироваться с Eclipse IDE (интегрированной средой разработки), которую мы используем большую часть времени.
В Eclipse есть модуль Mylyn, предназначенный именно для такой интеграции, поэтому поддержка Mylyn была бы полезна. Mylyn уже несколько выпусков является частью Eclipse и был улучшен в текущей версии (3.6 или «Helios»), как описано во вставке ниже.
К сожалению, не все наше программирование выполняется в Eclipse, а среда Apple Xcode, похоже, не поддерживает никаких программ. система контроля ошибок (в программном обеспечении Apple никогда не бывает ошибок, его просто нужно правильно хранить), поэтому нам нужен был хороший отдельный пользовательский интерфейс слишком.
