Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

436

.pdf
Скачиваний:
5
Добавлен:
07.01.2021
Размер:
495.54 Кб
Скачать

может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

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

1.5. Основные технологии и методы тестирования

Вопросы для рассмотрения: Стандарты и модели жизненного цикла разработки программного обеспечения. Модульное тестирование, интеграционное тестирование, системное тестирование, регрессионное тестирование. Издержки тестирования. Ручное и автоматизированное тестирование. Тестирование графического интерфейса. Тестирование производительности. Нагрузочное тестирование. Стресс тестирование. Конфигурационное тестирование. Тестирование надежности, удобства использования, производительности.

Рекомендуемая литература: 7.

Перечень дополнительных ресурсов: 4, 5, 6, 10. Наименование вида самостоятельной работы: изучение

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

Технологий тестирования существует целое множество. Условно их можно отнести к статическим или к динамическим.

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

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

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

запуска системы или подсистемы;

вызова необходимых функциональных элементов или модулей;

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

Широко используемыми методами тестирования являются

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

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

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

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

приемочные испытания. Методы тестирования:

Восходящее тестирование – программа собирается и тестируется снизу-вверх.

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

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

всистему все сразу.

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

2.ПРАКТИЧЕСКИЕ РАБОТЫ

2.1. Практическая работа № 1 «Процессы отладки и тестирования. Основные законы теории

тестирования программных продуктов»

Рекомендуемая литература: 7.

Перечень дополнительных ресурсов: 1, 3, 9, 10.

Задание:

Цель работы: в практической работе тестируем и оцениваем качественные показатели ПП.

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

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

Показатели

Сущность

Экспертная оценка

Оценка, установленная

качества

показателя

(вес) wi

экспериментом ri

 

 

 

 

Установить веса показателей wi (∑wi =1).

Для каждого показателя установить конкретную численную

оценку ri от 0 до 1, исходя из следующего:

 

0 – свойство в ПП присутствует, но качество его неприемлемо; 0.5 - 1 – свойство в ПП присутствует и обладает приемлемым

качеством; 1 – свойство в ПП присутствует и обладает очень высоким

качеством.

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

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

2.2. Практическая работа № 2 «Выявление дефектов по тестовым сценариям»

Рекомендуемая литература: 5.

Перечень дополнительных ресурсов: 4, 5, 7.

Цель работы: провести функциональное и нефункциональное тестирование мобильных и веб-приложений.

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

Необходимо учитывать особенности тестирования на мобильных устройствах:

размер экрана и touch-интерфейс;

ресурсы устройства;

различные разрешения экрана и версии ОС;

реакция приложения на внешние прерывания;

удобство навигации по приложению;

тестирование вёрстки сайта;

отсутствие пустых экранов;

одновременное нажатие на все клавиши («защита от дурака»);

жесты предусмотренные функционалом;

Подготовка и порядок выполнения работы:

выбрать любой интернет-сайт и эмулятор (симулятор) мобильного устройства;

провести функциональное и нефункциональное тестирование этого сайта;

найти дефекты в работе сайта, сравнив отображение на эмуляторе устройства и на ПК в различных браузерах;

Заполнить тест-план и 10 тест-кейсов для тестирования

сайта.

2.3. Практическая работа № 3 «Метрики тестирования и качества. Метрики покрытия»

Рекомендуемая литература: 7.

Перечень дополнительных ресурсов: 2, 4, 10.

Задание:

1.познакомьтесь с метриками;

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

3.выберите вариант задания (таблица 1);

4.определите метрики для оценки заданной характеристики качества (для этого выберите метрики из моделей 9126, QUIM и т.д. или разработайте собственные оригинальные метрики для следующих характеристик пользовательских программных интерфейсов);

5.задайте метрику в форме спецификации;

6.обоснуйте адекватность выбранных метрик;

Варианты заданий

Таблица 1. Характеристики и требования к ним

Характеристика

 

Описание

 

 

 

Безопасность

Дизайн

интерфейса

должен

обеспечивать

1.

минимальную возможность травм и воздействия

персонала

 

 

вредных материалов.

 

 

 

 

 

Роль

оператора

должна

состоять

из

2.

Когнитивная

целенаправленных и значимых задач, которые

 

совместимость

позволяют персоналу

поддерживать хорошую

 

 

осведомленность с АЭС и поддерживать уровень

Характеристика

 

 

Описание

 

 

 

 

 

нагрузки, который не настолько высокий, чтобы

 

 

негативно повлиять на производительность, но

 

 

достаточной для поддержания бдительности.

 

 

Дизайн

интерфейса

 

должен

отражать

 

 

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

физиологических

характеристик

3.

Физиологическая

