Преподаватель который помогает студентам и школьникам в учёбе.

Отладка и тестирование программ: основные подходы и ограничения (Разработка проекта тестирования программы «Помощник администратора»)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объект исследования: тестирование и отладка программного обеспечения.

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

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

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

В настоящее время существует множество трудов, посвященных методам повышения качества ПО, включая процесс тестирования. В данной работе при исследовании вопросов программной инженерии и тестирования были использованы учебные пособия российских авторов – Липаева В.В., Перемитиной Т.О., Котлярова В.П., Андона Ф.И. и др., а также литературные источники зарубежных авторов – Канера С., классика тестирования – Майерса Г., Макгрегора Д., Соммервила И.

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ИЗУЧЕНИЯ ТЕСТИРОВАНИЯ И ОТЛАДКИ И ОТЛАДКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1 История тестирования программного обеспечения

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

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

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования программного обеспечения. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. [5,c.608]

Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в программах, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки программного обеспечения.

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

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

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

В начале 1990-х годов в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки программного обеспечения. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х годов с развитием Интернета и разработкой большого количества веб-приложений особую популярность стало получать «гибкое тестирование» (по аналогии с гибкими методологиями программирования).

В 2000-х появилось ещё более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий». Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки программного обеспечения для достижения необходимого уровня качества, производительности, доступности. [10,c.320]

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

Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий две различные цели:

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

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

Тестированием программного обеспечения (software testing) является процесс анализа либо эксплуатации программного обеспечения для выявления дефектов.

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

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

По данному определению процесс тестирования представляет собой эксплуатацию и анализ программы. Тестирование напрямую взаимосвязано с анализированием результативности разработки ПО, которое довольно часто именуют стратегическим тестированием. Тестирование такого рода- это проверка программного кода, и осуществление сквозного контроля, а также проверка программы не запуская ее, то есть проверка за столом, на англ. desk checks). Тестовая деятельность, которой предусмотрен процесс эксплуатации ПО, называется динамическим тестированием, на англ. dynamic testing). Оба вида тестирования дополняют друг друга, что дает возможность провести качественное тестирование и выявить все ошибки [9,c.288-299]

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

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

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

1.3 Этапы, цели и задачи тестирования программного обеспечения

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

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

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

Есть разные подходы по формулировке стратегии тестирования:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приемочное

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

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

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

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

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

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

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

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

Название теста Критерий	Малые тесты (аналог модульного тестирования)	Средние тесты (аналог интеграционного тестирования)	Большие тесты (аналог системного тестирования)
Цели	Делает ли этот код то, что должен делать	Взаимодействуют ли соседние функции друг с другом так, как должны	Работает ли продукт так, как нужно пользователю, и дает ли желаемый результат
Размер кода	Малые объемы кода	Средние объемы	Большие объемы
Автоматизация	Практические всегда	Обычно	Автоматизация и ручной способ
Проверяемых функций	Одна	Две и более	Более трех
Ограничения по времени	После 1 минуты	После 5 минут	После 15 минут
Среда	Среда с заглушками	Несколько модулей с привлечением внешних источников	Модули для сквозного выполнения задач
Недостатки	Не проверяют интеграцию между модулями. Иногда сложно применить подставные объекты, они отличаются от реальности	Медленнее, чем малые	Сложно найти причину дефекта. Длительная подготовка данных. Трудно проработать граничные значения
Достоинства	Повышают чистоту кода. Быстрота. Надежность во всех средах. БОльшая детализация. Упрощение локализации ошибок	Быстрое выполнение. Легкий запуск. Учитывают поведение внешних подсистем	Учитывают поведение внешних систем. Могут быть недетерминированными

Бизнес

Тесты «историй» (приемочные)

Поддержка процесса программирования

Соответствие запросам заказчика

Тесты простоты использования

Испытание продукта

Проводят пользователи в реальных условиях.

Диагностические тесты

Изучают поведение системы при нагрузках, непредвиденных входных данных

