Системы отслеживания ошибок (bug tracking system BTS)

Печать
Рейтинг пользователей: / 7
ХудшийЛучший 

Системы отслеживания ошибок
(
bug tracking system BTS)

Что это такое BTS

Вначале определимся, что такое отчет о проблеме (Bug Report) и в чем состоит отслеживание проблем (bug tracking).

Итак, отслеживание проблемы (bug tracking) в простейшем варианте - это процесс, включающий в себя обнаружение ошибки, ее описание, исправление и проверку этого исправления, т.е. процесс “слежения” за багом в течение всего как его жизненного цикла, так и жизненного цикла разработки в целом.

Что такое баг (bug)? Прежде всего под багом понимают ошибку в программе, проявляющуюся при ее использовании. Багом можно назвать так же и недокументированные или нежелательные, "побочные" реакции программы на те или иные действия пользователя равно как и при использовании ее одновременно с другим ПО или в другой аппаратной конфигурации.

Существуют и другие определения багов. В своей книге "Тестирование программного обеспечения" Сэм Канер приводит определение: "Если программа не делает того, чего пользователь от нее вполне обосновано ожидает, значит налицо программная ошибка.”

Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать, насколько программа не справляется со своей задачей, – это исключительно субъективная характеристика.

Определение ошибок как расхождения между программой и ее спецификацией — не верно. Так как даже точно соответствующая спецификации программа содержит ошибки в том случае, если есть ошибки и в самой спецификации.

В литературе можно встретить целый ряд синонимов этого понятия. Помимо бага довольно часто встречаются такие термины как ошибка (error), проблема (problem), дефект (defect), неисправность (fault) и конечно же "жаргонный" глюк. Но какой бы термин мы не использовали, суть его остается неизменной.

Не следует путать баги (ошибки, дефекты и т.п.) с т.н. фичами (feature). Мы склонны объединять под этим понятием прежде всего те черты и свойства программы, которых она не имеет, но на наш взгляд очень ей не помешали бы. Безусловно, фичи сугубо субъективны. Как правило, в четко организованном и спланированном проекте их встречаться не должно, так как вся функциональность программы должна быть оговорена еще до начала разработки (см. жизненный цикл ПО). Особенно это касается тех проектов, которые делаются под определенного заказчика.

Отчет о проблеме – это по сути его описание. Из каких элементов состоит это описание, как правильно составлять отчет о проблеме рассмотрим ниже.

Система отслеживания ошибок (BTS) — это программный продукт, основанный на использовании базы данных и контролирующий все этапы жизненного цикла ошибок в ПО: от инициализации до момента исправления. Конечная цель BTS — улучшение менеджмента разработки программных продуктов.

Программа класса BTS представляет собой базу данных с удаленным доступом, располагающуюся, как правило, на сервере локальной сети, и клиентских приложений установленных на машинах сотрудников компании. Единая база данных обеспечивает централизованный доступ ко всем документам (программам, спецификациям, графикам, планам и т.п.). Информация о каждом шаге работы с документом становится доступна всем заинтересованным лицам. Например, если документ помечен как "ошибка" (bug), то об этом будет оповещена группа разработчиков. Документ, помеченный как "запрос" (requirement), попадет в почтовые ящики отдела маркетинга и технической поддержки. Механизм контроля обращений различных пользователей к документу позволяет получить полную картину того, кем из сотрудников была найдена ошибка, и кто из клиентов ожидает увидеть в следующей версии то или иное новшество.

Система может быть сконфигурирована так, чтобы пользователь мог подключиться к системе извне, посредством авторизированного доступа (web-enabled) или, к примеру, вынести bug-report форму на Web-страничку компании, предоставив, таким образом, клиентам удобный способ сообщить об ошибке.

Большинство систем отслеживания проблем (систем трекинга багов - bug tracking system) имеют возможность составлять не только отчеты о багах (Bug Report), но и вносить Feature Request (запрос свойства), что позволяет тестировщикам вносить свои предложения по улучшению тестируемой программы.

Система отслеживания ошибок содержит три этапа: сбор данных об ошибке, её отслеживание и решение проблемы.

Существует большое разнообразие bugtraking систем – систем обнаружения ошибок (mantis, bugzilla и т.п.).


