Сложность систем и ее причины.

10.09.2012

Тема: «Введение в дисциплину. Жизненный цикл ПО»

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

В начале 1970-х годов, в США имел место так называемый «кризис ПО». Заключался в следующем: большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов.

Причины неудач:

1. Нечеткая и неполная формулировка требований ПО.

2. Отсутствие необходимых ресурсов (человеческих, временных или материальных).

3. Неудовлетворительное планирование.

4. Частое изменение требований и спецификаций.

5. Новизна используемых технологий.

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

Свойства и виды систем

Система – совокупность взаимосвязанных и часто взаимодействующих элементов.

Элемент – это нечто, обладающее следующими свойствами:

1. Внутренне связное.

2. Имеющие четко очерченные границы с внешней средой.

3. Обладающее определенными свойствами.

4. Часто обладающее определенным поведением.

5. Часто имеющее себе подобных.

Элементы системы могут быть реальными или абстрактными, как и сами системы.

Пример: Элементами программной системы могут быть объекты, модули, компоненты, функции и подсистемы.

Типизация – это образование и использование типов объектов, предназначенное для защиты, от использования объектов одного типа вместо другого.

Декомпозиция системы – выделение объектов, частей, подсистем из целого. Внутренняя связь объектов, должна быть выше связи между объектами. Чем больше это различие, тем лучше выполнена декомпозиция.

Каждый элемент этой системы должен скрывать свое содержимое.

 

Практика

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

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

Модели бывают:

1. Натуральная модель – физический упрощенный аналог системы.

2. Изображение – Представление зримо воспринимаемых аспектов системы.

3. Математическая модель – некоторые аспекты системы описанные с помощью строго математического аппарата.

4. Компьютерная модель – некие проявление системы, воспроизведенные на компьютере.

5. Словесное описание – неформальное описание системы, при помощи естественно языкового способа.

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

Сложность систем и ее причины.

Сложность программных систем может быть обусловлена:

1. сложностью реальной предметной областью.

2. Трудности управления процессом разработки:

3. Неудовлетворительным способом описание систем.

4. Неудовлетворительными или неподходящими средствами систем.

5. Взаимными противоречиями предъявляемых требований.

6. Отсутствием аналогов и типовых проектных решений.

7. Необходимость интеграции существующих и вновь разрабатываемых приложений.

Причины нечеткости формулирования требований:

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

2. Недостаточным взаимопониманием заказчика и разработчика из-за разности предметных областей.

3. Отсутствие подходящих средств общения и документирования информации.

 

SADT – технология структурного анализа и проектирования. Заключает в себе графические обозначения и подход к описанию систем.

Входов должен быть хотя бы один и выходов, хотя бы один.

Исполнители это то, что выполняет процесс.

 

 

17.09.2012.

Жизненный цикл ПО

Согласно стандарту IEEE 610.12, жизненным циклом ПО называется период времени, с момента принятия решения о необходимости создания ПО, до момента его полного изъятия из эксплуатации.

Разработка ПО как правило, включает:

1. Анализ.

2. Проектирования.

3. Реализацию.

После процесса реализация, идет тестирования, документирование и эксплуатация. Эксплуатация – включает в себя:

1. Работы по внедрению компонентов ПО в эксплуатацию.

2. Сопровождение – внесение изменений в ПО, с целью исправления ошибок, повышение производительности или адаптация к изменившимся условиям работы.

Стратегия и модели конструирования ПО. Начальные этапы конструирования ПО.

Каскадная стратегия

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

Схема каскадной разработки ПО:

 

Преимущества:

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

2. Удобства планирования сроков и затрат

Недостатки:

1. Запаздывание с получением результатов.

2. Согласование результатов с пользователями возможно только после завершения какого-либо этапа работы.

3. Сложности с внесением изменений, при изменении требований.

Эволюционная стратегия

Эволюционная стратегия заключается в повторении процесса разработки ПО выпуском новой версии. К существующим этапам жизненного цикла разработки ПО добавляются этапы:

1. Планирования цикла

2. Анализ рисков.

Схема:

…

…

Преимущества:

1. Неполное завершение работ на каждом этапе, позволяет переходить на следующий, не срывая сроки.

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

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

