tehnologia (1018792), страница 46
Текст из файла (страница 46)
Если попробовать вложитьнезависимые проверки, то, возможно, число тестов можно еще сократить.9.5. Тестирования модулей и комплексное тестированиеКак уже упоминалось в § 2.3 при тестировании модулей программного обеспечения,так же, как при проектировании и кодировании возможно применение как восходящего, таки нисходящего подходов.Восходящее тестирование. Восходящий подход предполагает, что каждый модультестируют отдельно на соответствие имеющимся спецификациям на него, затем собираютоттестированные модули в модули более высокой степени интеграции и тестируют их. Приэтом проверяют межмодульные интерфейсы, используемые для подключения модулей болеенизкого уровня иерархии. И так далее, пока не будет собран весь программный продукт (рис.9.3).Такой подход обеспечивает полностью автономное тестирование, для которогопросто генерировать тестовые последовательности, которые передаются в модуль напрямую.Однако он имеет и существенные недостатки.
Во-первых, при восходящем тестировании также, как при восходящем проектировании, серьезные ошибки в спецификациях, алгоритмах иинтерфейсе могут быть обнаружены только на завершающей стадии работы над проектом.Во-вторых, для того, чтобы тестировать модули нижних уровней, необходимо разработатьспециальные тестирующие программы, которые обеспечивают вызов интересующих насмодулей с необходимыми параметрами. Причем эти тестирующие программы также могутсодержать ошибки.Нисходящее тестирование.
Нисходящее тестирование органически связано снисходящим проектированием и разработкой: как только проекти-279рование какого-либо модуля заканчивается, его кодируют и передают на тестирование.В этом случае автономно тестируется только основной модуль. При его тестированиивсе вызываемые им модули заменяют модулями, которые в той или иной степени имитируютповедение вызываемых модулей (рис. 9.4). Такие модули принято называть «заглушками».
Вотличие от тестирующих программ заглушки очень просты, например, они могут простофиксировать, что им передано управление. Часто заглушки просто возвращают какие-либофиксированные данные.Как только тестирование основного модуля завершено, к нему подключают модули,непосредственно им вызываемые, и необходимые заглушки, а затем проводят их совместноетестирование. Далее последовательно подключают следующие модули, пока не будетсобрана вся система. Желательная последовательность сборки обсуждалась в § 2.3, хотя напрактике ее редко удается соблюдать.Основной недостаток нисходящего тестирования - отсутствие автономноготестирования модулей. Поскольку модуль получает данные не непосредственно, а черезвызывающий модуль, то гораздо сложнее обеспечить его «достаточное» тестирование.Основным достоинством данного метода является ранняя проверка основныхрешений и качественное многократное тестирование сопряжения модулей в контекстепрограммного обеспечения.
При нисходящем тестировании есть возможность согласования сзаказчиком внешнего вида (интерфейса) программного обеспечения.280Комбинированный подход. Чаще всего применяют комбинированный подход:модули верхних уровней тестируют нисходящим способом, а модули нижних уровней восходящим. Этот способ позволяет с одной стороны начать с тестирования интерфейса, сдругой - обеспечивает качественное автономное тестирование модулей низших уровней.Тестирование программного обеспечения специалистами. Согласно основнымпринципам нежелательно тестирование программного обеспечения его автором, поэтому этуработу, как правило, выполняют другие программисты, желательно - специалисты в этойобласти.Задачей специалиста по тестированию является обнаружение максимальногоколичества несоответствий тестируемого модуля и спецификаций на него.
Для выполненияэтой задачи специалист по тестированию формирует тесты, используя как структурный, таки функциональный подходы, обеспечивая всестороннее тестирование.Каждое отклонение от спецификации обязательно документируют, заполняяспециальный протокол (рис. 9.5). Наиболее интересными полями протокола являются типпроблемы и ее описание.281В поле тип проблемы указывают один из вариантов:1 - ошибка кодирования - программа ведет себя не так, как следует из общепринятыхпредставлений, например, 2 + 2 = 5 - на что разработчик может выдать резолюцию«соответствует проекту»;2822 - ошибка проектирования - программа ведет себя в соответствии с проектом, носпециалист по тестированию не согласен с данным решением в проекте - на что разработчикможет отреагировать, наложив резолюцию «не согласен с предложением»;3 - предложение - предложение по улучшению проекта;4 - расхождение с документацией - обнаружено, что программа ведет себя не так, какуказано в документации;5 - взаимодействие с аппаратурой - обнаружены проблемы при использованииопределенного вида аппаратуры;6 - вопрос - программа делает что-то не совсем понятное.
Описание проблемы должнобыть коротким и понятным, например:«Система не запоминает настройки принтера, выполняемые в окне настройки».Если программист исправляет ошибку, то тестирование повторяют сначала, так какпри исправлении ошибки программист может внести в программу новые ошибки. Такоетестирование называют «регрессионным».Комплексное тестирование.
Особенностью комплексного тестирования является то,что структурное тестирование для него практически не применимо. В основном на даннойстадии используют тесты, построенные по методам эквивалентных классов, граничныхусловий и предположении об ошибках.Критерии завершения тестирования и отладки. Одним из самых сложных являетсявопрос о том, когда следует завершать тестирование, поскольку невозможно гарантировать,что в разрабатываемом программном обеспечении не осталось ошибок.Предложено очень много критериев. Все критерии можно разделить на три группы:• основанные на методологиях проектирования тестов - определенноеколичество тестов, полученных по методам анализа причинно-следственныхсвязей, анализа граничных значений и предположения об ошибке, перестаютвыявлять ошибки;• основанные на оценке возможного количества ошибок - возможное количествоошибок оценивают экспертно, или по специальным методикам [21], а затемзавершают тестирование при нахождении примерно 93-95% ошибок;• основанные на исследовании результатов тестирования - строят графикзависимости количества обнаруженных ошибок от времени тестирования, еслион напоминает график, представленный на рис.
9.6, то тестирование можнозавершать.Часто тестирование завершают потому, что закончилось время, отведенное навыполнение данного этапа. В этом случае тестирование сворачивают, обходясьминимальным вариантом. Минимальное тестирование [31] предполагает:283•••тестирование граничных значений;тщательную проверку руководства;тестированиеминимальныхконфигураций технических средств;• тестированиевозможностиредактирования команд и повторенияих в любой последовательности;• тестированиеустойчивостикошибкам пользователя.Частьошибокприэтомостаютсянеисправленными «отложенными» до выпускаследующей версии.9.6. Оценочное тестированиеПосле завершения комплексного тестирования приступают к оценочномутестированию, целью которого является тестирование программы на соответствие основнымтребованиям.
Эта стадия тестирования особенно важна для программных продуктов,предназначенных для продажи на рынке.Оценочное тестирование, которое также называют «тестированием системы в целом»,включает следующие виды:• тестирование удобства использования - последовательная проверкасоответствия программного продукта и документации на него основнымположениям технического задания;• тестирование на предельных объемах - проверка работоспособностипрограммы на максимально больших объемах данных, например, объемахтекстов, таблиц, большом количестве файлов и т.
п.;• тестирование на предельных нагрузках - проверка выполнения программы навозможность обработки большого объема данных, поступивших в течениекороткого времени;• тестирование удобства эксплуатации - анализ психологических факторов,возникающих при работе с программным обеспечением; это тестированиепозволяет определить, удобен ли интерфейс, не раздражает ли цветовое илизвуковое сопровождение и т. п.;• тестирование защиты - проверка защиты, например, от несанкционированногодоступа к информации;• тестирование производительности - определение пропускной способности призаданной конфигурации и нагрузке;• тестирование требований к памяти - определение реальных потребностей воперативной и внешней памяти;284•тестирование конфигурации оборудования - проверка работоспособностипрограммного обеспечения на разном оборудовании;• тестирование совместимости - проверка преемственности версий: в техслучаях, если очередная версия системы меняет форматы данных, она должнапредусматривать специальные конвекторы, обеспечивающие возможностьработы с файлами, созданными предыдущей версией системы;• тестирование удобства установки - проверка удобства установки;• тестирование надежности - проверка надежности с использованиемсоответствующих математических моделей [66];• тестирование восстановления - проверка восстановления программногообеспечения, например системы, включающей базу данных, после сбоевоборудования и программы;• тестирование удобства обслуживания - проверка средств обслуживания,включенных в программное обеспечение;• тестирование документации - тщательная проверка документации, например,если документация содержит примеры, то их все необходимо попробовать;• тестирование процедуры - проверка ручных процессов, предполагаемых всистеме.Естественно, целью всех этих проверок является поиск несоответствий техническомузаданию.
Считают, что только после выполнения всех видов тестирования программныйпродукт может быть представлен пользователю или к реализации. Однако на практикеобычно выполняют не все виды оценочного тестирования, так как это очень дорого итрудоемко. Как правило, для каждого типа программного обеспечения выполняют те видытестирования, которые являются для него наиболее важными. Так базы данных обязательнотестируют на предельных объемах, а системы реального времени - на предельных нагрузках.Контрольные вопросы и задания1. Что является целью тестирования программ? Почему?2.