Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
с различной степенью точности, в различном порядке или в разных местах экрана? К тому же малейшие изменения программы могут оказаться фа тальными для огромного количества тестовых файлов. Некоторые программы перехвата изображений умеют сравнивать только отдельные фрагменты экрана, содержащие важные для тестирования дан ные, и игнорировать все остальное. Другой прием заключается в том, что программа отображает две копии экрана, старую и новую, и закрашивает белым цветом все, что совпадает, оставляя только различающиеся фрагмен ты для визуального сравнения. Нам приходилось видеть программное обеспечение для перехвата и сравнения ввода/вывода, которое производило вполне солидное впечатле ние. Ряд руководителей групп тестирования говорили нам, что вполне полагаются на эти программы, особенно активно пользуясь ими при вы полнении приемочного тестирования. Однако сами мы еще не пользова лись подобными средствами, а потому воздерживаемся от каких-либо одобрительных или критических замечаний в их адрес. Вот несколько воп росов, которые следует обдумать, планируя автоматизацию процесса тести рования. • Временные затраты. На создание автоматизированных тестов ухо дит очень много времени. Как утверждается в Microsoft Test User's Guide (Microsoft, 1992, с. 15), автоматизация тестирования требует самого тщательного планирования и организации и часто наиболь ших временных затрат. Предположим, что на проектирование, создание и документирова ние автоматизированного теста уходит вдесятеро больше времени, чем необходимо на подготовку и выполнение его вручную. Это оз начает, что временные затраты на автоматизацию окупаются толь ко после десятого или одиннадцатого прогона теста. Все последующие его прогоны не стоят почти ничего, если только тест не придется модифицировать. Получается, что тесты, которые вы полняются всего несколько раз, автоматизировать вообще не стоит. • Задержки в тестировании. Если отложить серьезное тестирование до тех пор, пока не будет подготовлена целая "батарея" тестов, можно поставить под угрозу весь проект. Программистам необходи ма быстрая ответная реакция группы тестирования, состояние про екта всегда должно быть известно. Поэтому с самого начала проекта стоит подумать о расширении группы тестирования, чтобы в то время, когда одна часть персонала занята разработкой автоматизи- Глава 11: Инструментальные средства тестировщика 2 7 5 рованных тестов, другая могла выполнять тестирование вручную в нормальном рабочем режиме. • Инерция. Вложения в разработку автоматизированных тестов доста точно велики. Если программист изменит пользовательский интер фейс программы или формат ее входных или выходных данных, огромную часть тестов придется просто-напросто выбросить. Осо бенно остро эта проблема стоит в тех случаях, когда тесты разраба тываются на самых ранних стадиях проекта, поскольку вероятность последующих значительных изменений в программе при этом силь но увеличивается. Как правило, изменения вносятся в проект отнюдь не по чьей-либо прихоти. Руководитель проекта соглашается на них потому, что они значительно усовершенствуют или улучшают программу, делают ее более последовательной и простой в использовании. Формат файлов данных обычно меняется ради достижения совместимости или уст ранения ошибок. А раз так, вы должны приветствовать всякое по добное усовершенствование. Однако если у вас имеется достаточно большое количество необходимых тестов, основанных на старом варианте интерфейса или формате файлов, для группы тестирования изменения могут быть очень нежелательны, и вместо оказания со действия в улучшении качества продукта вы можете невольно стать его противником. • Риск пропущенных ошибок. Microsoft (1990, с. 7.33) предупреждает, что автоматизированные тесты должны планироваться и организовы ваться очень тщательно, поскольку за их выполнением тестировщик не наблюдает так внимательно, как при выполнении тестов вручную. О том же говорит и наш собственный опыт. Нам случалось видеть, как тестировщики, проводившие автоматизированное тестирование, про пускали очень серьезные и совершенно очевидные ошибки. Майерс (Myers, 1979) также писал о результатах исследований, показывающих, что тестировщики недостаточно внимательно анализируют результа ты автоматизированных тестов и пропускают очень много ошибок. Продумывая тесты, особое внимание уделите тому, чтобы их резуль таты были как можно короче и представлены в простой и наглядной форме. Никто не будет вычитывать километры распечаток, и уж во всяком случае никто не сможет сделать это достаточно внимательно. Скорее всего, вам понадобится небольшой журнал тестирования, в котором в одной строке фиксировался бы каждый выполненный тест. Кроме того, в нем должны фиксироваться все сбои программы, и записи о сбоях должны дополняться копиями неверных данных. 2 7 6 Часть II: Приемы и технологии тестирования Еще одним полезным приемом может быть выдаваемый тестировоч- ной программой звуковой сигнал о неудачном тесте и сообщение, которое остается на экране до тех пор, пока тестировщик с ним не ознакомится. Так вы гарантируете, что будете знать о каждой выяв ленной ошибке. Однако тут необходима аккуратность, звуковые сигналы не должны выдаваться в тех случаях, когда в сравниваемых файлах различаются незначащие детали, например, даты. Иначе из организующего фактора такая технология работы превратится в бедствие. • Частичная автоматизация. Вовсе необязательно полностью авто матизировать весь процесс тестирования. Часть тестов может быть автоматизирована, в то время как другие лучше по-прежнему про водить вручную. Для начала стоит автоматизировать наиболее под ходящие для этого тесты, а также те, которые наверняка будут проводиться десятки раз. Потенциальными кандидатами для автома тизации являются также те тесты, которые требуют большого объе ма клавиатурного ввода, сложны и утомительны для ручного выполнения. Что касается отдельных тестов, то их автоматизация также может быть частичной. Например, можно записать и проигрывать клавиа турный ввод, а результаты анализировать визуально. Это сэкономит некоторое время на вводе информации и позволит избежать возни со сравниваемыми выходными файлами. Автоматизация приемочного тестирования Некоторые руководители большую часть средств, выделенных на авто матизацию тестирования, тратят на создание приемочных тестов. Их сооб ражения таковы. • Именно эти тесты выполняются чаще всего. Если обновленная версия программного продукта передается тестировщикам каждую неделю, да плюс еще периодически появляются внеочередные вер сии с исправлениями наиболее существенных ошибок, за все время разработки комплекс приемочных тестов может быть выполнен пятьдесят и даже сто раз. • К каждой функциональной области программы относится сравни тельно небольшое количество тестов. Приемочные тесты быстро прогоняют все основные части программы, ни на чем не останавли ваясь подробно. Поэтому, когда одна из составляющих программы меняется, соответствующую группу тестов легко можно переделать. • Утомительность процедуры приемочного тестирования ведет к ошибкам. Тестировщику приходится выполнять одни и те же тесты Глава 11: Инструментальные средства тестировщика 277 множество раз, поэтому неудивительно, что он пропускает некото рые тесты или выполняет их невнимательно. Программа же всегда выполняет тесты одинаково — ведь ей не бывает скучно и она ни когда не устает. Стандарты Ваша компания может подписать контракт, по которому программа должна удовлетворять определенным стандартам. Подтверждение соответ ствия этим стандартам входит в задачи группы тестирования. Программы, выполняющие такую проверку, часто доморощенные и трудно поддаются модификации. Утилиты, анализирующие программу на соответствие стан дартам, могут сообщать о следующих ее недостатках. • Проблемы с переносимостью. Программа может использовать рас ширения языка, несовместимые с другим компилятором, непосред ственно записывать или считывать данные из определенных областей памяти или ориентироваться на новые возможности уст ройств ввода/вывода, которые имеются далеко не во всех системах. • Рекурсия. Программа называется рекурсивной, если в ней имеется подпрограмма, вызывающая сама себя. Этот прием запрещается некоторыми стандартами. • Степень вложенности. Главная программа может вызывать под программу, та — еще одну подпрограмму, та — еще одну и т.д. В конце концов вызывается подпрограмма, выполняющая нужную работу. Сколько же вызовов для этого потребуется? Приемлемо ли такое количество? Аналогичным образом вложенными могут быть циклы и условные операторы. Если язык программирования позво ляет определять пользовательские типы данных, насколько допусти мо определять переменную, относящуюся к типу, определенному посредством другого типа, определенного посредством другого типа и т.д. Как глубоко придется копать, чтобы выяснить, о каких же в самом деле данных идет речь? • Константы в коде. Предположим, что программа проверяет, дей ствительно ли введенное значение меньше 6. Одни программисты определят именованную константу, например MAX_VAL, назначат ей значение 6 и будут использовать это имя в коде для сравнения. Другие же просто будут сравнивать введенное значение с числом 6, поместив его прямо в код. Этот второй способ часто является зап рещенным. Недостаток его в том, что при изменении максимального значения с 6 на какое-нибудь другое число придется искать и заме- 2 7 8 Часть II: Приемы и технологии тестирования нять шестерки по всему программному коду — ведь сравнение мо жет выполняться и не в одном месте. Если же определить констан ту и вынести ее в самое начало программного кода, то найти и изменить ее значение будет гораздо проще. • Размер модуля. Сколько строк программного кода может содержать процедура или функция? Нет ли в программе чересчур длинных подпрограмм или, наоборот, слишком коротких, так что программ ный код становится настолько фрагментированным, что теряется его логика? А как насчет количества подпрограмм в одном файле? • Комментарии. По стандарту на каждые три строки программного кода может требоваться по одному комментарию. Стандартом может определяться формат комментариев, их длина, расположение в фай ле и другие характеристики. • Соглашения об именах. Стандарт может определять принципы наи менования переменных, подпрограмм и файлов. • Форматирование. В стандарте могут быть описаны такие вещи, как отступы, расположение операторов, отмечающих начало и конец блоков кода, или максимальное количество символов в строке. • Запрещенные конструкции. Может быть запрещено применение операторов GOTO, операторов прерывания потока типа EXIT или вызов подпрограмм, адреса которых хранятся в переменных-указа телях. Могут быть запрещены определенные способы протоколиро вания ошибок или определенные команды ввода/вывода. • Запрещенные действия. Примером таких действий может быть зап рет перехода по команде GOTO назад по программному коду, в то время как аналогичные переходы вперед могут разрешаться. (При чина такого запрета в том, что переходы назад ведут к большему количеству ошибок, чем переходы вперед.) • Псевдонимы. Если два различных имени относятся к одной и той же переменной, т.е. указывают на одно и то же место памяти, они считаются псевдонимами. Такие вещи могут не допускаться стандар том. • Преобразование типов данных. Одни и те же данные могут по-раз ному интерпретироваться в различных местах программы. Напри- мер, можно объявить массив целых чисел и передать его подпрограмме, которая будет работать с ним как со строкой. Это может быть запрещено стандартом. Если программа проверки соответствия стандартам может выявлять все эти проблемы, возможно, она может обнаруживать и некоторые типы ошибок. Такие программы часто выявляют следующее. Глава 11: Инструментальные средства тестировщика 2 7 9 • Неверный синтаксис. Компилятор такие ошибки обнаруживает, а вот в интерпретируемой программе они проявляются только во вре мя выполнения соответствующего фрагмента кода. • Смешанные вычисления. Если А=5 и В=2, тогда возможно, что А/В=2,5, если обе переменные являются числами с плавающей за пятой, и А/В=2, если числа целые. Эти правила определяются язы ком программирования, но главное, что при этом программист не всегда получает то, чего ожидает. Иногда он может просто не заме тить, что смешал в одном выражении различные типы данных. • Переменные, определенные в программном коде, но никогда не ис пользуемые. Программа может установить, что А=5, но никогда больше не использовать переменную А. Скорее всего, программист предназначал ее для какой-то цели, а потом о ней просто забыл. Хотя такое объявление само по себе совершено безобидно, в даль нейшем оно может смутить того, кому придется эту программу под держивать. • Переменные, которые используются до их инициализации. Если программа присваивает переменной В значение А и только после этого присваивает переменной А начальное значение, то что будет в переменной В? • Чтение файла до его открытия или после закрытия. Выявив подоб ные команды, можно предотвратить сбои при обращении к устрой ствам ввода/вывода. • Код, который никогда не выполняется. В программе могут быть процедуры, которые никогда не вызываются, или фрагменты кода, которым никогда не передается управление (например, условие вет вления не выполняется ни при каких обстоятельствах). • Бесконечные циклы. Условие выхода из цикла может либо просто никогда не выполняться, либо зависеть от данных, что является потенциальной возможностью зацикливания программы. Приведенный список можно было бы продолжить. Суть его в том, что программу можно анализировать на предмет стиля, формата, соответствия разнообразным правилам и наличия определенных типов ошибок. Часто последнее слово в таком анализе остается за программистом, который один только и может точно сказать, является ли определенный фрагмент кода ошибочным или просто представляет собой несколько необычную КОНСТ РУКЦИЮ. Однако если речь идет о соответствии определенным стандартам, это должна гарантировать группа тестирования. Необходимо очень тщательно проанализировать вопрос применимости проекту конкретных стандартов. Сама по себе эта идея неплохая, но на практике чревата целым рядом сложностей. 2 8 0 Часть II: Приемы и технологии тестирования • Программисты могут пытаться некорректными способами улучшить свои показатели или препятствовать попыткам анализировать их работу. (Керней (Kearney, 1986), Вейнберг (Weinberg, 1971)). • Чем больше внимания будет уделяться соответствию стандартам, тем меньше времени, людей и сил будет оставаться для реального тести рования программного продукта — анализа его производительности, удобства, эффективности и исправления ошибок. Иногда качество продукта определяют как степень его соответствия определенным стандартам. Однако, на наш взгляд, все, что не связано непосредственно с его функциональностью, с восприятием продукта пользователем, является скорее тормозом в работе по его совершенствова нию. Гласе (Glass, 1992, с. 92) утверждает, и мы полностью с этим согласны, что если оценивать качество продукта в терминах соответствия стандартам, сформированным критериям могут удовлетворять явно плохие продукты. Поэтому, на наш взгляд, лучше избегать включать в договор требование со ответствия стандартам. Разумеется, можно и пользоваться средствами ана лиза на соответствие стандартам, и писать собственные такие средства, но стандарты должны вырабатываться самими разработчиками, а не навязы ваться извне. Тестирование "стеклянного ящика" При тестировании "стеклянного ящика" тестировщик анализирует про граммный код. При противоположном подходе — тестировании "черного ящика", которому главным образом посвящена эта книга, тестировщик в код не заглядывает, работая с программой исключительно извне. Однако иногда программист снабжает тестировщика средствами, позво ляющими при тестировании "черного ящика" в некоторой степени опи раться и на программный код. Примерами таких средств могут быть следующие виды отладочного кода: • Для отслеживания путей выполнения программы. • Для проверки определенных фактов. • Для отслеживания использования памяти. Если вы захотите прибегнуть к подобным технологиям работы, обрати тесь к такому автору, как Гласе (Glass, 1992). Отслеживание путей выполнения программы Протестировать каждый путь выполнения программы нереально. А вот выполнение хотя бы по одному разу каждой строки программного кода — задача вполне реальная и к тому же совершенно необходимая. (О ней Глава 11: Инструментальные средства тестировщика 2 8 1 подробно рассказывалось в главе 3.) Самый очевидный способ ее выпол нения — просто сесть перед компьютером с листингом и попытаться вы явить все возможные ветви кода. Однако есть и лучший подход, требующий участия программиста, — добавить в программу специальный отладочный код. Когда программа достигает заданной точки, она печатает определенное сообщение. Все со общения отличаются. Как правило, их нумеруют, так что всегда можно сказать, в какой точке программного кода они были выданы. Программист размещает отладочные сообщения во всех ключевых точках программы. По завершении цикла тестирования он анализирует распечатки или файл жур нала и выясняет, попало ли туда каждое из сообщений хотя бы по одному разу. Если что-нибудь пропущено, значит, соответствующая область про граммы не была протестирована и можно подсказать тестировщикам, как ее достичь. Такая технология очень облегчает работу тестировщика, ведь ему боль ше не нужно анализировать программный код. Да так в конечном счете и надежнее. Отслеживать сообщения по ходу тестирования также ни к чему, они могут и вовсе не выводиться на экран, а просто записываться в файл журнала. Существуют специальные программные средства мониторинга охвата (coverage monitors), вставляющие в код подобные отладочные команды. Эти команды называются зондами (probes). Такие программные средства могут не только начинять программу зондами, но и собирать статистику их про хождения, формируя итоговые данные. Получив от средства мониторинга охвата сведения о том, какие ветви программы не были пройдены, можно подготовить и провести дополнительные тесты. Хотя средства мониторинга охвата предназначены для тестирования "стеклянного ящика", ими можно пользоваться и в обычной работе. В этом случае вы просто узнаете, насколько полно ваши тесты охватывают про граммный код. Средств мониторинга охвата на рынке имеется предостаточно. Стоит составить их список, чтобы иметь что предложить программистам. Одна ко вполне возможно, что вы услышите от них целый ряд разумных возра жений. Их основания могут быть такими. • |