Недостатки:

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

2. Структура разрабатываемого программного обеспечения не всегда несет целостную идею.

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

В инкрементной стратегии не происходит переопределение требований.

 

24.09.2012.

Подготовительная работа

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

1. Написание экономического образования (бизнес план) проекта.

2. Определение границ проекта

3. Некоторый начальный анализ, для оценки его размера.

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

Анализ требований к системе

Под собой подразумевает:

1. Определение ее функциональных возможностей.

2. Пользовательских требований.

3. Требований к надежности.

4. Требования к безопасности.

5. Требования к расширяемости.

6. Требования к масштабируемости.

7. И другим потребительским характеристикам.

 

Базис языка UML

В состав выразительных средств языка UML входят три разновидности строительных блоков:

1. Предметы – это абстракции, которые являются основными элементами в моделях.

2. Отношения – связывают предмет.

3. Диаграммы – группируют коллекции предметов.

Замечание:

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

Предметы

Есть 4 разновидности предметов:

1. Структурные предметы.

2. Предметы поведения.

3. Группирующие предметы.

4. Поясняющие предметы.

Структурные предметы

Структурные предметы являются существительными в UML моделях. Они представляют статические части моделей. К ним относятся:

1. Класс – описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантика (смысл).

2. Интерфейс – набор операций, которые определяют услуги класса или компонента. Описывает поведение элемента видимое извне.

3. Кооперация (сотрудничество) – определяет взаимодействие объектов и является совокупностью их ролей и других элементов, совместно обеспечивающих коллективное поведение.

4. Актер – набор согласованных ролей, в которые могут играть пользователи, при взаимодействии с системой. Каждая роль требует от системы определенного поведения.

5. Вариант использований (прецедент – элемент «use case») – описание последовательности действий, выполняемых системой в интересах отдельного актера и производящий видимый для актера результат.

6. Активный класс – это класс, чьи объекты имеют один или несколько процессов и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс, но его объекты действуют одновременно с объектами других классов.

7. Компонент – это физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов (обычно это физическая упаковка различных логических компонентов). Компонентами выступают не только написанные, но и используемые извне.

8. Узел – это физический элемент, который существует в период работы системы и представляет ресурс (устройство).

Предметы поведения.

Предметы поведения – это динамические части UML моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Разновидности:

1. Взаимодействие – поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Элементами взаимосвязи являются сообщения, последовательность действий и связи.

2. Конечный автомат – поведение, которое определяет последовательность состояний объекта или взаимодействия, выполняемое в ходе его существования в ответ на его событие. Соответственно элементами конечного автомата являются состояния, переходы, события и действия (реакция на переход).

Группирующие предметы.

Группирующие предметы – организационные части UML моделей, по которым может быть «разложена» модель.

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

Поясняющие предметы.

Поясняющие предметы – разъясняющие части UML моделей, являются замечаниями, которые можно применить для описания объяснения и комментирования любого элемента модели.

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

 

 

Практика

1.10.2012

Отношения

Разновидности:

1. Зависимость – это семантическое отношение между двумя предметами, в котором, изменения в одном предмете, независимом, может влиять на семантику другого предмета, зависимого.

2. Ассоциация – это структурное отношение, которое описывает набор связей, являющихся соединениями между объектами. Агрегация и композиция являются разновидностями ассоциации.

3. Обобщение – это отношение специализации-обобщения, в котором объекты специализируемого элемента (потомка), могут заменять объекты обобщенного элемента (предка).

4. Реализация – это семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнить. К классификатором относятся:

a. Классы

b. Интерфейсы

c. Компоненты

d. Варианты использования

e. Кооперации.

Диаграммы

Диаграмма – это графическое представление некоторого множества элементов модели. Чаще изображается как связный граф из вершин предметов и дуг отношений. Разные диаграммы визуализируют систему с разных точек зрений.

Диаграмма является лишь средством визуализации элементов модели (в модели могут существовать элементы, не отображенные ни на одной диаграмме).

Теоретически UML диаграмма может содержать любую комбинацию предметов и отношений. На практике ограничиваются малым количеством комбинаций.

Разновидности:

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