человека,

 

включая

 

визуальное/слуховое

 

совместимость

восприятие, биомеханику (достижения и

 

 

движения), характеристики управления, и

 

 

антропометрии.

 

 

 

 

 

 

Простота

ЧМИ должны представлять простой дизайн в

4.

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

 

конструкции

и требованиями задачи.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Должна быть высокая степень согласованности

 

 

между ЧМИ, процедурами и обучающими

 

 

системами. В ЧМИ пути системных функций и

5.

Согласованность

деятельности

бригады

 

всегда

должны быть

 

 

согласованы, отражать высокую степень

 

 

стандартизации, и быть в полном соответствии с

 

 

процедурами и подготовкой кадров.

 

 

 

Информация,

представленная

пользователям

 

 

ЧМИ должна быть правильно, быстро и легко

 

Понимание

понята

(например,

 

«непосредственное

6.

восприятие»

или «определение состояния с

ситуации

 

 

одного взгляда» на дисплее) и поддерживаться

 

 

на высоком уровне с целью осведомленности

 

 

пользователей о статусе системы.

 

 

 

 

Система

должна

отвечать

требованиям

 

 

пользователей для выполнения своих задач (в

 

 

том числе, безопасное завершение работы,

 

 

осмотр, техническое обслуживание и ремонт).

 

 

Данные должны быть представлены в формах и

7.

Целевая

форматах,

соответствующих

задач

(включая,

совместимость

необходимость доступа

к

подтверждающим

 

 

данным или необработанным данным в случае

 

 

отображения

более

 

высокого

уровня).

 

 

Возможность контроля должна охватывать ряд

 

 

потенциальных действий. Не должно быть

 

 

ненужной информации или вариантов контроля.

Характеристика

 

 

 

Описание

 

 

 

 

 

Все аспекты системы должны быть совместимы

 

 

с ментальными (психическими) моделями

 

 

пользователей

(понимание

и

ожидание

 

Пользовательская

поведения

 

системы осуществляется

путем

8.

подготовки

кадров, использования

процедур и

модель

опыта). Все аспекты системы должны быть

 

совместимости

 

совместимы

с

установленными допущениями,

 

 

т.е. должны быть выражены в обычной,

 

 

привычной, пригодной и функциональной точки

 

 

зрения, а не абстрактно.

 

 

 

 

 

Структура всех аспектов ЧМИ (от элементов в

 

 

отдельных дисплеях до отдельных рабочих

 

 

станций и всей комнаты управления) должна

 

 

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

 

Структура

должна отражать общие принципы организации

9.

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

 

элементов ЧМИ

Информация критических функций безопасности

 

 

должна быть доступна всем, работающим в

 

 

команде, для обеспечения ее распознавания и

 

 

сведения к минимуму поиска данных и ответных

 

 

мер.

 

 

 

 

 

 

 

 

Все аспекты системы (форматы, терминология,

 

 

последовательность, группировка, и поддержка

 

 

принятия решений оператора) должна отражать

 

 

очевидную логику, основанную на требованиях

 

 

задачи

или

других

непроизвольных

 

 

обоснованиях. Отношения каждого отображения,

 

 

управления и обработки данных для общей

 

Логическая/

задачи/функции

должны

быть

 

ясными.

10.

Структура интерфейса и связанная с ней

 

Явная структура

навигация должны быть сделаны легкой для

 

 

пользователей, чтобы было понятно, где они

 

 

находятся в пространстве данных. Структура

 

 

интерфейса

 

 

должна

 

позволить

 

 

пользователям получить быстрый доступ к

 

 

данным, не

видимым в

настоящее

время

 

 

(например, на других страницах дисплей). Ход

 

 

работы системы и структурированность должны

Характеристика

 

 

 

Описание

 

 

 

 

 

 

быть ясными для пользователя

 

 

 

 

 

 

Проектирование системы должны принимать во

 

 

внимание

 

когнитивные

 

возможности

 

 

пользователей, а также связанные с процессом

 

 

ограничения

времени для обеспечения того,

11.

Своевременность

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

 

 

информационного потока и требования контроля

 

 

за исполнением, которые являются слишком

 

 

быстрыми или слишком медленными могут

 

 

привести к снижению производительности.

 

12.

Совместимость

Отображения

должны

быть

совместимы

с

управления/

вводимыми данных и требованиями управления.

 

отображения

 

 

 

 

 

 

 

 

 

 

 

 

 

Система должна давать полезную информацию о

13.

Обратная связь

состоянии

системы,

допустимых

операциях,

ошибках

и

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

после

ошибки,

 

 

опасных операциях, и достоверности данных.

 

 

 

Информация, представленная системой должна

 

 

