Выявление ошибок системных компонентов это

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

Меры по обнаружению ошибок можно разбить на две подгруппы:

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

Пассивное обнаружение ошибок

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

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

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

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

3. Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

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

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

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

· Проверяйте, находится ли входное значение в установленных пределах. Например, если входной элемент — адрес в основной памяти, проверяйте его

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

· Проверяйте допустимость всех вариантов значений. Если входное поле — код, обозначающий один из десяти районов, никогда не предполагайте, что если это не код ни одного из районов 1, 2,…, 9, то это обязательно код района 10.

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

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

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

Когда разрабатываются меры по обнаружению ошибок, важно принять согласованную стратегию для всей системы (т.е. применить идею концептуальной целостности). Действия, предпринимаемые после обнаружения ошибки в программном обеспечении (например, возврат кода ошибки), должны быть единообразными для всех компонент системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение — немедленно завершить выполнение программы или (в случае операционной системы) перевести ЦП в состояние ожидания. С точки зрения предоставления человеку, отлаживающему программу, например системному программисту, самых благоприятных условий для диагностики ошибок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом. Такой метод использован в операционной системе OS/VS2MVS фирмы IBM. Каждая компонента содержит программу восстановления, которая перехватывает все случаи ненормального

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

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

Пример: система PRIME

Система PRIME-это мультипроцессорная система с виртуальной памятью, разработанная в Калифорнийском университете в Беркли. Один из процессоров системы выделен в качестве центрального процессора и содержит центральный управляющий монитор (ССМ — central control monitor) — управляющую программу, которая распределяет страницы памяти и пространство на диске, назначает программы другим процессорам (проблемным процессорам) и регулирует пересылки всех межпроцессорных сообщений. Расширенный управляющий монитор (ЕСМ — extended control monitor) — это реализованная микропрограммно-управляющая программа, постоянно присутствующая в каждом процессоре и управляющая диспетчеризацией процессов, операциями ввода-вывода и посылки / получения.

Защита данных — одна из основных целей системы. В этом направлении в системе PRIME сделан шаг вперед по сравнению с большинством других систем: в дополнение к обеспечению защиты в нормальных условиях ставится цель гарантировать защиту даже при наличии отдельной ошибки в программном обеспечении или отдельного сбоя аппаратуры. Меры по обнаружению ошибок составляют основу метода достижения этой цели.

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

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

Система PRIME содержит механизм посылки / получения, который позволяет процессу одного пользователя послать сообщение процессу другого пользователя. Для этого процесс-отправитель передает своему ЕСМ это сообщение и идентификатор процесса-получателя. ЕСМ добавляет идентификатор отправителя и передает сообщение ССМ. Тот передает сообщение ЕСМ процессора, содержащего процесс-получатель, а ЕСМ наконец передает сообщение указанному процессу пользователя. В этой последовательности выполняются три проверки с целью обнаружения ошибки. ССМ проверяет, правильный ли идентификатор процесса-отправителя добавлен ЕСМ; он может это сделать, поскольку известно, какому пользователю выделен процессор. ЕСМ адресата проверяет, тому ли процессору ССМ направил сообщение; он выполняет это, сравнивая идентификатор процесса в сообщении с идентификатором процесса, которому в данный момент выделен процессор. Третья проверка делается для обеспечения сохранности сообщения при транзите. ЕСМ-отправитель формирует для сообщения контрольную сумму и передает ее вместе с сообщением. ЕСМ-получатель вычисляет контрольную сумму доставленного сообщения и сравнивает с извлеченной из сообщения.

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

Активное обнаружение ошибок

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

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

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

Диагностический монитор можно реализовать как периодически выполняемую задачу (например, она планируется на каждый час) либо как задачу с низким приоритетом, которая планируется для выполнения в то время, когда система переходит в состояние ожидания. Как и прежде, выполняемые монитором конкретные проверки зависят от специфики системы, но некоторые идеи будут понятны из примеров. Монитор может обследовать основную память, чтобы обнаружить блоки памяти, не выделенные ни одной из выполняемых задач и не включенные в системный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск «затерявшихся» внутри системы сообщений или операций ввода-вывода, которые необычно долгое время остаются незавершенными, участков памяти на диске, которые не помечены как выделенные и не включены в список свободной памяти, а также различного рода странностей в файлах данных.

Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вызывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время выполнения. Монитор может также периодически предъявлять системе «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.

Пример: программа обнаружения разрушений, разработанная фирмой TRW

Система защиты ресурсов фирмы IBM — это экспериментальная модификация операционной системы OS/360 для изучения проблем, связанных с системами защиты. Используя ее, корпорация TRW разработала монитор, действующий в заранее установленные интервалы времени и пытающийся обнаружить признаки того, что программа пользователя нарушила правила защиты.