Зачем нужны BTS

Для компании по производству ПО внедрение BTS — своего рода политический ход. Информация о проекте, известная ранее лишь начальнику и нескольким программистам, становится доступной широкому кругу разработчиков и менеджеров. В результате ведение проекта превращается в реально контролируемый процесс, что позволяет в ряде случаев предотвратить появление заведомо невыполнимых проектов. Более того, облегчается коммуникация между специалистами отдела качества (QA) и программистом при работе над конкретными ошибками.

Ведение базы данных ошибок в программе – один из признаков хорошей программистской команды. К сожалению, далеко не все разработчики её используют. Одно из типичных программистских заблуждений – это вера в то, что можно сведения обо всех ошибках удержать в памяти или на отрывных листочках.

Если вы пишете код, пусть даже в одиночку, и не ведёте систематизированный учёт всех найденных в коде ошибок, вы обречены поставлять низкокачественный продукт. В хороших командах база данных учёта ошибок не просто используется, это становится привычкой. И программисты начинают её использовать для поддержки своих рабочих планов, список назначенных им ошибок делают стартовой страницей своего браузера.

Главной деятельностью тестировщика является обнаружение багов. Но ошибку мало найти. О найденной проблеме нужно сообщить программисту, который затем исправит ее, или другому ответственному за это члену команды. Однако и это еще не все. После того как ошибка исправлена, необходимо будет провести тест, который выявлял ее ранее, еще раз - чтобы убедится, что это исправление действительно имеет место, кроме того необходимо будет провести целый набор тестов для того, чтобы удостоверится в том, что сделанное исправление не нарушило работу других частей программы.

Выполнение описанных задач без специализированной системы (BTS) становиться крайне затруднительным.


Пример обработки одной ошибки

На основе статьи Джоеля Спольски «Работа над ошибками малой кровью»

http://russian.joelonsoftware.com/Articles/PainlessBugTracking.html

Давайте последим за какой-нибудь ошибкой от момента рождения до конца её бренного пути. Возьмём для примера ошибку 1203. Вот какую информацию о ней выдаёт база данных:

ID-Номер

 

1203

Проект

 

Bee Flogger 2.0

Раздел

 

Ftp Клиент

Название

 

Загрузка файла роняет ftp сервер

Назначено

 

Закрыто

Статус

 

Закрыто-Решено-Исправлено

Важность

 

2 - Необходимо исправить

Архитектура

 

2.0 Alpha

Версия

 

Сборка 2019

Компьютер

 

Макинтош iMac Джилл. MacOS 9.0, 128Mb ОЗУ, 1024x768, миллионы цветов

Описание

 

1 ноября 2000 Открыто Джилл, очень-очень хорошим тестером.

* Запустить Bee Flogger
* Создать новый документ без имени содержащий букву "а"
* Щёлкнуть кнопку ftp на панели
* Попробовать загрузить документ по ftp на сервер
 
ОШИБКА: ftp сервер не отвечает.
Команда ps -augx показывает, что ftp сервер вообще не выполняется.
В корневом каталоге содержится дамп памяти.
 
ТРЕБУЕТСЯ: ftp сервер не должен падать.

1 ноября 2000 Джилл, очень-очень хороший тестер, поручила работу над ошибкой Вилли, ведущему разработчику.

2 ноября 2000 (вчера) Решено - Исправлять не будем - Вилли, ведущий разработчик.

Не наш код, Джилл. Это proftpd, входящий в поставку Linux.

2 ноября 2000 (вчера) Возобновлено (поручено Вилли, ведущему разработчику) Джилл, очень-очень хоршим тестером.

Неубедительно. Мне никогда не удавалось уронить proftpd другими ftp клиентами. Наш же клиент роняет его каждый раз. Ftp серверы сами по себе не падают.

3 ноября 2000 (сегодня) Вилли, ведущий разработчик поручил работу над ошибкой Майку, простому программисту.

Майк, взгляни-ка сюда. Может твой код в клиенте делает что-то не то?

3 ноября 2000 (сегодня) Решено - Исправлено. Майк, простой программист.

Я думаю, что я передавал имя пользователя вместо пароля или что-то типа того...

