Канер С. Тестирование программного обеспечения

Подождите немного. Документ загружается.

Глава

Инструментальные

средства

тестировщика

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

Теперь читателю предстоит познакомиться с программными средствами,

автоматизирующими процедуру тестирования "черного ящика", узнать,

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

пойдет не о конкретных программах, а о классах подобных средств.

Библиография

В поиске подходящих программных средств могут помочь два известных

каталога: Testing Tools Reference Guide: A catalog of Software Quality

Support Tools, публикуемый Software Quality Engineering (800-423-8378,

3000-2 Hartley Road, Jacksonville, FL 32257) и Programmer's Shop (800-421-

8006, 90 Industrial Park Road, Hingham, MA 02043).

Немало полезной информации можно почерпнуть из книг таких авторов,

как Гласе (Glass, 1992), Бейзер (Beizer, 1990), Андриоле (Andriole, 1986),

Данн (Dunn, 1984) и Де Милло (DeMillo, 1981). Обзорные статьи и опи-

сания конкретных программных средств печатаются во многих журналах.

К ним нередко прилагаются CD с описываемыми программами и их

последними версиями.

Обзор

В этой главе обсуждаются следующие вопросы:

• Базовые инструменты тестировщика.

• Автоматизация приемочного и регрессионного тестирования.

• Технологии и инструменты тестирования соответствия стандартам.

• Средства для тестирования "стеклянного ящика".

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

Базовые инструменты тестировщика

Вот каковы основные инструменты тестировщика:

• Персональный компьютер, терминал или рабочая станция. Никог-

да не пренебрегайте помощью компьютера — обращайтесь к нему

каждый раз, когда в этом возникает потребность.

Значительно повышает производительность одновременная

работа с двумя компьютерами, на одном из которых

запущена тестируемая программа, а другой служит

для регистрации проблем и корректировки плана

тестирования.

• Хороший текстовый процессор. Вам необходима программа, позво-

ляющая вводить и редактировать руководства, планы тестирования,

отчеты, записи и письма. Пользоваться ею вы будете так активно,

что стоит потратить время на выбор самого оптимального продукта.

• Процессор планов. Эта программа специально предназначена для

составления и реорганизации иерархических структур, и она гораз-

до лучше справляется с этой работой, чем обычный текстовый про-

цессор. С ее помощью удобно составлять планы тестирования,

списки функций, подробные отчеты о состоянии и списки задач.

Мы предпочитаем пользоваться именно отдельными процессорами

планов, а не их ограниченными версиями, включаемыми в тексто-

вые процессоры. Выбирая такой продукт, прежде всего обратите

внимание на функции группировки, сортировки и реорганизации

информации.

• Электронная таблица. Эта программа незаменима для работы с

тестовыми таблицами.

• Утилиты сравнения файлов. Подобных программ достаточно мно-

го: они сравнивают пару файлов, сообщают, найдены ли различия,

и если да, показывают их список. Лучшие из них генерируют пере-

чень изменений, которые необходимо внести в один из файлов,

чтобы получить другой.

Простейшие утилиты сравнения файлов нередко поставляются в

комплекте операционных систем. Однако если вам встретится про-

грамма, более подходящая для решения именно ваших задач, стоит

на нее потратиться. Утилиты могут предназначаться для разных

целей: сравнения двоичных файлов (объектного кода, графики,

сжатых данных и т.п.) и сравнения текста. От их назначения зави-

сит то, в каком виде будут представлены результаты сравнения.

266 Часть II: Приемы и технологии тестирования

• Просмотровики файлов. Такие программы позволяют просматривать

данные, хранящиеся в файлах самых разнообразных форматов.

• Конвертеры файлов. Эти утилиты преобразовывают файлы данных

(текстовые, графические и т.п.) из одного формата в другой. Напри-

мер, текст может быть преобразован из формата одного текстового

процессора в формат другого.

• Утилиты для создания копий экрана. Эти утилиты позволяют сохра-

нить содержимое экрана или текущего окна в файле на диске. Воз-

можно, вам понадобится даже несколько таких программ, поскольку

некоторые из них несовместимы с отдельными типами программно-

го обеспечения. Копии экрана полезны как для анализа ошибок и

поиска их источника, так и для того, чтобы показать ошибку про-

граммисту. Нередко проще предоставить ему копию экрана, чем

описывать его содержимое на словах.

• Утилиты для поиска текста. С помощью такой утилиты можно

найти в объектном коде программы текстовые строки. Простейшие

из них просто прочесывают программный файл и записывают в от-

дельном текстовом файле все содержащиеся в нем строки ASCII. В

результате получается список всего встроенного в программу текста

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

проекта будет убеждать вас, что не стоит тратить времени на подоб-

ную работу, поскольку весь текст хранится в файлах ресурсов. Од-

нако это утверждение не мешает проверить, поскольку программист

может все же вставить в программу парочку коротких сообщений,

особенно о критических ошибках.

• Устройства видеозаписи (VCR). Весь вывод на экран можно запи-

сать на видеопленку. Для этого нужен обычный видеомагнитофон и

специальная видеоплата с соответствующим выходом. (Имейте в

виду, что платы NTSC не сохраняют на ленте весь экран VGA.) Для

тестирования неустойчивых программ с трудноуловимыми ошибка-

ми записывающие устройства просто незаменимы. Они невероятно

облегчают поиск и воспроизведение ошибок, а если ошибку невоз-

можно воспроизвести, видеозапись подтверждает, что она все же