быстро восприниматься и пониматься. Поэтому

 

 

система должна минимизировать требования для

 

 

вычислений или преобразований в уме и

 

 

использовать

напоминания

(ссылаясь

на

14.

Когнитивная

длинные

списки

кодов,

сложные

команды,

 

нагрузка

информацию

с одного экрана на другой, или

 

 

длительные последовательности действий).

 

 

Исходные данные должны быть обработаны и

 

 

представлены

в

непосредственно

удобной

 

 

форме. Исходные данные должны быть

 

 

доступны для подтверждения.

 

 

 

 

 

 

Система

должна

требовать

минимальное

 

 

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

 

 

Например, одну команду ввода вместо

 

Нагрузка ответа

нескольких

команд,

меню

выбора

вместо

15.

(реакции)

многократных команд,

один

режим ввода

 

 

(клавиатура, мышь) вместо смешанного режима.

 

 

Система не должна требовать ввода избыточных

 

 

данных,

повторного

 

ввода

информации,

 

 

имеющейся уже в

системе, или

информации,

Характеристика

 

 

 

 

Описание

 

 

 

 

 

 

которую система может генерировать по уже

 

 

 

поступившим данным.

 

 

 

 

 

 

 

Система должна

предоставить

пользователю

 

 

 

несколько способов для совершения действий и

 

 

 

проверить

 

автоматические

 

действия.

 

 

 

Отображение и контроль должен быть

16.

Гибкость

 

отформатирован

в

конфигурации

наиболее

 

удобной для задачи. Однако, гибкость должна

 

 

 

 

 

 

быть ограничена ситуациями, когда она

 

 

 

предлагает преимущества в выполнении задачи

 

 

 

(например, для приспособления к различным

 

 

 

уровням опыта пользователей).

 

 

 

 

 

 

Система

должна

обеспечить

эффективную

 

Руководства

и

«Помощь».

 

Информативные,

легкие

в

17.

поддержка

 

использовании

рекомендации

должны

быть

 

предоставлены в онлайн и оффлайн режимах,

 

пользователя

 

 

 

чтобы помочь пользователю понять, как

 

 

 

 

 

 

работать с системой.

 

 

 

 

 

 

 

Отказоустойчивый

 

дизайн

 

должен

 

 

 

предоставляться везде, где сбой может привести

 

 

 

к

повреждению

 

оборудования,

травмам

 

 

 

персонала, или непреднамеренной работе

 

 

 

критически важного оборудования. Таким

 

Толерантность

 

иобразом,

система

должна вообще

быть

18.

управление

 

сконструирована таким образом,

чтобы ошибки

 

ошибками

 

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

 

 

 

Надо управлять негативными

последствиями

 

 

 

ошибок, и сводить их к минимуму. Система

 

 

 

должна

предлагать

простые,

понятные

 

 

 

уведомления

об

 

ошибке,

и

простые,

 

 

 

эффективные методы для восстановления.

 

2.4. Практическая работа № 4 «Обзор инструментальных средств тестирования ПО»

Рекомендуемая литература: 7.

Перечень дополнительных ресурсов: 1, 2, 4, 5.

Задание: проведите классификацию средств тестирования, основанную на оценке качественных характеристик инструментария

исопутствующих условий внедрения и использования.

Ванализе необходимо рассмотреть следующие критерии:

поддерживаемые процессы тестирования (управление жизненным циклом, управление тестированием, управление изменениями, управление ошибками, управление требованиями, управление конфигурациями);

поддерживаемые типы тестов (функциональные, регрессионные, нагрузочные, Unit-тесты, анализ исходного кода, анализ утечек памяти);

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

например, технологии .NET, CORBA, OLE, COM, DCOM, COM+ и т.д.);

интеграция с системами разработки (Под системами разработки ПО будем понимать не только саму среду разработки

(development environment) уровня Visual Studio и Delphi, но и инструменты планирования и управления процессом разработки

(например, Microsoft Project Manager, DevPartner, Rational Unified Process), документооборота и управления ошибками, конфигурациями

(Borland StarTeam, Rational ClearQuest) и средства централизованного хранения и изменения данных (Visual Source Safe, CVS).

техническая и документальная поддержка компанией разработчиком;

обучение и сертификация персонала, работающего с набором инструментов и/или методологией;

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

2.5. Практическая работа № 5 «Разработка примеров модульных тестов»

Рекомендуемая литература: 7.

Перечень дополнительных ресурсов: 4, 5, 6, 10.

Задание: изучите и кратко опишите популярные инструменты и библиотеки модульного тестирования (для Java, C, C++, .NET, Delphi, PHP, Python, Perl, Ruby).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]