Блочные тесты (модульные)

Соответствие кода замыслам разработчиков.

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

Проверка нефункциональных свойств

Технология

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очевидно, что в процессе разработки происходит ежедневное изменение ПП и нужно снова ее тестировать и так до бесконечности. В свою очередь наличие оболочек и заглушек дает возможность систематизации этого муторного и однообразного труда[18].

Имеется еще один принцип, касающийся организации тестирования, при котором ПП, как и при восходящем тестировании, не полностью подлежит тестировки, а тестирование производится по составляющим. Только лишь направление движения иногда меняется, изначально тестируется верхний уровень модульной иерархии, и затем, тестировщик поэтапно опускается все ниже. Подобная технологи получила название нисходящей, на англ. top-down.

Обе такие технологии именую инкрементальными.

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

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

ГЛАВА 2. СТРАТЕГИЯ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Метод Сандвича

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

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

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

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

Модифицированный метод сандвича.

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

2.2 Метод «белого ящика»

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

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

- предоставление гарантии на то, что все независимые пути в модуле проверены минимум единожды;

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

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

- Исследуют структуры внутренних данных с целью проверки их достоверности.[2,c.312]

Тестирование при помощи белого ящика включает в себя стратегию модульного тестирования, при котором тестирование ведется на модульном или функциональном уровне и работы по тестированию направлены на исследование внутреннего устройства модуля. Такое тестирование именуется модульным прозрачного ящика, на англ. clear box, или же, прозрачным, на англ. Translucent. С учетом того, что те сотрудники, которые заняты тестирование, имеют полный доступ к коду, они могут наблюдать за работой программы внутри самой программы. Нередко такое тестирование называется структурным.

На данном этапе идет проверка управляющей логики, которая проявляется еще на модульном уровне. Использование тестовых драйверов нужно для того, чтобы все пути в данном модуле хотя бы 1 раз прошли проверку, а все решения логического порядка удалось рассмотреть при любых условиях, цикл был исполнен при применении верхней и нижней границы, а так же все структуры внутренних данных .были проконтролированы.[4,c.775]

Методы тестирования на основе стратегии белого ящика:

- ввод неправильного значения. В таком случае тестировщик провоцирует код возврата на показа ошибок, затем наблюдает за реакцией кода. Это отличная методика моделировании некоторых событий, таких как нехватка памяти или переполненный диск. Довольно распространенной является подмена функции, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате.

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

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

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

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

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

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

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

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

- Исследование покрытия. Когда избирается инструмент для того, чтобы исследовать покрытие, очень важно, чтобы тестировщики провели анализ типа покрытия, который нужен для данного приложения. Процесс исследования покрытия можно провести при помощи целого перечня технологий. Методик покрытия операторов чаще называют С1, то есть, покрытие узлов. Данные изменения открыто демонстрируют факт проверки каждого исполнения в отношении оператора или его отсутствие. Этот способ тестировании чаще используют в качестве программы протоколировании производительности

- Покрытие решений. Этот метод ориентирован ан то, чтобы в % соотношении определить весь спектр возможных последствий или исходов решений, которые уже подверглись проверке. Такой метод довольно части причисляют к покрытию ветвей и именуют С2. Для его осуществления нужно: чтобы каждая точка входа и выхода в программе была пройдена 1 или более раз, чтобы весь перечень вероятных условий был протестирован 1 или более раз, а так же обязательным является тестировании и использование всего спектра вероятных исходов.

- Покрытие условий, в чем-то схоже с покрытием решений и направлено на факт проведения проверки истинной или же ложной результативности любого логического выражения. Данная методика включает к себя тестирование, которое направлено на проверку выражения независимо друг от друга. Результаты таких проверок идентичны тем, которые удается получить с использованием методики покрытия решений, кроме того, что сама методика покрытия более чувствительна к логической составляющей ПП [1,c.148]

2.3 Метод «черного ящика»

