Всё для Учёбы — студенческий файлообменник
1 монета
ppt

Студенческий документ № 050921 из МЭСИ

Методологии ИТ-консалтинга

Калянов Георгий Николаевич

профессор, доктор технических наук

зав. кафедрой "Системный анализ и управление ИТ"

зав. лабораторией Института проблем управления РАН

Kalyanov@mail.ru

http://www.kalyanov.by.ru

Лекция №15

Тестирование бизнес-процессов

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

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

Подобие бизнес-процессов и компьютерных программ:

• в основе обеих объектов лежит понятие алгоритма;

• оба объекта имеют одинаковые этапы жизненного цикла;

• оба объекта могут выполняться как последовательно, так и параллельно;

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

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

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

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

План тестирования должен содержать:

• формулировку целей тестирования;

• критерии качества тестирования, позволяющие оценить его результаты;

• стратегию проведения тестирования, обеспечивающую достижение заданных критериев качества;

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

• Для целей тестирования объект удобно представлять в виде ориентированного графа G = (N, E), где N = (N1, N2, ..., Nm) - множество узлов (вершин), соответствующих функционалу объекта; E = (E1, E2, ..., En) - множество ребер (дуг), соответствующих передачам управления между функциями.

• Путем (маршрутом) называется последовательность вершин и дуг P = (N1, E1,2, N2, E2,3, ..., Ek-1,k, Nk), где каждая дуга Ei,i+1 выходит из Ni и входит в Ni+1, причем N1 не обязательно начальный узел.

• Ветвью называется путь P, в котором N1- либо начальный узел, либо узел ветвления, Nk - либо узел ветвления, либо завершающий узел, все остальные Ni не являются узлами ветвления.

Полное тестирование всех возможных маршрутов не реально

• Поэтому на практике применяются критерии выбора тестов, не гарантирующие полной проверки программы.

• Общим требованием к этим критериям является достижение лишь определенной степени полноты покрытия объекта или его компонент.

• Как правило, эти критерии устанавливают требование по крайней мере однократной проверки всех функций (критерий C0), всех его ветвей (критерий C1), либо всех подпутей специального вида.

• Самым распространенным критерием тестирования является критерий, требующий по крайней мере однократной проверки каждой из ветвей объекта (критерий C1).

• Так, например, тестирование при приемке программного обеспечения для ВВС США производится на основании этого критерия.

• По ряду независимых оценок использование критерия C1 обеспечивает обнаружение от 67% до 90% ошибок (для компьютерных программ).

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

• планируемые

• спонтанные (пример молокозавода)

Ошибки в потоках данных

• создание информационных объектов (ИО) и/или их атрибутов, не используемых в дальнейшей деятельности;

• отсутствие и/или неполнота ИО и/или их атрибутов;

• дублирование ИО и/или их атрибутов и, как следствие, их несогласованность и противоречивость и др.

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

Проблема

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

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

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

Модель потоков данных бизнес-процесса

Для целей обнаружения ошибок в потоках данных в качестве управляющего каркаса целесообразно использовать подграф уровня операций графа бизнес-процесса G. Формально такой подграф описывается как G1 (N, E, n0, R1, ER1), где

• N, E и n0 имеют тот же смысл, что и в графе G (соответственно, множество узлов, множество ребер и начальный узел);

• R1R - множество информационных объектов (подмножество множества ресурсов предприятия);

• ER1ER - множество ребер использования информационных объектов.

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

• определение маски (прав доступа к атрибутам ИО);

• определение ИО при заданной маске;

• использование ИО при заданной маске.

• Определение 1. Под определением маски будем понимать введение или изменение прав доступа к любому ИО или его атрибутам.

• Определение 2. Некоторое определение маски dMi называется живым в данной функции бизнес-процесса, если существует маршрут из точки определения маски в данную точку бизнес-процесса, на котором не встречается никакое другое определение маски dMj.

• Определение 3. Под определением ИО будем понимать любое изменение его атрибутов при выполнении бизнес-функции или бизнес-операции.

• Определение 4. Определение ИО X называется живым в некоторой точке (функции/операции) ? бизнес-процесса, если существует маршрут из точки определения X в данную точку бизнес-процесса, вдоль которого ИО X не переопределяется.

Модель потоков данных

• Определение 5. Множество всех живых определений всех аргументов функции/операции ? называется средой данных функции/операции ?.

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

Модель потоков данных

• Отметим, что в случае бизнес-операции с m аргументами (при m?1) такая модель является неполной, так как выполнение данной операции в ряде случаев требует одновременного использования n определений (m?n?1) различных атрибутов ИО из среды данных. Этот факт отражается нотацией контекста данных.

• Определение 6. Элементарным контекстом данных операции ?, имеющей K аргументов X1, X2, ..., XK называется множество определений ИО из списка аргументов, для которых существует маршрут из входной точки бизнес-процесса в точку ?, такой что все определения из КД(?) являются живыми при выполнении операции ?.

• Определение 7. Контекстом данных операции ? называется множество всех ее элементарных контекстов.

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

Модель потоков данных

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