Этот монитор проверяет много различных условий. Большинство из них характерно именно для OS/360 и поэтому интересны не для всех. В качестве некоторых примеров, можно, однако, указать, что монитор определяет, вся ли управляющая информация OS/3CO о задачах пользователя хранится в защищенной области памяти. Монитор также проверяет, всели программы пользователя выполняются в режиме задачи и вся ли память пользователя защищена от выборки соответствующим ключом защиты. Монитор контролирует правильность соблюдения очереди ожидающими операциями ввода-вывода и гарантирует, что точки входа для всех прерываний являются соответствующими входами OS/360 и что вся память супервизора надлежащим образом

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

Содержание

Введение………………………………………………………………………….5

Тема 3.1 Организация тестирования в
команде разработчиков………………6

Цели и область тестирования……………………………………………………6

Коммуникация и взаимодействие в процессе
тестирования………………….8

Методология тестирования………………………………………………………9

Тестовые среды………………………………………………………………….10

Документированность процесса тестирования………………………………..12

Методология тестирования сложных систем………………………………….13

Тема 3.2 Тестирование web-приложений………………………………………15

Особенности тестирования web-приложений…………………………………15

Тестирование пользовательского интерфейса.
……………………………….17

Ручное тестирование…………………………………………………………….18

Тема 3.3 Организация тестирования
информационных систем……………19

Основные этапы тестирования……………………………………………….19

Функциональное  тестирование………………………………………………21

Структурное тестирование……………………………………………………23

Тестирование покрытия программного кода………………………………..24

Тестирование скорости загрузки системы…………………………………..26

Тестирование функциональных требований.
Комплексное тестирование..28

Тестирование граничных условий……………………………………………31

Тестирование утечки памяти………………………………………………….32

Тема 3.4 Тестирование отдельных модулей…………………………………33

Инструментарии анализа качества
программных продуктов в среде разработке………………………………………………………………………34

Выявление ошибок системных компонентов………………………………..35

Методы идентификации сбоев и ошибок……………………………………37

Автоматизация тестирования в продуктивной
среде……………………….39

Тема 3.5 Реинжиниринг бизнес-процессов в
информационных системах..41

Сущность реинжиниринга бизнес-процессов.
Этапы реинжиниринга……41

Изучение методологии структурного
системного анализа…………………42

Основные методологии обследования
организаций………………………..44

Особенности национальной практики
применения функционального моделирования ………………………………………………………………..45

Причины реинжиниринга информационных
систем……………………….46

Список использованных
источников………………………………………..48

Введение

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

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

·       
автономное тестирование компонентов
программного обеспечения;

·       
комплексное тестирование разрабатываемого
программного обеспечения;

·       
системное или оценочное тестирование на
соответствие основным критериям качества.

Для
повышения качества тестирования рекомендуется соблюдать следующие основные
принципы:

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

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

·       
досконально изучать результаты каждого
теста;

·       
необходимо проверять работу программы на
неверных данных;

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

Формирование
набора тестов имеет большое значение, поскольку тестирование является одним из
наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания
программного продукта. Существуют два принципиально разных подхода к
формированию тестовых наборов – структурный и функциональный.

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

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

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

Тема
3.1 Организация тестирования в команде разработчиков

Цели
и область тестирования

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

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

Термин
«отладка» в отечественной литературе используется двояко: для обозначения
активности по поиску ошибок (собственно тестирование), по нахождению причин их
появления и исправлению, или активности по локализации и исправлению ошибок.

Тестирование
— это процесс выполнения ПО системы или компонента в условиях анализа или
записи получаемых результатов с целью проверки (оценки) некоторых свойств
тестируемого объекта.

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

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

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

Тестирование
обеспечивает:

·       
Обнаружение ошибок.

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

·       
Демонстрацию реализации требований к
характеристикам программы.

·       
Отображение надежности как индикатора
качества программы.

Тестирование
не может показать отсутствие дефектов (оно может показывать только присутствие
дефектов). Важно помнить это утверждение при проведении тестирования.

Тестирование
— важная часть любой программы контроля качества, а зачастую и единственная.
Это печально, так как разнообразные методики совместной разработки позволяют
находить больше ошибок, чем тестирование, и в то же время обходятся более чем
вдвое дешевле в расчете на одну обнаруженную ошибку. Каждый из отдельных этапов
тестирования (блочное тестирование, тестирование компонентов и интеграционное
тестирование) обычно позволяют найти менее 50% ошибок. Комбинация этапов
тестирования часто приводит к обнаружению менее 60% ошибок.

Коммуникация
и взаимодействие в процессе тестирования

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

Аккаунт-менеджер
— менеджер по работе с клиентами, специалист, который работает с клиентами
компании и обеспечивает их лояльность. Аккаунт-менеджер обеспечивает выполнение
всех необходимых клиенту задач, находит к каждому заказчику индивидуальный
подход, поддерживает с ним хорошие отношения (даже после того, как все заказы
уже выполнены), предлагает ему новые услуги и продукты. Иными словами,
профессия аккаунт-менеджера обязывает ее представителя сделать все возможное,
чтобы клиент был счастлив, работал с компанией всегда и всем ее рекомендовал.

