Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
2 6 7 середины, применяя это, без сомнения, эффективное средство толь ко там, где оно действительно необходимо. • Диагностические программы. Существует ряд утилит, анализирую щих аппаратное и программное обеспечение системы. Они помогут вам выяснить, какие в вашем распоряжении имеются устройства, все ли с ними в порядке и как они работают. В частности, с их помо щью можно найти и исключить из использования поврежденные участки жесткого диска или определить, работает ли видеоплата в режиме, позволяющем осуществлять видеозапись работы. Можно также сохранять информацию о состоянии оперативной памяти в момент сбоя — в определенных случаях эта информация может быть очень полезна программисту. Он скажет вам, какой утилитой лучше всего для этого воспользоваться, и предоставит ее в случае необхо димости. • Таймер. Иногда необходимо определить длительность какой-либо операции, возможно в десятых или сотых секунды. Для этого пре красно подойдет программный таймер. Отдельные устройства вроде наручных часов менее удобны, и с их помощью нельзя работать с очень маленькими временными интервалами. Чаще всего измерения времени необходимы при тестировании тайм-аутов, условий гонок, а также задержек реакции системы на действия пользователя и вы полнения относительно длительной обработки данных. • Система отслеживания проблем. Это настолько важная тема, что она обсуждалась в отдельной главе. • Программист. Если вам не удается воспроизвести ошибку, вы не знаете, каковы граничные условия процесса или не понимаете, как тестировать какую-либо функцию программы, обращайтесь к про граммисту. Ложная гордость в этом вопросе совершенно неуместна, вы не можете всегда и на все знать точные ответы. Однако всегда критически анализируйте слова программиста, поскольку сознатель но или ненамеренно он может ввести вас в заблуждение. Впрочем, это крайний случай. В основном же программист может сэкономить вам часы и дни работы, либо сразу определив источник проблемы, либо написав специальный диагностический код, либо просто разъяснив некоторые особенности программы и посоветовав, как или какими средствами ее можно эффективнее протестировать. Автоматизация приемочного и регрессионного тестирования Как правило, каждая новая версия программы, получаемая тестировщи- кзш, проходит стандартное приемочное тестирование. Его цель — убедить- 2 6 8 Часть II: Приемы и технологии тестирования ся, что в программе не появилось серьезных проблем и все ее базовые функции успешно работают. Обычно на такое тестирование уходит не более одного дня. В соответствующий набор тестов включаются только базовые и быстровыполнимые примеры, проверка всех возможных гранич ных условий сюда не входит. В некоторых коллективах практикуется рас пространение набора приемочных тестов не только среди тестировщиков, но и среди остального заинтересованного персонала. В частности, при необходимости руководитель проекта может лично убедиться, что состоя ние очередной версии программы удовлетворяет базовым приемочным тре бованиям. • В некоторых компаниях программа, не прошедшая приемочного тестирования, вообще не принимается тестировщиками и возвраща ется обратно программистам на доработку. Особенно часто так бывает на более поздних стадиях разработки, когда программа уже не раз проходила приемочное тестирование, и вдруг очередная вер сия его не прошла. Обычно это означает, что в процессе корректи ровки исходного кода или его компиляции программистами была допущена грубая ошибка, которая, однако, легко может быть ис правлена. • Существует и иная практика, когда приемочное тестирование при меняется для выявления самых очевидных ошибок очередной вер сии программы. После выполнения этих тестов становиться очевидно, на какие части программы следует обратить особое вни мание, а какие, наоборот, оставить пока в покое, если группа тес тирования еще не готова взяться за них со всей серьезностью. • Приемочное тестирование — процедура довольно утомительная и скучная и к тому же занимает много времени. Поэтому независимо от того, насколько велика разрабатываемая программа, для него на значается относительно небольшое количество тестов. В противном случае оно слишком дорого обходится. Регрессионное тестирование выполняется после каждого изменения программы. Если программа прошла определенную группу тестов в про шлый раз, то, скорее всего, пройдет и в этот. Однако провести их все равно придется — это неотъемлемая часть общего процесса тестирования. Итак, и приемочные, и регрессионные наборы тестов выполняются по многу раз — они так и просятся, чтобы их автоматизировали. Это вполне возможно. Задача состоит в том, чтобы объяснить компьютеру, как выполнить тест, собрать результаты, сравнить их с заранее известными правильными ре зультатами и сообщить вам, чем все кончилось. В этой главе главным образом рассматривается автоматизация регрессионного тестирования, но все сказан ное в равной мере справедливо и для приемочного. Глава 11: Инструментальные средства тестировщика 2 6 9 Несколько ранее, в главе 11, рассказывалось об автоматизации тестиро вания печати. Ряд приводившихся в ней соображений можно распростра нить и на автоматизацию процесса тестирования в целом. Откуда берутся регрессионные тесты Когда программист исправляет ошибку, существует определенная веро ятность, что он исправит не то, что нужно, или допустит новую ошибку, нарушит что-то, что уже работало. Поэтому после каждого такого исправ ления (или группы исправлений), необходимо, во-первых, проверить, ре шена ли та проблема, из-за которой вносились исправления, а во-вторых, проверить целостность всей программы. • Тесты для граничных условий и другие заранее запланированные тесты. Среди всех тестов, перечисленных в вашем рабочем плане, необходимо выбрать те, которые с наибольшей вероятностью выя вят возможные ошибки. • Тесты, уже однажды выявившие ошибку. То, что однажды почини ли, нередко ломается снова. Так происходит потому, что в том ме сте, где в программу внесено исправление, ее код часто выглядит непонятным, непоследовательным или неловким. А если исправле ния в программу вносил один программист, а продолжает ее дора ботку другой, то существует большая вероятность того, что исправленный фрагмент будет неверно понят и повторно исправлен. • Ошибки, выявленные пользователями. Ошибки, о которых сообща ют пользователи, группа технической поддержки и другой персонал, не входящий в группу тестирования, указывают на дыры в плане работ вашей группы. В некоторых группах тестирования принято добавлять в тестовые планы регрессионные тесты для каждой такой ошибки. • Наборы тестовых данных, сгенерированных методами случайного подбора. Об использовании генератора случайных чисел уже расска зывалось в главе 7 при обсуждении тестирования функциональной эквивалентности. Хотя случайные данные не заменят граничных тестов, они послужат полезным дополнением, позволяющим проте стировать программу с более разнообразной входной информацией. Снабжение программы входными данными В чем состоит сложность составления набора регрессионных тестов, так это в огромном количестве тестов — потенциальных кандидатов на звание регрессионных. Все их выполнить просто невозможно. Поэтому в главе 7 подробно описывались принципы отбора тестов, позволяющие составить тносительно небольшую, но при этом эффективную группу тестировочных заданий. Теперь же мы рассмотрим способы автоматизации регрессионного тестирования (полной или хотя бы частичной), и, если процесс тестирова- 2 7 0 Часть II: Приемы и технологии тестирования ния удастся успешно автоматизировать, вам не придется отсеивать такое большое количество тестов просто из-за нехватки времени. Существует несколько способов того, как тестовые данные могут попа дать в программу. • Файлы данных. Программа может быть способна считывать тесто вые данные из файлов. При этом ее пользовательский интерфейс, разумеется, не тестируется, но зато основательно проверяется ее базовая функциональность. Заранее подготовленные файлы приго дятся при тестировании загрузки информации программой, ее экс порта и импорта. Разумно составленные файлы позволяют протестировать программу на границах ее возможностей (максимум записей, огромные числа и т.п.). В каждой программе это может быть нечто свое, так что потребуется довольно много времени на подготовку тестовой информации. Иногда тестовые данные стоит хранить в базе данных. Программа, используемая для управления этой базой данных, должна обладать способностью сохранения информации в различных форматах. Если формат входных данных тестируемой программы изменится, с помо щью СУБД можно будет сформировать новые файлы. Впрочем, даже если формат входных данных и не является для вашей программы первоочередным вопросом, СУБД предоставляет целый ряд других полезных возможностей для работы с данными, как, например, удобные средства редактирования и возможность снабжения инфор мации необходимыми комментариями. • Пакетные файлы. Некоторые программы, такие как компиляторы и компоновщики, а также многие программы для математических расчетов, могут считывать с диска абсолютно всю необходимую информацию, включая и команды. Существуют и такие программы, которые предназначены исключительно для пакетного выполнения, они, по определению, читают все входные данные из файлов. Если вам посчастливилось иметь дело именно с такой программой, под готовки тестовых файлов и анализа результатов будет достаточно для тестирования практически всех ее аспектов. • Перенаправление ввода. Если программа ожидает, что команды бу дут введены с клавиатуры, это еще не означает, что ею невозмож но управлять через файл. Просто следует воспользоваться возможностью операционной системы перенаправлять ввод и вывод информации (если, конечно, такая возможность имеется). Суть та кого перенаправления состоит в том, что программе кажется, будто данные поступают из стандартного входного устройства (обычно это клавиатура), в то время как на самом деле они считываются опера ционной системой из указанного вами файла. Всеми деталями это го механизма управляет операционная система. Глава 11: Инструментальные средства тестировщика 271 Перенаправление ввода подходит не для всех случаев, поскольку его возможности ограничены. Как, например, организовать задержку в 3,2 секунды между двумя нажатиями клавиш? • Ввод через последовательный порт. Еще один трюк, применяемый тестировщиками, как и предыдущий, состоит в подмене входного устройства таким образом, чтобы программа этого не заметила. Од нако на этот раз данные поступают не из файла, а из последователь ного порта. Существует специальное программное обеспечение, позволяющее одному компьютеру управлять работой другого, свя занного с ним через сеть, модем или нуль-модем. В частности, это имеющиеся на рынке персональных компьютеров программы эму ляции терминала. Соединив два компьютера либо с помощью кабеля, подключенного к их последовательным портам, либо через телефонную линию по средством модемов, можно, сидя за одним из них, управлять вторым так, как будто вы работаете с его клавиатурой и мышью, и видеть на экране отображаемую им информацию. Но главное, что действия пользователя можно определить заранее, так чтобы их эмулировало программное обеспечение. При этом его возможности гораздо шире, чем при вводе данных операционной системой из файла. В частно сти, можно определить любые необходимые временные задержки и реакцию пользователя на действия тестируемой программы. На рынке имеется целый ряд мощных и дорогостоящих систем для тестирования персональных компьютеров по описанной технологии, и их возможности постоянно расширяются. • Перехват и воспроизведение клавиатурного ввода. Если воспользо ваться программой, перехватывающей клавиатурный ввод, можно один раз выполнить и "записать" с ее помощью тест, а затем вос производить его сколько угодно раз. Такая программа может запи сывать не только все нажатия клавиш, но и все манипуляции пользователя с мышью. Подобная технология не только облегчает работу, освобождая тести- ровщика от необходимости выполнять утомительные и однообраз ные действия и позволяя ему полностью сосредоточиться на программе, но и гарантирует, что тест всегда будет выполняться абсолютно одинаково. Однако у нее есть и определенные издержки. Записав тест, необходимо его тут же проиграть, чтобы убедиться, что он записан правильно. Кроме того, определенных усилий требует организация и документирование записанных тестировочных фай лов. В общей сложности на запись, проверку, сохранение и докумен тирование теста уходит как минимум в 3, а то и в 10 раз больше времени, чем на его выполнение вручную. 2 7 2 Часть II: Приемы и технологии тестирования К тому же автоматизированный тест, представляющий собой запись действий пользователя, не сработает, если в программу будут внесе ны даже самые незначительные изменения, связанные с последова тельностью этих действий. Тест придется выполнять и записывать заново. Простейшим примером может быть реорганизация меню программы. Покупая программу перехвата и воспроизведения ввода, убедитесь, что она записывает не только действия пользователя, но и времен ные интервалы между ними. Кроме того, проверьте, правильно ли воспроизводятся манипуляции с мышью при различных разрешениях экрана. Хорошо бы убедиться и в ее надежности. Рынок таких про грамм относительно невелик, и они не всегда тщательно тестируют ся. Имейте в виду, что покупаемая вами утилита относится к разряду резидентных, а это означает потенциальную возможность проблем не только в ее собственной работе, но и во взаимоотношениях с остальным запущенным программным обеспечением. Запись вывода тестируемой программы Автоматизировать ввод данных для тестируемой программы обычно гораздо проще, чем записать ее выходную информацию в подходящей для анализа форме. Выбор у вас следующий. • Файлы выходных данных. Идеальным случаем является программа, сама сохраняющая свои данные в файлах, причем в формате, под ходящем для тестирования. • Перенаправление вывода в файл. В дисковый файл можно, напри мер, перенаправить вывод, предназначенный для принтера. Если это возможно, то перенаправление вывода извне предпочтительнее ис пользования соответствующей функции самой программы, посколь ку гарантирует, что в файл попадет в точности та же информация, что и на принтер. Если программа предназначена для работы в текстовом режиме, то в файл можно перенаправить и то, что она выводит на экран. • Вывод через последовательный порт. Если имеется возможность удаленного управления компьютером либо с терминала, либо со второго компьютера посредством специального программного обес печения, этот второй компьютер может записывать принимаемые выходные данные в файл для последующего анализа. • Перехват экрана. Существует множество программ, позволяющих сохранить изображение текущего окна и всего экрана. Как будет рассказано чуть позже, мы очень широко пользуемся такими про граммами. Глава 11: Инструментальные средства тестировщика 2 7 3 • Перехват вывода программы с помощью специальных тестирован ных утилит. Совершенно очевидно, что, если программа разрабо тана специально для тестирования, ее возможности гораздо шире, чем у утилит общего назначения. Хорошая программа позволяет сохранять указанные области экрана, например поля данных, кото рые меняются от теста к тесту. Оценка выходной информации Записав выходную информацию программы, тестировочная система должна оценить ее правильность. Как это сделать? Существует несколько традиционных подходов. • Если существует эталонная программа, выполняющая то же самое, что и тестируемая, можно сравнить их вывод. • Написать параллельную программу, генерирующую точно такие же результаты, и сравнивать их вывод. На практике проще создать несколько десятков небольших параллельных программ — по одной на каждую тестируемую функцию. • Сформировать библиотеку правильных выходных данных. При этом для каждого нового набора тестов придется создавать и новые эта лоны выходных данных. Это довольно долгий и трудоемкий про цесс, особенно если данные эталонных файлов придется вводить вручную. И здесь неизбежны издержки по выявлению множества ошибок и опечаток. Однако основной объем работы придется на самое начало, когда необходимо будет сформировать основную мас су данных, дальше будет легче. При наличии времени тесты можно будет автоматизировать постепенно, один за другим. • Перехват вывода программы. Сохраняйте результаты каждого тес та, какими бы они ни были. Результат теста записывается в отдель ный файл, анализируется сразу или позднее и помечается как хороший или плохой. После того как тесты будут выполнены повторно, их результаты можно снова записать в файлы и сравнить с предыдущими. Эта работа прекрасно поддается автоматизации. Несовпадение нового файла со старым, помеченным как хороший, означает либо появле ние новой ошибки, либо изменение спецификации. Если очередной результат теста оказывается хорошим, все предыдущие плохие ре зультаты можно удалить. Как и предыдущая, эта стратегия носит инкрементальный характер. Библиотека результатов тестов постепенно растет, пополняясь все новыми данными, и в конечном счете в ней оказывается по файлу на каждый тест, причем в этих файлах только положительные данные. 2 7 4 Часть II: Приемы и технологии тестирования В организации корректного сравнения выходных данных, особенно сравнения копий экрана, существует целый ряд сложностей. Как, напри мер, обучить программу сравнения игнорировать различающиеся даты? Как быть с изменяющимися заголовками окон? Что, если данные выводятся |