3 ноября 2000 (сегодня) Реактивировано (поручено Майку, простому программисту) - Джилл, очень-очень хорошим тестером.

Всё то же самое в 2001-й сборке.

3 ноября 2000 (сегодня) Отредактировано Майком, простым программистом.

О как! Очень странно. Надо будет взглянуть внимательнее.

3 ноября 2000 (сегодня) Отредактировано Майком, простым программистом.

Мне кажется это в MikeyStrCpy()...

3 ноября 2000 (сегодня) Решено - Исправлено Майком, простым программистом.

Уфффф!!! Исправлено!

3 ноября 2000 (сегодня) Закрыто Джилл, очень-очень хорошим тестером.

Похоже-таки исправлено в сборке 2022 - закрываю.

Итак, вот что произошло.

Майк, простой программист, колдовал над новой возможностью своей превосходной программы для макинтошей: ftp клиентом. В один прекрасный момент из хулиганских побуждений он написал свою собственную функцию копирования строк.

Беда приходит нежданно, Майк, когда ты не используешь повторно код! На этот раз никто не ждал, что Майк забудет завершить копируемую строку нулём. И ошибка осталась незамеченной, потому что при отладке строка копировалась в заранее обнулённую область памяти.

Позже на той же неделе, Джилл, очень-очень хороший тестер, терзала код, нажимая все клавиши подряд и выполняя другие, столь же коварные тесты. Внезапно произошло что-то очень странное — ftp сервер, на котором она проверяла клиента, упал! Да, я знаю, что это был Линукс, а компьютеры под Линуксом никогда не падают, но эта чёртова штука таки упала! А ведь Джилл даже не дышала на ftp сервер. Она просто пыталась загрузить на него файл, используя код для Mac-а, написанный Майком.

Поскольку Джилл была очень-очень хорошим тестером, она аккуратно вела запись всех своих действий. Она перезагрузила всё, что было можно. Начала повторять свои действия на чистой машине, и — гляньте-ка — это случилось снова! Ftp сервер опять упал! Дважды за один день! Вот тебе, Линукс!

Джилл взглянула на запись своих действий. Там было порядка двадцати шагов. Некоторые из них, похоже, не имели отношения к проблеме. После некоторых экспериментов Джилл сократила число действий до четырёх, которые всегда вызывали ошибку. Теперь она была готова описать ошибку.

Джилл ввела информацию об ошибке в базу данных. Кстати, даже сам процесс записи информации об ошибке требует определенной дисциплины: бывают хорошие описания, а бывают и плохие.

Короче, Джилл ввела информацию об ошибке. В хорошей системе учёта ошибок работа над ошибкой автоматически поручается ведущему разработчику проекта. И в этом кроется вторая идея — ошибкой, пока она не закрыта, в каждый заданный момент времени должен заниматься только один человек.

Вилли, ведущий разработчик, взглянул на описание ошибки и решил, что, вероятно, что-то не в порядке с ftp сервером, и пометил её как "исправить невозможно". В конце концов, не они же писали код ftp сервера.

Когда ошибка разрешена, она назначается обратно тому, кто открыл её. Это важный момент. Ошибка не исчезает только потому, что программист так решил. Золотое правило гласит, что закрыть ошибку может только тот, кто её открыл. Программист может только "решить" ошибку, в смысле — "ага, я думаю, ошибка исправлена", но реально закрыть ошибку и убрать её из списка может только человек, увидевший её впервые. Только он может подтвердить, что ошибка в самом деле исправлена, или согласиться с тем, что по каким-либо причинам исправить её невозможно.

Джилл получила е-мэйл: ошибка опять вернулась к ней. Она посмотрела комментарии Вилли. Что-то ей показалось неверным. Куча народа годами использует этот ftp сервер с различными приложениями, и он не падает. Это происходит только когда используется код Майка. Джилл реактивировала ошибку, объяснив своё решение, и вернула её на рассмотрение Вилли. Вилли поручил ошибку Майку для исправления.

Майк изучил ошибку, думал долго и упорно, но, тем не менее, сделал неверные выводы. Он исправил несколько несвязанных между собой ошибок и решил, что в их число попала ошибка Джилл.