произошла, и сохраняет точную хронологию событий. Обычно это-

го достаточно, чтобы программист мог проанализировать ситуацию

и выявить причину сбоя.

Однако, несмотря на всю полезность этого инструмента, его приме-

нения может стать для тестировщика сущим бедствием. В восторге

от таких возможностей, руководитель проекта может требовать, что-

бы видеозапись прилагалась к каждой выявленной ошибке, а это уже

серьезно затормозит вашу работу. Поэтому придерживайтесь золотой

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

середины, применяя это, без сомнения, эффективное средство толь-

ко там, где оно действительно необходимо.

• Диагностические программы. Существует ряд утилит, анализирую-

щих аппаратное и программное обеспечение системы. Они помогут

вам выяснить, какие в вашем распоряжении имеются устройства, все

ли с ними в порядке и как они работают. В частности, с их помо-

щью можно найти и исключить из использования поврежденные

участки жесткого диска или определить, работает ли видеоплата в

режиме, позволяющем осуществлять видеозапись работы. Можно

также сохранять информацию о состоянии оперативной памяти в

момент сбоя — в определенных случаях эта информация может быть

очень полезна программисту. Он скажет вам, какой утилитой лучше

всего для этого воспользоваться, и предоставит ее в случае необхо-

димости.

• Таймер. Иногда необходимо определить длительность какой-либо

операции, возможно в десятых или сотых секунды. Для этого пре-

красно подойдет программный таймер. Отдельные устройства вроде

наручных часов менее удобны, и с их помощью нельзя работать с

очень маленькими временными интервалами. Чаще всего измерения

времени необходимы при тестировании тайм-аутов, условий гонок,

а также задержек реакции системы на действия пользователя и вы-

полнения относительно длительной обработки данных.

• Система отслеживания проблем. Это настолько важная тема, что

она обсуждалась в отдельной главе.

• Программист. Если вам не удается воспроизвести ошибку, вы не

знаете, каковы граничные условия процесса или не понимаете, как

тестировать какую-либо функцию программы, обращайтесь к про-

граммисту. Ложная гордость в этом вопросе совершенно неуместна,

вы не можете всегда и на все знать точные ответы. Однако всегда

критически анализируйте слова программиста, поскольку сознатель-

но или ненамеренно он может ввести вас в заблуждение. Впрочем,

это крайний случай. В основном же программист может сэкономить

вам часы и дни работы, либо сразу определив источник проблемы,

либо написав специальный диагностический код, либо просто

разъяснив некоторые особенности программы и посоветовав, как

или какими средствами ее можно эффективнее протестировать.

Автоматизация приемочного и

регрессионного тестирования

Как правило, каждая новая версия программы, получаемая тестировщи-

кзш, проходит стандартное приемочное тестирование. Его цель — убедить-

268 Часть II: Приемы и технологии тестирования

ся, что в программе не появилось серьезных проблем и все ее базовые

функции успешно работают. Обычно на такое тестирование уходит не

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

базовые и быстровыполнимые примеры, проверка всех возможных гранич-

ных условий сюда не входит. В некоторых коллективах практикуется рас-

пространение набора приемочных тестов не только среди тестировщиков,

но и среди остального заинтересованного персонала. В частности, при

необходимости руководитель проекта может лично убедиться, что состоя-

ние очередной версии программы удовлетворяет базовым приемочным тре-

бованиям.

• В некоторых компаниях программа, не прошедшая приемочного

тестирования, вообще не принимается тестировщиками и возвраща-

ется обратно программистам на доработку. Особенно часто так

бывает на более поздних стадиях разработки, когда программа уже

не раз проходила приемочное тестирование, и вдруг очередная вер-

сия его не прошла. Обычно это означает, что в процессе корректи-

ровки исходного кода или его компиляции программистами была

допущена грубая ошибка, которая, однако, легко может быть ис-

правлена.

• Существует и иная практика, когда приемочное тестирование при-

меняется для выявления самых очевидных ошибок очередной вер-

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

очевидно, на какие части программы следует обратить особое вни-

мание, а какие, наоборот, оставить пока в покое, если группа тес-

тирования еще не готова взяться за них со всей серьезностью.

• Приемочное тестирование — процедура довольно утомительная и

скучная и к тому же занимает много времени. Поэтому независимо

от того, насколько велика разрабатываемая программа, для него на-

значается относительно небольшое количество тестов. В противном

случае оно слишком дорого обходится.

Регрессионное тестирование выполняется после каждого изменения

программы. Если программа прошла определенную группу тестов в про-

шлый раз, то, скорее всего, пройдет и в этот. Однако провести их все равно

придется — это неотъемлемая часть общего процесса тестирования.

Итак, и приемочные, и регрессионные наборы тестов выполняются по

многу раз — они так и просятся, чтобы их автоматизировали. Это вполне

возможно. Задача состоит в том, чтобы объяснить компьютеру, как выполнить

тест, собрать результаты, сравнить их с заранее известными правильными ре-

зультатами и сообщить вам, чем все кончилось. В этой главе главным образом

рассматривается автоматизация регрессионного тестирования, но все сказан-

ное в равной мере справедливо и для приемочного.

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

Несколько ранее, в главе 11, рассказывалось об автоматизации тестиро-

вания печати. Ряд приводившихся в ней соображений можно распростра-

нить и на автоматизацию процесса тестирования в целом.

Откуда берутся регрессионные тесты

Когда программист исправляет ошибку, существует определенная веро-