Тестирование на базе стратегии черного ящика можно провести только тогда, когда есть установленные открытые пользовательские интерфейсы приложения (API). В том случае, если тестирование базе стратегии белого ящика занимается исследование внутренней работы ПП, то тестирование базе стратегии черного ящика проводит сравнительный анализ приложений согласно предъявляемым требования.

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

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

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

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

Эта разновидность тестирования ориентирована на выявление ошибок, которые относятся к категориям, изложенным ниже:

- пропущенный или ошибочный функционал

- неудобное использование

- методики тестирования на базе автоматизированных инструментов

- ошибки в структурных данных или в доступе к внешним БД

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

- ошибки при загрузке

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

- проблемы с безопасностью.[7,c.116]

Методики тестирования на базе стратегии черного ящика:

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

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

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

Анализ граничных значений. Такой анализ можно использовать на структурном и функциональном этапах тестирования. Границами определено 3 вида данных: правильные, граничные, неправильные. Процесс тестирования первых применяет те значения, которые находятся в рамках границ, или непосредственно на границы, а так же максимальное или минимальное значение.

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

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

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

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

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

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

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

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

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

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

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

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

2.4 Методы отладки программного обеспечения

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

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

- Метод пролога частично базируется на подробном анализе использования симптомов ошибок, которые могут указать неверные данные расчета или выскочить в виде окна с ошибкой. Если ПК просто завис, то часть экрана с ошибкой вычисляется при помощи изучения происхождения полученной результативности и движений потребителя. Те данные, что удалось получить таким образом, нужно организовать и осторожно изучить при просмотре адекватной части программного кода. По результативности этих гипотез совершенствуется движение о неточностях и погрешностях, каждая из которых в обязательном порядке проверяется 1 и более раз.

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

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

- Метод обратной трассировки. Для небольших программ наиболее оптимально и эффективно приложение методики обратной трассировки. Прежде всего стоит начать с точки вывода неверного результата. Для этого в работе есть гипотеза относительно значения основной переменной, что могло стать причинно получении доступных результатов. Затем, происхождение заной гипотезы, нужно сформировать предложение о значимости переменные в предыдущей точке. Процесс продолжается, все же не узнавайте причину Ошибки. [11]

ГЛАВА 3. Разработка проекта тестирования программы «Помощник администратора»

3.1 Описание программы

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

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

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

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

3.2 Выбор и обоснование методик тестирования

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

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

Для создания ПО приемлемого качества и для значительной экономии времени на создании пользовательского интерфейса было решено использовать библиотеку классов Microsoft Foundation Class.

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

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

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

1. Тестирование функций добавления, редактирования и сохранения информации об услугах

2. Тестирование пользовательского интерфейса

3. Тестирование скорости работы

Были выбраны следующие методы ООП тестирования:

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

Тестирование моделированием конечными автоматами было выбрано, т.к. данный метод зарекомендовал себя для проверки взаимодействия объектов ООП.

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

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

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

3.3 Планирование процесса тестирования

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

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

3.4 Разработка тестовых сценариев Use Case

При составлении тестовых сценариев были включены следующие пункты:

1. Состояние программы до начала теста (систему приводит в начальное состояние тестировщик)

2. Последовательность действий

3. Конечное состояние программы / ожидаемый результат

Далее приводятся тестовые сценарии для некоторых функций программы:

Use Case №1: добавление новой услуги

Состояние до начала теста

Последовательность

Действий

Ожидаемый

результат

Открыто главное меню

1. Нажатие кнопки «Добавить услугу»

2. Печатать текст в редакторе названия услуги

3. Нажать «Сохранить услугу»

Открыто главное меню, присутствует кнопка с названием добавленной услуги

Use Case №2: редактирование информации об услуге

Состояние до начала теста

Последовательность

Действий

Ожидаемый

результат

Открыто главное меню

1. Нажатие кнопки с названием услуги, которую нужно отредактировать

2. Печатать текст в редакторе преимуществ