Менеджер
проекта (Project manager, руководитель проекта, проект-менеджер; сокращенно —
PM, ПМ, РП) — лицо, ответственное за управление проектом. Менеджер проекта
несет ответственность за достижение целей проекта в рамках бюджета, в срок и с
заданным уровнем качества.

Системный
аналитик (аналитик) является “мостиком” между заказчиком и членами команды.
Переводит пожелания заказчика в формат точно описанных технических заданий. 

Системный
архитектор (архитектор) проектирует разрабатываемую систему на самом верхнем
уровне и принимает ключевые решения по поводу технологий и методологий
разработки. Активно занимается исследованиями и экспериментами, рисует
многочисленные диаграммы и документирует архитектурные решения.

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

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

QA-специалист
— специалист, который обеспечивает качество продукта (тестирует, контролирует и
управляет качеством продукта).

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

QA
lead (ведущий специалист по управлению и контролю качества) — QA-специалист,
который руководит командой тестирования.

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

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

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

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

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

·
Интеграционное тестирование — это совместное выполнение двух или более классов,
пакетов, компонентов или подсистем, созданных несколькими программистами или
группами.

·
Регрессивным тестированием называют повторное выполнение тестов, направленное
на обнаружение дефектов в программе, уже прошедшей этот набор тестов.

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

Фазы
тестирования.

Реализация
тестирования делится на три этапа:

1.
Создание тестового набора (test suite) путем ручной разработки или
автоматической генерации для конкретной среды тестирования (testing
environment).

2.
Прогон программы на тестах, управляемый тестовым монитором (test monitor, test
driver) с получением протокола тестирования (test log).

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

Тестовые
среды

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

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

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

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

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

Документированность
процесса тестирования

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

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

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

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

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

В
тестовом плане определяются и документируются различные типы тестов. Типы
тестирования по виду подсистемы или продукта таковы:

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

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

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

Методология
тестирования сложных систем

Тестирование
сложных программных решений и комплексных систем.

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

Эффективно
начинать тестирование комплексных (и других) систем на ранних стадиях
разработки ПО.

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

Тестирование
на протяжении процесса разработки сложной структуры из модулей выполняется на
нескольких уровнях. Для каждого определяются категория объектов тестирования
(ПС, компоненты, отдельные модули) и набор проверяемых тестируемых характеристик.

На
каждом уровне тестирование повторяется многократно, образуя циклы: тестирование
— исправление — повторное тестирование.

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

Тестирование
имеет много общего с процессами верификации и валидации (V& V). Общность
процесса тестирования с процессами V& V заключается в единстве состава и
структуры планов, рекомендуемых стандартом IEEE Std. 829, а также объектов и
применяемых методов. Отличие этих процессов состоит в условиях их применения.
Тестирование выполняется всегда, для всех объектов ПО системы независимо от ее
критичности. Процессы V&.V в современной трактовке стандартов IEEE Std.
1012 и ISO/IEC 12207 — поддерживающие процессы, которые могут применяться к
выбранным объектам тестирования для проверки планов тестирования и
подтверждения того, что выполненное тестирование адекватно уровню критичности
ПС. По отношению к процессу тестирования V&V выполняет контрольную функцию
и подтверждает соответствие объектов установленным требованиям.

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

Традиционно
выделяются три уровня тестирования ПО: автономное или модульное (unit testing),
интеграционное (integrating testing) и системное (system testing). В стандарте
ISO/IEC 12207 прослеживаются четыре уровня тестирования:

•
модульное (в процессе «Построение ПО»);

•
интеграционное (в процессе «Сборка ПО»);

•
тестирование ПС (как процесс);

•
системное (в процессе «Испытания ПС»)

Тема
3.2 Тестирование web-приложений

Особенности
тестирования web-приложений

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

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

Тестирование
совместимости – это процесс оценки поведения приложения в различных браузерах,
операционных системах, на устройствах с разным разрешением экрана. Проверка
совместимости продукта со всеми последними версиями браузеров Chrome, Firefox,
MS Edge, Safari и ОС Windows 7, 8 и 10 является примером данного вида
тестирования.

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

·       
Статистические данные по времени отклика с
сервера для наиболее важных операций;

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

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

·       
Информация об устойчивости системы и ее
способности выдерживать постоянную нагрузку;

·       
Статистика ошибок;

·       
Выводы об эффективности системы в целом,
ошибках ее производительности;

·       
Рекомендации по повышению
производительности системы.

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

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

·       
Перевод содержимого страницы и элементов
пользовательского интерфейса;

·       
Формат данных и времени;

·       
Обозначение денежных единиц;

·       
Цветовые схемы, символы, значки и другие
графические элементы, которые могут быть по-разному истолкованы в различных
регионах;

·       
Правовые нормы, которые следует учитывать.

Цель
тестирования соответствия – установить, соответствует ли приложение юридическим
нормам и стандартам, которым подчиняется ваш бизнес. Примером тестирования
соответствия является проверка выполнения рекомендаций Руководства по
обеспечению доступности веб-контента (WCAG). Учет требований данного
Руководства помогает сделать веб-продукт доступным для людей с ограниченными
возможностями.