ятность, что он исправит не то, что нужно, или допустит новую ошибку,

нарушит что-то, что уже работало. Поэтому после каждого такого исправ-

ления (или группы исправлений), необходимо, во-первых, проверить, ре-

шена ли та проблема, из-за которой вносились исправления, а во-вторых,

проверить целостность всей программы.

• Тесты для граничных условий и другие заранее запланированные

тесты. Среди всех тестов, перечисленных в вашем рабочем плане,

необходимо выбрать те, которые с наибольшей вероятностью выя-

вят возможные ошибки.

•

Тесты, уже однажды выявившие ошибку. То, что однажды почини-

ли, нередко ломается снова. Так происходит потому, что в том ме-

сте, где в программу внесено исправление, ее код часто выглядит

непонятным, непоследовательным или неловким. А если исправле-

ния в программу вносил один программист, а продолжает ее дора-

ботку другой, то существует большая вероятность того, что

исправленный фрагмент будет неверно понят и повторно исправлен.

•

Ошибки, выявленные пользователями. Ошибки, о которых сообща-

ют пользователи, группа технической поддержки и другой персонал,

не входящий в группу тестирования, указывают на дыры в плане работ

вашей группы. В некоторых группах тестирования принято добавлять

в тестовые планы регрессионные тесты для каждой такой ошибки.

•

Наборы тестовых данных, сгенерированных методами случайного

подбора. Об использовании генератора случайных чисел уже расска-

зывалось в главе 7 при обсуждении тестирования функциональной

эквивалентности. Хотя случайные данные не заменят граничных

тестов, они послужат полезным дополнением, позволяющим проте-

стировать программу с более разнообразной входной информацией.

Снабжение программы входными данными

В чем состоит сложность составления набора регрессионных тестов, так

это в огромном количестве тестов — потенциальных кандидатов на звание

регрессионных. Все их выполнить просто невозможно. Поэтому в главе 7

подробно описывались принципы отбора тестов, позволяющие составить

тносительно небольшую, но при этом эффективную группу тестировочных

заданий. Теперь же мы рассмотрим способы автоматизации регрессионного

тестирования (полной или хотя бы частичной), и, если процесс тестирова-

270 Часть II: Приемы и технологии тестирования

ния удастся успешно автоматизировать, вам не придется отсеивать такое

большое количество тестов просто из-за нехватки времени.

Существует несколько способов того, как тестовые данные могут попа-

дать в программу.

• Файлы данных. Программа может быть способна считывать тесто-

вые данные из файлов. При этом ее пользовательский интерфейс,

разумеется, не тестируется, но зато основательно проверяется ее

базовая функциональность. Заранее подготовленные файлы приго-

дятся при тестировании загрузки информации программой, ее экс-

порта и импорта. Разумно составленные файлы позволяют

протестировать программу на границах ее возможностей (максимум

записей, огромные числа и т.п.). В каждой программе это может

быть нечто свое, так что потребуется довольно много времени на

подготовку тестовой информации.

Иногда тестовые данные стоит хранить в базе данных. Программа,

используемая для управления этой базой данных, должна обладать

способностью сохранения информации в различных форматах. Если

формат входных данных тестируемой программы изменится, с помо-

щью СУБД можно будет сформировать новые файлы. Впрочем, даже

если формат входных данных и не является для вашей программы

первоочередным вопросом, СУБД предоставляет целый ряд других

полезных возможностей для работы с данными, как, например,

удобные средства редактирования и возможность снабжения инфор-

мации необходимыми комментариями.

• Пакетные файлы. Некоторые программы, такие как компиляторы и

компоновщики, а также многие программы для математических

расчетов, могут считывать с диска абсолютно всю необходимую

информацию, включая и команды. Существуют и такие программы,

которые предназначены исключительно для пакетного выполнения,

они, по определению, читают все входные данные из файлов. Если

вам посчастливилось иметь дело именно с такой программой, под-

готовки тестовых файлов и анализа результатов будет достаточно для

тестирования практически всех ее аспектов.

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

дут введены с клавиатуры, это еще не означает, что ею невозмож-

но управлять через файл. Просто следует воспользоваться

возможностью операционной системы перенаправлять ввод и вывод

информации (если, конечно, такая возможность имеется). Суть та-

кого перенаправления состоит в том, что программе кажется, будто

данные поступают из стандартного входного устройства (обычно это

клавиатура), в то время как на самом деле они считываются опера-

ционной системой из указанного вами файла. Всеми деталями это-

го механизма управляет операционная система.

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

Перенаправление ввода подходит не для всех случаев, поскольку его

возможности ограничены. Как, например, организовать задержку в

3,2 секунды между двумя нажатиями клавиш?

•

Ввод через последовательный порт. Еще один трюк, применяемый

тестировщиками, как и предыдущий, состоит в подмене входного

устройства таким образом, чтобы программа этого не заметила. Од-

нако на этот раз данные поступают не из файла, а из последователь-

ного порта. Существует специальное программное обеспечение,

позволяющее одному компьютеру управлять работой другого, свя-

занного с ним через сеть, модем или нуль-модем. В частности, это

имеющиеся на рынке персональных компьютеров программы эму-

ляции терминала.

Соединив два компьютера либо с помощью кабеля, подключенного

к их последовательным портам, либо через телефонную линию по-

средством модемов, можно, сидя за одним из них, управлять вторым

так, как будто вы работаете с его клавиатурой и мышью, и видеть на

экране отображаемую им информацию. Но главное, что действия

