hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Справлюсьm		ли я сам?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
205Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

•версию программного обеспечения, точный номер сборки и ис% пользовавшееся оборудование;

•все остальное, что предположительно могло бы иметь отношение.

4.Запишите все и не теряйте! Занесите данные в систему контроля ошибок, даже если это простая ошибка в коде, которую вы собирае% тесь исправить сами (см. ниже раздел «Справлюсь ли я сам?»)

5.Напишите простейший контрольный пример, демонстрирующий сбой, и добавьте его в набор автоматически выполняемых тестов. Этим вы гарантируете, что ошибка не будет потеряна или забыта, а когда она будет исправлена, но не повторится в новых разработках.

Запомните: тестирование – это не отладка, и данные действия – не от% ладка! Вы же не пытаетесь вскрыть причину сбоя, не изучаете код, а просто регистрируете сведения, которых достаточно для описания проблемы другому разработчику.

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

Справлюсь ли я сам?

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

•Программист находит проблемы, глядя на код – свой собственный или чужой.

•Интегратор кода обнаруживает ошибки в ходе соединения отдель% ных компонент.

•Отдел QA обнаруживает ошибки во время тестирования.

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

Система контроля ошибок

Наше главное оружие в борьбе с ошибками – система контроля оши# бок. Это особая база данных, интерфейс которой доступен всем, кто принимает какое%то участие в процессе тестирования.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								206m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 8. Время испытанийClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

По ходу обнаружения ошибок и действий по их устранению в эту базу вносятся данные, отражающие текущее состояние программного про% дукта. Таким образом, этот инструмент становится составной частью технологии борьбы с ошибками в проекте. Вот основные действия, вы% полняемые системой:

Отчет об ошибке

Обнаружив ошибку, создайте для нее запись в базе данных в виде от# чета об ошибке. Он становится полноправным членом клуба ошибок с личным членским номером. В дальнейшем данный номер уникаль% ным образом идентифицирует ошибку. Теперь пропустить ошибку нельзя. С ней нужно что%то сделать, прежде чем выпускать продукт.

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

Назначение ответственного

В отчете об ошибке указывается конкретное лицо. Оно становится ответственным за устранение ошибки (самостоятельно или назна% чив для этого кого%то другого). Если не назначить «хозяина» ошиб% ки, каждый программист будет считать, что ее исправит кто%то дру% гой, и ошибка будет благополучно существовать дальше.

Установление приоритетов

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

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

Пометка проблемы как решенной

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

Закрытие отчета

После проверки отчет можно закрыть, оставив его лишь для исто% рии (или статистики проекта).

Есть разные ситуации, в которых отчет может быть закрыт; на% пример, если выяснится, что это не ошибка, а свойство системы

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Справлюсьm		ли я сам?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
207Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

и, возможно, совершенно допустимое поведение. Тестеры тоже мо% гут ошибаться.

Можно не закрывать отчет, с которым вы не намереваетесь работать, а отложить его с пометкой, что ошибка будет исправлена в следую% щей версии.

Запрос к базе данных

У системы контроля ошибок можно запрашивать различную ин% формацию:

•Разумеется, можно сделать список всех незакрытых отчетов, упорядочив его по версии программного продукта, ответственно% му исполнителю, приоритету и пр.

•Можно выяснить, какие ошибки назначены для исправления вам.

•Можно создать отчет по ошибкам, исправленным в каждой вер% сии программного продукта. Это полезно при подготовке сопро# водительного текста к новому выпуску.

•Можно посмотреть статистику по проекту: сколько отчетов об ошибках поступило во время разработки, сколько ошибок ис% правлено и каково соотношение между скоростью обнаружения и исправления. Статистика в графическом виде позволит полу% чить хорошее представление о состоянии процесса разработки.

Модификация записи

Можно открыть отчет и изменить содержащиеся в нем данные, в том числе:

•Добавить комментарии в связи с обнаружением новых данных.

•Прикрепить файлы журналов с данными вывода, иллюстрирую% щими проблему.

•Пометить, что данный отчет является дубликатом для некой ошибки, чтобы избежать путаницы в дальнейшем.

Существует масса пакетов контроля за ошибками – как коммерческих, так и бесплатных, например популярная система Bugzilla, входящая в проект Mozilla.

Обсуждение ошибок

По мере приближения конца сроков разработки совещания по поводу оставшихся ошибок (bug review) становятся нормой жизни и происхо% дят практически еженедельно. Эти обзоры проводятся, когда функции программы реализованы, но ошибки не устранены – затянувшаяся финишная прямая процесса разработки. На этих совещаниях все за% интересованные стороны могут узнать о ходе проекта, планируются оставшиеся ремонтные работы и весь программный проект направля% ется к окончательному выпуску.