Тестирование
пользовательского интерфейса.

Графический
интерфейс пользователя (Graphical user interface, GUI) –разновидность
пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки,
значки, списки и т. п.), представленные пользователю на дисплее, исполнены в
виде графических изображений. Проверяется в целом общий вид приложения и в
отдельности формы, расположенные на странице.

Общие
проверки:

·       
Вид элементов при уменьшении окна браузера
+ появление скрола

·       
Правильность написания текста + текст
должен быть выровнен

·       
Правильность перемещения фокуса в окне
(Tab / Tab+Shift)

·       
Выбранные элементы выделяются

·       
Неизменяемые поля выглядят одинаково и
отличаются от редактируемых

·       
Желательно не использовать двойной клик

·       
Проверка наличия нужных нотификейшенов

·       
Унификация дизайна (цвет, шрифт, размер)

·       
При необходимости должны быть тултипы

·       
Изменение вида элемента при ховере на него

·       
Если формы дублируются, то должны быть
одинаковые названия

·       
Дополнительные проверки для веб-форм

Основные
моменты при проверке GUI:

·       
расположение, размер, цвет, ширина, длина
элементов; возможность ввода букв или цифр

·       
реализуется ли функционал приложения с
помощью графических элементов

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

·       
читабелен ли использованный шрифт

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

·       
выравнивание текста и форм 

·       
качество изображений

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

·       
проверить текст на орфографические,
пунктуационные ошибки

·       
появляются ли тултипы (если есть
необходимость)

·       
унификация дизайна (цвета, шрифты, текст
сообщений, названия кнопок и т.д.)

Наиболее
распространенные баги:

·       
курсор не переходит в поинтер при
наведении на активный элемент

·       
орфографические и грамматические ошибки

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

·       
неправильное отображение элементов при
смене размера окна браузера и масштаба страницы

·       
изменение размера текста при смене языка

·       
неровное расположение форм

·       
разные шрифты

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

Ручное
тестирование

Ручное
тестирование (manual testing)  — часть процесса тестирования на этапе контроля
качества в процессе разработки программного обеспечения. Оно производится
тестировщиком без использования программных средств, для проверки программы или
сайта путём моделирования действий пользователя. В роли тестировщиков могут
выступать и обычные пользователи, сообщая разработчикам о найденных ошибках.

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

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

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

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

Тема
3.3 Организация тестирования информационных систем

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

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

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

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

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

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

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

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

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

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

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

Функциональное 
тестирование

Существуют
2 основных принципа тестирования программ:

1)
функциональное тестирование (тестирование черного ящика);

2)
структурное тестирование (тестирование белого ящика).

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

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

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

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

Тестирование
функциональности может проводиться в двух аспектах:

●     требования

●     бизнес-процессы

Тестирование
в перспективе «требования» использует спецификацию функциональных требований к
системе как основу для дизайна тестовых случаев (Test Cases). В этом случае
необходимо сделать список того, что будет тестироваться, а что нет,
приоритезировать требования на основе рисков (если это не сделано в документе с
требованиями), а на основе этого приоритезировать тестовые сценарии (test
cases).

Это
позволит сфокусироваться и не упустить при тестировании наиболее важный
функционал.

Тестирование
в перспективе «бизнес-процессы» использует знание этих самых бизнес-процессов,
которые описывают сценарии ежедневного использования системы. В этой
перспективе тестовые сценарии (test scripts), как правило, основываются на
случаях использования системы (use cases).

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

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

Принципы
безопасности программного обеспечения: 

Общая
стратегия безопасности основывается на трех основных принципах:

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

Целостность
— существует два основных критерия при определении понятия целостности:

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

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

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

Структурное
тестирование

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

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

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

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

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

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

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

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

1)
гарантируется проверка всех независимых маршрутов программы;

2)
проверяются ветви TRUE и FALSE для всех логических решений;

3)
выполняются все циклы в пределах их границ и диапазонов;

4)
анализируется правильность внутренних структур данных.

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

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

Существует
несколько различных способов измерения покрытия:

·       
покрытие операторов — каждая ли строка
исходного кода была выполнена и протестирована;

·       
покрытие условий — каждая ли точка решения
(вычисления истинно ли или ложно выражение) была выполнена и протестирована;

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

·       
покрытие функций — каждая ли функция
программы была выполнена;

·       
покрытие вход/выход — все ли вызовы
функций и возвраты из них были выполнены.

·       
покрытие значений параметров — все ли
типовые и граничные значения параметров были проверены.

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

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

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

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

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

Тестирование
скорости загрузки системы

Хорошая
скорость загрузки страницы — 0.35–0.38 секунд. Такие результаты показывают
сайты в топе выдачи. Чтобы посчитать это время, нужно измерить так называемую
«скорость ответа сервера» — как быстро он реагирует на запрос клиента
(браузера).

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