пользователя можно определить заранее, так чтобы их эмулировало

программное обеспечение. При этом его возможности гораздо шире,

чем при вводе данных операционной системой из файла. В частно-

сти, можно определить любые необходимые временные задержки и

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

рынке имеется целый ряд мощных и дорогостоящих систем для

тестирования персональных компьютеров по описанной технологии,

и их возможности постоянно расширяются.

• Перехват и воспроизведение клавиатурного ввода. Если воспользо-

ваться программой, перехватывающей клавиатурный ввод, можно

один раз выполнить и "записать" с ее помощью тест, а затем вос-

производить его сколько угодно раз. Такая программа может запи-

сывать не только все нажатия клавиш, но и все манипуляции

пользователя с мышью.

Подобная технология не только облегчает работу, освобождая тести-

ровщика от необходимости выполнять утомительные и однообраз-

ные действия и позволяя ему полностью сосредоточиться на

программе, но и гарантирует, что тест всегда будет выполняться

абсолютно одинаково. Однако у нее есть и определенные издержки.

Записав тест, необходимо его тут же проиграть, чтобы убедиться, что

он записан правильно. Кроме того, определенных усилий требует

организация и документирование записанных тестировочных фай-

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

тирование теста уходит как минимум в 3, а то и в 10 раз больше

времени, чем на его выполнение вручную.

272 Часть II: Приемы и технологии тестирования

К тому же автоматизированный тест, представляющий собой запись

действий пользователя, не сработает, если в программу будут внесе-

ны даже самые незначительные изменения, связанные с последова-

тельностью этих действий. Тест придется выполнять и записывать

заново. Простейшим примером может быть реорганизация меню

программы.

Покупая программу перехвата и воспроизведения ввода, убедитесь,

что она записывает не только действия пользователя, но и времен-

ные интервалы между ними. Кроме того, проверьте, правильно ли

воспроизводятся манипуляции с мышью при различных разрешениях

экрана. Хорошо бы убедиться и в ее надежности. Рынок таких про-

грамм относительно невелик, и они не всегда тщательно тестируют-

ся. Имейте в виду, что покупаемая вами утилита относится к разряду

резидентных, а это означает потенциальную возможность проблем

не только в ее собственной работе, но и во взаимоотношениях с

остальным запущенным программным обеспечением.

Запись вывода тестируемой программы

Автоматизировать ввод данных для тестируемой программы обычно

гораздо проще, чем записать ее выходную информацию в подходящей для

анализа форме. Выбор у вас следующий.

• Файлы выходных данных. Идеальным случаем является программа,

сама сохраняющая свои данные в файлах, причем в формате, под-

ходящем для тестирования.

• Перенаправление вывода в файл. В дисковый файл можно, напри-

мер, перенаправить вывод, предназначенный для принтера. Если это

возможно, то перенаправление вывода извне предпочтительнее ис-

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

ку гарантирует, что в файл попадет в точности та же информация,

что и на принтер.

Если программа предназначена для работы в текстовом режиме, то

в файл можно перенаправить и то, что она выводит на экран.

• Вывод через последовательный порт. Если имеется возможность

удаленного управления компьютером либо с терминала, либо со

второго компьютера посредством специального программного обес-

печения, этот второй компьютер может записывать принимаемые

выходные данные в файл для последующего анализа.

• Перехват экрана. Существует множество программ, позволяющих

сохранить изображение текущего окна и всего экрана. Как будет

рассказано чуть позже, мы очень широко пользуемся такими про-

граммами.

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

•

Перехват вывода программы с помощью специальных тестирован-

ных утилит. Совершенно очевидно, что, если программа разрабо-

тана специально для тестирования, ее возможности гораздо шире,

чем у утилит общего назначения. Хорошая программа позволяет

сохранять указанные области экрана, например поля данных, кото-

рые меняются от теста к тесту.

Оценка выходной информации

Записав выходную информацию программы, тестировочная система

должна оценить ее правильность. Как это сделать? Существует несколько

традиционных подходов.

•

Если существует эталонная программа, выполняющая то же самое,

что и тестируемая, можно сравнить их вывод.

•

Написать параллельную программу, генерирующую точно такие же

результаты, и сравнивать их вывод. На практике проще создать

несколько десятков небольших параллельных программ — по одной

на каждую тестируемую функцию.

•

Сформировать библиотеку правильных выходных данных. При этом

для каждого нового набора тестов придется создавать и новые эта-

лоны выходных данных. Это довольно долгий и трудоемкий про-

цесс, особенно если данные эталонных файлов придется вводить

вручную. И здесь неизбежны издержки по выявлению множества

ошибок и опечаток. Однако основной объем работы придется на

самое начало, когда необходимо будет сформировать основную мас-

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

будет автоматизировать постепенно, один за другим.

• Перехват вывода программы. Сохраняйте результаты каждого тес-

та, какими бы они ни были. Результат теста записывается в отдель-

ный файл, анализируется сразу или позднее и помечается как

хороший или плохой.

После того как тесты будут выполнены повторно, их результаты

можно снова записать в файлы и сравнить с предыдущими. Эта

работа прекрасно поддается автоматизации. Несовпадение нового

файла со старым, помеченным как хороший, означает либо появле-

ние новой ошибки, либо изменение спецификации. Если очередной

результат теста оказывается хорошим, все предыдущие плохие ре-

зультаты можно удалить.

Как и предыдущая, эта стратегия носит инкрементальный характер.

Библиотека результатов тестов постепенно растет, пополняясь все

