|
118 Тогда очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, упрощающие проверку структуры управления. Общими требованиями к этим критериям является достижение лишь определенной степени полноты покрытия структуры управления. Эти критерии устанавливают требование однократной проверки всех функций (Со), всех его ветвей (Ci), либо всех подпутей специального вида. Однако функции управления являются гораздо более сложным и непредсказуемым объектом, чем компьютерная программа. Поэтому основной проблемой при планировании процедуры тестирования является проблема выбора критерия (стратегии) тестирования, т.е. задача выделения тех частей структуры управления, которые необходимо тестировать. Существующие критерии тестирования программ и соответствующие алгоритмы выбора стратегий тестирования, основанные на анализе графовой модели структуры управления [19], не обеспечивают обнаружения ошибок в потоках данных функций управления. Следовательно, при создании критерия тестирования функций управления необходимо учитывать не только его структуру управления, но и структуру его потоков данных. Для обнаружения ошибок в потоках данных в качестве управляющего каркаса целесообразно использовать подграф уровня операций введенного в главе 2 графа функций управления G. Формально такой граф описывается как Gl(N,E,n0,Rl,ER\) [96], где: • N,Е,по имеют тот же смысл, что и в графе G; • 7?1 с R множество информационных объектов (подмножество множества ресурсов структуры управления ГПС); • ER} ст ER множество ребер использования информационных объектов. |
проблема оценки их необходимого количества и использования методов их сокращения. Поэтому тестирование (как и любой другой вид деятельности) целесообразно планировать. План тестирования должен содержать: • формулировку целей тестирования; • критерии качества тестирования, позволяющие оценить его результаты; • стратегию проведения тестирования, обеспечивающую достижение заданных критериев качества; • потребности в ресурсах для достижения заданного критерия качества при выбранной стратегии. Для целей тестирования объект удобно представлять в виде ориентированного графа G = (N, Е), где N = (N4, N2, ..., Nm) множество узлов (вершин), соответствующих функционалу объекта; Е = (Еч, Е2, ..., Еп) множество ребер (дуг), соответствующих передачам управления между функциями. Путем (маршрутом) называется последовательность вершин и дуг Р = (N1, Е12, N2j Е2,з, ..., Ek.i,k, Nk), где каждая дуга Ej,i+1 выходит из 14 и входит в Nj+ч, причем N1 не обязательно начальный узел. Ветвью называется путь Р, в котором N-iлибо начальный узел, либо узел ветвления, Nk либо узел ветвления, либо завершающий узел, все остальные Nj не являются узлами ветвления. Очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, не гарантирующие полной проверки программы. Общим требованием к этим критериям является достижение лишь определенной степени полноты покрытия объекта или его компонент. Как правило, эти критерии устанавливают требование по крайней мере однократной проверки всех функций (критерий Со), всех его ветвей (критерий Ci), либо всех подпутей специального вида. Самым распространенным критерием тестирования является критерий, требующий по крайней мере однократной проверки каждой из ветвей объекта (критерий Сч). Так, например, тестирование из Безусловно, подобную ошибку нельзя обнаружить никаким, даже самым тщательным, тестированием, поскольку еще никто не научился формализовать людскую смекалку. Вообще говоря, существует два типа бизнес-процессов планируемые и спонтанные, приведенный пример относится ко второй категории. Спонтанные процессы не подлежат тестированию и исключаются из рассмотрения. В данной главе выделяется класс наиболее типичных для планируемых бизнеспроцессов современного предприятия ошибок, связанных с информационными ресурсами (ошибок в потоках данных) и предлагается комплекс методов и средств их обнаружения и локализации. Примерами таких ошибок являются: • создание информационных объектов (ИО) и/или их атрибутов, не используемых в дальнейшей деятельности; • отсутствие и/или неполнота ИО и/или их атрибутов; • дублирование ИО и/или их атрибутов и, как следствие, их несогласованность и противоречивость и др. Специфика данных ошибок для бизнес-процесса обуславливается наличием регламентов доступа к атрибутам ИО, запрещающих или ограничивающих доступ при выполнении ряда бизнес-операций. Так, например, такой атрибут сотрудника как его зарплата на ряде предприятий доступен только руководству и сотрудникам бухгалтерии. Основной проблемой при планировании процедуры тестирования является проблема выбора критерия (стратегии) тестирования, т.е. задача выделения тех частей объекта, которые необходимо тестировать. Известные критерии тестирования программ [3] и соответствующие алгоритмы выбора стратегий тестирования, основанные на анализе графовой модели объекта, не обеспечивают обнаружения рассматриваемых ошибок в потоках данных бизнес-процессов. Следовательно, при создании критерия тестирования бизнес-процесса необходимо учитывать не только его структуру управления, но и структуру его потоков данных. В главе выделяются присущие бизнес-процессам структурные свойства потоков данных, и на их основе предлагаются 3 критерия тестирования, 115 ориентированных на потоки данных и обеспечивающих выявление ошибок, связанных с информационными ресурсами бизнес-процесса. § 3.1. Модель потоков данных бизнес-процесса. Для целей обнаружения ошибок в потоках данных в качестве управляющего каркаса целесообразно использовать подграф уровня операций введенного в главе 2 графа бизнес-процесса G. Формально такой подграф описывается KaxG1 (N, Е, n0, R1, ER1), где • N, Е и По имеют тот же смысл, что и в графе G; • R1 cz R множество информационных объектов (подмножество множества ресурсов предприятия); • ER1 С каждым из узлов такого подграфа, являющихся элементами множества N связаны три типа событий, касающихся обработки информационных объектов: • определение маски (прав доступа к атрибутам ИО); • определение ИО при заданной маске; • использование ИО при заданной маске. При этом с каждым из узлов может ассоциироваться произвольная комбинация этих событий за исключением комбинации, в которой событие “определение ИО” присутствует более одного раза. При выполнении бизнес-процесса существенное значение придается разграничениям прав доступа к ИО и их атрибутам. Поэтому традиционного понимания событий определения/использования ИО недостаточно, поскольку фактически эти события происходят при определенных правах доступа при выполнении каждой из функций бизнес-процесса, при этом эти права могут изменяться при переходе от функции к функции. Поэтому вводятся новые типы событий: определение маски и определение/использование ИО при заданной маске. Определение 3.1. Под определением маски будем понимать введение или изменение прав доступа к любому ИО или его атрибутам. 116 |