Google
PageSpeed Insights бесплатно измеряет скорость загрузки и на мобильных, и на
стационарных устройствах. Рейтинг определяется по 100-балльной шкале: чем
больше баллов, тем лучше. Если ваш сайт получил более 85, значит, все хорошо.
Не стремитесь получить 100 баллов. Это не удается даже сервисам Google.

Яндекс.Вебмастер

Посмотреть
скорость ответа сервера на запрос робота «Яндекса» можно с помощью инструмента
webmaster.yandex.ru. Он покажет время ответа в миллисекундах: Если код ответа —
«200 ОК», с сайтом все в порядке. Если какой-то другой («404 Not Found», «301
Moved Permanently»), у вас проблемы. Как и у Google, у «Яндекса» это бесплатный
сервис, которым можно пользоваться без регистрации и глубокого понимания
бекенда.

Pingdom

Сервис
pingdom.com предоставляет более подробную информацию для тестирования сайтов,
чем перечисленные выше. Кроме оценки общей скорости сайта, Pingdom покажет, с
какой скоростью загружается каждый элемент страницы. Если на сайте возникли
неполадки, Pingdom пришлет уведомление. Есть приложения для Android и iOS,
чтобы вы следили за скоростью ресурсов в режиме реального времени. Сервис
собирает статистику скорости за период времени и предоставляет подробный отчет
об ошибках. Самый большой минус Pingdom — то, что сервис платный.

Sitespeed.ru

Еще
один популярный инструмент в рунете — sitespeed.ru. Интерфейс простой и
понятный: пишешь URL, запускаешь тест, получаешь результат. Сервис дает
подробное описание, как справиться с каждой проблемой сайта. Еще одна любопытная
функция — каскадная диаграмма загрузки сайта: вы видите, сколько времени
загружается каждый объект: скорость загрузки сайта speedtest. Если оставить
почту на сайте, вам пришлют красивый подробный отчет по результатам
тестирования. И все это абсолютно бесплатно.

GTmetrix
позволяет легко определить производительность вашего сайта. Просто вставьте URL
на главную страницу и получите данные о скорости загрузки и рекомендации, как
исправить ошибки. Тестировать скорость можно из нескольких регионов. Кроме того,
сервис анализирует эффективность ресурса на мобильных устройствах. До трех URL
можно мониторить бесплатно. Больше сайтов можно подключить на премиум-тарифах
(от $14,95 в месяц). Они включают и другие интересные возможности, например,
брендированные отчеты о скорости сайта и запись видео с загрузкой, чтобы
увидеть узкие места в режиме реального времени.

YSlow

YSlow
анализирует веб-страницы и определяет, что идет не так по правилам Yahoo для
высокопроизводительных сайтов. Это расширение, которое можно установить на
популярные браузеры: Firefox, Chrome, Opera, Safari. Сервис бесплатный сервис и
с открытым кодом. YSlow оценивает веб-страницу, обобщает компоненты и
статистику, предлагает улучшения и предоставляет инструменты для анализа
производительности.

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

Тестирование
функциональных требований. Комплексное тестирование

Комплексное
тестирование — процесс поиска несоответствия системы ее исходным целям. В процессе
тестирования участвует система, описание целей продукта и вся документация,
поставляемая вместе с системой.

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

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

2.
Тестирование объема представляет собой попытку предъявить системе большие
объемы данных в течение более длительного времени, чем п. 1. На вход
компилятора следует подать огромную программу (например, программу обработки
текстов). Очередь заданий операционной системы следует заполнить до предела.
Цель — показать, что система не может обрабатывать данные в количествах,
указанных в их спецификациях.

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

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

5.
Тестирование защиты. К большинству систем предъявляются определенные требования
по обеспечению защиты от несанкционированного доступа. Цель тестирования защиты
— нарушить секретность в системе. Один из методов — нанять профессиональную
группу «взломщиков», т. е. людей с опытом разрушения средств обеспечения защиты
в системах. Одним из путей разработки подобных тестов является изучение
известных проблем защиты в этих системах и генерация тестов, которые позволяют
проверить, как решаются аналогичные проблемы в тестируемой системе.

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

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

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

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

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

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

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

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

14.
Тестирование удобства установки.

15.
Тестирование удобства эксплуатации.

Не
все из перечисленных 15 пунктов применимы к тестированию всякой системы
(например, когда тестируется отдельная прикладная программа), но тем не менее
это перечень вопросов, которые разумно иметь в виду.

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

Тестирование
граничных условий

Граничные
значения — это те места, в которых один класс эквивалентности переходит в
другой.

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

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

На
каждой границе диапазона следует проверить по три значения:

·       
граничное значение;

·       
значение перед границей;

·       
значение после границы.

Цель
этой техники — найти ошибки, связанные с граничными значениями.

Алгоритм
использования техники граничных значений:

·       
выделить классы эквивалентности;

·       
определить граничные значения этих
классов;

·       
нужно понять, к какому классу будет
относиться каждая граница;

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