3. Ввести в редакторе стоимости целочисленные значения

4. Нажать «Сохранить»

5. Нажать «Выйти в главное меню»

6. Нажать на кнопку с названием услуги, которую редактировали

Открыто окно информации об услуге с тем текстом и стоимостью услуги, которые были введены.

Use Case №3: просмотр информации об услуге

Состояние до начала теста

Последовательность

Действий

Ожидаемый

результат

Открыто главное меню

1. Нажатие кнопки с названием услуги, которую нужно просмотреть

Открыто окно с информацией об услуге.

Use Case №4: ввод неверной информации

Состояние до начала теста

Последовательность

Действий

Ожидаемый

результат

Открыто окно редактирования услуги

1. Ввести текстовую информацию о преимуществах услуги

2. В поле редактирования стоимости ввести не числа, а текст

3. Нажать «Сохранить»

На экране возникло окно с просьбой ввести корректную информацию о стоимости

Use Case №5: выход из программы во время редактирования услуги

Состояние до начала теста

Последовательность

Действий

Ожидаемый

результат

Открыто окно редактирования услуги

1. Ввести текстовую информацию о преимуществах услуги

2. В поле редактирования стоимости ввести целочисленное значение

3. Нажать кнопку «Закрыть»

На экране возникло окно с предупреждением о том, что информация не сохранена с выбором: Сохранить, Закрыть без сохранения, Отмена

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Ехлаков Ю.П. Введение в программную инженерию: учебное пособие. – Томск: Эль Контент, 2011. – 148 с.
Липаев В.В. Программная инженерия сложных заказных программных продуктов: Учебное пособие. – М.: МАКС Пресс, 2014. – 312 с.
Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, 2010. – 400 с.
Мейер Б. Почувствуй класс.—М.: Национальный Открытый Университет «ИНТУИТ»: БИНОМ. Лаборатория знаний, 2011. —775 с.
Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. – СПб.: Питер, 2012. – 608 с.
Панюкова Т.А. Документирование программного обеспечения: в помощь техническому писателю: Учебное пособие. – М.: Книжный дом «Либроком», 2012. – 264 с.
Перемитина Т.О. Тестирование программного обеспечения: учебное пособие. – Томск: факультет дистанционного обучения ТУСУРа, 2015. - 116 с.
Поппендик М., Поппендик Т. Бережливое производство программного обеспечения: от идеи до прибыли. - М. : ООО ‘‘И.Д. Вильямс’’, 2010. - 256 с.
Тюгашев А.А., Ильин И.А. Ермаков И.Е. Пути повышения надежности и качества программного обеспечения в космической отрасли // Управление большими системами: сборник трудов Выпуск 39 2012 С. 288-299
Уиттакер Дж., Арбон Дж., Каролло Дж. Как тестируют в Google. - СПб. : Питер, 2014. — 320 с.
Фролов Е.М., Солдатова М.А. Методика оценки качества прикладного программного обеспечения технического назначения // Известия Волгоградского государственного технического университета. - Выпуск № 8 (135) / том 11 / 2014
Testing the limits беседует с Бобом Биндером. // QATesting.ru. [Электронный ресурс]. URL: http://qatesting.ru/blog/interviews/2012/0916utest-bob-binder (дата обращения 16.05.2015)
Вудкок Д. Первые шаги к решению проблемы верификации программ. / Открытые системы. – http://www.osp.ru/os/2006/08/3584577/ (дата обращения 5.05.2015)
Гуров В.С., Мазин М.А., Шалыто А.А. UniMod – программный пакет для разработки объектно-ориентированных приложений на основе автоматного подхода [Электронный ресурс]. / Информационно-коммуникационные технологии в образовании. – URL: http://www.ict.edu.ru/vconf/index.php?a= vconf&c=getForm&r=thesisDesc&id_sec=143&id_vconf=25&id_thesis=5645&d=light (дата обращения 22.05.2015)
Дэвис Ч. Передовой опыт управления тестированием. // IBM.com [Электронный ресурс]. URL: http://www.ibm.com/developerworks/ru/library/1107_davis /index.html (дата обращения 19.05.2015)
Зизин М. Концепция создания системного и прикладного программного обеспечения задач математического моделирования. // AtomInfo.ru. [Электронный ресурс]. URL: http://www.atominfo.ru/news4/d0185.htm (дата обращения: 15.04.2015).
Карпов Ю. Синдром «146%»: некомпетентность или злой умысел? // Открытые системы [Электронный ресурс]. URL: http://www.osp.ru/os/2014/05/ 13041826/ (дата обращения 10.05.2015)
Количественное управление процессом тестирования. // Тестирование и качество ПО [Электронный ресурс]. URL: http://www.software-testing.ru/library/around-testing/processes/309-quantitative-process-management (дата обращения 18.05.2015)
Михайлов А. Тестирование объектно-ориентированных программных систем. // Объектно-ориентированный анализ и проектирование [Электронный ресурс]. URL: http://ooad.asf.ru/standarts/Library/OORP/List10.aspx (дата обращения 19.05.2015)
https://ru.wikipedia

