Файл: Отладка и тестирование программ: ограничения и основные подходы.pdf

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

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

- определение стратегии автоматизации тогда, если запланировано применение автоматизации определенного типа тестирования. Стоит учесть, что автоматизация требует обязательного проведения независимых параллельных работ, тщательно спланированных и исполненных только тогда, когда это не становится причиной падения эффективности.

Определение объемов тестовых работ.

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

В том случае, если имеет место быть перебор в тестирование, или же тестовое покрытие настолько обширно, что является избыточным, то для того, чтобы отладить ПП нужно будет время, а это лишний риск просрочить сдачу проекта. В том случае, если проведенного тестирования будет недостаточно, если говорить точнее, то тестовое покрытие будет слишком мало, то растет риск пропустить какой-либо дефект, устранение которого влетит в копеечку, особенно на том этапе, когда ПП уже сдан в эксплуатацию. Чтобы найти ту самую точку баланса меж этими крайностями, нужно иметь опыт, для того, чтобы измерить все параметры и подобрать наиболее оптимальный метод тестирования.

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

- сначала провести тестирование самых приоритетных требований;

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

- протестировать в полной мере возможности функционала;

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

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

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

Выявление и определение подхода тестирования.

2 глава описание понятия стратегии тестирования напрямую касается конкретного подхода к тестированию. Конструкция и схема подхода к тестированию должна начинаться с проведения исследований в отношении всех стадий разработки, чтобы отобрать тесты для проведения обоих видов тестирования, каждый из которых следует использовать на соответствующей стадии. Кроме того, совсем неважно, какая из моделей жизненного цикла разработки тут используется, будь она: каскадной, спиралевидной, или с интегративной версией, для того, чтобы отобрать наиболее эффективные тесты для исследования этапы любой из моделей.

Как пример рассмотрим каскадную модель и определим, какой из видов тестирования можно использовать в отношении этой модели:

- этап формулировки требований;

- этап системного проектирования;

-этапы тестирования ПП, кода, модуля и полный комплекс тестирования;

- тестирование системы;

- приемочное тестирование;

- регрессивное тестирование;

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

Определение критериев тестирования и точки контроля качества.

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

- критерии входа, они описывают действия до того, как начнется тестирование;

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

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

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

Иные критерии, которые определяются стандартами или же процессами. В том случае, если ПП должен отвечать определенным стандартам или в том случае, когда эти стандарты и требования ставит сама компания, необходимо принять в расчет дополнительные критерии.

Определение стратегии амортизации.

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

Любая задача, которая многократно повторяется или выполняется, автоматически попадает в список кандидатов на автоматизацию. Как правило, на то, чтобы автоматизировать задачу нужно больше времени, чем на то, чтобы ее исполнить, именно по этой причине для каждой задачи, которую потенциально можно автоматизировать, логично и нужно провести тщательное анализирование потенциального дохода от проведения автоматизации. При проведении анализа вероятной выгоды, нельзя забывать о том, что для процесса автоматизации в большей мере свойственен автономный цикл жизнедеятельности [6,c.264]

Чтобы автоматизация была эффективной, требуется особым образом подготовить сотрудников, провести разработку, верификацию и отладку, ровно, как и для всех проектов разработки ПП. В том случае, если автоматизация выполнена плохо и беспланово, то это значит напрасную трату ресурсов, и даже может нарушить запланированный график проведения работ, в том случае, если время будет потрачено на отладку автоматизации, а на тестирование его почти не останется.

Цели тестирования:

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

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

- провести тестирование максимально оперативно.

Задачи тестирования:

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

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

- проверить работу пользовательских интерфейсов

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

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

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

В процессе проектирования автоматизированных тестов пользоваться стандартами разработки так, чтобы сформировать неоднократно применяемые и сопровождаемые скрипты.[3,c.400]

Уровень тестирования определяет, на каком уровне системы производятся тесты. Ехлаков Ю.П. выделяет следующие (рис. 1):[1,c.148]

Модульное тестирование

Проверка отдельных элементов программы

Интеграционное тестирование

Проверка связей и способов взаимодействия

элементов друг с другом

Системное тестирование

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

Приемочное

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

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

Рисунок 1 – Уровни тестирования

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

В компании Google создали собственную классификацию тестов, которая схожа с классической (таблица 1) и дает более подробное представление об особенностях организации тестирования на каждом из уровней.[19]