Количество
тестов для проверки граничных значений будет равен количеству границ,
умноженному на 3. Рекомендуется проверять значения вплотную к границе. К
примеру, есть диапазон целых чисел, граница находится в числе 100. Таким
образом, будем проводить тесты с числом 99 (до границы), 100 (сама граница),
101 (после границы).

Тестирование
утечки памяти

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

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

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

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

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

Явный
признак — наличие ошибки OutOfMemoryError в Java или OutOfMemoryException в
.NET. Ее можно найти в логах сервера или приложения, либо сообщение о нем будет
выведено на экран. В разных языках программирования название ошибки может
выглядеть иначе, но смысл её будет прежним — Недостаточно памяти для завершения
операции.

Утечка
памяти может воспроизвестись по-разному, в зависимости от того в какой части
системы она поселилась, а также самой реализации приложения.

Иногда
причина возникновения OutOfMemoryError — это недостаточное выделение памяти
приложению. Допустим для загрузки всех объектов в память требуется 128Мб, а
приложению выделили только 64Мб.

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

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

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

Тема
3.4 Тестирование отдельных модулей

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

Software
Quality Assurance (SQA) — это комплекс мероприятий по обеспечению качества в
процессах разработки программного обеспечения. Это гарантирует, что
разработанное программное обеспечение соответствует и соответствует
определенным или стандартизированным спецификациям качества. SQA — это
непрерывный процесс в рамках жизненного цикла разработки программного
обеспечения (SDLC), который регулярно проверяет разработанное программное
обеспечение, чтобы убедиться, что оно соответствует требуемым показателям
качества.

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

Включает
в себя следующие виды деятельности:

·       
Определение и реализация процесса

·       
Аудиторская проверка

·       
Повышение квалификации

Могут
проводиться процессы:

·       
Методология разработки программного
обеспечения

·       
Управление проектом

·       
Управление конфигурацией

·       
Разработка требований / Управление

·       
Предварительный расчет

·       
Разработка программного обеспечения

·       
Тестирование и др.

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

·       
Выявить слабые места в процессах

·       
Исправить эти недостатки, чтобы постоянно
улучшать процесс

Выявление
ошибок системных компонентов.

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

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

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

·       
сложность ошибок при создании
корректировок компонентов и комплекса программ — статическая сложность, когда
реализуются его требуемые функции, вносятся основные дефекты и ошибки;

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

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

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

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

Методы
идентификации сбоев и ошибок

Ошибка
(error) — состояние программы, при котором выдаются неправильные результаты,
причиной которых являются изъяны (flaw) в операторах программы или в технологическом
процессе ее разработки, что приводит к неправильной интерпретации исходной
информации, следовательно, и к неверному решению.

Дефект
(fault) в программе — следствие ошибок разработчика на любом из этапов
разработки, которая может содержаться в исходных или проектных спецификациях,
текстах кодов программ, эксплуатационной документация и т.п. В процессе
выполнения программы может быть обнаружен дефект или сбой.

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

Отказ
может быть результатом следующих причин:

·       
ошибочная спецификация или пропущенное
требование, означающее, что спецификация точно не отражает того, что
предполагал пользователь;

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

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

·       
программа может быть неправильной, т.е.
она выполняет несвойственный алгоритм или он реализован не полностью.

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

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

·       
логические и функциональные ошибки;

·       
ошибки вычислений и времени выполнения;

·       
ошибки ввода/вывода и манипулирования
данными;

·       
ошибки интерфейсов;

·       
ошибки объема данных и др.

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

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

Автоматизация
тестирования в продуктивной среде

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

Главным
элементом непрерывного тестирования является его автоматизация, что даёт
множество преимуществ:

·       
Быстрое получение обратной связи

·       
Аккуратное и тщательное тестирование

·       
Высокое покрытие тестами

·       
Быстрое обнаружение ошибок

·       
Повторное использование тестов

·       
Более короткие сроки поставки

·       
Адаптация для DevOps

·       
Экономия времени и денег

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

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

Пользовательский
опыт (UX) — Эта область тестирования не может быть автоматизирована. Многие
аспекты UX-проектирования требуют ручного, долгого и утомительного
тестирования. Например, когда разработчики хотят понять, насколько легко
пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы
полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены
вручную.

Стадии
ранней разработки — Когда какая-то функция только-только разрабатывается, в её
код постоянно вносятся изменения, а это может затруднить составление и теста.
На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться
стабильной версии.

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

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

Тема
3.5 Реинжиниринг бизнес-процессов в информационных системах

Сущность
реинжиниринга бизнес-процессов. Этапы реинжиниринга

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

Реинжиниринг
— это фундаментальное переосмысление и радикальное перепроектирование деловых
процессов для достижения резких, скачкообразных улучшений главных современных
показателей деятельности компании, таких, как стоимость, качество, сервис и
темпы (термин «реинжиниринг» ввел М. Хаммер).

Это
определение содержит четыре ключевых слова: «фундаментальный», «радикальный»,
«резкий (скачкообразный)» и «процесс» (наиболее важное слово).