Приложение 1

Методов тестирования в стратегиях белого и черного ящика

	Критерии	Описание
Стратегия белого ящика	Эквивалентное разбиение	Множество значений входных данных функции, образующих ее входное пространство, разбивается на набор под-множеств таким образом, что в каждое подмножество попадают значения, эквивалентные друг другу с точки зрения их использования в тестах для обнаружения ошибок.
	Анализ граничных значений	Дополняет эквивалентное разбиение. Данные выбираются на границах входной области, поскольку многие отказы происходят из-за дефектов, связанных с обработкой предельных значений входов. Ценное расширение этого метода – тестирование устойчивости, когда тестовые данные выбираются также и вне области для тестирования отказоустойчивости программы к недопустимым входам.
	Применение функциональных диаграмм	Функциональная диаграмма – формальный язык, на который транслируется спецификация, написанная на естественном языке. Помогает систематически выбирать высокорезультативные тесты. Позволяет обнаруживать неполноту и неоднозначность исходных спецификаций. Не обеспечивает построение всех полезных тестов, неадекватно исследует граничные значения
	Предположение об ошибке	Интуитивное перечисление в некотором списке возможных ошибок или ситуаций, в которых они могут появиться, написание на их основе тестов. Для эффективного применения необходим опыт в тестировании.
Стратегия чернго ящика	Покрытие операторов.	Выполнение каждого оператора хотя бы один раз. Слабый критерий, т.к. покрытие операторов недостаточное условие для успешного тестирования
	Покрытие решений.	Каждое решение должно иметь результат значения истина и ложь и при этом каждый оператор должен выполняться, по крайней мере, один раз. Необходимость модификации для программ, содержащих многозначные решения.
	Покрытие условий.	Все возможные результаты каждого условия в решении должны выполняться хотя бы один раз. Недостаточно чувствителен к ошибкам в логических выражениях
	Покрытие решений/условий.	Все возможные результаты каждого условия в решении, все результаты каждого решения выполнялись, по крайней мере, один раз и каждой точке входа передавалось управление, по крайне мере, один раз. Недостаточно чувствителен к ошибкам в логических выражениях
	Комбинаторное покрытие условий	Все возможные комбинации результатов условия в каждом решении и все точки входа должны выполняться, по крайней мере, один раз.

Приложение 2

Техническое задание на разработку ПО

1. Введение

1.1. Наименование программного продукта.

Полное наименование программы – «Помощник администратора». Краткое наименование – Помощник.

1.2. Область применения

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

2. Назначение разработки

Помощь администратору клиники в консультировании клиентов

3. Требования к программе

3.1. Требования к функциональным характеристикам

3.1.1. Состав выполняемых функций