новыми данными, и в конечном счете в ней оказывается по файлу на

каждый тест, причем в этих файлах только положительные данные.

274 Часть II: Приемы и технологии тестирования

В организации корректного сравнения выходных данных, особенно

сравнения копий экрана, существует целый ряд сложностей. Как, напри-

мер, обучить программу сравнения игнорировать различающиеся даты? Как

быть с изменяющимися заголовками окон? Что, если данные выводятся с

различной степенью точности, в различном порядке или в разных местах

экрана? К тому же малейшие изменения программы могут оказаться фа-

тальными для огромного количества тестовых файлов.

Некоторые программы перехвата изображений умеют сравнивать только

отдельные фрагменты экрана, содержащие важные для тестирования дан-

ные, и игнорировать все остальное. Другой прием заключается в том, что

программа отображает две копии экрана, старую и новую, и закрашивает

белым цветом все, что совпадает, оставляя только различающиеся фрагмен-

ты для визуального сравнения.

Нам приходилось видеть программное обеспечение для перехвата и

сравнения ввода/вывода, которое производило вполне солидное впечатле-

ние. Ряд руководителей групп тестирования говорили нам, что вполне

полагаются на эти программы, особенно активно пользуясь ими при вы-

полнении приемочного тестирования. Однако сами мы еще не пользова-

лись подобными средствами, а потому воздерживаемся от каких-либо

одобрительных или критических замечаний в их адрес. Вот несколько воп-

росов, которые следует обдумать, планируя автоматизацию процесса тести-

рования.

•

Временные затраты. На создание автоматизированных тестов ухо-

дит очень много времени. Как утверждается в Microsoft Test User's

Guide (Microsoft, 1992, с. 15), автоматизация тестирования требует

самого тщательного планирования и организации и часто наиболь-

ших временных затрат.

Предположим, что на проектирование, создание и документирова-

ние автоматизированного теста уходит вдесятеро больше времени,

чем необходимо на подготовку и выполнение его вручную. Это оз-

начает, что временные затраты на автоматизацию окупаются толь-

ко после десятого или одиннадцатого прогона теста. Все

последующие его прогоны не стоят почти ничего, если только тест

не придется модифицировать. Получается, что тесты, которые вы-

полняются всего несколько раз, автоматизировать вообще не стоит.

• Задержки в тестировании. Если отложить серьезное тестирование

до тех пор, пока не будет подготовлена целая "батарея" тестов,

можно поставить под угрозу весь проект. Программистам необходи-

ма быстрая ответная реакция группы тестирования, состояние про-

екта всегда должно быть известно. Поэтому с самого начала проекта

стоит подумать о расширении группы тестирования, чтобы в то

время, когда одна часть персонала занята разработкой автоматизи-

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

рованных тестов, другая могла выполнять тестирование вручную в

нормальном рабочем режиме.

• Инерция. Вложения в разработку автоматизированных тестов доста-

точно велики. Если программист изменит пользовательский интер-

фейс программы или формат ее входных или выходных данных,

огромную часть тестов придется просто-напросто выбросить. Осо-

бенно остро эта проблема стоит в тех случаях, когда тесты разраба-

тываются на самых ранних стадиях проекта, поскольку вероятность

последующих значительных изменений в программе при этом силь-

но увеличивается.

Как правило, изменения вносятся в проект отнюдь не по чьей-либо

прихоти. Руководитель проекта соглашается на них потому, что они

значительно усовершенствуют или улучшают программу, делают ее

более последовательной и простой в использовании. Формат файлов

данных обычно меняется ради достижения совместимости или уст-

ранения ошибок. А раз так, вы должны приветствовать всякое по-

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

большое количество необходимых тестов, основанных на старом

варианте интерфейса или формате файлов, для группы тестирования

изменения могут быть очень нежелательны, и вместо оказания со-

действия в улучшении качества продукта вы можете невольно стать

его противником.

• Риск пропущенных ошибок. Microsoft (1990, с. 7.33) предупреждает,

что автоматизированные тесты должны планироваться и организовы-

ваться очень тщательно, поскольку за их выполнением тестировщик

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

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

тестировщики, проводившие автоматизированное тестирование, про-

пускали очень серьезные и совершенно очевидные ошибки. Майерс

(Myers, 1979) также писал о результатах исследований, показывающих,

что тестировщики недостаточно внимательно анализируют результа-

ты автоматизированных тестов и пропускают очень много ошибок.

Продумывая тесты, особое внимание уделите тому, чтобы их резуль-

таты были как можно короче и представлены в простой и наглядной

форме. Никто не будет вычитывать километры распечаток, и уж во

всяком случае никто не сможет сделать это достаточно внимательно.

Скорее всего, вам понадобится небольшой журнал тестирования, в

котором в одной строке фиксировался бы каждый выполненный

тест. Кроме того, в нем должны фиксироваться все сбои программы,

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

276 Часть II: Приемы и технологии тестирования

Еще одним полезным приемом может быть выдаваемый тестировоч-

ной программой звуковой сигнал о неудачном тесте и сообщение,

которое остается на экране до тех пор, пока тестировщик с ним не

ознакомится. Так вы гарантируете, что будете знать о каждой выяв-

ленной ошибке. Однако тут необходима аккуратность, звуковые

сигналы не должны выдаваться в тех случаях, когда в сравниваемых

файлах различаются незначащие детали, например, даты. Иначе из

организующего фактора такая технология работы превратится в

бедствие.

• Частичная автоматизация. Вовсе необязательно полностью авто-

