Файл: ОСНОВЫ АЛГОРИТМИЗАЦИИ И ПРОГРАММИРОВАНИЯ (Проверка ПО комплексный метод).pdf

1.1 Принципы тестирование и отладка программного обеспечения

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

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

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

И последний пункт, который необходимо объяснить из этого понятия – это понятие «дефекта» или «бага». Проще говоря, программная ошибка – не что иное как изъян в разработке программного обеспечения, который приводит к неверному конечному результату, несоответствии ожидаемого результата и физически полученного результата. Дефект может появиться как на стадии создания кода, так и на стадиях формирования требований и проектирования, так же причина может скрываться в некорректной конфигурации или данных. Дефектом может является нечто другое, например, результат какого-то действия не соответствует ожиданиям заказчика и что может быть не определенно в спецификации программного продукта.

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

1.2 Этапы тестирования программного обеспечения

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

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

Существуют следующие подходы к формулированию стратегии тестирования:

Определить объемы тестовых работ путем анализа документов, содержащих требования к программному продукту (технические условия), чтобы выяснить, что нужно тестировать. Рассмотреть виды тестирования, которые не следуют непосредственно из документов с требованиями, такие как тестирование возможности установки и наращивания возможностей программного продукта, удобство и простота обслуживания продукта, а также способности к взаимодействию с другими видами аппаратных средств из среды заказчика.

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

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

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

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

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

Тестировать в первую очередь требования с наивысшим приоритетом.

Тестировать новые функциональные возможности и программный код, который изменялся с целью исправления или совершенствования старых функциональных средств

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

Тестировать те участки, в которых наиболее вероятно присутствие проблем

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

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

- Стадия формулирования требований

- Стадия системного проектирования

- Стадии тестирования проектов программ, программных кодов, модульного тестирования и комплексных испытаний

- Системные испытания

- Приемочные испытания

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

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

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

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

- Критерий входа. Описывает, что нужно сделать перед началом тестирования.

- Критерий выхода. Описывает то, что вы считается необходимым для завершения испытаний.

- Критерий приостановки/возобновления. Описывает, что произойдет, если по причине из-за дефектов продолжение тестирования окажется невозможным.

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

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

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

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

1.3 Цели и задачи проверки ПО

Цель проверки ПО:

- Увеличить качество работы ПО в разного рода обстоятельствах.

- Увеличить процент соответствия с предъявляемыми требованиями.

- Полноценная проверка ПО в минимально отведённые сроки.

Задачи проверки ПО:

- Система должна отвечать на отклики клиентской и серверной стороны в определённый промежуток времени, установленным предварительно разработчиками.

- Система должна правильно выполнять порядок действий даже в наиболее критических последовательностях.

- Работа интерфейсов пользователя должна производиться корректно.

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

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

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

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

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

1.4 Проверка ПО комплексный метод

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

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

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

Каждая процедура проверки ПО проводится и уточняются необходимым образом, составленные после отчёты о проблемах строго отслеживаются через документацию. По уровню серьёзности проблемы принято классифицировать их по степени тяжести от 1-4, где 4 уровень наименее критичен. Программист производит проверку путём регрессионного тестирования, после того как обработал отчёты, на момент устранения проблемы.

1.5 Проверка ПО восходящим и нисходящим методом

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