Lecture 06 11/24/2011 1:04:00 PM Стадии процесса
реклама
Lecture 06 1/23/2016 7:19:00 AM Стадии процесса тестирования (Планирование, Контроль, Test analysis and design…), Test levels (Unit testing, Integration testing) Тестирование – этап разработки ПО. Фазы тестирования. Ранее мы выявили, что Тестирование - это процесс, целью которого является выявление качества продукта, т.е. соответствие продукта заявленным требованиям. Наиболее заметным процессом тестирования является исполнение тестов – выполнение тестовых сценариев. Помимо этого необходимо проанализировать тесты, подготовить необходимый материал для тестов и определиться с критерием окончания тестов. Очень сложно проводить тесты без решения того как, когда и что тестить. Стадии процесса тестирования Для этого в процесс тестирования включены следующие стадии: 1. Test planning and control 2. Test analysis and design 3. Test implementation and execution 4. Evaluating exit criteria and reporting 5. Test closure activities Несмотря на то, что эти стадии идут в строгой последовательности она не всегда строго соблюдается. Test planning and control Test analysis and design Test implementation and execution Evaluating exit criteria and reporting Test closure activities 1. Test planning and control Планирование (planning) - это определение того, что должно быть протестировано и того, как этого достичь. Определяется какие именно задачи нужно выполнить и кто будет за это отвечать. Помимо этих целей во время планирования определяется completion criteria. Основные цели планирования: Определение областей и целей тестирования Определение подхода тестирования (объектов тестирования, рисков) Планирование анализа результатов Планирование времени исполнения заданий 1 Lecture 06 1/23/2016 7:19:00 AM Определние выходного критерия Контроль (control) – это определение того, что должно быть сделано, если исполняемые задачи не совпадают с планом. Контроль осуществляется на протяжении всего тестирования – сравнивается прогресс тестирования в с планом. Цели контроля: Анализ результатов Сравнение текущего прогресса выполнения тестов с запланированым Исправление ошибок, если тестирование пошло не по плану 2. Test analysis and design Стадия Test analysis and design – cвязующая стадия между планированием тестов и исполнением тестов. На этой стадии происходит детальное определение того, что должно быть протестировано и выбор наименьшего списка тест кейсов, которое удовлетворяет заданым целям. Во внимание принимаются части определённые в planning (даты, люди, области тестирования). На этой стадии до начала самого тестирования выявляются expected results. - изучение требований к продукту, архитектуры, интерфейса анализ тестируемых компонентов, спецификаций создание тестов определение степени готовности реквайрементов 3. Test implementation and execution Эта стадия подразумивает исполнение тестов. Также подразумивается проверка готовности среды тестирования к работе. Тестирование – самая видная стадия процесса, но она невозможна без других стадий процесса тестирования. Например, первыми должны выполняться самые важные тесты. Как определить, какой тест самый важный без стадии планирования? Во время исполнения тестов производится сравнение между полученым и ожидаемым результатом. В случае несовпадения необходимо произвести исследование поведения и вероятно залогировать баг. Надо отметить, что не всегда при наблюдении какого-то неожиданого поведения необходимо что-то исправлять или чинить. Test implementation and execution обычно включает следующие части: Создание кейсов, подготовка данных необходимых для тестирования, подготовка автоматических инструментов Проверка среды тестирования на готовность Исполнение тестов (ручное или автоматическое тестирование) Сохранение результатов тестирования (статусов, версий компонентов и т.п.) Сравнение полученых и ожидаемых результатов 4. Evaluating exit criteria and reporting Выходной критерий определяется на стадии планирования, до начала исполнения тестов. По окончанию исполнения тестов менеджер проверяет, если результаты соответсвуют критериям. Например, если критерием было покрытие в 85% от общего а в результате было покрыто 75%, то есть два выхода – продолжить тестирование или изменить выходной критерий. Таким образом выявляются следующие цели этой стадии: Определение соответствия выходному критерию Определение необходимости прогона дополнительных тестов Создание репортов по результатам тестирования 2 Lecture 06 1/23/2016 7:19:00 AM 5. Test closure activities На этой стадии тестирование закончивается. На этой стадии необходимо убедиться, что все баги в нужном статусе, написаны репорты, все тесты завершены. Выявляются замечания для будущих тестов, которые могли бы улучшить процесс. -------------------------------------Environment - программное и аппаратное обеспечение, в котором будут проводиться тесты. Сюда попадает не только только то программное обеспечение, которое будет тестироваться, но и дополнительное неоходимое для проведения тестов ПО – операционная система, базы данных и т.д. • Development Environment – Среда разработки. Используется программистами для создания и развития (upgrade) системы/программы • Test Environment – Среда, в которой будут проводиться тесты. Помимо самого продукта могут быть установленне различные тестовые программы такие как симуляторы, ПО для автоматического выполнения тестовых скриптов и др. Production environment – реальная среда, в которой программа или система функционирует в стабильном варианте и доступна конечному пользователю. Используются реальные данные и т.п. Уровни тестирования (test levels) Test levels Вспомним лекцию 3, в которой рассказывалось о моделях жизненых циклов программ – V-model, Waterfall Напомню, что процесс верификации активен в течение практически всего жизненного цикла системы и работает параллельно с процессом разработки. Разработка системы, как правило, идет на различных уровнях – вначале разрабатывается концепция системы, системные требования, затем архитектура системы, ее разбиение на модули, затем разрабатываются отдельные модули. Последовательность этих уровней зависит от типа жизненного цикла, но их состав практически всегда одинаков. Процесс верификации также разбивается на отдельные уровни: системное тестирование, в ходе которого тестируется система в целом; интеграционное тестирование, в ходе которого тестируются группы взаимодействующих модулей и компонент системы; модульное тестирование, в ходе которого тестируются отдельные компоненты; 3 Lecture 06 1/23/2016 7:19:00 AM Модульное тестирование (Unit testing) Каждая сложная программная система состоит из отдельных частей – модулей, выполняющих ту или иную функцию в составе системы. Для того, чтобы удостовериться в корректной работе системы в целом, необходимо вначале протестировать каждый модуль системы по отдельности. В случае возникновения проблем при тестировании системы в целом это позволяет проще выявить модули, вызвавшие проблему и устранить соответствующие дефекты в них. Такое тестирование модулей по отдельности получило называние модульного тестирования (unit testing). Для каждого модуля, подвергаемого тестированию, разрабатывается тестовое окружение, включающее в себя драйвер и заглушки, готовятся тест-требования и тест-планы, описывающие конкретные тестовые примеры. Основная цель модульного тестирования – удостовериться в соответствии требованиям каждого отдельного модуля системы перед тем, как будет произведена его интеграция в состав системы. Unit testing обычно проводиться программистами, которые написали код. Зачастую баги выявленные и починеные во время unit testing нигде не отмечаются (bugtracker) Интеграционное тестирование (Integration testing) Результатом тестирования и верификации отдельных модулей, составляющих программную систему, является заключение о том, что эти модули являются внутренне непротиворечивыми и соответствуют требованиям. Однако отдельные модули редко функционируют сами по себе, поэтому следующая задача после тестирования отдельных модулей – тестирование корректности взаимодействия нескольких модулей, объединенных в единое целое. Такое тестирование называют интеграционным. Его цель – удостовериться в корректности совместной работы компонент системы. Интеграционное тестирование называют еще тестированием архитектуры системы. С одной стороны это связано с тем, что, интеграционные тесты включают в себя проверки всех возможных видов взаимодействий между программными модулями и элементами, которые определяются в архитектуре системы – таким образом, интеграционные тесты проверяют полноту взаимодействий в тестируемой реализации системы. С другой стороны, результаты выполнения интеграционных тестов – один из основных источников информации для процесса улучшения и уточнения архитектуры системы, межмодульных и межкомпонентных интерфейсов. Т.е. с этой точки зрения интеграционные тесты проверяют корректность взаимодействия компонентов системы. Примером проверки корректности взаимодействия могут служить два модуля, один из которых накапливает сообщения протокола о принятых файлах, а второй выводит этот протокол на экран. В функциональных требованиях на систему записано, что сообщения должны выводиться в обратном хронологическом порядке. Однако, модуль хранения сообщений сохраняет их в прямом порядке, а модуль вывода – использует стек для вывода в обратном порядке. Модульные тесты, затрагивающие каждый модуль по отдельности, не дадут здесь никакого эффекта – вполне реальна обратная ситуация, при которой сообщения хранятся в обратном порядке, а выводятся с использованием очереди. Обнаружить потенциальную проблему можно только проверив взаимодействие модулей при помощи интеграционных тестов. Ключевым моментом здесь является, что в обратном хронологическом порядке сообщения выводит система в целом, т.е. проверив модуль вывода и обнаружив, что он выводит сообщения в прямом порядке, мы не сможем гарантировать того, что мы обнаружили дефект. В результате проведения интеграционного тестирования и устранения всех выявленных дефектов получается согласованная и целостная архитектура программной системы, т.е. можно считать, что интеграционное тестирование – это тестирование архитектуры и низкоуровневых функциональных требований. Интеграционное тестирование, как правило, представляет собой итеративный процесс, при котором проверяется функциональной все более и более увеличивающейся в размерах совокупности модулей. 4 1/23/2016 7:19:00 AM Lecture 06 Структурная классификация методов интеграционного тестирования Как правило, интеграционное тестирование проводится уже по завершении модульного тестирования для всех интегрируемых модулей. Однако это далеко не всегда так. Существует несколько методов проведения интеграционного тестирования: • восходящее тестирование; • монолитное тестирование; • нисходящее тестирование. Все эти методики основываются на знаниях об архитектуре системы, которая часто изображается в виде структурных диаграмм или диаграмм вызовов функций [10]. Каждый узел на такой диаграмме представляет собой программный модуль, а стрелки между ними представляют собой зависимость по вызовам между модулями. Основное различие методик интеграционного тестирования заключается в направлении движения по этим диаграммам и в широте охвата за одну итерацию. Восходящее тестирование (Buttom-up integration) 1 2 4 3 5 6 7 При использовании этого метода подразумевается, что сначала тестируются все программные модули, входящие в состав системы и только затем они объединяются для интеграционного тестирования. При таком подходе значительно упрощается локализация ошибок: если модули протестированы по отдельности, то ошибка при их совместной работе есть проблема их интерфейса. При таком подходе у область поиска проблем у тестировщика достаточно узка, а поэтому гораздо выше вероятность правильно идентифицировать дефект. Однако, у восходящего метода тестирования есть существенный недостаток – необходимость в разработке драйвера и заглушек для модульного тестирования перед проведением интеграционного тестирования и необходимость в разработке драйвера и заглушек при интеграционном тестировании части модулей системы. С одной стороны драйверы и заглушки – мощный инструмент тестирования, с другой – их разработка требует значительных ресурсов, особенно при изменении состава интегрируемых модулей. Т.е. может потребоваться один набор драйверов для модульного тестирования каждого модуля, отдельный драйвер и заглушки для тестирования интеграции двух модулей из набора, отдельный – для тестирования интеграции трех модулей и т.п. В первую очередь это связано с тем, что при интеграции модулей отпадает необходимость в некоторых заглушках, а также требуется изменение драйвера, поддерживающее новые тесты, затрагивающие несколько модулей. Монолитное тестирование (Big-bang integration) предполагает, что отдельные компоненты системы серьезного тестирования не проходили. Основное преимущество данного метода – отсутствие 5 1/23/2016 7:19:00 AM Lecture 06 необходимости в разработке тестового окружения, драйверов и заглушек. После разработки всех модулей выполняется их интеграция, после чего система проверяется вся в целом, как она есть. Этот подход не следует путать с системным тестированием, которому посвящена следующая тема. Несмотря на то, что при монолитном тестировании проверятся работа всей системы в целом, основная задача этого тестирования – определить проблемы взаимодействия отдельных модулей системы. Задачей же системного тестирования является оценка качественных и количественных характеристик системы с точки зрения их приемлемости для конечного пользователя. Монолитное тестирование имеет ряд серьезных недостатков: • Очень трудно выявить источник ошибки (идентифицировать ошибочный фрагмент кода). В большинстве модулей следует предполагать наличие ошибки. Проблема выглядит как определение того, какая из ошибок во всех вовлечённых модулях привела к полученному результату. При этом возможно наложение эффектов ошибок. Кроме того, ошибка в одном модуле может блокировать тестирование другого. • Трудно организовать исправление ошибок. В результате тестирования тестировщиком фиксируется найденная проблема. Дефект в системе, вызвавший эту проблему будет устранять разработчик. Поскольку, как правило, тестируемые модули написаны разными людьми, возникает проблема – кто из них является ответственным за поиск устранение дефекта? При такой «коллективной безответственности» скорость устранения дефектов может резко упасть. Процесс тестирования плохо автоматизируется. Преимущество (нет дополнительного программного обеспечения, сопровождающего процесс тестирования) оборачивается недостатком. Каждое внесённое изменение требует повторения всех тестов. Нисходящее тестирование (Top-down integration) 1 2 4 3 5 6 7 предполагает, что процесс интеграционного тестирования движется следом за разработкой. Сначала при нисходящем подходе тестируют только самый верхний управляющий уровень системы, без модулей более низкого уровня. Затем постепенно с более высокоуровневыми модулями интегрируются более низкоуровневые. В результате применения такого метода отпадает необходимость в драйверах (роль драйвера выполняет более высокоуровневый модуль системы), однако сохраняется нужда в заглушках b У разных специалистов в области тестирования разные мнения по поводу того, какой из методов более удобен при реальном тестировании программных систем. Йордан доказывает, что нисходящее тестирование наиболее приемлемо в реальных ситуациях [27], а Майерс полагает, что каждый из подходов имеет свои достоинства и недостатки, но в целом восходящий метод лучше. 6 Lecture 06 1/23/2016 7:19:00 AM Постепенная интеграция модулей при нисходящем методе тестирования 7