Ошибка вернулась к Джилл с описанием "решена-исправлена". Джилл попробовала повторить шаги, ведущие к ошибке, и глядите-ка, ftp сервер опять упал. Она опять реактивировала ошибку и теперь поручила её исправление непосредственно Майку.

Майк был озадачен, но, в конце концов, он-таки нашёл источник ошибки. Он исправил её, проверил, и — эврика! Ftp сервер больше не падал. Опять он пометил ошибку как "решено-исправлено". Джилл тоже повторила все действия, приводившие к ошибке, и убедилась, что ошибка исправлена. После этого она с чистой совестью закрыла её.


Классификация программных ошибок

Сэм Канер в своей книге "Тестирование программного обеспечения" приводит список из более чем 400 стандартных ошибок. Существует также их классификация по группам.

• Ошибки пользовательского интерфейса

• Обработка ошибок

• Ошибки, связанные с граничными условиями

• Ошибки вычислений

• Начальное и последующее состояния

• Ошибки управления потоком

• Ошибки обработки или интерпретация данных

• Ситуации гонок

• Повышенные нагрузки

• Аппаратное обеспечение

• Контроль версий и идентификаторов

• Ошибки тестирования

К сожалению, далеко не все системы трекинга используют одну и туже классификацию. Более того, благодаря гибкости настроек большинства из них можно с легкостью менять используемые понятия на те, которые Вам более привычны или приняты в Вашей компании.

В целом ниже приведенная классификация носит чисто практический характер, она далека от совершенства, но, тем не менее, она позволяет обеспечить достаточную преемственность между разработчиком и тестером:

1. Causes crash - название говорит само за себя. Под ним объединяют все те ошибки в программе, которые могут вызвать крах или зависание всей системы, нарушить стабильность ее работы.

2. Cosmetic - под этим понятием объединяют ошибки дизайна (например, не тот цвет линии или шрифт), пользовательского интерфейса и т.п. Иными словами все те баги, которые не мешают работать программе, но портят ее "товарный вид".

3. Critical - все то, что ведет к зависанию или краху самой программы, не затрагивая операционной системы в целом.

4. Error Handling - баги в обработке ошибок.

5. Functional - баги в функциональности.

6. Setup - баги инсталляции.

7. Minor - теоретически малозначимые,

8. Suggestion - т.н. предложение. На наш взгляд к ним лучше всего относить feature.


Структура хорошего отчета по ошибке

Вкратце, цель сообщения об ошибке — позволить программисту увидеть перед собой, как программа дает сбой.

Каждое хорошее описание ошибки должно содержать ровно три вещи:

1.    Какие шаги привели к ошибке.

2.    Что вы ожидали увидеть.

3.    Что вы в самом деле увидели.


Основные атрибуты отчета об ошибке

Прежде всего следует помнить о том, что составленный отчет может, а скорее всего и будет, подвергаться изменениям не только тестером, но и другими членами команды. Кроме того, отчет может быть составлен как на бумаге, так и с помощью специально созданных для этого программ - систем отслеживания проблем (bug tracking system). Исходя из этого, можно составить некий универсальный список пунктов (граф) отчета:

1. Название тестируемой программы (Program).

2. Номер версии тестируемой программы (Version).

3. Номер ее сборки (Build).

4. Функциональная область (Area).

5. ФИО лица, составившего отчет (Reported by).

6. Дата составления (Date).

7. Дата последней модификации (Last modify).

8. Серьезность проблемы (Severity).

9. Приоритет (Priority).

10. Статус (состояние) (Status).

11. Тип отчета (Problem type).

12. Повторяемость (Recurrence)

13. Идентификатор (Identifier).

14. Краткое описание (Description).

15. Детальное описание (Report).

16. Шаги воспроизведения (Steps to recreate).

17. Обходной путь (Workaround).

18. Конфигурация (Configuration).

19. Аттачмент (приложения) (Attachment).

20. Поручено (Delegated).

21. Комментарии (Comments).

22. Резолюция (Resolution).

23. Отложено (Deffered).

24. Подпись (нотификация для электронного варианта) (Signature/Notify).

25. История (History).


Советы Джоеля Спольски по использования BTS

1. Хороший тестер должен всегда стремиться сократить до минимума число действий, необходимых для воспроизведения ошибки. Следование этому правилу может оказать неоценимую помощь программисту, который будет искать эту ошибку.