2. Диаграмма объектов (Object Diagram) – показывает набор объектов и их отношений. Диаграмма объектов представляет статический «моментальный снимок» с экземпляров объектов, которые находятся в диаграмме классов. Диаграмма объектов является статической диаграммой.

3. Диаграмма вариантов использования (диаграмма прецедентов – Use Case Diagram) – показывает набор вариантов использования, актеров и их отношений. Создается статическое представление использования. Часто используется при организации и моделировании поведения системы, задания требований заказчика к системе.

4. Диаграмма взаимодействия (Interaction Diagram) – показывает взаимодействия включающие набор объектов и их отношений, а также пересылаемые между объектами сообщения. Обеспечивают динамическое представление систем.

a. Диаграмма последовательности (Sequence Diagram) – это диаграмма взаимодействия, которая выделяет упорядоченные сообщения по времени.

5. Диаграмма сотрудничества или кооперации – это диаграмма взаимодействия, которая выделяет структурную организацию объектов посылающих и принимающих сообщения.

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

7. Диаграмма деятельности (Activity Diagram) – специальная разновидность диаграмм схем состояний, которая показывает поток от действия к действию внутри системы. Особенно важны при моделировании функциональности системы и выделяют поток управления между объектами.

8. Компонентная диаграмма – показывает организацию набора компонентов и зависимости между компонентами. Обеспечивают статическое представление реализации системы.

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

Механизмы расширения в UML

Механизмами расширения в UML являются:

1. Ограничения (Constrain) – расширяет семантике строительного UML блока, позволяя добавлять новые правила или модифицировать существующие. Показывается как текстовая строка, заключенная в фигурные скобки.

2. Теговая величина (Tag value) – расширяет характеристики строительного UML блока, позволяя создать новую информацию в спецификации конкретного элемента.

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

 

08.10.2012

Диаграмма вариантов использования.

Диаграмма вариантов использования (Диаграмма Use case) – определяет поведение системы с точки зрения пользователя, не рассматривая внутреннюю структуру. Рассматривается как главное средство для первичного моделирования динамики системы. Используется для выяснения требований к системе и фиксация в форме – позволяющая проводить дальнейшую разработку.

В состав диаграммы входит:

1. Вариант использования – описывает, что должна делать система, но не описывает, как она должна это делать.

 

2. Актер – это роль, которую пользователь играет по отношению к системе. Один актер может использовать несколько вариантов использования и наоборот.

 

3. Между актером и вариантом использования может быть только один вид отношения – ассоциация.

 

4. Между актерами допустимо отношение обобщение. Отношение обобщение фиксирует, что потомок наследует поведения родителя.

 

5. Стереотипы для ассоциации:

a. « include» – отношение включения между вариантами использования означает что базовый вариант использования явно включает поведения другого варианта использования.

 

b. « extend» – отношение расширения между вариантами использования означает, что базовый вариант использования неявно включает поведение другого варианта использования. Базовый вариант использования может быть автономен, но при определенных условиях, его поведение может расширяться поведением из другого варианта использования. Таким образом, можно отделить обязательное поведение системы от необязательного.

 

Динамические модели

Динамические модели обеспечивают представление поведение систем.

Диаграммы схем состояний

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

Диаграмма состояний показывает:

1. Набор состояний системы.

2. События, которые вызывает переход из одного состояния в другое.

3. Действие которое происходит в результате изменения состояния.

Компоненты:

Состояние отображается в виде овала.

Начальное состояние

Конечное состояние

- состояние является составным.

Пример:

…

Семантика вложенности следующая:

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

15.10.12

Диаграмма деятельности

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

Компоненты:

1. - прямоугольник с закруглёнными углами.

2. - объединение

3. - решение

4. - линейнось синхронизации

5. - начало

6. - конец

7. - переход

Пример:

…

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

Вершина «Объединение» отмечает точку объединения альтернативных потоков действия

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

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

Существует две разновидности:

1. Диаграмма последовательности

2. Диаграмма сотрудничества.

Диаграмма сотрудничества

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

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

Пример записи имени:

Объект: класс

(объект сирота – нету класса)

Свойство записывается следующим образом:

имя: Тип =значение

Пример:

номер:Телефон= «1234567»

активен =true

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

Связь это путь для пересылки сообщений. Путь может быть снабжен характеристикой видимости. В UML есть следующие стереотипы видимости:

1. «global» – объект поставщик находится в глобальной области видимости

2. «local» – объект поставщик находится в глобальной области видимости клиента.

3. «parameter» – объект поставщик является параметром операций объекта клиента

4. «self» – когда один и тот же объект является и клиентом и поставщиком.

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

Прием сообщения это событие

Разновидности действий:

1. Вызов – в объекте запускается операция.

2. Возврат – возврат значения в вызывающий объект.

3. Посылка (Send) – в объект посылается сигнал.

4. Создание – создание объекта по стандартному сообщению «create»

5. Уничтожение - уничтожение объекта по стандартному сообщению «destroy»

возвращаемое значение:= имя сообщения (аргументы)

Пример:

координаты:= текущее положение (самолет)

оповещение()

установитьМаршрут(x)

«create»

…

…

 

22.10.12

29.10.12

Комментарии

Когда следует ставить комментарий:

1. Комментарии следует ставить в процессе написания программы.

2. Делайте комментариев чуть больше, чем это кажется необходимым.

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

Три типа комментариев:

1. Вводный комментарий. Заголовочный комментарий может включать следующие пункты:

a. Назначение программ.

b. Указание по вызову программы и ее использование.

c. Список и назначение основных переменных или массива.

d. Указание по вводу/выводу список всех файлов.

e. Список используемых подпрограмм.

f. Назначение переменных и математических методов.

g. Сведенье о времени выполнения программы.

h. Требуемый объем памяти

i. Специальные указания оператора

j. Сведенье о авторе

k. Дата написания программы.

l. Версия программы

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

05.11.12

Отношение эффективности.

В отношении к эффективности можно выделить три типа программ:

1. Часто используемые программы:

a. Операционные системы.

b. Компиляторы.

c. Трансляторы.

d. Графические библиотеки.

e. Средство сжатия данных.

f. Некоторые прикладные программы.

Для таких программ эффективность является первостепенной задачей.

2. Производственные программы – написанные профессиональными программистами, эксплуатируемые долгое время. Хотя эффективность таких программ существенна, обычно больше внимания уделяется их эксплуатационным характеристикам.

3. Программы написанные не программистами, а научными сотрудниками.

Очевидно, что следует модифицировать, только те программы, которые многократно используются. Методы, делающие программу эффективнее, могут существенно влиять на ее удобочитаемость. А очень часто удобочитаемость важнее ее эффективности.

Ошибки

Виды ошибок:

1. Ошибки в описании задач – связанные с отсутствием взаимопонимания между исполнителем и заказчиком и качественным определением требований.

2. Ошибки в выборе алгоритма – неэффективный алгоритм может существенно снизить качество продукта или привести к перепрограммированию.

3. Ошибки анализа – связанны с неполным отчетом возникающих ситуаций, мелкие и крупные логические ошибки:

a. Отсутствие заданий начальных значений.

b. Неверное условие окончания цикла.

c. Отсутствие задание обнуления цикла.

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

5. Синтаксические. Ошибки, вызванные неправильным написанием операторов.

6. Семантическая ошибка – неправильное использование написанных операторов.

7. Ошибки данных.

 

12.11.12

Отладка

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

Тестирование ПО – это процесс выявления несоответствия работы программы, при ее выполнении на некотором наборе данных, для которого заранее известен результат.

Отладка это – тестирование плюс поиск ошибок, плюс редактирование.

1. Считайте тестирование ключевой задачей разработки программного обеспечения. Поручайте его самым квалифицированным и одаренным программистам. Не желательно тестировать свою собственную программу.

2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

3. Готовьте тесты как для правильных, так и для неправильных данных.

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

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

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

Советы по организации тестирования:

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

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

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

19.11.12

Методы оптимизации

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

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

 

24.11.12.

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

1. Производительность компонентов.

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

2. Взаимодействие программы с операционной системой.

Низкая производительность разрабатываемой системы может быть связана с слишком частым обращением к операционной системе.

3. Компиляция кода

Хорошие компиляторы преобразуют ясный высокоуровневый код в оптимизированный машинный код.

4. Оборудование

5. Оптимизация кода

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

