Недостатки существующих решений

Определение границ системы

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

— Для этого надо ответить на вопросы:

◦ Кто будет снабжать систему информацией?

◦ Кто будет получать информацию от системы?

◦ Кто будет осуществлять поддержку и обслуживание системы?

◦ Использует ли система внешние ресурсы?

Ключевые абстракции

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

— Ключеваяабстракция - это класс или объект, который входит в словарь проблемной области

— Ключевые абстракции определяют границы системы: выделяют то, что входит в нее и важно для нас, а также устраняют все лишнее

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

2. Функциональные требования к системе. Способ их представления в виде UML -диаграммы. Пример диаграммы с использованием отношений «расширяет» и «включает».

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

— Требования этой категории исследуются и формулируются в процессе разработки модели прецедентов (вариантов использования)

— Как правило, одной задаче исполнителя соответствует один прецедент

Пример диаграммы с использованием отношений «расширяет» и «включает»

Способ их представления в виде UML -диаграммы:

Диаграмма прецедентов

// на всякий случай

Описание прецедентов

— Диаграмма прецедентов дает наглядное изображение системного контекста – границ системы, внешние по отношению к ней понятия и способы использования системы

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

— Требования можно разбить на категории (модель FURPS+):

◦ F unctionality – функциональности,

◦ U sability – эргономичности,

◦ R eliability – надежности,

◦ P erformance – производительности,

◦ S upportability – возможности поддержки,

◦ + – дополнительные требования (реализация, интерфейс, юридические вопросы)              //

Понятие прецедента и сценария. Пример прецедента, основного и дополнительного сценариев.

Сценарий (Scenario) - это некоторая последовательность действий, иллюстрирующая поведение системы.

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

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

