Методологии ИТ-консалтинга. Тестирование бизнес-процессов. (Лекция 15) презентация

Методологии ИТ-консалтинга Калянов Георгий Николаевич профессор, доктор технических наук зав. кафедрой “Системный анализ и управление ИТ” зав. лабораторией Института проблем управления РАН 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.

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

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