Запуск	При запуске Помощника с помощью файла PomAdmin.exe программа должна обеспечить загрузку главного меню Помощника
Редактирование	Добавление новой услуги
	Редактирование информации о преимуществах услуги и стоимости
	Сохранение отредактированной информации
	Удаление услуги
Просмотр	Выбор интересующей услуги в главном меню и окне просмотра услуги N
	Вывод на экран окна с информацией об услуге
	Возврат в главное меню из любых других окон, кроме главного
Помощь	В любой момент работы программы при нажатии клавиши F1 либо при выборе пункта «Помощь» главного меню должна выводиться справочная информация по работе в программе
О программе	Вывод на экран окна с информацией о программе
Выход	В любой момент при нажатии кнопки «Закрыть» или при нажатии комбинации клавиш Alt+F4 программа закрывается

3.1.2. Схема внешнего вида программы

Главное меню

О программе

Закрыть

Помощь

Услуга 1

Услуга 2

Услуга 3

Услуга 4

Услуга 5

Услуга 6

Добавить услугу

Окно информации об услуге

О программе

Закрыть

Помощь

Услуга 1

Услуга 2

Услуга 3

Услуга 4

Услуга 5

Услуга 6

Редактировать

Преимущества услуги

Стоимость

Окно редактирования услуги

О программе

Закрыть

Помощь

Сохранить

текстовый редактор преимуществ

текстовый редактор стоимости

Выйти в главное меню

Удалить услугу

Окно добавления услуги

О программе

Закрыть

Помощь

Сохранить услугу

Текстовый редактор названия услуги

Выйти в главное меню

3.1.3. Временные характеристики

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

3.2. Требования к надежному функционированию

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

1) перезагрузки операционной системы

2) запуска исполняемого файла программы; повторного выполнения действий, потерянных до последнего сохранения информации.

Уровень надежности программы должен соответствовать технологии программирования, предусматривающей:

1) инспекцию исходного текста программы;

2) модульное тестирование;

3) интеграционное тестирование;

4) системное тестирование.

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

4. Язык программирования и инструменты разработки.

Программа разрабатывается в среде MS Visual Studio 2013, язык программирования – C++.

5. Стадии и этапы разработки

Разработка программы должна выполняться по следующим этапам:

1) разработка, согласование и утверждения технического проекта программы с пояснительной запиской – 5 недель;

2) разработка рабочего проекта программы с комплексным тестированием – 6 недель;

3) приемка-сдача с исправлением обнаруженных недостатков в программе и программной документацией – 2 недели;

6. Порядок контроля и приемки

6.1. Виды испытаний

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

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

Приложение 3

План тестирования программы «Помощник администратора»

Цель плана: организация и контроль процесса тестирования программы

Тестируемые опции:

Опция (функция)	Степень риска
Запуск программы	высокий
Добавление новой услуги	высокий
Редактирование информации о преимуществах услуги и стоимости	высокий
Сохранение отредактированной информации	высокий
Удаление услуги	низкий
Вывод на экран окна с информацией об услуге	высокий
Возврат в главное меню из любых других окон, кроме главного	средний
Открытие раздела «Помощь»	средний
Открытие раздела с информацией о программе	низкий
Выход из программы	средний

Критерий завершения тестового плана: пройдены запланированные тесты

Критерий приостановления/возобновления работы:

1. На уровне тестирования поведения классов методом тестирования конечными автоматами – пройдены все состояния объектов, количество обнаруженных дефектов не более 1 для каждого объекта

2. На уровне тестирования бумажного прототипа пользовательского интерфейса – опрошено не менее 5 человек из числа будущих пользователей программы, от каждого получены ответы на все вопросы анкеты

3. На уровне верификации технического задания методом, основанным на сценариях – сценарии согласованы (если нужно скорректированы) с заказчиком и утверждены им

4. На уровне проверки взаимодействия подсистем методом, основанным на сценариях – согласованные с заказчиком сценарии пройдены без ошибок

5. На уровне приемочного тестирования – программный продукт принят заказчиком

График тестирования:

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