13.Программные решения для бизнеса_Казань. 2 обзор современных технологий в области разработки программного обеспечения. Технологии разработки программного
 Скачать 5.72 Mb.
|
|
Какие ошибки обычно выявляются на этом уровне тестирования? Это ошибки надежности, безопасности, производительности. Также на этом уровне тестируется интерфейс для внешнего окружения, например, доступ к другим программам, доступ к операционной системе, доступ к «железу» компьютера. Знания внутреннего устройства работы программы не требуются. Таким образом, модульное тестирование - проводим методом «белого ящика», обнаруживаем ошибки функциональности. Затем проводим интеграционное тестирование - методом «черного ящика», обнаруживаем ошибки взаимодействия модулей программы. И, наконец, системное тестирование – методом «черного ящика», выявляем ошибки производительности, надежности, безопасности и других параметров. В системном тестировании можно выделить два этапа, которые будут являться стадиями разработки продукта: альфа-тестирование, бета- тестирование. Выполнение задач процесса тестирования программных комплексов сопровождается разработкой различных артефактов (документов, моделей и других материалов проекта). Обычно разработка артефактов может проводиться в разной форме с разными требованиями к способу выполнения, рецензированию и качеству оформления. Ниже представлены основные рабочие артефакты тестировщиков, в той или иной форме связанные со сценариями использования. Эти документы необходимо передавать заказчику или группе сопровождения и технической поддержки системы в случае необходимости. Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 152 План тестирования (Test plan). План тестирования определяется международным стандартом IEEE 829-1998. В нем должны быть предусмотрены как минимум три раздела содержащие, следующие описания: что будет тестироваться (тестовые требования, тестовые варианты); какими методами и насколько подробно будет тестироваться система; план-график работ и требуемые ресурсы (персонал, техника) (Shedule). Дополнительно описываются критерии удачного/неудачного завершения тестов, критерии окончания тестирования, риски, непредвиденные ситуации, приводятся ссылки на соответствующие разделы в основных документах проекта - план управления требованиями, план конфигурации [8]. Сценарий тестирования (Test case, тест кейс). Это один из основных документов, с которыми имеет дело тестировщик. По сути, упрощенное описание теста. То есть входной информации, условий и последовательности выполнения действий и ожидаемого выходного результата. Учитывая, что даже успешно прошедшие тесты выполняются неоднократно в ходе регрессионного тестирования, наличие таких описаний необходимо. Однако уровень формальных требований к их оформлению может меняться в очень широких пределах. Одно дело, если вы собираетесь использовать тесты в ходе приемочных испытаний, проводимых заказчиком, и другое — в ходе внутреннего тестирования коробочного продукта. Тест скрипт(Test script). Обычно говорят о программной реализации теста, хотя скрипт может описывать и ручные действия, необходимые для выполнения конкретного тест кейса. Набор тестов(Test set). Как правило, сценарии тестирования объединяются в пакеты или наборы. Во-первых, это просто способ группирования тестов со сходными задачами, а, во-вторых, в такой набор можно включать зависимые тесты, которые должны выполняться в определенном порядке (поскольку последующие тесты используют данные, сформированные в ходе выполнения предыдущих). Список идей тестов. Использование списка идей тестов для анализа и проектирования системы сценариев использования существенно упрощает задачу разработки необходимого набора тестов. Основной объем тестов строится как проверка различных вариантов выполнения каждого сценария использования. Однако тесты не сводятся к сценариям использования, как и задачи тестирования не сводятся только лишь к проверке функциональных требований к системе. Проверка нефункциональных требований может Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 153 потребовать использования специальных приемов и подходов. Соответствующие тесты не всегда очевидны. Для таких ситуаций и создается список идей тестов. В него все желающие могут записать «что и как» стоит еще проверить. Этот список является внутренним рабочим документом группы тестирования. Наиболее разумная форма его ведения — электронный документ с минимальными формальными требованиями к оформлению. Модель нагрузки. Сценарии использования, как правило, описывают взаимодействие с системой одного пользователя, часто этого бывает мало. При тестировании систем необходимо учитывать возможность параллельной работы большого числа пользователей, решающих различные задачи. Модель реальной нагрузки описывает характеристики типового «потока заявок», которые должны использоваться для нагрузочного тестирования, имитирующего работу системы в реальных условиях. Также могут быть созданы стрессовые модели нагрузки для тестирования отказоустойчивости системы. Дефекты (Deffects). Основополагающие артефакты процесса тестирования – описывают обнаруженные факты несоответствия системы предъявляемым требованиям [9]. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования. Хотя базу данных дефектов можно вести в текстовом файле или Excel таблице, предпочтительным является использования специализированного инструментального средства, которое позволяет передавать информацию об обнаруженных дефектах от тестировщиков к разработчикам, а в обратную сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о тенденциях изменения количества обнаруживаемых и устраняемых дефектов. Журнал тестирования. Каждое выполнение теста должно быть зарегистрировано в журнале тестирования. Журнал тестирования будет содержать записи о том, когда запускался каждый тест, итог выполнения каждого теста и может также содержать важные наблюдения, сделанные при выполнении теста. Зачастую журнал тестирования не ведут для нижних уровней тестирования (тестов компонент и интеграции ПО). Отчеты о тестировании. Отчеты о тестировании могут формироваться в различных точках в течение процесса тестирования. Отчеты о тестировании будут суммировать результаты тестирования и документировать любой анализ. Отчет о приемочном тестировании часто является договорным документом, подтверждающим приемку ПО. Функциональность Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 154 Функциональное тестирование объекта-тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают диаграммы use- case, бизнес-функции и бизнес-правила. Цель функциональных тестов состоит в том, чтобы проверить соответствие разработанных графических компонентов установленным требованиям. В основе функционального тестирования лежит методика «черного ящика» [3]. Идея тестирования сводится к тому, что группа тестировщиков проводит тестирование, не имея доступа к исходным текстам тестируемого приложения. При этом во внимание принимается только входящие требования и соответствие им тестируемым приложением. Цель тестирования: Убедиться в надлежащем функционировании объекта тестирования. Тестируется правильность навигации по объекту, а также ввод, обработка и вывод данных. Методика: Необходимо исполнить (проиграть) каждый из use-case, используя как верные значения, так и заведомо ошибочные, для подтверждения правильного функционирования, по следующим критериям: продукт адекватно реагирует на все вводимые данные (выводятся ожидаемые результаты в ответ на правильно вводимые данные); продукт адекватно реагирует на неправильно вводимые данные (появляются соответствующие сообщения об ошибках); каждое бизнес-правило реализовано надлежащим (установленным) образом. Критерии Завершения: Все запланированные действия по тестированию выполнены. Все найденные дефекты были соответствующим образом обработаны (документированы и помещены в базу дефектов). Целостность данных и баз данных Цель Тестирования: Убедиться в надежности методов доступа к базам данных, в их правильном исполнении, без нарушения целостности данных. Методика: Необходимо последовательно испробовать максимально возможное число способов обращения к базе. Используется подход, при котором тест составляется таким образом, чтобы «нагрузить» базу последовательностью, как верных значений, так и заведомо ошибочных. Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 155 После этого необходимо оценить правильность внесения данных и убедиться в корректной обработке базой входящих значений. Критерии Завершения: Все способы доступа функционируют, в соответствии с требованиями. Действия скрипта не приводят к потере данных или нарушению целостности базы, либо к другим неадекватным реакциям. Пользовательский интерфейс Цель Тестирования: Проверить правильность навигации по объекту тестирования (в том числе межоконные переходы, переходы между полями, правильность обработки клавиш «enter» и «tab», работа с мышью, функционирование клавиш-акселераторов и полное соответствие индустриальным стандартам); Проверить объекты и их характеристики (меню, размеры, положения, состояния, фокус ввода и др.) на соответствия общепринятым стандартам на графический интерфейс пользователя. Методика: Создаются или дорабатываются тесты для каждого из окон, на предмет соответствия навигации и состояний каждого из объектов. Критерии завершения: Каждое окно протестировано и удовлетворяет, базовой линии поведения, требованиям стандартов и не противоречит проектным требованиям. Все выявленные дефекты обработаны и документированы. Описание процесса тестирования как этапа разработки программного обеспечения Процесс тестирования - один из основных процессов общего процесса разработки программного обеспечения. Для того чтобы выработать правильный алгоритм процесса тестирования, определить стратегии тестирования, запланировать процесс тестирования заданного программного комплекса необходимо знать место процесса тестирования в общем процессе разработки программного обеспечения. Покажем место тестирования в общем процессе разработки программного обеспечения, определим объекты тестирования, уровни тестирования на карте процесса тестирования, которая приведена на рисунке 4. Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 156 Этапы разработки ПО Объекты тестирования Уровни и типы тестирования Документация Техническ ое задание Техническ ий проект Специфи кация Модуль (БД, ММ, интерфейс) Группа модулей Программный комплекс Программный комплекс Тестирование документации на - корректность - однозначность - полноту - непротиворечивость Подготовка к тестированию: - описание и внесение требований в систему - создание тест-планов - создание тест-кейсов Модульное Интеграционное Системное Тестирование «Белого ящика» Тестирование «Черного ящика» «Альфа» тестирование Системное «Бета» тестирование Анализ Проектирование Внедрение и сопровождение Модуль (БД, ММ, интерфейс) Группа модулей Программный комплекс Интеграционное Системное Реализация Тестирование Рисунок 4 – Место тестирования в процессе разработки ПО Анализируя карту процесса тестирования, мы видим, что процесс тестирования начинается на этапе проектирования и разработки технической документации на программный комплекс. Правильно построенный процесс тестирования не может начинаться на этапе программирования или внедрения и сопровождения. Только таким образом построенный процесс тестирования позволит на ранних стадиях разработки, а именно, на стадии разработки требований к программным комплексам, выявить дефекты, которые в будущем могут негативно сказаться на разрабатываемом программном комплексе. Объектами тестирования на этапе разработки требований к программному комплексу является техническая документация в виде технических заданий, спецификаций на отдельные модули или систему в целом, руководства пользователей. Этап тестирования заключается в регистрации и анализе требований к программному комплексу в системе поддержки процесса тестирования через модуль управления требованиями к ПО. Тестирование документации проводится на корректность, полноту, однозначность, непротиворечивость, тестируемость, упорядоченность, модифицируемость, отслеживаемость. На данном этапе процесса тестирования инженер по тестированию обращается к базе данных документов. В результате тестирования документации и ее анализа необходимо перейти к этапу планирования процесса тестирования конкретного модуля, интеграции модулей или системы в целом. Руководитель группы тестирования составляет план тестирования, определяет стратегии тестирования, при этом он работает с базой данных заданий на тестирование. Группа тестирования начинает проектирование тестов, подготовку тестовых данных, тестовой среды и Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 157 окружения. Как только группа тестирования получает от разработчиков модуль, группу модулей или программный комплекс начинается этап выполнения тестов и регистрации дефектов. При этом идет пополнение базы данных тестов и дефектов. Руководитель группы тестирования, в свою очередь, работая с базами данных тестов и дефектов через подсистему генерации отчетности, получает информацию о ходе процесса тестирования и анализирует состояние тестируемого программного комплекса. Как только выполняется условие завершения работ (закончилось время, отведенное на тестирование; закончились денежные средства, выделенные на тестирование проекта; найдены дефекты, неисправленными остались лишь незначительные дефекты), руководитель группы тестирования составляет отчет о тестировании и программный комплекс передается в эксплуатацию. Таким образом, происходит тестирование программного комплекса на всех трех уровнях тестирования: модульном, интеграционном, системном, изменяется лишь объект тестирования. Модель работы с дефектами Каждый обнаруженный дефект программного комплекса должен быть зарегистрирован и с ним должна быть проведена работа, которая в конечном итоге должна привести к исправлению дефекта. Работа с дефектами осуществляется по выбранной модели работы с дефектами. Выбор модели работы с дефектами зависит от конкретного проекта, структуры подразделения разработчиков и инженеров по тестированию. Для разработанной системы поддержки процесса тестирования была спроектирована модель работы с дефектами, которая представлена на рисунке 5: Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 158 Рисунок 5 – Модель работы с дефектами Как только дефект обнаружен, тестировщик регистрирует его в подсистеме работы с дефектами, присваивая ему статус «Новый» и направляет его на руководителя группы тестирования. Руководитель группы тестирования подтверждает дефект и направляет его на руководителя группы разработчиков или направляет дефект на инженера по тестированию на доработку. Далее руководитель группы разработчиков направляет дефект на студента или специалиста, отвечающего за дефект, студент или специалист изучает суть дефекта и проставляет статус «В процессе». Если в данный момент необходимо отложить исправление дефекта, то разработчик может присвоить дефекту статус «Отложен». После исправления дефекта разработчик присваивает ему статус «Исправлен» и направляет дефект на руководителя группы тестировщиков, а тот направляет дефект на тестировщика. Инженер по тестированию проверяет дефект и если он исправлен, присваивает ему статус «Исправлен». Если дефект не исправлен, то ему присваивается статус «Не исправлен» и направляется на студента или специалиста для исправления. Всем дефектам со статусом «Исправлен» руководитель группы тестирования присваивает статус «Закрыт». Кроме статусов атрибутами дефекта являются приоритет и важность. Приоритет дефекта показывает, насколько быстро нужно исправить дефект, по приоритету определяется очередность выполнения задачи. Важность характеризует критичность дефекта по отношению к тестируемому приложению. Например, по признаку «важность» дефект может быть описан как Практика и методика реализации образовательных среднего профессионального образования с учетом спецификации стандарта компетенции Ворлдскиллс 159 «блокирующий» - не позволяющий приложению запуститься, «критичный» - некоторые функции приложения недоступны, «крупный» - какая-то функция не работает, «средний» - часть функции не работает и «второстепенный» - не влияющий не работу приложения (например, неправильное написание или неудобное расположение элементов управления). Приоритет в свою очередь может быть «высоким», «средним» и «низким». Такая модель работы с дефектами позволяет полностью контролировать состояние тестируемого проекта, распределяет роли между участниками процесса тестирования и делает процесс работы с дефектами открытым и отслеживаемым как для тестировщиков, так и для разработчиков. Рассмотрим пример создания unit-test. СОЗДАНИЕ ПРОЕКТА ТЕСТИРОВАНИЯ Откроем созданное решение, нажмем правой кнопкой мыши на решении и выберем «New Project» Далее выберем Test – Unit Test Project. |