3.2.3. Критерии тестирования бизнес-процессов

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

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

Рассмотренным трем этапам построения модели потоков данных соответствуют три следующих критерия тестирования, ориентированные на проверку отдельных операций бизнес-про­цесса:

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

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

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

по крайней мере однажды.

ill

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

Предложенные критерии тестирования являются универсаль­ ными в смысле применимости к бизнес-операции произвольно­ го типа в отличие от существующих критериев выборочного тес­ тирования отдельных операторов компьютерной программы, за­ висящих от типа тестируемого оператора. Так; при тестировании условного оператора обычно требуется проверка каждой из двух порождаемых им ветвей, при тестировании оператора цикла типа пересчета рекомендуется проверять выполнение цикла при на­ чальном значении управляющей переменной, конечном значе­ нии управляющей переменной и хотя бы одном из ее промежу­ точных значений. ; ; !_t',v .;..-

Оценим число маршрутов, выбй]раешлс jpj1 сЧютветствии с тре­бованиями критериев 1-3, при тестирований операции <р, имею­щей К аргументов XI, XI,..., ХК. Пусть во всём бизнес-процессе имеется л_; определений каждого i-го аргумента (1 <, i < К).

Утверждение. Число возможных маршрутов Р\, F2, РЗ, выб­ранных в соответствии с требованиями критериев 1, 2, 3, оцени­вается по следующим формулам:

PUIrfA/rZ^/i, (3.3)

F2<\dM\^K*U_l=x^Kn_t (3.4)

Pb<R*\dM\^K*U_i=i^Kn_i, (3.5)

где | dM | — мощность множества dM.

Отметим, что неравенства (3.3)—(3.5) оценивают число воз­можных маршрутов достаточно грубо. В табл. 3.6 приводится сравнение фактического и оцененного числа маршрутов для при­мера, приведенного на рис. 3.3. Для данного примера К = 2, \4М\^2,п_{ = 2, и₂ = 2.

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

(х₂', у₂¹) требуется выполнение-маршрута (1,2,3,4,5,6,7,4,5,8,4,5), который также проверяет и элементарные контексты (хД у, ) и

Таблица 3.6

Номер критерия	Оцененное число маршрутов	Мощность модели	Фактичес­кое число маршрутов	Проверяемые элементы модели
1	8	6	4	х2 «х2 >Уг гУг
, 2	16	7	3	(Х2в,Лв),(^,,й'), {х2\Уг)
3	32	8	4	(хг\У11),<Уг0,х2«)

Заметим, что для данного примера при применении наиболее часто используемых критериев тестирования компьютерных программ, требующих по крайней мере однократной проверки каждого оператора илн.каждой ветви программы, необходимо, соответственно, два Л<1,2,3,4,5,8), (1,2,3,4,5,6,7)} и три {(1,2,3,4,5,8), (1,2,3,4,5,|,7), (1,2,3,4,5,7)} маршрута.

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

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

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

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

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

5-10%) по сравнению с наиболее часто используемым критерием тестирования компьютерных программ Cj (требующим проверки каждой ветви программы по крайней мере однажды), при этом может существенно увеличиться длина и сложность этих марш- . РУтов. [

Таблица 3.7 j

Бизнес-процесс	Критерий 1	Критерий Ci
Перевозки	31	29
Ремонты и техническое обслуживание	78	75
Обеспечение безопасности движения	12	12
Материально-техническое снабжение	68	61

Продемонстрируем преимущества предложенных критериев на примере, приведенном на рис. 3.3. Для наглядности предполо­жим, что информационные объекты X и Y содержат по два атри-. бута, т.е. X = (х[1], х[2]), Y = (у[Ц, у[2]) соответственно. Реально эти объекты могут содержать следующую информацию:

х[ 1 ] — планируемый объем поставляемого товара;

x[2J) — фактический объем поставляемого товара;

y[lj — планируемый платеж за поставленный товар;

у[2] — фактический платеж за поставленный товар.

Пусть т₀ = (1,0), j»j = (1,1) — данные маски определяют раз­деление доступа к формированию и использованию планируемой и фактической информации, a F(X, Y) — некоторая функция контроля и согласования поставок и платежей.

При выполнении бизнес-процесса (фрагмент графа которого анализируется) на любом маршруте, проверяющем элемент кон­текста данных (х₂', у?), например, на маршруте (1,2,3,4,5,6,7,4,5), обнаруживается ошибка в потоках данных, проявляющаяся как попытка использования в узле 5 неопределенного элемента дан­ных по фактическим платежам у[2]. Причем данная ошибка об­наруживается при выборе произвольного множества маршрутов, удовлетворяющих требованиям критерия 1 (Г), так как при про­верке контекста (х₂, У]⁰) ни одно из определений ИО Y не может производиться при маске т, по определению.

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

ошибки. Например, множество маршрутов {(1,2,3,4,5,6,7,4,9), (1,2,3,4,5,7,4,9), (1,2,3,4,5,8,4,9)} удовлетворяет требованиям это­го критерия тестирования, но не выявляет данную ошибку. Выб­ранное множество маршрутов тем более удовлетворяет требова­нию по крайней мере однократной проверки каждого оператора программы, следовательно, соответствующий критерий также не гарантирует обнаружения данной ошибки.

Для удобства исследования предложенных критериев прону­меруем их следующим образом: С₂ - критерий Г, С₃ - крите­рий 2', С₄ - критерий 3'. Известные критерии тестирования компьютерных программ, требующие проверки каждой ветви или каждого функционального узла (оператора) графа по край­ней мере однажды, обозначим традиционно Cj и С₀ соответ­ственно.

Пусть М^в — множество, элементами которого являются все возможные подмножества множества маршрутов в некотором бизнес-процессе В. Тот факт, что некоторое M_k e М^в, удовлетво­ряет требованиям некоторого критерия тестирования C_i5 обозна­чим следующим образом: М_к <-► Q. ^.

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

Теорема. Любое множество маршрутов М_к е М^в, удовлетворя­ющее требованиям критерия Cj для 1 < i < 4, также удовлетворяет и требованиям любого из критериев Cj при 1 < j < i.

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

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

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

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

Будем говорить, что некоторый критерий Q не хуже критерия Cj для некоторого бизнес-процесса В, если V М_к е М^в: М_к <-> Q => М_к <-> Cj. Если при этом 3 М_к е М^в: М_к «-> Q -i => М_к о CJ, то будем считать, что критерий С, лучше критерия Cj. Cj эквивален­тен Cj, если Cj не хуже Cj, a Cj не хуже Cj.

Следствие 1. Для бизнес-процессов, удовлетворяющих усло­виям теоремы, критерий С; не хуже Cj при 0 < j < i £ A.

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

На рис. 3.4 приведены четыре регулярные абстрактные гра­фовые структуры, охватывающие наиболее типовые варианты фрагментов бизнес-процессов. Анализируемые графы различа­ются шириной, наличием симметрии и структурированности. Графы G1 и G3 — структурированы и симметричны, граф G2 -структурирован и асимметричен. Асимметричный неструктури­рованный граф G4 довольно часто встречается в реальных биз­нес-процессах.

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

Следствие 3, Для бизнес-процессов, представленных графом G2, все критерии тестирования Cj для 1 < / < 4 эквивалентны и лучше критерия С₀.

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

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

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

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

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