матизировать весь процесс тестирования. Часть тестов может быть

автоматизирована, в то время как другие лучше по-прежнему про-

водить вручную. Для начала стоит автоматизировать наиболее под-

ходящие для этого тесты, а также те, которые наверняка будут

проводиться десятки раз. Потенциальными кандидатами для автома-

тизации являются также те тесты, которые требуют большого объе-

ма клавиатурного ввода, сложны и утомительны для ручного

выполнения.

Что касается отдельных тестов, то их автоматизация также может

быть частичной. Например, можно записать и проигрывать клавиа-

турный ввод, а результаты анализировать визуально. Это сэкономит

некоторое время на вводе информации и позволит избежать возни

со сравниваемыми выходными файлами.

Автоматизация приемочного тестирования

Некоторые руководители большую часть средств, выделенных на авто-

матизацию тестирования, тратят на создание приемочных тестов. Их сооб-

ражения таковы.

• Именно эти тесты выполняются чаще всего. Если обновленная

версия программного продукта передается тестировщикам каждую

неделю, да плюс еще периодически появляются внеочередные вер-

сии с исправлениями наиболее существенных ошибок, за все время

разработки комплекс приемочных тестов может быть выполнен

пятьдесят и даже сто раз.

•

К каждой функциональной области программы относится сравни-

тельно небольшое количество тестов. Приемочные тесты быстро

прогоняют все основные части программы, ни на чем не останавли-

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

меняется, соответствующую группу тестов легко можно переделать.

•

Утомительность процедуры приемочного тестирования ведет к

ошибкам. Тестировщику приходится выполнять одни и те же тесты

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

множество раз, поэтому неудивительно, что он пропускает некото-

рые тесты или выполняет их невнимательно. Программа же всегда

выполняет тесты одинаково — ведь ей не бывает скучно и она ни-

когда не устает.

Стандарты

Ваша компания может подписать контракт, по которому программа

должна удовлетворять определенным стандартам. Подтверждение соответ-

ствия этим стандартам входит в задачи группы тестирования. Программы,

выполняющие такую проверку, часто доморощенные и трудно поддаются

модификации. Утилиты, анализирующие программу на соответствие стан-

дартам, могут сообщать о следующих ее недостатках.

• Проблемы с переносимостью. Программа может использовать рас-

ширения языка, несовместимые с другим компилятором, непосред-

ственно записывать или считывать данные из определенных

областей памяти или ориентироваться на новые возможности уст-

ройств ввода/вывода, которые имеются далеко не во всех системах.

• Рекурсия. Программа называется рекурсивной, если в ней имеется

подпрограмма, вызывающая сама себя. Этот прием запрещается

некоторыми стандартами.

• Степень вложенности. Главная программа может вызывать под-

программу, та — еще одну подпрограмму, та — еще одну и т.д. В

конце концов вызывается подпрограмма, выполняющая нужную

работу. Сколько же вызовов для этого потребуется? Приемлемо ли

такое количество? Аналогичным образом вложенными могут быть

циклы и условные операторы. Если язык программирования позво-

ляет определять пользовательские типы данных, насколько допусти-

мо определять переменную, относящуюся к типу, определенному

посредством другого типа, определенного посредством другого типа

и т.д. Как глубоко придется копать, чтобы выяснить, о каких же в

самом деле данных идет речь?

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

ствительно ли введенное значение меньше 6. Одни программисты

определят именованную константу, например MAX_VAL, назначат

ей значение 6 и будут использовать это имя в коде для сравнения.

Другие же просто будут сравнивать введенное значение с числом 6,

поместив его прямо в код. Этот второй способ часто является зап-

рещенным. Недостаток его в том, что при изменении максимального

значения с 6 на какое-нибудь другое число придется искать и заме-

278 Часть II: Приемы и технологии тестирования

нять шестерки по всему программному коду — ведь сравнение мо-

жет выполняться и не в одном месте. Если же определить констан-

ту и вынести ее в самое начало программного кода, то найти и

изменить ее значение будет гораздо проще.

• Размер модуля. Сколько строк программного кода может содержать

процедура или функция? Нет ли в программе чересчур длинных

подпрограмм или, наоборот, слишком коротких, так что программ-

ный код становится настолько фрагментированным, что теряется его

логика? А как насчет количества подпрограмм в одном файле?

• Комментарии. По стандарту на каждые три строки программного

кода может требоваться по одному комментарию. Стандартом может

определяться формат комментариев, их длина, расположение в фай-

ле и другие характеристики.

• Соглашения об именах. Стандарт может определять принципы наи-

менования переменных, подпрограмм и файлов.

• Форматирование. В стандарте могут быть описаны такие вещи, как

отступы, расположение операторов, отмечающих начало и конец

блоков кода, или максимальное количество символов в строке.

• Запрещенные конструкции. Может быть запрещено применение

операторов GOTO, операторов прерывания потока типа EXIT или

вызов подпрограмм, адреса которых хранятся в переменных-указа-

телях. Могут быть запрещены определенные способы протоколиро-

вания ошибок или определенные команды ввода/вывода.

• Запрещенные действия. Примером таких действий может быть зап-

рет перехода по команде GOTO назад по программному коду, в то

время как аналогичные переходы вперед могут разрешаться. (При-

чина такого запрета в том, что переходы назад ведут к большему

количеству ошибок, чем переходы вперед.)

• Псевдонимы. Если два различных имени относятся к одной и той же

переменной, т.е. указывают на одно и то же место памяти, они