1.
Фундаментальный. На начальной стадии реинжиниринга необходимо ответить на такие
основные вопросы:

·       
почему компания делает то, что она делает?

·       
почему компания делает это таким способом?

·       
какой хочет стать компания?

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

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

3.
Резкий (скачкообразный). Реинжиниринг не применяется в тех случаях, когда
необходимо улучшение либо увеличение показателей деятельности компании на
10-100%, а используются более традиционные методы (от произнесения
зажигательных речей перед сотрудниками до проведения программ повышения
качества), применение которых не сопряжено со значительным риском. Реинжиниринг
целесообразен только в тех случаях, когда требуется достичь резкого
(скачкообразного) улучшения показателей деятельности компании (500-1000% и
более) путем замены старых методов управлении новыми.

Смысл
реинжиниринга бизнес-процессов в двух его основных этапах:

·       
определение оптимального (идеального) вида
бизнес-процесса (в первую очередь основного);

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

Порядок
проведения:

·       
Разработка корпоративной стратегии;

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

·       
Подробный анализ существующих процессов;

·       
Выявление процессов, требующих изменения;

·       
Определение ключевых показателей
эффективности для бизнес-процессов;

·       
Собственно реинжиниринг;

·       
Контроль и постоянное совершенствование
новых процессов на основе ключевых показателей эффективности.

Изучение
методологии структурного системного анализа

Методология
структурного анализа и проектирования ПО определяет шаги работы, которые должны
быть выполнены, их последовательность, правила распределения и назначения
операций и методов. В настоящее время успешно используются такие методологии,
как SADT (Structure Analysis and Design Technique), структурный системный
анализ Гейна-Сарсона, структурный анализ и проектирование Йодана/Де Марко,
развитие систем Джексона и другие.

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

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

Диаграммы
потоков данных в нотации Йодана/Де Марко или Гейна-Сарсона, обеспечивающие
анализ требований и функциональное проектирование информационных систем;

Расширения
Хатли и Уорда-Меллора для проектирования систем реального времени, основанные
на диаграммах переходов состояний, таблицах решений, картах и схемах потоков
управления;

Диаграммы
«сущность-связь» (в нотации Чена или Баркера) для проектирования
структур данных, схем БД, форматов файлов как части всего проекта;

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

Разработка
ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему,
обрабатываются или преобразуются и выходят из системы. Такая модель
используется во всех структурных методологиях. При этом важен порядок
построения модели. Традиционный процедурно-ориентированный подход
регламентирует первичность проектирования функциональных компонент по отношению
к проектированию структур данных: требования к данных раскрываются через
функциональные требования. При подходе, ориентированном на данные, вход и выход
являются наиболее важными – структуры данных определяются первыми, а
процедурные компоненты являются производными от данных.

Основные
методологии обследования организаций

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

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

В
настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

IDEF1
– методология моделирования информационных потоков внутри системы, позволяющая
отображать и анализировать их структуру и взаимосвязи;

IDEF1X
(IDEF1 Extended) – методология построения реляционных структур. IDEF1X
относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship)
и, как правило, используется для моделирования реляционных баз данных, имеющих
отношение к рассматриваемой системе;

IDEF2
– методология динамического моделирования развития систем. В связи с весьма
серьезными сложностями анализа динамических систем от этого стандарта
практически отказались, и его развитие приостановилось на самом начальном
этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные
реализации, позволяющие превращать набор статических диаграмм IDEF0 в
динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN –
Color Petri Nets);

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

IDEF4
– методология построения объектно-ориентированных систем. Средства IDEF4
позволяют наглядно отображать структуру объектов и заложенные принципы их
взаимодействия, тем самым позволяя анализировать и оптимизировать сложные
объектно-ориентированные системы;

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

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

В
последние годы интерес в России к методологиям семейства IDEF неуклонно растет.
Первые Case-средства, позволяющие строить DFD и IDEF0 диаграммы появились на
российском рынке еще в 1996 году.

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

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

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

·       
Что поступает в подразделение “на входе”?

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

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

·       
Чем руководствуется исполнитель при
выполнении каждой из функций?

·       
Что является результатом работы
подразделения (на выходе)?

Причины
реинжиниринга информационных систем

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

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

·       
моральное устаревание информационной
системы (информационных технологий, пользовательских и программных интерфейсов,
используемых в составе ИС);

·       
физическое устаревание информационной
системы (износ ее аппаратных компонентов);

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

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

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

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

Часто
причиной реинжиниринга ИС является реинжиниринг бизнес-процессов. И наоборот,
реинжиниринг ИС часто приводит к РБП. В любом случае, реинжиниринг ИС требует
коррекции бизнес-процессов предприятия.

Первой
волной реинжиниринга информационных систем в нашей стране можно считать
массовый перевод систем с морально устаревшей платформы операционной системы MS
DOS (частично также с MS Windows 3.x) на более современные MS Windows 9x, NT во
второй половине 90-х годов прошлого века. Эта волна также вызвана началом
поставки в Российскую федерацию более новых персональных компьютеров.

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