Таблица 1 - Характеристики уровней тестов

Также интересен подход к классификации уровней (категорий) тестирования у Поппендик М. и Пппендик Т. Согласно данной классификации тестирование проводится с точки зрения технологии и с точки зрения бизнеса.[8,c.256]

Такое деление демонстрирует две цели тестирования ПО. С одной стороны оно облегчает работу разработчиков программы, с другой – испытывает в различных режимах весь программный продукт (рис.2).[17]

Бизнес

Технология

Рисунок 2 – Типы тестирования

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

Главная цель проведения комплексного тестирования - проверить насколько корректно и четко модули ПП согласованы друг с другом. Если тестирование комплексное, то можно использовать технологию обработки как сверху вниз, так и наоборот и тут каждый модуль интегрируется с последующим модулем, который выше или ниже уровнем, до тех пор, пока дерево ПП не будет полностью сформировано.

Данная технология тестирования ориентирована на то, чтобы проверить те параметры, которые передаются меж 2 компонентами и на проверку глобальных параметров и если приложение объектное и ориентированное, то каждого класса верхнего уровня. Каждая процедура комплексного тестирования в свою очередь состоит из нескольких скриптов верхнего уровня, которые отвечают за моделирование выполнения определенного задания с использованием модульных тестов нижнего уровня, у которых есть все необходимые параметры, чтобы проверить интерфейс. Для того, чтобы принять решение относительно отчетности о проблемах модульного тестирования, проводят инкрементное объединение модулей и тестируют их одновременно на базе управляющей логики. С учетом того, что модули так часто состоят из других модулей, частично комплексное тестирование можно провести во время модульного. В том случае, если скрипт модульного тестирования был сформирован при помощи инструментов автоматизированного тестирования, допускается их объединение и добавление новых скриптов для того, чтобы протестировать модульные связи.

Само по себе комплексное тестирование исполняется и должно быть уточнено в качестве отчета о проблеме, задокументировано и находится под пристальным надзором. Отчет о проблеме может быть причислен к определенной категории в зависимости от уровня серьезности по шкале от 1 до 4. После того, как эти отчеты обработаны, тестировщик может провести регрессивное тестирование, чтобы проверить, удалось ли полностью устранить проблемы.

Восходящее тестирование является отличным методом локализовать ошибки. В том случае, если на тестировании единственного модуля обнаружили ошибку, то вполне понятно, что она заключается именно в этом модуле и для того, чтобы найти источник ошибки нет нужно анализировать весь системный код. В том случае если ошибка выявлена при совместной работе 2 модулей, которые уже были протестированы, то выходит, что проблема в интерфейсе. Еще одно важное преимущество такого типа тестирования этот тот факт, что программист, который его проводит, сконцентрирован на особо узком участке, то есть на конкретном модуле. Именно благодаря этому, тестирование более дотошное и тщательное, тут шанс выявить ошибки становится гораздо выше.

Главный минус такого типа тестировать - необходимость написания особого кода-оболочки, который и вызывает тестируемый модуль. В том случае, если он вызывает не тот модуль, требуется написание заглушки. Заглушка представляет собой имитацию вызываемой функции, которая возвращает данные и ничего более. [16]

Очевидно, что написание лишних элементов тормозить работу, кроме того, для конечного продукта они никакой ценности не представляют. Стоит отметить, что использовать их можно многократно.

Хороший набор оболочек и заглушек тоже является эффективным инструментом тестирования.

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

Главное достоинство стратегии то, что можно не писать дополнительный код. По этой причине довольно часть предпочтение отдается именно этому методу, ведь лучше провести разработку 1 большого набора теста и им осуществлять проверку системы. Однако это в корне неверно и ниже описано по какой причине:

- источник ошибок найти очень сложно. Именно это является главной проблемой, по той причине, что проверенных основательно модулей нет и почти во всех модулях имеются ошибки. Отсюда следует, что вопрос о том, в каком модуле есть ошибка, перетекает в вопрос о том, какая из всех ошибок стала причиной такого результата. И в том случае, когда имеет место быть ошибки в нескольких модулях, то локализовать и исправить все намного сложнее. Помимо этого ошибка в каком-то модуле может заблокировать тестирование другого модуля. А как проверить функционал, если модуль, который его вызывает, сам не функционирует? Если не будет написанной программы оболочки, то нужно будет дождаться отладки модуля - это очень долго.