126 Часть I: Основы

подобной ошибки необходимо снова запустить программу с теми же дан­ными.

Ошибка, являющаяся побочным эффектом другой проблемы

Если в процедуре обработки ошибок имеется ошибка, восстановление после очередного сбоя может пройти неудачно. В этом случае может про­изойти все что угодно, и в том числе новая ошибка. Для ее повторения понадобится воспроизвести причину первого сбоя.

Нерегулярные аппаратные сбои

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

Однако не стоит торопиться с выводами. На аппаратный сбой ошибку следует списывать в самую последнюю очередь.

Дата и время

Программа, работа которой зависит от даты или времени, может выпол­нять некоторые специфические действия в полночь, первого января или в конце февраля в високосный год.

Общеизвестна “Проблема 2000 года” — возможность сбоев самых раз­нообразных программ при переходе от 31 декабря 1999 года к 1 января 2000 года из-за ошибок, связанных с проверками попадания даты в определен­ный диапазон, формированием даты по умолчанию и другими подобными моментами.

Поэтому в любой программе, работающей с датами и временем, следует внимательно проверить значения, попадающие на границу суток, недели, месяца, года, високосного года и столетия.

Зависимость от ресурсов

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

Глава 5: Документирование и анализ ошибок 127

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

Пауза между ошибкой и ее проявлением

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

Типичным примером подобной ситуации является переполнение стека или другой аналогичной структуры. Стек — это область памяти, зарезерви­рованная для временного хранения данных. Программа помещает в него информацию, работает с ней, а после использования удаляет. Если одна из процедур забывает выполнять этот последний шаг, через какое-то время стек окажется переполненным и другая, вполне исправная процедура не сможет поместить в него данные. Переполнение стека часто вызывает се­рьезный сбой программы.

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

Особые фрагменты кода

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

Кто-то поэкспериментировал с вашим компьютером

Такое случается. Вы проводили тестирование и вышли ненадолго. Пока вас не было, кто-то подошел к компьютеру, ввел некоторые данные, пора­ботал с программой, выключил принтер. Это могла быть намеренная шутка. А может быть, шеф демонстрировал программу гостю и забыл вас предуп­редить. Оставляя компьютер включенным, вы всегда рискуете, вернувшись, найти его в другом состоянии.

Часть

Приемы и технологии тестирования

Глава 6. Система отслеживания проблем

Глава 7. Разработка тестов

Глава 8. Тестирование принтеров и других устройств

Глава 9. Адаптационное тестирование

Глава 10. Тестирование документации

Глава 11. Инструментальные средства тестировщика

Глава 12. Планирование и документация

Глава

6

Система

отслеживания

проблем

Назначение этой главы

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

Примечание

До сих пор под словом "вы" в этой книге имелся в виду начинающий те­стировщик. В этой главе ситуация меняется, и дальнейший рассказ об­ращен уже не к новичку, а к профессионалу, готовому взять на себя руководство проектом. Предполагается, что читатель руководит группой тестирования и его слово в разработке системы отслеживания проблем имеет значительный вес. Однако и тем, у кого еще нет столь серьез­ного профессионального опыта, прочитать эту главу будет небезынтерес­но. Ее материал охватывает множество аспектов работы специалистов группы тестирования и их взаимодействия с остальными сотрудниками компании и изложен на вполне доступном уровне даже для новичка.

Первая часть главы посвящена вопросам наиболее эффективного исполь­зования системы отслеживания проблем.

Обзор