- •Вопросы:
- •Лекция №5-6. Базовые элементы платформы приложений су для построения интерфейса пользователя. Концепция открытой модульной архитектуры в приложениях прикладного программного обеспечения
- •Компоненты каркаса
- •Конфигурирование компонентов в составе системы
- •Вопросы
- •Лекция №9-10. Принципы классификации прикладных компонентов систем управления. Принцип трехуровневого конфигурирования компонентов в приложениях су. Инструменты конфигурирования и их принципы работы.
- •Виртуальная структура прикладной области
- •Преобразование исходных кодов в новый формат языков .Net
- •Обобщенно использование двоичных компонентов заключается в следующем:
- •Вопросы
- •Лекция №13-14. Инструменты отладки приложений в .Net Framework 2.0 и выше.
- •Сборка мусора в .Net Framework
- •Причины смешивания управляемого и неуправляемого кодов
- •2. В чём заключается Концепция CoDeSys?
- •Для высших стандартов качества системы существует три аспекта:
- •Интерфейс PlcHandler предоставляет следующие функции и сервисы:
- •Реализация opc компонентов диагностики для контроллеров CoDeSys sp
- •Вопросы
- •Каскадный жизненный цикл
- •Тестирование, верификация и валидация - различия в понятиях
- •Задачи и цели процесса верификации
- •2) Сценарии на формальных языках
- •Принцип использования коммерческих приложений для тестирования пользовательского интерфейса
- •Обзор Quickt Test. Основные понятия
- •Использование объекта DataTable и параметризация
- •Распознавание объектов в qtp и уникальность их свойств
- •5. Использование объекта DataTable и параметризация
- •6. Распознавание объектов в qtp и уникальность их свойств
- •5. Практический (лабораторный) комплекс Лабораторная работа №1
- •Лабораторная работа №2
- •Лабораторная работа № 3
- •6. Перечень тестовых вопросов для промежуточного и итогового контроля
- •197.Группа компьютеров, связанных каналами передачи информации и находящихся в пределах территории, ограниченной небольшими размерами: комнаты, здания, предприятия, называется:
Тестирование, верификация и валидация - различия в понятиях
Несмотря на кажущуюся схожесть, термины "тестирование", "верификация" и "валидация" означают разные уровни проверки корректности работы программной системы. Дабы избежать дальнейшей путаницы, четко определим эти понятия (Рис. 42).
Тестирование
программного обеспечения -
вид деятельности в процессе разработки,
который связан с выполнением процедур,
направленных на обнаружение (доказательство
наличия) ошибок (несоответствий,
неполноты, двусмысленностей и т.д.) в
текущем определении разрабатываемой
программной системы. Процесс тестирования
относится в первую очередь к проверке
корректности программной реализации
системы, соответствия реализации
требованиям, т.е. тестирование - это
управляемое выполнение программы с
целью обнаружения несоответствий ее
поведения и требований.
Рис.
42 Тестирование, верификация и валидация
Верификация программного обеспечения - более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам. Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации, такое же допущение сделано и в данном учебном курсе.
Валидация программной системы - целью этого процесса является доказательство того, что в результате разработки системы мы достигли тех целей, которые планировали достичь благодаря ее использованию. Иными словами, валидация - это проверка соответствия системы ожиданиям заказчика. Вопросы, связанные с валидацией, выходят за рамки данного учебного курса и представляют собой отдельную интересную тему для изучения. Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос "Как это сделано?" или "Соответсвует ли поведение разработанной программы требованиям?", верификация - "Что сделано?" или ""Соответствует ли разработанная система требованиям?", а валидация - "Сделано ли то, что нужно?" или "Соответствует ли разработанная система ожиданиям заказчика?"
Задачи и цели процесса верификации
Сначала рассмотрим цели верификации. Основная цель процесса - доказательство того, что результат разработки соответствует предъявленным к нему требованиям. Обычно процесс верификации проводится сверху вниз, начиная от общих требований, заданных в техническом задании и/или спецификации на всю информационную систему, и заканчивая детальными требованиями к программным модулям и их взаимодействию. В состав задач процесса входит последовательная проверка того, что в программной системе:
общие требования к информационной системе, предназначенные для программной реализации, корректно переработаны в спецификацию требований высокого уровня к комплексу программ, удовлетворяющих исходным системным требованиям;
требования высокого уровня правильно переработаны в архитектуру ПО и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня;
спецификации требований к функциональным компонентам ПО, расположенным между компонентами высокого и низкого уровня, удовлетворяют требованиям более высокого уровня;
архитектура ПО и требования к компонентам низкого уровня корректно переработаны в удовлетворяющие им исходные тексты программных и информационных модулей;
исходные тексты программ и соответствующий им исполняемый код не содержат ошибок.
Кроме того, верификации на соответствие спецификации требований на конкретный проект программного средства подлежат требования к технологическому обеспечению жизненного цикла ПО, а также требования к эксплуатационной и технологической документации. Цели верификации ПО достигаются посредством последовательного выполнения комбинации из инспекций проектной документации и анализа их результатов, разработки тестовых планов тестирования и тест-требований, тестовых сценариев и процедур и последующего выполнения этих процедур. Тестовые сценарии предназначены для проверки внутренней непротиворечивости и полноты реализации требований. Выполнение тестовых процедур должно обеспечивать демонстрацию соответствия испытываемых программ исходным требованиям. На выбор эффективных методов верификации и последовательность их применения в наибольшей степени влияют основные характеристики тестируемых объектов:
класс комплекса программ, определяющийся глубиной связи его функционирования с реальным временем и случайными воздействиями из внешней среды, а также требования к качеству обработки информации и надежности функционирования;
сложность или масштаб (объем, размеры) комплекса программ и его функциональных компонентов, являющихся конечными результатами разработки;
преобладающие элементы в программах: осуществляющие вычисления сложных выражений и преобразования измеряемых величин или обрабатывающие логические и символьные данные для подготовки и отображения решений.
Определим некоторые понятия и определения, связанные с процессом тестирования как составной части верификации.
Тестирование - процесс выполнения программы с целью обнаружения ошибки. Тестовые данные - входы, которые используются для проверки системы. Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований. Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки. Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку. Ошибка - действие программиста на этапе разработки, приводящее к тому, что в программном обеспечении содержится внутренний дефект, который в процессе работы программы может привести к неправильному результату. Отказ - непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней. Таким образом, в процессе тестирования программного обеспечения, как правило, проверяют следующее:
программное обеспечение соответствует требованиям на него;
в ситуациях, не отраженных в требованиях, программное обеспечение ведет себя адекватно, то есть не происходит отказ системы;
наличие типичных ошибок, которые делают программисты.
Использование пакетов автоматизации тестирования
Использование пакетов автоматизации тестирования. Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса. Ручное тестирование. Сценарии на формальных языках. Система Quick Test.
Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса.
Тестирование функций пользовательского интерфейса может проводиться различными методами - как вручную при непосредственном участии оператора, так и при помощи различного инструментария, автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы более подробно.
1) Ручное тестирование
Ручное тестирование пользовательского интерфейса проводится тестировщиком-оператором, который руководствуется в своей работе описанием тестовых примеров в виде набора сценариев. Каждый сценарий включает в себя перечисление последовательности действий, которые должен выполнить оператор, и описание важных для анализа результатов тестирования ответных реакций системы, отражаемых в пользовательском интерфейсе. Типичная форма записи сценария для проведения ручного тестирования - таблица, в которой в одной колонке описаны действия (шаги сценария), в другой - ожидаемая реакция системы, а третья предназначена для записи того, совпала ли ожидаемая реакция системы с реальной и перечисления несовпадений. Ручное тестирование пользовательского интерфейса удобно тем, что контроль корректности интерфейса проводится человеком, т.е. основным "потребителем" данной части программной системы. К тому же при чисто косметических изменениях в интерфейсах системы, не отраженных в требованиях (например, при перемещении кнопок управления на 10 пикселей влево), анализ успешности прохождения теста будет выполняться не по формальным признакам, а согласно человеческому восприятию.
При этом ручное тестирование имеет и существенный недостаток - для его проведения требуются значительные человеческие и временные ресурсы. Особенно сильно этот недостаток проявляется при проведении регрессионного тестирования и вообще любого повторного тестирования - на каждой итерации повторного тестирования пользовательского интерфейса требуется участие тестировщика-оператора. В связи с этим в последнее десятилетие получили распространение средства автоматизации тестирования пользовательского интерфейса, снижающие нагрузку на тестировщика-оператора.