• Определение 8. Упорядоченным элементарным контекстом данных операции ?, имеющей K аргументов X1, X2, ..., XK называется последовательность таких определений из элементарного контекста операции ? КД(?), что существует маршрут из входной точки бизнес-процесса в точку ?, вдоль которого все эти определения выполняются в порядке, предписанном заданной последовательностью, и являются живыми при выполнении операции ?.

• Определение 9. Упорядоченным контекстом данных операции ? называется множество всех ее упорядоченных элементарных контекстов.

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

Пример

• Для данного примера среда данных операции ?=5 имеет вид: СД = { x10, x20, x21, y10, y20, y21}

• Элементам данного множества, например, соответствуют следующие маршруты, на которых эти элементы (определения ИО) не переопределяются: (1,2,3,4,5), (1,2,3,4,5,7,4,5), (1,2,3,4,5,6,7,4,5), (1,2,3,4,5), (1,2,3,4,5,8,4,5), (1,2,3,4,5,6,7,4,5,8,4,5).

• Контекст данных содержит следующие элементарные контексты: КД = { (x10, y10), (x10, y20), (x20, y10), (x20, y20), (x21, y10), (x21, y20), (x21, y21)}

• Элементам данного множества, например, соответствуют следующие маршруты, на которых эти элементы (пары определений ИО) не переопределяются: (1,2,3,4,5), (1,2,3,4,5,8,4,5), (1,2,3,4,5,7,4,5), (1,2,3,4,5,7,4,5,8,4,5), (1,2,3,4,5,6,7,4,5), (1,2,3,4,5,8,4,5,6,7,4,5), (1,2,3,4,5,6,7,4,5,8,4,5).

• Упорядоченный контекст данных включает дополнительно к вышеперечисленным элементарным контекстам один следующий упорядоченный элементарный контекст: УКД = КД ? { (y20, x20)}

• Соответствующий маршрут выглядит следующим образом: (1,2,3,4,5,8,4,5,7,4,5).

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

• Критерий 1 требует, чтобы каждый элемент среды данных тестируемой бизнес-операции был проверен по крайней мере однажды.

• Критерий 2 требует, чтобы каждый элемент контекста данных тестируемой бизнес-операции был проверен по крайней мере однажды.

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

• Критерий 1' требует, чтобы каждый элемент среды данных каждой бизнес-операции был проверен по крайней мере однажды.

• Критерий 2' требует, чтобы каждый элемент контекста данных каждой бизнес-операции был проверен по крайней мере однажды.

• Критерий 3' требует, чтобы каждый элемент упорядоченного контекста данных каждой бизнес-операции был проверен по крайней мере однажды.

Количество маршрутов

Теорема о вложении критериев

• Для удобства исследования предложенных критериев пронумеруем их следующим образом: C2 - критерий 1', C3 - критерий 2', C4 - критерий 3'. Известные критерии тестирования компьютерных программ, требующие проверки каждой ветви или каждого функционального узла (оператора) графа по крайней мере однажды, обозначим традиционно C1 и C0 [3], соответственно.

• Пусть MB - множество, элементами которого являются все возможные подмножества множества маршрутов в некотором бизнес-процессе B. Тот факт, что некоторое Mk ? MB удовлетворяет требованиям некоторого критерия тестирования Ci, обозначим следующим образом: Mk ? Ci.

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

• Теорема. Любое множество маршрутов Mk ? MB, удовлетворяющее требованиям критерия Ci для 1 ? i ? 4, также удовлетворяет и требованиям любого из критериев Cj при 1 ? j ? i.

Что обеспечивает такое преимущество

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

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

Следствие из теоремы

• Будем говорить, что некоторый критерий Ci не хуже критерия Cj для некоторого бизнес-процесса B, если ? Mk ? MB: Mk ? Ci ==> Mk ? Cj. Если при этом ? Mk ? MB: Mk ? Ci ? ==> Mk ? Cj , то будем говорить, что критерий Ci лучше критерия Cj. Будем говорить, что Ci эквивалентен Cj, если Ci не хуже Cj, а Cj не хуже Ci.

• Следствие 1. Для бизнес-процессов, удовлетворяющих условиям теоремы, критерий Ci не хуже Cj при 0 ? j ? i? 4.

Ациклические бизнес-процессы (60% от общего числа)

Следствия из теоремы

• Следствие 2. Для бизнес-процессов, представленных графом G1, все критерии тестирования Ci для 0 ? i ? 4 эквивалентны.

• Следствие 3. Для бизнес-процессов, представленных графом G2, все критерии тестирования Ci для 1 ? i ? 4 эквивалентны и лучше критерия C0.

• Следствие 4. Для бизнес-процессов, представленных графами G3 и G4, любой из критериев тестирования Ci при i = 2,3,4 лучше любого из критериев Cj при j = 0,1.

Граф частичного упорядочивания критериев тестирования на основе операции "не хуже"

Таким образом, предложенные критерии тестирования позволяют:

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

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

Показать полностью… https://vk.com/doc-128381368_438865638
235 Кб, 11 ноября 2016 в 14:32 - Россия, Москва, МЭСИ, 2016 г., ppt
Рекомендуемые документы в приложении