считаются псевдонимами. Такие вещи могут не допускаться стандар-

том.

• Преобразование типов данных. Одни и те же данные могут по-раз-

ному интерпретироваться в различных местах программы. Напри-

мер, можно объявить массив целых чисел и передать его

подпрограмме, которая будет работать с ним как со строкой. Это

может быть запрещено стандартом.

Если программа проверки соответствия стандартам может выявлять все

эти проблемы, возможно, она может обнаруживать и некоторые типы

ошибок. Такие программы часто выявляют следующее.

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

• Неверный синтаксис. Компилятор такие ошибки обнаруживает, а

вот в интерпретируемой программе они проявляются только во вре-

мя выполнения соответствующего фрагмента кода.

• Смешанные вычисления. Если А=5 и В=2, тогда возможно, что

А/В=2,5, если обе переменные являются числами с плавающей за-

пятой, и А/В=2, если числа целые. Эти правила определяются язы-

ком программирования, но главное, что при этом программист не

всегда получает то, чего ожидает. Иногда он может просто не заме-

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

• Переменные, определенные в программном коде, но никогда не ис-

пользуемые. Программа может установить, что А=5, но никогда

больше не использовать переменную А. Скорее всего, программист

предназначал ее для какой-то цели, а потом о ней просто забыл.

Хотя такое объявление само по себе совершено безобидно, в даль-

нейшем оно может смутить того, кому придется эту программу под-

держивать.

• Переменные, которые используются до их инициализации. Если

программа присваивает переменной В значение А и только после

этого присваивает переменной А начальное значение, то что будет

в переменной В?

• Чтение файла до его открытия или после закрытия. Выявив подоб-

ные команды, можно предотвратить сбои при обращении к устрой-

ствам ввода/вывода.

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

процедуры, которые никогда не вызываются, или фрагменты кода,

которым никогда не передается управление (например, условие вет-

вления не выполняется ни при каких обстоятельствах).

• Бесконечные циклы. Условие выхода из цикла может либо просто

никогда не выполняться, либо зависеть от данных, что является

потенциальной возможностью зацикливания программы.

Приведенный список можно было бы продолжить. Суть его в том, что

программу можно анализировать на предмет стиля, формата, соответствия

разнообразным правилам и наличия определенных типов ошибок. Часто

последнее слово в таком анализе остается за программистом, который один

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

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

РУКЦИЮ.

Однако если речь идет

соответствии определенным стандартам,

это должна гарантировать группа тестирования.

Необходимо очень тщательно проанализировать вопрос применимости

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

практике чревата целым рядом сложностей.

280 Часть II: Приемы и технологии тестирования

• Программисты могут пытаться некорректными способами улучшить

свои показатели или препятствовать попыткам анализировать их

работу. (Керней (Kearney, 1986), Вейнберг (Weinberg, 1971)).

• Чем больше внимания будет уделяться соответствию стандартам, тем

меньше времени, людей и сил будет оставаться для реального тести-

рования программного продукта — анализа его производительности,

удобства, эффективности и исправления ошибок.

Иногда качество продукта определяют как степень его соответствия

определенным стандартам. Однако, на наш взгляд, все, что не связано

непосредственно с его функциональностью, с восприятием продукта

пользователем, является скорее тормозом в работе по его совершенствова-

нию.

Гласе (Glass, 1992, с. 92) утверждает, и мы полностью с этим согласны,

что если оценивать качество продукта в терминах соответствия стандартам,

сформированным критериям могут удовлетворять явно плохие продукты.

Поэтому, на наш взгляд, лучше избегать включать в договор требование со-

ответствия стандартам. Разумеется, можно и пользоваться средствами ана-

лиза на соответствие стандартам, и писать собственные такие средства, но

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

ваться извне.

Тестирование "стеклянного ящика"

При тестировании "стеклянного ящика" тестировщик анализирует про-

граммный код. При противоположном подходе — тестировании "черного

ящика", которому главным образом посвящена эта книга, тестировщик в

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

Однако иногда программист снабжает тестировщика средствами, позво-

ляющими при тестировании "черного ящика" в некоторой степени опи-

раться и на программный код. Примерами таких средств могут быть

следующие виды отладочного кода:

• Для отслеживания путей выполнения программы.

• Для проверки определенных фактов.

• Для отслеживания использования памяти.

Если вы захотите прибегнуть к подобным технологиям работы, обрати-

тесь к такому автору, как Гласе (Glass, 1992).

Отслеживание путей выполнения программы

Протестировать каждый путь выполнения программы нереально. А вот

выполнение хотя бы по одному разу каждой строки программного кода —

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

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

подробно рассказывалось в главе 3.) Самый очевидный способ ее выпол-

нения — просто сесть перед компьютером с листингом и попытаться вы-

явить все возможные ветви кода.

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

добавить в программу специальный отладочный код. Когда программа

достигает заданной точки, она печатает определенное сообщение. Все со-

общения отличаются. Как правило, их нумеруют, так что всегда можно

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

размещает отладочные сообщения во всех ключевых точках программы. По

завершении цикла тестирования он анализирует распечатки или файл жур-

нала и выясняет, попало ли туда каждое из сообщений хотя бы по одному

разу. Если что-нибудь пропущено, значит, соответствующая область про-

граммы не была протестирована и можно подсказать тестировщикам, как

ее достичь.

Такая технология очень облегчает работу тестировщика, ведь ему боль-

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

надежнее. Отслеживать сообщения по ходу тестирования также ни к чему,