2. Помните, что закрыть ошибку может только тот, кто её открыл. Кто угодно может решить её; но только тот, кто первым увидел ошибку, может быть уверен, что то, что он видел - исправлено.

3. Существует много способов разрешить ошибку. Например, можно сделать это следующими способами: исправлена, не подлежит исправлению, отложено, не воспроизводится, повторная, особенность дизайна.

4. Не воспроизводится — значит, что никто не смог воспроизвести ошибку. Программисты часто используют этот вердикт, если в описании ошибки опущены шаги для воспроизведения ошибки.

5. Вы должны аккуратно отслеживать версии программы. Каждая сборка программы, которая передается тестеру, должна иметь номер версии, чтобы несчастный тестер не проверял ошибку, которая и не должна быть исправлена в этой версии.

6. Если вы программист, и вам не удается сподвигнуть тестеров на использование базы данных учёта ошибок, перестаньте обращать внимание на информацию об ошибках, переданных вам в любой другой форме. Если ваш тестер присылает вам информацию об ошибке по электронной почте, отправляйте его письма обратно с короткой припиской: "пожалуйста, поместите эту информацию в базу данных. Я не имею возможности отслеживать информацию об ошибках, поданных с помощью электронной почты".

7. Если вы тестер, и у вас проблеммы с программистами, которые не используют базу данных учёта ошибок, не давайте им информацию об ошибках ни в какой другой форме. Помещайте информацию в базу данных, она сама сообщит им об этом через электронную почту.

8. Если вы программист, и некоторые из ваших коллег не используют базу данных учёта ошибок, начните назначать им ошибки через базу. В конце концов, до них дойдёт.

9. Если вы менеджер, и вам кажется, что никто не использует базу данных учёта ошибок, которую вы выбили большой кровью, начните назначать программистам новые задачи в форме ошибок. Система отслеживания ошибок также является отличным средством учёта заданий.

10. Избегайте соблазна добавить новые поля в базу данных. Примерно раз в месяц кому-нибудь в голову приходит "светлая" идея добавить к базе данных новое поле. Вам приносят самые разные мудрые идеи, например: указывать файл, в котором обнаружена ошибка; или вести учёт, в каком проценте повторов ошибка воспроизводится; вести учёт версий всех DLL, которые были запущены на компьютере, когда произошла ошибка; и так далее. Очень важно не поддаваться этим идеям. Иначе рано или поздно экран ввода информации об ошибке будет представлять собой форму с тысячью полей, которые необходимо заполнить, и никто не будет вводить эту информацию. Чтобы база данных учёта ошибок приносила толк, ее должны использовать все. И если ввод информации об ошибке будет требовать слишком больших усилий, люди найдут обходные пути.


Жизненный цикл ошибки

Итак, тест проведен, ошибка найдена, при этом сомнений в том, что ошибка имеет место - нет. Что делать дальше? Необходимо сообщить разработчику (программисту) о том, что ошибка найдена, т.е. написать отчет о проблеме (bug report).

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

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

В практике чаще всего используются следующие состояния багов:

Unconfirmed - баг только открыт и еще не был обработан. Когда тестер открывает баг, то первым информацию о нем получает некто по умолчанию (для разных тестируемых систем это может быть разные люди), читает его, и переправляет это баг программисту, который непосредственно будет его исправлять.

Баг переходит в состояние Assigned. По мере работы, этот программист может переадресовать баг другому программисту, который, например, знает данную часть системы лучше. К сожалению, это порождает ситуации, когда баг "плутает" от одного разработчика к другому несколько месяцев.

Assigned - Конкретный программист получил этот баг и теперь должен отвечать "за базар" - исправлять свою или чужую ошибку.

В случае, если ошибка не является "ошибкой" (тестер ошибся) то баг превращается в Resolved-Invalid и переправляется тестеру обратно.

Если баг о той же проблеме уже есть, и над ним работают, то баг превращается в Resolved-Duplication. Например, ошибка была описана ранее и была исправлена, но исправленный код еще не поступил к тестерам.

Когда программист ошибку исправил, то баг превращается в Resolved-Fixed. Сам программист эти состояния и выставляет.

