Файл: Отладка и тестирование программ: основные подходы и ограничения (Этапы, цели и задачи тестирования программного обеспечения).pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользоваться инструментами автоматизированного тестирования где это целесообразно.

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

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

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

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

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

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

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

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

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

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

Приемочное

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

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

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

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

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

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

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

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

Бизнес

Технология

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

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

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

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

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

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