они могут и вовсе не выводиться на экран, а просто записываться в файл

журнала.

Существуют специальные программные средства мониторинга охвата

(coverage monitors), вставляющие в код подобные отладочные команды. Эти

команды называются зондами (probes). Такие программные средства могут

не только начинять программу зондами, но и собирать статистику их про-

хождения, формируя итоговые данные. Получив от средства мониторинга

охвата сведения о том, какие ветви программы не были пройдены, можно

подготовить и провести дополнительные тесты.

Хотя средства мониторинга охвата предназначены для тестирования

"стеклянного ящика", ими можно пользоваться и в обычной работе. В этом

случае вы просто узнаете, насколько полно ваши тесты охватывают про-

граммный код.

Средств мониторинга охвата на рынке имеется предостаточно. Стоит

составить их список, чтобы иметь что предложить программистам. Одна-

ко вполне возможно, что вы услышите от них целый ряд разумных возра-

жений. Их основания могут быть такими.

•

Средства мониторинга охвата вставляют в программу отладочный

код. В конечном продукте этого кода быть не должно. В результате

вы тестируете программу не в том виде, в каком она будет прода-

ваться, а это потенциальная возможность появления ошибок.

• Со средствами мониторинга программа медленнее работает. В

результате получаются условия гонок, отличные от реальных, а это

снова повышает вероятность появления ошибок.

282 Часть II: Приемы и технологии тестирования

•

Нашпигованная зондами программа сильно увеличивается в разме-

ре. Если размер программы имеет критическое значение, это обсто-

ятельство может скрыть тот факт, что ее размер и в самом деле

превысил допустимую величину.

• Некоторые из таких программных средств сами полны ошибок.

Программистам едва ли понравится, если они проведут пару дней в

поисках ошибки и окажется, что ее виновником является средство

мониторинга. Поэтому такое средство следует выбирать очень тща-

тельно и при его покупке осведомиться у продавца о наличии списка

известных ошибок.

Проверка утверждений

Обычно в каждой программе есть точки, в которых всегда должны

выполняться определенные условия. Чтобы убедиться, что необходимые

условия в самом деле выполняются, программист может поместить в эти

точки отладочные команды. Это и есть проверка утверждений (assertion

check). Если условие выполняется, программа не производит никаких не-

стандартных действий, если же нет, она может выдать на экран соответ-

ствующее сообщение или записать его в файл журнала. Возможно также,

что программа просто молча выполнит код обработки ошибочной ситуации.

Как правило, тестирование утверждений организуется таким образом,

чтобы тестировщик сразу же видел, что что-то идет не так. Для этого все

сообщения программы о неверных утверждениях выводятся на экран или

распечатываются. Так гораздо легче отслеживать и исправлять ошибочные

ситуации — ведь кроме того, в какой точке программы произошла ошиб-

ка, необходимо еще знать, как вы туда попали и с какими данными рабо-

тали. В противном случае ошибочную ситуацию может быть трудно

воспроизвести.

Анализ использования памяти

Работающая программа использует память следующими способами.

•

Часть памяти занимает сам программный код. За исключением

(весьма непопулярных) самомодифицирующихся программ, про-

грамма не может писать в собственную область кода.

• Часть памяти занимают данные. Программа может считывать и

записывать информацию своей области данных, но не может попро-

сить центральный процессор выполнить команду, записанную в этой

области.

• Определенная память связана с аппаратным обеспечением. Про-

грамма может общаться с внешним устройством, считывая и запи-

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

сывая информацию по определенным адресам памяти. Однако при-

кладные программы, как правило, взаимодействуют с внешними

устройствами через промежуточное программное обеспечение,

встроенное в BIOS компьютера или операционную систему. Для них

считается даже некорректным прямо обращаться к памяти устройств

ввода/вывода, минуя установленные драйверы.

• Недоступная память. Запуская программу, операционная система

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

программе обычно недоступна память, выделенная другим програм-

мам, работающим одновременно с ней. И уж во всяком случае ни

одной программе недоступна память, которая физически отсутствует.

Специальные утилиты, анализирующие использование памяти, могут

выявить подозрительные команды программы. Они могут остановить про-

цесс и сохранить в файле дамп памяти, могут перевести программу в ре-

жим отладки или просто сообщить о событии и продолжить выполнение

программы.

Утилиты, анализирующие использование памяти, могут предоставить

программисту и тестировщику множество полезной информации, и в том

числе об объеме свободной памяти, размере наибольшего свободного бло-

ка, подробный список всех работающих процессов или всех блоков памя-

ти с информацией о том, какой программой используется каждый из них.

Все эти данные очень полезны, так как проблемы с использованием памяти

являются наиболее трудноуловимыми. С их помощью можно выяснить сле-

дующее:

• Какой объем памяти занимает каждая составляющая программы.

• Возвращает ли программа операционной системе ту память, которая

ей больше не нужна. Особенно это касается достаточно больших

объемов памяти, выделенных, например, под графику. Если нет, то

рано или поздно вся свободная память системы будет исчерпана.

Оценивая картину использования памяти по данным подобных утилит,

следует учитывать и их собственную роль в этом процессе. Бывает, что

именно утилита не позволяет тестировщику воспроизвести произошедшую

ошибку. Однако в целом предоставляемая информация может быть просто

неоценима. Наш собственный опыт показывает, что из всех отладочных

команд, которые программисты встраивают в программный код, наиболее

ценны именно команды формирования отчета об использовании памяти.