Resolved (Fixed, Invalid, Duplication)- ошибка исправлена и возвращена тестерам для проверки.

Если баг в состоянии Resolved-Invalid то тестер обязан еще раз убедиться, ошибка была или нет. Другими словами перетестировать.

Когда баг в состоянии Resolved-Duplication то тестер должен убедиться, что действительно, другой(ие), аналогичный(ые) баг(и) существует, его номер обычно программер указывает в своем комментарии. Доверяй, но проверяй.

В случае, когда баг Resolve-Fixed тестер проверяет (тестирует проблему) опять. Если ошибка исправлена - Verified (Closed). Если ошибка не исправлена - баг переоткрывается опять (Unconfirmed, Assigned)

Verified ошибка исправлена и перетестирована на тестовой машине.

Closed - ошибка исправлена, перетестирована и исправленный код помещен на живую систему, или новый билд выпущен.


Рассмотрение конкретной BTS на примере Mantis

Система отслеживания ошибок Mantis представляет собой Web-приложение, написанное на PHP и является свободно распространяемым. Для её работы необходим СУБД MySQL и Web сервер Apache. Система так же может быть адаптирована к СУБД PostgreSQL и другому Web серверу, поддерживающему PHP.

Домашняя страница проекта:

http://www.mantisbt.org/

Установка и начальное конфигурирование

Требования к ПО:

·         MySQL 3.23.2 или старше

·         PHP 4.0.6 или старше

·         Web-сервер

Краткое описание:

·         Разместить инсталляционный архив на сервере

·         Разархивировать

·         Сгенерировать базу данных

·         Отредактировать конфигурацию

·         Настроить поддержку PHP

·         Войти в систему

 

После размещения сценариев на Web-сервере в определенном каталоге (например, mantis) необходимо создать пустую базу данных сервере MySql и заполнить её содержимое с помощью команды:

mysql -u<имя_пользователя> -p<пароль> <имя_базы> < db_generate.sql

Например, если имя пользователя bob, пароль mypass, а БД называется  bugtracker, то команда будет иметь вид:

mysql -ubob -pmypass bugtracker < db_generate.sql

В каталоге установки необходимо переименовать файл config_inc.php.sample в config_inc.php. Далее необходимо открыть этот файл в текстовом редакторе и прописать настройки доступа к БД и адреса электронной почты для уведомлений. Этот файл переопределяет настройки по умолчанию из файла config_inc.php.

После установки необходимо войти в Mantis (пользователь: Administrator, пароль: root) в раздел «Управление» и выполнить первоначальное конфигурирование. Оно включает в себя создание проектов, регистрацию пользователей, блокировку первоначальной административной учетной записи и раздачу прав пользователям на проекты.

Способ взаимодействия с пользователем

Создание пользователей, проектов и категорий

При регистрации пользователя необходимо указать реальное имя пользователя, login, адрес электронной почты (e-mail) и уровень доступа по умолчанию. Предусмотрены следующие уровни доступа:

·         Зритель

·         Автор

·         Редактор

·         Разработчик

·         Менеджер

·         Администратор

Пользователю на e-mail будет отправлен запрос на подтверждение регистрации со ссылкой на Web-сайт системы. При переходе по ссылке пользователь должен установить свой пароль и далее может работать с системой.

Администратор системы должен создать необходимое количество проектов. Для проекта задается его название, текущий статус, режим доступа, вложенные проекты, категории, версии и уровень доступа для выбранных пользователей. Категории необходимы для логического разделения информации о проекте. Например, можно выделить такие категории: системные модули, прикладные модули, документация, инсталлятор. Набор категорий определяется индивидуально для каждого проекта его администратором.

Страница управления проектами

Регистрация новых ошибок и изменение статуса существующих

Форма регистрации ошибок имеет следующий вид:

На ней можно задать:

·         Категория

·         Воспроизводимость

·         Критичность

·         Приоритет

·         Сводка

·         Дополнительная информация

·         Прикрепленный файл

·         Режим доступа

Просмотр списка ошибок под различными фильтрами

Система предоставляет возможность фильтровать список зарегистрированных ошибок по различным атрибутам и сортировать полученный список:

Подробную документацию по Mantis можно получить на сайте проекта:

http://manual.mantisbt.org/mantis.manual.zip