Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Средства мониторинга охвата вставляют в программу отладочный код. В конечном продукте этого кода быть не должно. В результате вы тестируете программу не в том виде, в каком она будет прода ваться, а это потенциальная возможность появления ошибок. • Со средствами мониторинга программа медленнее работает. В результате получаются условия гонок, отличные от реальных, а это снова повышает вероятность появления ошибок. 2 8 2 Часть II: Приемы и технологии тестирования • Нашпигованная зондами программа сильно увеличивается в разме ре. Если размер программы имеет критическое значение, это обсто- ятельство может скрыть тот факт, что ее размер и в самом деле превысил допустимую величину. • Некоторые из таких программных средств сами полны ошибок. Программистам едва ли понравится, если они проведут пару дней в поисках ошибки и окажется, что ее виновником является средство мониторинга. Поэтому такое средство следует выбирать очень тща тельно и при его покупке осведомиться у продавца о наличии списка известных ошибок. Проверка утверждений Обычно в каждой программе есть точки, в которых всегда должны выполняться определенные условия. Чтобы убедиться, что необходимые условия в самом деле выполняются, программист может поместить в эти точки отладочные команды. Это и есть проверка утверждений (assertion check). Если условие выполняется, программа не производит никаких не стандартных действий, если же нет, она может выдать на экран соответ ствующее сообщение или записать его в файл журнала. Возможно также, что программа просто молча выполнит код обработки ошибочной ситуации. Как правило, тестирование утверждений организуется таким образом, чтобы тестировщик сразу же видел, что что-то идет не так. Для этого все сообщения программы о неверных утверждениях выводятся на экран или распечатываются. Так гораздо легче отслеживать и исправлять ошибочные ситуации — ведь кроме того, в какой точке программы произошла ошиб ка, необходимо еще знать, как вы туда попали и с какими данными рабо тали. В противном случае ошибочную ситуацию может быть трудно воспроизвести. Анализ использования памяти Работающая программа использует память следующими способами. • Часть памяти занимает сам программный код. За исключением (весьма непопулярных) самомодифицирующихся программ, про грамма не может писать в собственную область кода. • Часть памяти занимают данные. Программа может считывать и записывать информацию своей области данных, но не может попро сить центральный процессор выполнить команду, записанную в этой области. • Определенная память связана с аппаратным обеспечением. Про грамма может общаться с внешним устройством, считывая и запи- Глава 11: Инструментальные средства тестировщика 2 8 3 сывая информацию по определенным адресам памяти. Однако при кладные программы, как правило, взаимодействуют с внешними устройствами через промежуточное программное обеспечение, встроенное в BIOS компьютера или операционную систему. Для них считается даже некорректным прямо обращаться к памяти устройств ввода/вывода, минуя установленные драйверы. • Недоступная память. Запуская программу, операционная система выделяет ей некоторый объем памяти. В мультизадачных системах программе обычно недоступна память, выделенная другим програм мам, работающим одновременно с ней. И уж во всяком случае ни одной программе недоступна память, которая физически отсутствует. Специальные утилиты, анализирующие использование памяти, могут выявить подозрительные команды программы. Они могут остановить про цесс и сохранить в файле дамп памяти, могут перевести программу в ре жим отладки или просто сообщить о событии и продолжить выполнение программы. Утилиты, анализирующие использование памяти, могут предоставить программисту и тестировщику множество полезной информации, и в том числе об объеме свободной памяти, размере наибольшего свободного бло ка, подробный список всех работающих процессов или всех блоков памя ти с информацией о том, какой программой используется каждый из них. Все эти данные очень полезны, так как проблемы с использованием памяти являются наиболее трудноуловимыми. С их помощью можно выяснить сле дующее: • Какой объем памяти занимает каждая составляющая программы. • Возвращает ли программа операционной системе ту память, которая ей больше не нужна. Особенно это касается достаточно больших объемов памяти, выделенных, например, под графику. Если нет, то рано или поздно вся свободная память системы будет исчерпана. Оценивая картину использования памяти по данным подобных утилит, следует учитывать и их собственную роль в этом процессе. Бывает, что именно утилита не позволяет тестировщику воспроизвести произошедшую ошибку. Однако в целом предоставляемая информация может быть просто неоценима. Наш собственный опыт показывает, что из всех отладочных команд, которые программисты встраивают в программный код, наиболее ценны именно команды формирования отчета об использовании памяти. Глава Планирование и документация Назначение этой главы Из главы 7 вы узнали о том, как проектировать и оценивать отдельные те сты. В главе 8 рассказывалось о планировании всей работы — на примере тестирования печати, в главе 9 — о планировании локализационного тести рования. А о том, как тестировщик м о ж е т автоматизировать свою работу, вы прочитали в главе 1 1 . Теперь, вооружившись всеми этими знаниями, м о ж н о приступить к рассмот рению одного из самых серьезных этапов тестирования программного про дукта — этапа планирования. Данную главу, в которой рассказывается о целях и стратегии планирования, м о ж н о назвать своеобразным центром всей книги, ее связующим звеном, объединяющим материал всех остальных глав. Планирование тестирования — процесс последовательный. Он включает в себя следующие задачи. • Разработка тестов с помощью аналитических средств. Специалисты, за нимающиеся планированием тестов, прибегают к помощи самых разно о б р а з н ы х аналитических средств — таблиц, д и а г р а м м и д р у г и х инструментов, позволяющих выделить те аспекты программы, которые подлежат отдельному тестированию, и определить, какие из возможных тестов являются наиболее важными для каждого из этих аспектов ( к о нечно, прежде всего, это тесты граничных условий). • Выбор стратегии тестирования. В этой и следующей главах рассказыва ется о том, как исследовать различные области и аспекты программы и определить, какие из них требуют более углубленного тестирования. • Разработка средств контроля за тестированием. Этот этап включает в себя создание контрольных списков, таблиц, автоматизированных тестов 12 Глава 12: Планирование и документация 2 8 5 и других материалов, задающих порядок выполнения тестов и опреде ляющих их входные данные. Эти простые средства позволяют аккурат но организовать работу, определяя ее последовательность и гарантируя, что ничто не будет потеряно или упущено. • Распространение информации. Подготовьте плановые документы, кото рые позволят другим сотрудником ознакомиться с принятой стратегией, понять ее цели и смысл. Распространите среди заинтересованных лиц разработанные тесты, данные и другие сопутствующие средства и до кументы. Обзор В этой главе рассматриваются следующие вопросы: • О б щ е е назначение тестового плана. • Цели, преследуемые при планировании тестов и разработке документа ции. • Какие типы тестов ("черного ящика") должны отражаться в плановых документах. • Стратегия создания тестовых планов и их компонентов: поступательная разработка. • Компоненты тестового плана: простые и иерархические списки, табли цы и матрицы. • Как документировать тестовые материалы. План тестирования определяется стандартом ANSI/IEEE (ANSI/IEEE Standard 829-2983 for Software Test Documentation) следующим образом: Это документ, в котором определены объем, ресурсы, а также описан календарный план работ по тестированию. В нем определяются выпол няемые тесты, тестируемые элементы, задачи тестирования, сотруд ники, ответственные за выполнение каждой из задач, а также указывается вероятность возникновения непредвиденных обстоятельств и описывается, какие меры нужно при этом принимать. Тестовый план — это огромный составной документ. Вам предстоит познакомиться с его назначением и содержанием, а также с целым рядом сопутствующих документов, создаваемых в процессе тестирования про граммного продукта. Сколько усилий и внимания уделяется тестовой документации — зави сит от конкретной группы тестировщиков и общего объема работ. В одних случаях удовлетворяются несколькими страницами заметок, в других созда ются многотомные труды. Не всегда объем документации определяется профессионализмом сотрудников, хотя и это тоже играет определенную роль. Основные стратегические различия связаны с конкретными задача ми каждой конкретной группы. Именно эти задачи и определяют, какой будет документация и для чего вообще она разрабатывается. 2 8 6 Часть II: Приемы и технологии тестирования Общее назначение тестового плана: продукт или инструмент? У авторов тестовых планов могут быть две принципиально различные цели: в одних случаях разрабатывается продукт, а в других — рабочий инструмент. Смешать эти цели легко, но такое смешение очень дорого обходится. При этом разработка продукта стоит гораздо дороже, чем раз работка инструмента. Тестовый план как продукт Хороший тестовый план помогает организовать и скоординировать уси лия сотрудников, разрабатывающих и тестирующих программный продукт. Однако многие тестовые планы не ограничиваются этой исключительно важной задачей. Они разрабатываются как самостоятельные продукты. Формат, структура и уровень детализации подобных планов определяются не только соображениями эффективности тестирования, но и нормами, определяемыми спецификацией. Вот несколько примеров. • Предположим, что ваша фирма разрабатывает программный про дукт, который затем будет перепродаваться телефонной компанией (примером может быть программа учета телефонных звонков). Те лефонная компания будет поддерживать этот продукт многие годы. Поэтому ее специалисты будут тщательно анализировать ваш план тестирования и вносить в него необходимые с их точки зрения кор- рективы. Им необходима гарантия, что продукт будет протестирован самым тщательным образом. Кроме того, если вы по какой-либо причине не сможете поддерживать продукт в дальнейшем (например, ваша компания обанкротится), им придется самим вносить в про грамму текущие изменения, а значит, и проводить повторное тести рование. Ясность и простота тестового плана, строгость его формата будут в этом случае играть решающую роль. • Если вы разрабатываете программное обеспечение для военных, то обязательно должны продать им и тестовые планы, причем соответ ствующие их собственной спецификации. Без таких планов военные просто не купят ни одну программу. То же самое касается и про граммного обеспечения для медицины. • Разработчик программного обеспечения может воспользоваться ус лугами вашего независимого тестового агентства, заказав разработ ку тестового плана, по которому он сам будет тестировать свой программный продукт. В этом случае план должен быть исключи тельно строго организованным и подробным, иначе покупатель не сможет им воспользоваться. Глава 12: Планирование и документация 2 8 7 Каждый из описанных выше планов в конечном счете служит для по иска ошибок. Однако важно понимать, что, даже если время, затраченное на его разработку, могло бы быть с большей производительностью исполь зовано для анализа и тестирования программы, вам все равно придется вы держать стандарты и написать тестовый план, полностью соответствующий требованиям заказчика или регулирующей организации. Тестовый план как инструмент По сложившейся традиции вся учебная литература мира информацион ных технологий обучает читателей и студентов разрабатывать объемную и подробную тестовую документацию. Мы позволим себе не согласиться с этой традицией, поскольку весь наш опыт свидетельствует, что документа ция не должна быть впечатляющей — она должна быть эффективной. Исключением могут быть только документы, сами являющиеся продукта ми. В официальных стандартах для планов тестирования, таких как ANSI/ IEEE 829, можно найти целый комплекс требований к спецификации те стового проекта, спецификации для самих тестов, журналам тестирования, разнообразным идентификаторам, к спецификации для тестовой процеду ры, спецификациям ввода/вывода, а также специальные процедурные тре бования, зависимости между тестами, календарный план, описание распределения работ между персоналом, критерии приостановки и возоб новления тестирования и описание массы других бумаг. Стандарты позволяют быстро генерировать огромное количество доку ментов. Это верно, но так ли все эти документы необходимы? Масса вре мени уходит на всю эту бумажную работу, но помогают ли эти бумаги быстрее и лучше находить ошибки? Пользователю требуется нечто, правильно выполняющее необходимые вычисления, издающее ожидаемые звуки, рисующее ожидаемые изображе ния или печатающее нужный текст в нужном месте. Ему все равно, как вы это будете тестировать. Главное, чтобы программа работала правильно. Для подобных пользователей план тестирования не является продуктом. Это просто невидимый инструмент, которым компания-разработчик пользует ся для организации своей работы. Когда план тестирования разрабатывается не как продукт, а как рабо чий инструмент, при его создании лучше всего руководствоваться следую щим критерием. Ценность плана тестирования определяется тем, насколько он помогает в организации процесса тестирования и поиске ошибок. Любые его составляющие, не отвечающие этим задачам, являются пустой тратой ресурсов. 288 Часть II: Приемы и технологии тестирования Далее вы увидите, что существует еще целый ряд полезных функций документации, не охваченных этим узконаправленным взглядом на плани рование тестирования. Цели, преследуемые при планировании тестов и разработке документации Хорошая документация обладает тремя важнейшими преимуществами, о которых и рассказывается в этом разделе: • облегчает тестирование; • помогает организовать взаимодействие между персоналом; • представляет собой удобную структуру для организации, планирова ния и управления тестовым проектом. Лишь в очень немногих организациях сотрудники используют все те преимущества, которые может предоставить имеющийся план тестирова ния. Разумеется, составляющие его специалисты обычно обладают хотя бы минимальными знаниями по этому вопросу. Но далеко не в каждой груп пе тестовые планы внимательно анализируются персоналом, и далеко не всегда в работе над планом учитываются мнения о нем других сотрудни ков группы разработки. Как правило, тестовые планы рассматриваются только как технические документы и не применяются для управления ра ботами по тестированию и отслеживания хода их выполнения. Вам как тестировщику придется тратить на разработку тестовых планов многие часы. А раз так, стоит извлечь из полученного инструмента макси мум пользы. (Гетзел (Hetzel, 1988) излагает иной взгляд на задачи плана тестирования, его анализ этого вопроса также весьма полезен.) Тестовая документация облегчает организацию технических аспектов тестирования Создание хорошего плана тестирования невозможно без самого тща тельного исследования программного продукта. Только после этого ваше представление о поставленных задачах станет ясным и четким, что привне сет в работу обстоятельность и сделает ее по-настоящему эффективной. В ходе планирования вы создадите целую серию списков и таблиц, роль которых будет заключаться в следующем. • Обеспечить полноту охвата продукта. Тестовые планы должны включать перечень функций программы. Этот перечень гаран тирует, что ни один из аспектов программы не останется непро- тестированным. Обычно с этой целью составляется список всех генерируемых программой отчетов, сообщений об ошибках, под- Глава 12: Планирование и документация 2 8 9 держиваемых устройств, команд меню, диалоговых окон и т.п. Чем подробнее этот список, тем менее вероятно, что одна из функций программы останется непротестированной просто потому, что вы о ней не знали. • Избежать лишних повторений и не забыть ничего важного. Вычер кивая из списка выполненные пункты, вы всегда будете видеть, что уже сделано и что еще осталось. • Быстро проанализировать программу и выделить наилучшие тесты. На рис. 12.5 (глава 12) и подобных ему рисунках из главы 7 приве дены примеры таблиц, используемых при анализе классов эквива лентности и граничных условий. Каждое из граничных условий требует отдельного теста, поскольку именно здесь допускается мак симальное число ошибок. • Подготовить информацию для завершающего тестирования. Когда весь программный код написан и продукт практически готов, насту пает время финального тестирования. Неоценимую помощь при его планировании оказывают заметки, сделанные на предыдущих этапах. К этому моменту психологическое давление возрастает, а времени до выпуска продукта остается совсем мало. Поэтому быстрота и эффек тивность работы здесь особенно важны. А без заметок придется все держать в голове, при этом можно нечаянно пропустить жизненно важные тесты. • Повышение эффективности тестирования. Такое повышение дос тигается за счет сокращения количества тестов без уменьшения охвата тестируемых аспектов продукта. А это, в свою очередь, дос тигается благодаря вычленению и удалению сходных тестов, от ко торых ожидаются одни и те же результаты. Вот несколько примеров. • Анализ граничных условий. Обратитесь к седьмой главе, где рас сказывается о классах эквивалентности и граничных условиях, а также к разделу данной главы, посвященному компонентам пла на тестирования. * Стратегия конфигурационного тестирования. На рис. 8.1 была представлена стратегическая схема тестирования принтеров. Зак лючается она в том, что с одним тщательно подобранным прин тером тестируются все аспекты программы, связанные с печатью. Затем совместимые принтеры объединяются в группы, и с каж дым из них по очереди тестируются все функции печати, но не во всех местах программы, где они встречаются, а только в одном. Для реализации этой стратегии необходимо составить список всех совместимых с программой принтеров, выделить их классы и 2 9 0 Часть II: Приемы и технологии тестирования отобрать для первоначального тестирования по одному принтеру каждого класса. Далее потребуется таблица с перечнем функций каждого принтера и тестируемых областей программы. Пример такой рабочей таблицы для тестирования одного принтера пока зан на рис. 8.4. Чтобы протестировать все остальные принтеры, необходимо сделать аналогичную таблицу для каждого из них. При этом тестированию должна подлежать только одна из всех областей программы, в которых эти функции используются. • Одно из группы эквивалентных действий. Пусть, например, про- грамма выводит на экран диалоговые окна с сообщениями об ошибках. В качестве ответа пользователя принимаются только щелчок мышью на кнопке ОК или нажатие клавиши Нажатия всех остальных клавиш и щелчки мышью вне кнопки ОК программой просто игнорируются. Разумеется, вы не сможете протестировать все возможные нажатия клавиш. При этом следует иметь также в виду, что нажатие клавиши, игнорируемое одним диалоговым окном, может разрушить другое. Для работы в такой ситуации очень удобна тестовая матрица, каждая строка которой соответствует одному из сообщений. Каждый столбец матрицы соответствует группе клавиш, отнесенных к одному классу экви валентности, например, всем буквам нижнего регистра. Для каж дого из сообщений следует проверить по одной или нескольку клавиш из каждого класса. Позднее в этой главе мы еще вернемся к этой матрице. • Контроль полноты. Если, работая в соответствии с составленным планом тестирования, вы пропускаете ошибки, значит, ваш план не полон. Пробелы в плане могут быть по следующим причинам. • Пропущенные области программы. Для полноценного тестирова ния необходим подробнейший список того, что уже протестиро вано и что еще предстоит протестировать. В ходе работы обязательно сверяйтесь с этим списком и пополняйте его в слу чае необходимости. Особенно это важно для программ, которые в ходе разработки претерпевают многочисленные изменения. • Пропущенные классы ошибок. Умение как следует организовать свою работу и последовательно тестировать программу на пред мет всех предсказуемых ошибок — редкое качество. Обычно та кое тестирование выполняется достаточно беспорядочно. В приложении А приведены краткие описания около 500 видов часто обнаруживаемых ошибок. Создавая собственный аналогич ный список, вы наверняка расширите этот перечень. По нему можно сверять свой тестовый план, чтобы убедиться, что он до- Глава 12: Планирование и документация 2 9 1 статочно адекватен. Для этого следует пройтись по списку оши бок, спрашивая себя, может ли очередная ошибка встретиться в тестируемой программе. Если да, план должен содержать как минимум один тест, предназначенный для ее выявления. Анализируя таким образом свои тестовые планы, мы не раз об наруживали, что пропущены целые классы ошибок. Например, в плане может вообще не оказаться тестов для условий гонок или сообщений об ошибках. Успешно зарекомендовала себя в этом отношении следующая технология составления тестовых планов. В план включается раз дел с перечнем всех ошибок, которые могут присутствовать в те стируемой программе. Этот раздел заполняется первым. Затем на его основе последовательно разрабатываются тесты для поиска этих ошибок и записываются в другой раздел плана. Так ни одна ошибка не выпадает из поля нашего зрения. • Пропущенные классы тестов. Примерами классов тестов могут служить нагрузочные испытания, тесты граничных условий, рабо та в условиях параллельного выполнения программой нескольких заданий (например, фоновая печать), испытания в режиме реаль ной эксплуатации и т.д. Включены ли в план все эти виды испы таний? Если нет, тс почему? • Простой недосмотр. Если даже ваш тестовый план в целом абсо лютно полон, в нем все же могут быть случайно пропущены от дельные тесты, например, забыто одно из граничных условий. Несколько таких недочетов — обычное дело. Вовремя выполнен ный анализ проведенных работ позволит выявить и устранить все основные недостатки первоначального тестового плана. Документация помогает организовать взаимодействие между персоналом Тестировщики являются членами команды разработки продукта. Все они зависят друг от друга, и на их работу полагаются остальные члены команды, в частности, менеджеры, программисты и авторы документации. Четко и ясно написанные материалы помогают им ознакомиться с вашей стратегией, понять глубину и масштаб предполагаемого тестирования и узнать о типах планируемых работ. Вот несколько коммуникационных преимуществ, обеспечиваемых распространением тестового плана среди заинтересованного персонала. • Совместное обдумывание стратегии тестирования. • Повышение эффективности и полноты тестирования. Читатели распространяемых материалов смогут привлечь ваше внимание к 292 Часть II: Приемы и технологии тестирования упущенным областям программы, ее неправильно понятым аспек там, а также недавним изменениям продукта, еще не отраженным в плане тестирования. • Обсуждение объема тестирования. В тестовом плане отражается как предполагаемый объем работ по тестированию программного про дукта, так и уже выполненная его часть. Это помогает руководству и вашим коллегам понять, почему в команде тестировщиков рабо тает столько народу, чем они все занимаются и почему на работу уходит столько времени. Руководитель проекта всегда заинтересован в ускорении и удешевлении работ, поэтому он может принять свои меры, удалив или упростив сложные для тестирования части про граммы. • Обсуждение глубины тестирования и календарного плана работ. Нередко после создания плана тестирования разворачиваются бур ные дебаты по поводу объема работ. В одних случаях руководитель проекта доказывает (возможно, вполне справедливо), что заплани- рованный объем работ чрезмерен и его вполне можно сократить. В других случаях, наоборот, руководитель настаивает на проведении более серьезных испытаний и готов выделить на это дополнительное время и людей. Еще одним предметом обсуждения часто становится время, выделен ное для определенных работ. Например, руководитель проекта или менеджер по маркетингу могут решить провести более длительное тестирование, эмулирующее реальную эксплуатацию продукта пользователем. В принципе, все эти вопросы могут быть подняты и без документа ции. Однако план помогает сфокусировать дискуссию, делает ее предмет более наглядным и четко очерченным и тем самым облег чает достижение соглашений. По собственному опыту мы знаем, что при наличии четкого и детализированного плана тестирования об суждения проходят гораздо более упорядочение и реалистично и приносят значительно более ощутимые результаты. • Распределение работы. И поручить кому-либо работу, и проследить за ее выполнением всегда гораздо легче, если вручить человеку чет кие и подробные печатные инструкции. Тестовая документация представляет собой удобную структуру для организации, планирования и управления тестовым проектом Тестирование продукта представляет собой самостоятельный проект, которым необходимо управлять. И даже если тестирование выполняется Глава 12: Планирование и документация 2 9 3 одним-единственным сотрудником, его работа обязательно должна быть строго организована. Итак, план тестирования является средством управ ления проектом и в качестве такого средства предоставляет руководству следующие преимущества. • Достижение соглашений о задачах тестирования. План работ чет ко определяет, что должно и что не должно быть выполнено персо налом группы тестирования. Дайте ознакомиться с планом другим сотрудникам компании, включая руководителя проекта, других за интересованных руководителей, программистов, тестировщиков, маркетологов — всех тех людей, которые в той или иной форме могут в дальнейшем выдвигать собственные требования. Их отзывы позволят заранее определить, обсудить и разрешить все спорные вопросы. • Оценка ресурсов. После того как задачи четко определены, можно оценить ресурсы, необходимые для их выполнения. Сюда входят деньги, время, люди и оборудование. • Структуризация. Определив задачи, вы увидите, что многие из них концептуально связаны. Некоторые из задач лучше всего будет ре шать совместно — их можно выделить в отдельные группы. Выпол нение такой группы задач лучше всего поручить одному человеку или маленькой команде. Анализируя, разрабатывая и выполняя те сты, лучше также концентрировать внимание на их группах, выби рая их одну за другой. • Организация. Полноценный тестовый план определяет, кто, где, когда и какие выполняет тесты, какими он для этого пользуется ресурсами и для чего нужны конкретные тесты и направления рабо ты. • Координирование. Если вы являетесь руководителем группы тестиро вания или ее ведущим специалистом, тестовый план может быть удобным инструментом распределения работ между сотрудниками. В нем расписано, кому какая поручается работа, в чем конкретно она состоит, и в нем же фиксируется ход ее выполнения. Контро лируйте, какие из тестов выполняются в срок и на какие уходит больше времени, чем первоначально запланировано. Это поможет пересмотреть оставшуюся часть плана и при необходимости вовре мя перераспределить задания и ресурсы. • Эффективное управление работой отдельных сотрудников. • Тестировщик понимает, за что он отвечает. Поручая подчиненно му работу, необходимо четка объяснить ему его задачу и свои ожидания. Иначе нечего ждать, что он отнесется к поручению се- 2 9 4 Часть II: Приемы и технологии тестирования рьезно и выполнит все, что от него требуется. Если, например, сопроводить поручение контрольным списком, сотруднику будет ясно, что его задача — выполнить все пункты этого списка и только после этого сообщить о завершении работы. • Своевременное выявление всех проблем, связанных с персоналом и планом тестирования. Предположим, что вы назначили тести- ровщику область программы, за тестирование которой он отвеча ет, тестировщик сообщил, что работа выполнена, а затем кто-то другой обнаружил в этой области серьезную ошибку. Такое слу чается достаточно часто. Если план тестирования содержит дос таточно подробное описание работ, ничего не стоит выяснить, явился ли причиной инцидента сам план (и, возможно, процесс планирования) или же виноват тестировщик. Может быть, конеч но, что проблема и в том, и в другом или же вообще никто не виноват — ведь какое-то количество ошибок в программе остает ся всегда. Разбираясь с этим вопросом, прежде всего следует выяснить, имеется ли в плане тест, предназначенный для выявления найден ной ошибки. Если да, то сказал ли тестировщик, что этот тест вы полнен? Возможно, что тест действительно был выполнен — тогда следует проверить, с какой версией программы работал тестиров- щик и действительно ли в ней была ошибка. Только после этого можно высказывать какие бы то ни было оценки его работы и делать какие бы то ни было заключения. Не забывайте, что регрес сионное тестирование проводится именно потому, что в ходе работы программисты нередко вносят ошибки в те части програм мы, которые уже работали. Вполне возможно, что именно с этой проблемой вы и столкнулись, а тестировщик здесь вообще не при чем. Гораздо чаще, чем можно предположить, тестировщики пропус кают отдельные тесты, особенно те из них, которые кажутся им избыточными и утомительными. Они могут говорить, что полно стью выполнили серию тестов, когда на самом деле сделали толь ко половину или даже четверть того, что перечислено в контрольном списке. Некоторые из этих людей просто безответ ственны, однако иногда так поступают и очень талантливые и ответственные сотрудники, действительно заботящиеся о качестве программного продукта. Ваша задача — довести до сознания каж дого из них, что такие действия абсолютно неприемлемы. Одна ко, столкнувшись с подобными вещами, не обвиняйте только тестировщиков. Внимательно проанализируйте тестовый план и Глава 12: Планирование и документация 2 9 5 условия работы людей. Возможно вы обнаружите, что некоторые тесты и в самом деле избыточны или же необоснованно сложны и утомительны, сотрудники работают свыше положенного време ни (особенно плохо, если они делают это не по своей воле, а под давлением руководства), а возможно, причиной является прессинг чересчур сжатых сроков работы, также усиливаемый постоянным давлением руководства. Если окажется, что проблема заключается в избыточности тестов, их количество можно сократить до разумного минимума. Нет никакого смысла растрачивать на них драгоценное время. Если же все запланированные тесты абсолютно необходимы, можно пронумеровать их и предложить тестировщику выполнять на од ном цикле тестирования все четные тесты, а на втором — все нечетные. Ваша задача — всячески облегчить работу своих подчиненных, поскольку, даже если они будут аккуратно следовать контрольным спискам, однообразие действий все равно будет снижать их про изводительность и отражаться на внимании. Ведь можно выпол нить тест и все равно пропустить ошибку. Поэтому старайтесь удалять из плана все наиболее трудоемкие и избыточные тесты, а кроме того, время от времени менять тестировщиков местами. Пусть задания передаются между ними по кругу — совершенно незачем заставлять тестировщика неделю за неделей проводить одну и ту же серию тестов. К тому же так вам будет обеспечен постоянно свежий взгляд на тестируемые области программы. • Выявление недостатков тестового плана. Если тестировщик про пустил серьезную ошибку потому, что в плане не было теста для ее выявления, это уже недостаток плана. Однако стоит еще раз подчеркнуть, что такая ситуация, хотя и неприятна, все же совер шенно естественна — как любое произведение человеческих рук, план тестирования не может не иметь недостатков. Поэтому не стоит относиться к происшествию как к чему-то трагическому или из ряда вон выходящему. Выясните, полностью ли процеду ра разработки и утверждения плана соответствовала стандарту, принятому в компании. Если нет, план требует некоторого пере смотра и приведения в соответствие с внутренними стандартами. Возможно, персоналу, занимавшемуся этим планом, требуется пройти профессиональную переподготовку. Если же план разра ботан в строгом соответствии со стандартами, тратить на него лишнее время означает отнимать это время у другой работы. Если вы станете пересматривать план просто потому, что на этой не- 2 9 6 Часть II: Приемы и технологии тестирования деле вам политически выгоднее была бы другая схема работы, в целом проект от этого только пострадает (Деминг (Deming, 1986)). В ситуации, когда серьезные ошибки пропускаются слишком уж часто или когда внутреннее чувство подсказывает вам, что мно гие из пропущенных ошибок вполне могли бы быть выявлены, стоит еще раз проанализировать процесс планирования. Однако это не значит, что следует переделывать имеющийся план — это решит лишь незначительную часть проблем. Скорее следует сде лать выводы на будущее и обсудить этот вопрос на уровне руко водства, поскольку речь здесь идет о стратегии компании, а не только о конкретном проекте. • Отслеживание состояния проекта и усовершенствование учета работ. Сравнить предполагаемую скорость выполнения работы с ее реальным продвижением помогают периодические отчеты о ходе разработки и выполнения плана тестирования. Если начать проект с написания полного плана тестирования, то можно предсказать (разумеется, с некоторой погрешностью), сколько времени займет каждый из запланированных этапов тестирования и каждый из его циклов. В дальнейшем по ходу работы можно пери одически генерировать отчеты об уже проделанной работе и сравни вать свои предположения с реальными данными. Разумеется, тестовые материалы могут разрабатываться и постепен но, параллельно с работами по тестированию. Но и в этом случае вся работа заранее разбивается на ряд этапов, для которых сроки и объемы заданий хотя бы приблизительно определены. Так что воз можность контролировать их выполнение все равно останется. Так или иначе, в начале проекта всегда определяются основные задачи и цели, и в ходе тестирования обязательно контролируется их выполнение. Смысл генерируемых отчетов прежде всего в том, что бы вовремя корректировать дальнейшие действия, учитывая уже имеющийся опыт, а также выявлять и решать возникающие пробле мы. В частности, в критических ситуациях к проекту могут подклю чаться дополнительно люди и ресурсы, и, если необходимо и возможно, сроки его могут пересматриваться. Тесты каких типов следует фиксировать в плановых документах Хорошие программисты — люди ответственные, они тщательно тести руют свой код. Однако они не выполняют всей той работы, которую про водите вы. Именно поэтому вы находите ошибки, которые они Глава 12: Планирование и документация 297 пропускают, а также потому, что вы всегда видите программу с другой точки зрения. Программист тестирует и анализирует код изнутри, он выполняет стан дартное тестирование "стеклянного ящика". Он, и только он отвечает за анализ путей выполнения программы, только он видит все ее ветви, и он должен гарантировать, что каждый модуль, откуда бы он ни был вызван, выполнится успешно и данные между всеми взаимодействующими модуля ми будут передаваться правильно. Вполне возможно, что принять участие в процедуре тестирования "стек лянного ящика" предложат и вам. В этом случае ознакомиться с вопросом вам помогут книги таких авторов, как Хезел (Hetzel, 1988), Бейзер (Beizer, 1990), Гласс (Glass, 1992) и Миллер и Хауден (Miller & Howden, 1981). В такой ситуации было бы очень хорошо воспользоваться средствами мони торинга охвата — тестировочными утилитами, отслеживающими пути вы полнения программы, выполняемые ветви и модули. Тестирование "стеклянного ящика" окружено особым мистическим ореолом. Оно кажется более научным, логическим, более профессиональ ным и академическим и считается более престижным. Некоторые тестиров- щики не считают тестирование полноценным до тех пор, пока не будет проведено тестирование "стеклянного ящика". Однако эксперименты двух весьма уважаемых исследователей показали, что ни один из двух видов тестирования не является более эффективным. Этими исследователями являются Хезел (Hetzel, 1976) и Майерс (Myers, 1978). Что касается нашего собственного опыта, то, отставив в сторону пред рассудки, мы можем сказать, что эти методы являются взаимно дополня ющими и каждый из них выявляет свои специфические проблемы. Что упускается при тестировании "стеклянного ящика" Вот три примера ошибок, проявляющихся в системах MS-DOS и не выявляемых при анализе путей и ветвей программы. • Эта ошибка встречалась в ранних программах (до 1984 года) для ПК. Если в процессе загрузки программы нажать клавишу пробела, в очень многих случаях компьютер выключался из-за прерываний, которые оставались активными в ходе дискового ввода/вывода. Поскольку прерывание было для большинства программ событием совершенно неожиданным, кода для его обработки в программе не оказывалось. Очевидно, что, тестируя имеющиеся ветви программы, нельзя обнаружить, что определенная ветвь вообще отсутствует. • Если подключить к компьютеру два монитора, монохромный и цвет ной, и запустить одну из ранних игр под одной из ранних версий MS- 2 9 8 Часть II: Приемы и технологии тестирования DOS, изображение на монохромном мониторе с большой вероятностью окажется испорченным или же на экране будут странные помехи. • Подключите к компьютеру принтер, включите его и установите пе реключатель в Off line. Затем в какой-нибудь старой программе попробуйте выполнить команду печати. Если программа не "завис нет", проделайте то же самое с другой версией MS-DOS. Очень часто программы сбоят при тестировании с конфигурациями, отли чающимися от тех, с которыми они разрабатывались. Все эти ошибки нелегко обнаружить, поскольку в программном коде они не видны. В программе для них нет путей выполнения, поэтому, вы полнив даже каждую строку кода, вы все равно их не найдете. Чтобы выявить такие ошибки, нужно оставить в стороне программный код и подумать, какими способами и с каким оборудованием пользователи могут эксплуатировать программу. В целом для поиска ошибок, подобных перечисленным на рис. 12.1, тестирование "стеклянного ящика", без сомнения, является более слабым средством. Эта книга посвящена тестированию работающего кода, тестированию извне, которое осуществляется путем выполнения программы самыми разными способами и с самыми разнообразными нагрузками. Этот подход дополняет подход программиста и позволяет выполнить тесты, которые он едва ли когда-нибудь проведет. |