Прецеде́нт (Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними акторами (Actors).

Пример основного успешного сценария (или основного процесса)

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

2. Кассир открывает новую продажу.

3. Кассир вводит идентификацию товара.

4. Система записывает наименование товара и выдаёт его описание, цену и общую стоимость. Цена вычисляетя на основе набора правил.

Кассир повторяет действия, описанные в пп.3-4, для каждого наименование товара.

5. Система вычисляет общую стоимость покупки с налогом.

6. Касир сообщает покупателю общую стоимость и предлагает оплатить покупку.

7. Покупатель оплачивает покупку, система обрабатывает платеж.

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

9. Система выдает товарный чек.

10. Покупатель покидает магазин с чеком и товарами (если он что-то купил).

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

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

— Определяются в дополнительной спецификации

— Приведем пример такой спецификации для POS-системы

1. Эргономичность

— Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:

◦ обеспечить минимальное время отклика системы,

◦ текст должен быть виден с расстояния 1 м,

◦ не должно быть мерцания экрана,

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

2. Надежность

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

— Этот вопрос требует дальнейшей проработки

3. Производительность

— Покупатель хочет оформить покупку как можно быстрее

— Одна из основных причин задержки – низкая скорость авторизации

— Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев

Системные операции

— Диаграмма последовательностей системы позволяет выделить набор системных операций

— Операцией называется любое преобразование объекта или запрос к объекту

— Операция называется системной, если в качестве объекта выступает система в целом 

Описание прецедентов

— Диаграмма прецедентов дает наглядное изображение системного контекста – границ системы, внешние по отношению к ней понятия и способы использования системы

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

— Текстовое описание прецедента может быть развернутым или кратким

— На начальном этапе развернутое описание дается лишь для основных прецедентов (10-20% от их общего числа)

— Пример развернутого описания для прецедента Оформление продажи

Диаграммы взаимодействия как элементы концептуальной модели. Синтаксис диаграмм взаимодействия. Примеры диаграмм взаимодействия.

— Для визуализации распределения обязанностей между объектами используют диаграммы взаимодействия двух видов:

◦ диаграммы кооперации,

◦ диаграммы последовательностей

— В обоих случаях взаимодействие объектов представляется в виде обмена сообщениями

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

Идентификция классов

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

Определение методов классов

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

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

Ассоциации и навигация

— Линии связи и навигации устанавливаются на основе анализа диаграмм взаимодействия.

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

Отношения зависимости

— Означает наличие у одного из классов информации о другом классе.

— Изображается пунктирной линией.

— Объект класса Register получает информацию об объекте класса ProductSpecification в виде возвращаемого значения метода getSpecification, а объект класса Sale – через параметр метода makeLineItem.

// к чему тут это написано я хз//

Обязанности программных классов, виды обязанностей. Визуализация распределения обязанностей посредством UML -диаграмм. Примеры диаграмм.

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

Реализация обязанностей

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

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

Графически обязанности изображают в особом разделе в нижней части пиктограммы класса

Диаграммы взаимодействия

— Для визуализации распределения обязанностей между объектами используют диаграммы взаимодействия двух видов:

◦ диаграммы кооперации,

◦ диаграммы последовательностей

— В обоих случаях взаимодействие объектов представляется в виде обмена сообщениями

Контроллеры:

— классы, обязанности которых состоят в обработке системных сообщений называются (классами контроллера.)

— Классы контроллера не относятся к интерфейсу пользователя

— В рассматриваемом примере возможны два варианта решения:

1-й вариант - все системные операции выполняются одним внешним контроллером.

2-й вариант - системные операции распределены между несколькими контроллерами прецедента.

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

9. Шаблоны проектирования, их классификация. Правила описания шаблонов, примеры шаблонов с их описаниями.

// хз, это скопировано из 1йаттестации,//

Шаблоны проектирования (паттерн, англ. design pattern) — это многократно применяемая архитектурная конструкция, предоставляющая решение общей проблемы проектирования в рамках конкретного контекста

Классификация:

— - Шаблоны анализа

— - Архитектурные шаблоны

— - Шаблоны проектирования

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

примеры

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

Adapter - паттерн, позволяющий преобразовать интерфейс объекта к тому, который требует клиент.

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

Bridge - паттерн, позволяющий отделить интерфейс от реализации и изменять их независимо.

Decorator - паттерн, позволяющий динамически добавлять обязанности объекту, путем включения его в "конверт", обладающий совместимым интерфейсом

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

Шаблоны распределения обязанностей, их назначение. Примеры применения.

Шаблон

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

— Эти принципы формулируются в виде шаблонов проектирования (design patterns)

Шаблон Expert

— Проблема Каков наиболее общий принцип распределения обязанностей?

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

Шаблон Creator

— Проблема. Кто должен отвечать за создание нового экземпляра некоторого класса?Решение. Назначить классу B обязанность создавать экземпляры класса A, если выполняется одно из условий.

• Класс B агрегирует (aggregate) объекты A

• Класс B содержит (contains) объекты A

• Класс B записывает (records) экземпляры объектов A

• Класс B (closely uses) объекты A

• Класс B обладает данными инициализации (has the initializing data), которые будут передаваться объектам A при их создании (т.е. при создании объектов А класс В является экспертом)

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

Шаблон Low Coupling

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

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

Шаблон High Cohesion

— Проблема. Как обеспечить возможность управления сложностью?

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

— Функциональное зацепление – это мера взаимосвязи обязанностей класса

— Класс с низкой степенью зацепления выполняет много разнородных функций 

Шаблон Controller

—                    Проблема Кто должен отвечать за обработку системных сообщений?

— Решение Обязанности по обработке системных сообщений назначаются классу, который:

◦ представляет систему в целом;

◦ представляет сценарий некоторого прецедента, в рамках которого обрабатываются системные сообщения

Шаблон Polymorphism

Проблема. Как обрабатывать альтернативные варианты поведения на основе типа? Как создавать подключаемые программные компоненты?

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

Идентификация методов программных классов. Диаграммы классов, способы Отображения отношений ассоциации и зависимости. Пример диаграммы классов.

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

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

Примеры шаблонов:

Adapter/Адаптер - паттерн, позволяющий преобразовать интерфейс объекта к тому, который требует клиент.

Bridge/Мост - паттерн, позволяющий отделить интерфейс от реализации и изменять их независимо.

Composite/Компоновщик — объект, который объединяет в себе объекты, подобные ему самому.

Decorator/Декоратор - паттерн, позволяющий динамически добавлять обязанности объекту, путем включения его в "конверт", обладающий совместимым интерфейсом

Facade/Фасад - паттерн, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делигирующему их соответствующим объектам системы.

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

Proxy/Заместитель - предоставляет объект, контролирующий доступ к данному, перехватывая все вызовы к нему.

Стадии тестирования

· В процессе разработки программного средства обычно выделяют три стадии тестирования:

◦ модульное (компонентное),

◦ интеграционное (комплексное),

◦ системное (оценочное)

— Эти стадии различаются как объемом тестируемой части ПС, так и уровнем диагностируемых ошибок

Характеристика этапов

· Тестирование модулей. Цель – индивидуальная проверка каждого модуля

· Тестирование интеграции. Цель – проверка межмодульных интерфейсов

· Системное тестирование. Цель –проверка выполнения всех требований к ПС

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

· Модульному тестированию подвергаются небольшие модули (процедуры, классы и т.п.)

· Тестирование осуществляется по методу «белого ящика» и проверке подвергаются:

◦ интерфейс модуля;

◦ внутренние структуры данных;

◦ независимые пути выполнения;

◦ граничные условия;

◦ пути обработки ошибок

· Модульное тестирование обычно рассматривается как дополнение к этапу кодирования

· Модуль не является автономной системой, поэтому его тестирование требует использования дополнительных средств:

◦ драйверов тестирования,

◦ заглушек

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

· Интеграционное тестирование – это отладочное тестирование постепенно наращиваемой системы

· Система строится поэтапно путем добавления отдельных модулей и их групп

· На каждом этапе после приращения системы производится ее тестирование

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

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

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

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

· Основные виды системных тестов:

◦ функциональное тестирование (по методу «черного ящика»),

◦ тестирование восстановления,

◦ тестирование безопасности,

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

◦ тестирование производительности

Тестовые наборы

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

· Совокупность исходных данных и ожидаемого результата называется тестовым вариантом или просто тестом

· Каждый тест представляет собой вариант взаимодействия с тестируемой системой и проверки корректности ее поведения

· Хорошим считается тест, обеспечивающий высокую вероятность обнаружения ошибки

· Выполнение теста считается удачным, если оно сопровождается обнаружением новой ошибки

Тестовое покрытие

· Практически оценивается только степень соответствия программы ее спецификации

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

· Для оценки степени полноты тестирования вводится понятие уровня тестового покрытия

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

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

Структурный подход к формированию тестовых наборов. Пример реализации структурного подхода.

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

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

Назначение

· Основное назначение структурного тестирования – проверка внутренней логики ПС

· Структурные тесты проверяют:

◦ -корректность построения отдельных элементов и правильность их взаимодействия

◦ -управляющие и информационные связи между элементами программы

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

· Тесты формируются на основе анализа внутренней структуры программы.

· Одним из способов фиксации этой структуры является потоковый граф:

◦ -узлы графа соответствуют операторам или предикатам;

◦ -дуги графа отображают потоки управления в программе;

Пример:

· Рассмотрим процедуру добавления элемента в упорядоченный линейный список.

· Пронумеруем фрагменты исходного текста процедуры, которые будут соответствовать отдельным вершинам потокового графа.

· Каждое из простых условий, входящих в составное, рассматривается как отдельный предикатный узел.

Базовое множество путей

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

— Мощность этого множества называется его цикломатической сложностью

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

Функциональный подход к формированию тестовых наборов. Пример реализации функционального подхода.

Базируется на том, что структура тестируемого ПС неизвестна – тестирование по принципу «черного ящика».

Основное назначение

— Основное назначение функционального тестирования – проверка интерфейса ПС.

— Функциональные тесты проверяют:

◦ -как выполняются функции программы

◦ -как принимаются исходные данные

◦ -как вырабатываются результаты

◦ -как сохраняется целостность внешней информации

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

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

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

— Разработка функциональных тестов базируется на принципах:

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

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

◦ -на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест.

— Чаще всего используют два способа формирования тестовых наборов:

◦ -разбиение на классы эквивалентности,

◦ -анализ граничных значений.

— Эти способы являются взаимодополняющими и могут применяться совместно.

Достоинства:

— -независимость от реализации;

— -относительная простота подготовки тестов;

— -возможность анализа результатов специалистами предметной области

Недостатки:

— -слабая локализация ошибок.

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

— Интеграционное тестирование – это отладочное тестирование постепенно наращиваемой системы

— Система строится поэтапно путем добавления отдельных модулей и их групп

— На каждом этапе после приращения системы производится ее тестирование.

Уровни интеграционного тестирования:

1 Компонентный интеграционный уровень (Component Integration testing)

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

 2 Системный интеграционный уровень (System Integration Testing) Проверяется взаимодействие между разными системами после проведения системного тестирования.

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

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

Восходящее тестирование

· Модули нижнего уровня объединяются в несколько кластеров, каждый из которых выполняет определенную подфункцию.

· Для каждого кластера создается программу-драйвер,

· Тестируется кластер,

· Драйвер удаляется, а кластеры объединяются в структуру движением вверх,

Нисходящее тестирование

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

· Он тестируется при «естественном» состоянии информационной среды, при котором начинает выполняться эта программа.

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

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

· Процесс подключения продолжается вплоть до получения нужной конфигурации.

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

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

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

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

· Основные виды системных тестов:

o функциональное тестирование (по методу «черного ящика»),

o тестирование восстановления,

o тестирование безопасности,

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

o тестирование производительности

Критерии тестового покрытия

· Для системного и компонентного тестирования используются специфические виды критериев тестового покрытия:

o тестирование всех типовых сценариев работы;

o тестирование всех сценариев с нештатными ситуациями;

o тестирование попарных композиций сценариев и т.д.

Альфа-тестирование

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

· Альфа-тестирование - тестирование проводимое заказчиком в организации разработчика

· Разработчик фиксирует все выявленные ошибки и недостатки использования

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

· Бета-тестирование - опробование программного продукта потенциальными пользователями на реальных задачах

· О найденных ошибках и замечаниях пользователь сообщают разработчику  

· Тестируемая таким образом версия программного средства называется бета-версией и, как правило, она предшествует коммерческому выпуску продукта

Отличия от классического

· Тестирование объектно-ориентированных программных средств имеет ряд существенных отличий от классического тестирования:

o расширение области применения тестирования;

o изменение методики тестирования;

o учет особенностей ООП при проектировании тестовых вариантов

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

· Синтаксическая правильность связана с корректным использованием нотаций языка описания моделей

· Семантическая правильность определяется соответствием модели реальной системе и связанной с ней задаче

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

Полнота модели

· Мера наличия в модели необходимых элементов

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

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

Согласованность модели

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

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

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

· Наименьшим тестируемым элементом объектно-ориентированного ПО является не процедура, а класс

· Поскольку класс содержит набор свойств и методов, образующих единую сущность, изолированное тестирование методов не имеет смысла

· Методы должны тестироваться в контексте частных свойств и операций класса

Тестирование классов

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

o создавать экземпляры тестируемого класса;

o вызывать методы тестируемого класса и передавать им фактические параметры из тестовых вариантов;

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

Тестирование классов

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

· Создание драйвера для автономного тестирования класса может оказаться не менее сложной задачей, чем разработка самого класса.

· Решение об автономном тестировании класса принимается с учетом следующих факторов:

o -роли класса в системе;

o -сложности класса, измеряемой числом состояний, операций и связей с другими классами;

o -объема трудозатрат, связанных с разработкой тестового драйвера.

Виды взаимодействия классов:

· Метод одного класса содержит в списке своих формальных параметров имена других классов.

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

· Метод одного класса ссылается на глобальный экземпляр другого класса

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

· Объектно-ориентированное ПО не имеет иерархической управляющей структуры

· Методики нисходящего и восходящего тестирования здесь неприменимы

· Зачастую неосуществим классический прием интеграции – добавление по одной операции в класс

· Основная цель этого этапа тестирования – проверка правильности обмена сообщениями между объектами, классы которых уже прошли тестирование в автономном режиме

· Основная задача – выделение подмножества взаимодействующих классов

Наиболее популярными являются следующие методики тестирования интеграции объектно-ориентированных систем:

· тестирование, основанное на потоках;

· кластерное тестирование

Тестирование потоков

· Объектом интеграции является набор классов, обслуживающих единичный ввод данных в систему

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

· Для контроля побочных эффектов применяют регрессионное тестирование

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

· Объектом тестирования является кластер – набор сотрудничающих классов

· Для выделения кластеров можно использовать диаграммы взаимодействия, соответствующие отдельным прецедентам

Размер кластера

· При малых размерах кластера невозможно воспроизведение в полном объеме эффекта интеграции (системного эффекта)

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

Среда тестирования

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

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

o в среде, специально созданной тестирующим драйвером (результаты тестирования получаются в «чистом» виде; соответствие результатов тестирования реальным условиям эксплуатации зависит от степени адекватности этим условиям созданной драйвером среды тестирования)

26. Понятие автоматизированного тестирования. Автотесты. Достоинства и недостатки автоматизированного тестирования.

Автоматизация тестирования

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

Автотесты:

· Основная идея автоматизированного тестирования заключается в использовании автотестов – записанных на специальных скриптовых языках действий по проверке качества программ.

· Современные средства автоматизации позволяют вести запись действий тестировщика и создавать заготовку для автотеста.

Преимущества автоматизации

· -Экономия времени – программа-робот гораздо быстрее перебирает тестовые варианты, чем любой человек.

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

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

· -Наличие инструментария фиксации ошибок и результатов – это позволяет моделировать различные ошибочные ситуации, строить любые отчеты и диаграммы.

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

Недостатки автоматизации:

· -Временные затраты на создание, поддержку и тестирование (!) тестов – автоматизированное тестирование всегда начинается с тестирования вручную, поскольку необходимо показать роботу, как, что и с чем он должен делать.

· -Неприменимость к некоторым объектам, оцениваемым субъективно – с помощью автомата нельзя протестировать, например, эргономику интерфейса приложения.

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

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

Планирование функционального тестирования

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

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

· -Функциональные требования разделяют по степени критичности и начинают планирование тестов для самых критичных пользовательских бизнес-прецедентов.

Планирование регрессионного тестирования

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

Планирование нагрузочного тестирования

· три основные цели:

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

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

o -поиск опасных тенденций для системных ресурсов клиента и сервера.

· Выделяют три уровня нагрузки:

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

o -рабочая (некоторое количество клиентов, считающееся штатным) - когда приложение должно вести себя безукоризненно;

o -стрессовая или пиковая нагрузка, которую приложение должно выдерживать в принципе.

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

Утверждения

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