
436
.pdfможет писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. 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).