Принцип Парето – известен как «правило 80 на 20». Гласит, что 80 процентов результата, можно получить приложив 20 процентов усилий. Менее 4% кода соответствуют более, чем 50% времени выполнения.

При оптимизации кода нужно найти «горячие точки» и сосредоточиться на их оптимизации большее всего.

Заблуждение относительно оптимизации кода:

1. Сокращение числа строк высокоуровневого кода повышает быстродействие и уменьшает объем итогового машинного кода.

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

3. Оптимизацию следует выполнять по мере написания программы.

4. Быстродействие программы не менее важно, чем ее корректность.

Частые причины снижения эффективности:

1. Операции ввода вывода.

2. Системные вызовы – обращение к сети, прослушивание событий. Если вас не устраивает скорость выполнения системных вызовов, напишите свои.

3. Ошибки.

Оценка производительности

При оценке производительности нужно опираться на фактические показатели, а не на собственные ощущения.

 

26.11.12.

1. …

2. …

3. …

… неадекватный проект, неудачные технологии, неправильный алгоритм.

Оптимизируйте узкое место, определенное на этапе б):

a. Оцените каждое улучшение по одному за раз.

b. Если оптимизация не привела к улучшению, вернутся к сохраненному коду на этапе а).

4. Повторите процесс начиная с пункта 2.

Тестирование. Философия тестирования.

Тестирование – это процесс выполнения программы с целью обнаружения ошибок.

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

Экономика тестирования

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

Основные принципы тестирования:

1. Описание предполагаемых значений выходных данных или результатов, должно быть необходимой частью тестового набора.

2. Следует избегать тестирования программы ее автором.

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

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

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

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

7. Нельзя планировать тестирование в предположении, что ошибки ну будут обнаружены.

8. Вероятность наличия необнаруженных ошибок в части программы, пропорциональны числу ошибок уже обнаруженным ошибок в этой части.

9. Тестирование процесс творческий.

Типы ошибок и ручные методы тестирования.

Классификация ошибок.

По времени появления ошибки можно разделить на три вида:

1. Структурные ошибки.

2. Ошибки компиляции.

3. Ошибки периода выполнения.

В теоретической информатике, программные ошибки классифицируются по степени нарушения логики:

1. Синтаксические

2. Семантические

3. Прагматические

Классификация ошибок, основанных на опыте:

1. Ошибка адресации.

2. Ошибка ввода-вывода.

3. Ошибка вычисления.

4. Ошибка интерфейса

5. Ошибки обращения к данным.

6. Ошибки описания данных.

 

03.12.12

…

Стратегии белого ящика:

1. Покрытие операторов – если отказаться полностью от тестирования всех путей, то можно показать, что критерием покрытия является выполнение каждого оператора программы, по крайней мере один раз

2. Покрытие решений – предполагает выполнение достаточного количества тестов, чтобы каждое решение на этих тестах принимала значение истина или ложь по крайней мере один раз.

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

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

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

Стратегии черного ящика:

1. Эквивалентное разбиение требует выбора такого теста, который обладает двумя свойствами:

a. Уменьшать больше чем на единицу число других тестов, которые должны быть разработаны, для достижения заранее определенной цели, «приемлемого» тестирования

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

2. Анализ граничных значений – предполагает тестирование граничных условий. Граничные условия, это ситуации, возникающие непосредственно на выше или ниже границ классов и эквивалентности. Отличается от предыдущего в двух отношениях:

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

b. При разработке тестов рассматриваются не только входные условия (пространство входов) но и выходные (пространство результатов).

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

Этапы:

a. Спецификация разбивается на рабочие участки.

b. Определяются причины и следствия. Причины это входное условие, а следствие это выходное

c. Анализируется содержание спецификаций, которая преобразуется в булевский граф, связывающий причины и следствия.

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

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

f. Столбцы таблицы решений преобразуются в тесты.

4. Предположение об ошибке.

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

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

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

Сравнение восходящих и нисходящих.

 

10.12.12

Нисходящая тестирование. Преимущества:

1. Эффективней, если ошибки преимущественно в верхней части программы.

2. Представление теста облегчается после подключения функции ввода и вывода.

3. Ранее формирования структуры программы позволяет провести ее декомпозицию и служит моральным стимулом.