Список
использованных источников

1.    
Антамошкин, О.А. Программная инженерия.
Теория и практика : учебник /О.А. Антамошкин ; Министерство образования и науки
Российской Федерации, Сибирский Федеральный университет. – Красноярск :
Сибирский федеральный университет, 2012. – 247с. : ил., табл., схем. – Режим
доступа: по подписке. –URL:
http://biblioclub.ru/index.php?page=book&id=363975 – Библиогр.: с. 240. –
ISBN 978-5-7638-2511-4.

2.    
Зубкова, Т.М. Технология разработки
программного обеспечения : учебное пособие / Т.М. Зубкова ; Министерство
образования и науки Российской Федерации, Федеральное государственное бюджетное
образовательное учреждение высшего образования «Оренбургский государственный
университет», Кафедра программного обеспечения

3.    
вычислительной техники и
автоматизированных систем. – Оренбург : ОГУ, 2017. – 469 с. : ил.– Режим
доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=485553
–Библиогр.: с. 454-459. – ISBN 978-5-7410-1785-2

4.    
Извозчикова, В.В. Эксплуатация и
диагностирование технических и программных средств информационных систем :
учебное пособие / В.В. Извозчикова ; Министерство образования и науки
Российской Федерации, Оренбургский Государственный Университет, Кафедра
программного обеспечения вычислительной техники и автоматизированных систем.–
Оренбург : Оренбургский государственный университет, 2017. – 137 с. : ил. –
Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=481761
– Библиогр. в кн. –ISBN 978-5-7410-1746-3.

5.    
Ехлаков, Ю.П. Управление программными
проектами : учебное пособие / Ю.П. Ехлаков ; Министерство образования и науки
Российской Федерации, Томский Государственный Университет Систем Управления и
Радиоэлектроники (ТУСУР). – Томск : Эль Контент, 2014. – 140 с. : схем., табл.
– Режим доступа: по подписке. –
URL:http://biblioclub.ru/index.php?page=book&id=480462 – Библиогр.: с.
128-130. – ISBN 978-5-4332-0163-7.

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

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

        
Доказано,
что инспектирование является эффективным
методом обнаружения ошибок, причем оно
значительно дешевле экстенсивного
тестирования. Инспектированием можно
обнаружить более 60% всех ошибок, а при
более формальном подходе (используя
математические методы) – более 90%.
Процесс инспектирования также может
оценить другие качественные характеристики
систем: соответствие стандартам,
переносимость и удобства сопровождения.

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

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

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

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

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

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

7.2.3. Функциональное тестирование

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

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

В задачи функционального тестирования входят:

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

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

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

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

• корректное оформление требований и ограничений к качеству ПО;
• корректное описание модели функционирования ПО в среде эксплуатации у заказчика;
• адекватность модели ПО заданному классу.

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

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

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

Поэтому предпочтительным является метод «белого ящика», при котором можно использовать структуру объекта для организации тестирования по различным ветвям. Например, можно выполнить тестовые наборы, которые проходят через все операторы или все контрольные точки компонента для того, чтобы убедиться в правильности их работы.

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

Ошибка (error) — состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению.

Дефект (fault) в программе — следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может быть обнаружен дефект или сбой.

Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования [7.6, 7.11]. Отказ может быть результатом следующих причин:

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

• неадекватность спецификации требований конечным пользователям;- некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;
• несоответствие требований заказчика к отдельным и общим свойствам ПО;
• некорректность описания функциональных характеристик;
• необеспеченность инструментальными средствами всех аспектов реализации требований заказчика и др.

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

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

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

• бесконтрольность значений входных параметров, индексов массивов, параметров циклов, выходных результатов, деления на 0 и др.;
• неправильная обработка нерегулярных ситуаций при анализе кодов возврата от вызываемых подпрограмм, функций и др.;
• нарушение стандартов кодирования (плохие комментарии, нерациональное выделение модулей и компонент и др.);
• использование одного имени для обозначения разных объектов или разных имен одного объекта, плохая мнемоника имен;- несогласованное внесение изменений в программу разными разработчиками и др.

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:

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

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

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

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

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

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

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

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

На современном этапе развития средств поддержки разработки ПО (CASE-технологии, объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

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

• идентификация изъянов в технологиях проектирования и программирования;
• взаимосвязь изъянов процесса проектирования и допускаемых человеком ошибок;
• классификация отказов, изъянов и возможных ошибок, а также дефектов на каждом этапе разработки;- сопоставление ошибок человека, допускаемых на определенном процессе разработки, и дефектов в объекте, как следствий ошибок спецификации проекта, моделей программ;
• проверка и защита от ошибок на всех этапах ЖЦ, а также обнаружение дефектов на каждом этапе разработки;
• сопоставление дефектов и отказов в ПО для разработки системы взаимосвязей и методики локализации, сбора и анализа информации об отказах и дефектах;
• разработка подходов к процессам документирования и испытания ПО.

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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