Ни для кого не секрет, что QA — это процесс обеспечения качества. Но как можно обеспечить качество продукта, если качество самого процесса тестирования под большим вопросом?
Конечно, когда дело касается микро-стартапов, в команде которых всего пара человек: разработчик, он же и аналитик по совместительству, да и тестировщик, то сильно задумываться над построением процессов не имеет смысла. Но вот в крупном продукте, где команда тестирования состоит из трех и более человек, чтобы эффективно выполнять задачи, приходится налаживать процессы. Когда вокруг царит процессный хаос, сложно сосредоточиться на обеспечении качества, и высока вероятность что-то упустить из виду: где-то — сделать двойную работу, где-то, наоборот, что-то забыть. Вот от этого хаоса постараемся сегодня избавиться, разложив процесс тестирования по полочкам следуя советам Никиты Ткаченко, инженера по тестированию iiii Tech (“Форайз”).
Как построить процесс тестирования с нуля?
Вспоминаем жизненный цикл ПО
Чтобы четко формализовать процесс, необходимо понимать что и когда необходимо делать тестированию. Для этого давайте вспомним чуть упрощенный жизненный цикл ПО: работа с требованиями -> разработка -> тестирование -> внедрение и эксплуатация. И если мы работаем по гибкой методологии, то включаться в процесс разработки ПО мы — команда тестирования — должны как можно раньше. Рассмотрим, что можно сделать на каждом из этих этапов.
Работа с требованиями
Кроме самого очевидного — тестирования самих требований — на ранних этапах стоит подумать что и как будем проверять. В этом нам помогут декомпозиция, тест-план и оценки: 1. Декомпозиция: как гласит народная мудрость, «слона нужно есть по кусочкам», и в нашем случае удобнее всего это сделать в виде майнд-карты — так мы структурируем требования по логическим модулям и создадим себе шпаргалку для будущих проверок.
2. Тест-план: говоря о тест-планах, многие вспоминают нечитабельные «талмуды», изобилующие практически никогда не используемой информацией. Но тест-план должен быть удобен прежде всего для участников процесса и формат его выбираете вы.
А потому, возможно, и не стоит расписывать кто заказчик продукта, какова его ценность, критерии начала и окончания тестирования, какие виды тестирования планируете применять и так далее. А вот заранее подсветить возможные риски, оценить зависимости от других продуктов и команд, определить возможное регрессионное влияние — всегда полезно 3. Оценки трудозатрат: прогнозы — это хорошо, а сбывшиеся прогнозы — вдвойне хорошо!
Думаю, нет смысла лишний раз говорить насколько важно планирование трудозатрат и сроков для разработки продукта в целом. На первый взгляд кажется, что все вышеописанное — это просто лишняя работа.
Моделирование бизнес-процесса тестирования ПО в ELMA
Но, во-первых, их необходимость для себя команда тестировщиков определяет самостоятельно, а во-вторых, много времени они не занимают, а вот сэкономить при этом могут очень много — проверено не раз. Пожалуй, самым показательным случаем на моей практике оказалась одна небольшая задача: ее релиз был привязан к определенной дате, но работы по ней было буквально на неделю и потому никто особо не переживал за сроки.
Однако, все забыли, что получить тестовые данные, необходимые чуть ли не на последнем этапе работы над задачей, нам потребуется от третьей стороны, согласования с которой могут занять длительное время. К счастью, этот риск мною был учтен заранее и этап согласования начался параллельно с работой непосредственно над задачей. И в итоге он занял практически ту же неделю, что и помогло закончить работу прямо к дедлайну. Упусти мы этот момент на этапе планирования, и та самая неделя согласований добавилась бы сверху.
Разработка
Бытует мнение, что на этапе разработки, как следует из названия, эстафета передается разработчикам, а тестированию здесь делать нечего. Но нет, это самый подходящий момент начать тест-дизайн, подготовку тестовых данных и окружений, насколько это возможно. Как и при приеме гостей, стол следует накрыть заблаговременно и при приходе гостей останется лишь подать горячее, так и к моменту начала тестирования все к нему должно быть готово. Иначе могут возникнуть неприятности как, например, необходимость заказа «железа» или девайсов, которые за один день не решаются, или сложность подготовки тестовых данных, если для этого требуются дополнительные коммуникации или согласования. Все это на пользу релизу явно не пойдет.
Тестирование
этап выполнения проверок непосредственно. Все делается легко и непринужденно, так как о большинстве вопросов мы позаботились заранее. Кроме того, работы на этом этапе можно делегировать даже пока еще не самым опытным сотрудникам — все необходимое есть, остается только следовать инструкциям и проходить кейсы. По окончанию тестирования стоит также оформить некий паспорт качества релиза, где можно будет оценить качество релиза в целом, отметить известные, но пока еще не решенные проблемы, сравнить оценки с реальными трудозатратами и прочее, что поможет позже оценить свою работу
Внедрение и эксплуатация
С окончанием тестирования работа QA-инженеров не заканчивается: после внедрения рано или поздно прозвучит нежеланное «баг с прода!». Как бы команда тестирования ни старалась, все досконально проверить невозможно. И здесь просто исправить и забыть нельзя. Баг — это следствие, а команде прежде всего нужно понять причину и «починить» уже ее, чтобы в дальнейшем такое не происходило.
Работа внутри команды
Взаимодействие внутри команды также крайне важно наладить и для этого есть несколько подходов: * Прозрачность: участники команды должны всегда понимать кто чем занимается. Но не контроля ради, а для рационального распределения задач — чтобы не выполнять одну работу вдвоем, а другую полностью оставлять без внимания.
Для этого можно использовать как регулярные синки или специальные инструменты, так и просто мессенджеры — удобный способ для себя определяете вы сами. * Нивелирование бас-фактора: сосредоточение знаний в “одной голове” — плохая идея. Уйди сотрудник в отпуск, на больничный или вообще из проекта, и целый пласт знаний в определенной функциональности уйдет вместе с ним.
Решить эту проблему заранее поможет постоянный шаринг знаний (в виде встреч или инструкций — как удобно) или распределение компетенций в виде привлечения к задачам нескольких тестировщиков. Как это сделать в условиях ограниченных ресурсов? Очень просто: вместо подхода «один человек на одну задачу» применять «два человека на две задачи». Казалось бы, одно и то же, но во втором случае оба будут в курсе обеих задач, а степень погружения можно варьировать. Но главное, что всегда есть дублирующий.
Единый стиль
Разработчики в своей работе зачастую придерживаются определенного code style — набора правил и подходов при написании кода. Так и в тестировании следует применять подобный подход: определите требования к написанию тест-кейсов, созданию баг-репортов и прочих других артефактов. Условьтесь в их степени детализации, оформлении и придите к некой шаблонизации — так будет обеспечен единый стиль. Паттерны воспринимаются быстрее и проще, чем каждый раз уникальный авторский подход, зависящий от сотрудника.
Долой бюрократию
Документация и артефакты тестирования должны решать проблемы, а не создавать их! На моей практике был случай, когда один из артефактов, потребителем которого была другая команда, создавался вручную в виде docx-файла с оформлением таблиц и копированием туда множества ссылок. Занимало это зачастую не один час, не говоря уж о рутинности такой работы.
На мое возражение о нелогичности такой документации коллеги мне ответили что так исторически сложилось и такие требования потребителя. Конечно, так просто я не сдался и пошел выяснять почему так. На мое удивление, потребитель ответил что им по большому счету все равно в каком виде, главное получить нужную информацию.
Час работы над новым форматом в confluence, немного автоматизации средствами плагинов и теперь артефакт создается за. 30 секунд. Без документации, конечно, нельзя. Но решите что из нее не используется и может быть упразднено, а что — упрощено и автоматизировано.
Качественные процессы не существуют без коммуникаций
Как бы команды ни были хороши по отдельности, задача у них общая. Взаимодействие с другими командами — аналитиками, архитекторами, разработчиками, дизайнерами — очень важно. Требования могут вдруг поменяться, может возникнуть понимание что текущая реализация неудобна, или возникнут разночтения.
Один уточняющий вопрос может сэкономить очень много времени, а вовремя подсвеченная проблема — положительно повлиять на сроки вывода релиза. Общайтесь и желательно не в личных сообщениях, а в тематических каналах вашего корпоративного мессенджера — так все заинтересованные участники смогут вступить в обсуждение и помочь, или просто быть в курсе. Не забывайте фиксировать договоренности где-то за пределами мессенджеров — переписки имеют свойство теряться.
Эволюционируй и строй СВОЙ процесс
Идеальных процессов и универсальных подходов к ним не бывает. Неудачный опыт применения чужих «историй успеха» не говорит о проблемах явно — просто в конкретном случае этот подход мог не подойти. Построить все сразу хорошо вряд ли получится и начинать нужно постепенно, при этом периодически посматривая на свои процессы со стороны и оценивая результаты. А далее — постоянный процесс эволюционных изменений до тех пор, пока не придет осознание что «вот, это то, что мы и хотели! Теперь все работает как надо!»
Источник: www.it-world.ru
Наглядный пример из жизни
Это набор разноцветных деталей разной формы и размеров, которые после «магического» соединения превращаются в прикольную игрушку.
Обычно, процесс сборки игрушки выглядит так:
- Берем детали и инструкцию по сборке, и проверяем, что все на месте (детали правильной формы / размера / цвета)
- Собираем детали в «блоки». Если игрушка — это машинка, то мы соберем несколько блоков: двери, колеса, салон, корпус машины, подвеску и т.п.
- «Блоки» собираем в части побольше (если нужно), а уже из них складываем готовую машинку
- Проверяем, что машинка ездит, двери открывается, ничего от нее не отпадает и т.п.
- В конце мы проверяем, что машинка соответствует изображению и это то, что мы покупали
Программное обеспечение очень похоже на такой конструктор.
Но оно намного круче, ведь мы сами можем создавать любые детали и использовать детали (и даже блоки), созданные другими людьми (привет Open Source)
Если посмотреть на процесс сборки с точки зрения тестирования, его можно описать так:
- Проверка каждой отдельной детали на соответствие инструкции = Модульное тестирование
- Проверка «блоков», состоящих из отдельных деталей соединённых определенным образом = Интеграционное тестирование
- Проверка собранной игрушки = Системное тестирование
Собранная игрушка — это именно та игрушка, которую мы хотели = Приемочное тестирование
Суть процесса проста: проверка любой системы (будь то конструктор LEGO или мобильное приложение) начинается с ее наименьших элементов и двигается в сторону их объединения / увеличения до максимального размера.
Благодаря этому подходу ты никогда не попадешь в ситуацию, когда «колеса не того размера», «двери не от той машины» или «мы хотели самолет, а получили вертолет, платить не будем»
Теперь ты осознаешь уровни тестирования, но для эффективной работы этого недостаточно. Давай разбираться глубже)
Что такое уровень тестирования?
Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.
К характеристикам относятся:
- Цели тестирования (Для чего мы проводим тестирование?)
- Объект тестирования (Что мы тестируем? Модуль / компонент / под-систему / систему?)
- Базис тестирования (Что нам необходимо, чтоб провести тестирование? Объект тестирования, спецификации, требования, ТЗ)
- Типичные дефекты, которые мы планируем найти
- Зоны ответственности (Кто чем занимается и кто за что отвечает?)
- Окружение (Где проводится тестирование, локально или на production сервере?)
Перед тем, как мы перейдем к рассмотрению каждого конкретного уровня и его характеристик, давайте рассмотрим реальный пример этапов тестирования ПО, который поможет нам совместить теорию и практику.
Пример реальной задачи по разработке
Предположим, перед вашей командой ставят задачу:
Создать страницу “Contact Us” на сайте Х. После отправки формы отдел поддержки должен получить Email, содержащий введенные данные и контактную информацию клиента.
Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)
Первым делом разработчики прорабатывают дизайн системы.
Он может представлять собой следующую схему:
Далее, разработчики детализируют схему добавляя описание шагов:
- Клиент заполняет форму Contact Us и нажимает кнопку «Отправить»
- Frontend проверяет введенные значения*
- Frontend отправляет данные на Backend
- Contact Us Controller проверяет данные и формирует запрос на отправку письма*
- Contact Us Controller передает данные для отправки письма в Email Sender
- Email Sender получает данные, проверяет их, формирует письмо и отправляет его**
- Email Sender отвечает Contact Us Controller, что письмо отправлено
- Contact Us Controller формирует ответ для Frontend
- Backend отправляет данные об успешной отправке письма на Frontend
- Frontend получает данные, понимает, что отправка была успешной и показывает клиенту сообщение
логика проверки (валидации данных) опущена для упрощения; но, это не означает, что ее нет!
логика отправки Email опущена для упрощения схемы
Имея требования к странице, описание дизайна и логики работы, проект переходит на этап разработки. Разработчики начинают писать код, а тестировщики могут приступать к продумыванию тестов.
Как ты уже знаешь, процесс начинается с наименьших частей системы — модулей / компонентов.
1. Модульное / Компонентное / Unit тестирование
Модульное / Компонентное / Unit тестирование фокусируется на компонентах / модулях, которые должны быть проверены в изоляции, как самостоятельные, независимые блоки.
Module / Component / Unit testing: A test level that focuses on individual hardware or software components [ISTQB Glossary]
Характеристики модульного тестирования
Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок
- Объект: модуль / компонент / unit
- Базис: дизайн системы, код, спецификация компонента
- Типичные ошибки: ошибка в реализации требований, ошибка в коде
- Ответственный: разработчик (редко тестировщик)
На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях. Эти проверки всегда автоматизированы и выполняются очень быстро (несколько тысяч тестов в минуту).
Unit тесты, кроме поиска ошибок, также помогают оценивать качество кода, измерять покрытие кода тестами, сокращать время и затраты на тестирование.
Продолжая рассмотрение примера со страницей сайта, мы можем выделить следующие модули:
- Страница Contact Us отвечает за показ формы Contact Us
- Форма Contact Us отвечает за проверку и отправку данных на Backend
- Contact Us Controller является частью API и отвечает за обработку запросов с формы Contact Us
- Email Sender отвечает за отправку Email
Для примера, рассмотрим модуль «страница Contact Us».
- Открываться в браузере по указанному URL
- Содержать правильную информацию и тексты
- Содержать форму Contact Us (содержать, но не отвечать за ее работоспособность!)
- …
В свою очередь, требования к модулю «Contact Us Controller»:
- Принимать данные по указанному URL (API endpoint)
- Проверять полученные данные
- Правильно формировать данные для компонента Email Sender (без фактической отправки)
- Возвращать правильные HTTP ответы в случае успешной отправки Email И (. ) в случае возникновения ошибки
- …
Все описанные выше требования должны проверяться Unit тестами.
Когда проверки компонентов закончены и мы уверены, что модули по отдельности работают как ожидалось, можем переходить на следующий уровень.
2. Интеграционное тестирование
Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / под-системами / системами.
Выделяют 2 подтипа:
- Компонентное интеграционное тестирование — проверяет связи между компонентами. Может быть автоматизировано.
- Системное интеграционное тестирование — проверяет связи между под-системами / системами. Не всегда можно автоматизировать, так как часто интеграция происходит с внешним сервисом, к которому мы не имеем доступа.
Характеристики интеграционного тестирования
- Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы
- Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы
- Базис: дизайн системы, архитектура системы, описание связей компонентов
- Типичные ошибки: отсутствие / неправильные связи между элементами системы, неправильные передаваемые данные, отсутствие обработки ошибок, отказы и падения при обращениях к API
- Ответственный: разработчик и тестировщик
Системные интеграционные тесты выполняются дольше (несколько десятков в минуту), чем модульные интеграционные тесты (несколько сотен-тысяч в минуту) и являются более творческими.
Продолжим рассмотрение примера.
Теперь, обратим внимание на связи между компонентами / под-системами:
Начнем с компонентного интеграционного тестирования.
Обрати внимание на стрелки 5 и 7.
Они описывают связь между компонентами Contact Us Controller и Email Sender внутри под-системы Backend.
Contact Us Controller обращается к Email Sender с запросом для отправки Email сообщения (5), Email Sender отправляет письмо (6) и отвечает Contact Us Controller что все прошло удачно (7). Если при отправке (6) произошла ошибка, в ответе (7) вернется информация об ошибке.
В нашем случае интеграционные тесты проверят, что описанный выше процесс работает и что модуль Contact Us Controller инициирует отправку Email сообщения, а не SMS.
Тестирование интерфейсов (частично) и тестирование API являются примерами интеграционного компонентного тестирования.
В случае с тестированием API мы «имитируем» запрос от клиента — (3) и анализируем ответ сервера — (9), таким образом проверяя интеграцию всех задействованных модулей для конкретного API Endpoint внутри Backend.
Далее посмотрим на системное интеграционное тестирование.
Обрати внимание на стрелки 3 и 9.
Они описывают связь между двумя под-системами: Frontend, который формирует и отправляет запрос со страницы Contact Us с данными формы, и Backend, который обрабатывает и реагирует на запрос.
Тестирование на этом уровне показывает, что интеграция под-систем реализована в соответствии с заявленными требованиями.
В нашем случае для проверки правильности достаточно написать 1 тест: отправить форму Contact Us с ожидаемым результатом в виде показанного сообщения об успешной отправке — (10) и полученного Email сообщения с данными, оставленными с формы Contact Us.
Теперь, когда мы проверили интеграции компонентов внутри под-систем и интеграции под-систем, мы можем двигаться дальше.
3. Системное тестирование
Системное тестирование фокусируется на поведении всей системы в целом с точки зрения конечных пользователей.
Внимание уделяется задачам, на решение которых направлена система. Также во внимание берется нефункциональное поведение системы (скорость работы, нагрузка, и т.п.) при выполнении бизнес-задач.
Системное тестирование может проверять выполнение стандартов или законодательных / нормативных требований.
Тестовая среда для системного тестирования должна быть максимально приближенной (в идеальном варианте — идентичной) к окружению для эксплуатации (production).
Характеристики системного тестирования
- Цель: проверка работы системы в целом
- Объект: система, конфигурации системы, рабочее окружение
- Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции
- Типичные ошибки: невозможность выполнять функциональные задачи, для которых создавалась система, неправильная передача данных внутри системы, неспособность системы работать правильно в среде эксплуатации, нефункциональные сбои (уязвимости, зависания, выключения)
- Ответственный: тестировщик
Системное тестирование для нашего примера может включать в себя такие типы тестирования:
слово «тестирование» — убрано с изображения для упрощения
Помимо проверки отправки формы Contact Us, получения Email сообщения на почту суппорта и показа Success сообщения, в ходе системного тестирования мы должны ответить на вопросы:
- Работает ли форма Contact Us во всех поддерживаемых браузерах?
- Удобно ли ей пользоваться? Все ли понятно? Насколько осмысленны сообщения об ошибках?
- Что произойдет, если кто-то отправит 1,000 запросов Contact Us в секунду? (DDOS)
- Какое максимальное количество запросов можно отправить, чтобы сайт работал без сбоев? (Load testing)
- Насколько читабельным является Email, который получит поддержка? (весь текст в одну строку или письмо оформлено красиво)
- Не попадает ли письмо в Spam?
- Сохраняются ли данные клиента, который отправляет форму? Если «да» — насколько безопасно место хранения? Существует ли способ получения списка отправленных Email-ов?
- Знает ли суппорт о почтовом ящике, куда попадет письмо? Знает ли он, как реагировать на такие письма?
- и много, много других …
На этом уровне тестирования создаются end-to-end тесты, имитирующие бизнес процессы, Use Cases и Use Stories от начала до конца.
Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п. — все здесь).
“End to end“ / E2E тесты очень медленные (обычно 5-10 тестов в минуту) и коварные, с их автоматизацией нужно быть очень осторожным
Системное тестирование — одна из самых творческих и объемных областей тестирования. Кроме end-to-end тестирования, к этому уровню относятся все виды нефункционального тестирования.
Очень часто начинающие тестировщики видят только одно направление развития: автоматизация.
Но на самом деле направлений много.
Именно в системном тестировании можно развиваться бесконечно, становясь профессионалом в нагрузочном тестировании, юзабилити, тестировании безопасности, производительности и т.п. Конечно, автоматизация не помешает, но не все любят и хотят программировать
После завершения тестирования всей системы нас ждет последняя проверка перед сдачей работы.
4. Приемочное тестирование
Приемочное тестирование фокусируется на готовности всей системы в целом.
Существуют несколько форм приемочного тестирования:
- Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.
- Контрактное приемочное тестирование — проводится в соответствии с критериями, указанными в контракте приемки специального ПО.
- Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов. Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.
- Бета-тестирование проводится реальными пользователями системы.
Характеристики приемочного тестирования
- Цель: проверка готовности системы
- Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика
- Базис: системные требования, бизнес требования, сценарии использования, User Stories
- Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта
- Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик
Завершая рассмотрение примера можем написать приемочный тест, который выполнит заказчик:
- Заказчик заполняет форму, нажимает на кнопку «Отправить»
- Через 1 секунду он видит сообщение об успешной отправке формы
- В течении минуты на почту поддержки приходит письмо содержащее данные отправленные с формы
Количество тестов на приемочном уровне намного меньше, чем на других уровнях, потому что в этот момент времени вся система уже проверена. Приемочные тесты практически никогда не автоматизируются.
В Agile разработке, конкретно в Scrum, для всех User Stories обязательно прописываются Acceptance Criteria. Именно они являются основой для приемочных тестов и показывают, что команда сделала именно то, что было нужно.
После завершения приемочного тестирования задача передается клиенту.
Резюме
- В этой статье мы описали, что такое уровни тестирования, зачем они нужны и что собой представляет каждый из них.
- Мы рассмотрели пример тестирования формы Contact Us.
- Мы поняли, что тестирование нужно начинать с самых маленьких частей системы — компонентов / модулей.
- Далее стоит проверить взаимосвязи между компонентами и всю систему в целом.
- А завершает тестирование — заказчик, выполняя приемочное тестирование.
Источник: nujensait.ru
Методологии ИТ-консалтинга. Тестирование бизнес-процессов. (Лекция 15)
Калянов Георгий Николаевич
профессор, доктор технических наук
зав. кафедрой “Системный анализ и управление ИТ”
зав. лабораторией Института проблем управления РАН
[email protected]
http://www.kalyanov.by.ru
2. Лекция №15
Тестирование бизнес-процессов
3.
• На практике обнаружение и локализация
ошибок в бизнес-процессе осуществляется во
время его функционирования в реальных
экономических условиях, что может привести
и, как правило, приводит к плачевным
результатам.
• Поэтому актуальной является задача
выявления ошибок на стадиях планирования
(проектирования) и создания бизнес-процесса,
т.е. до того, как он начнет реально
функционировать.
4. Подобие бизнес-процессов и компьютерных программ:
в основе обеих объектов лежит
понятие алгоритма;
оба объекта имеют одинаковые этапы
жизненного цикла;
оба объекта могут выполняться как
последовательно, так и параллельно;
оба объекта адекватно моделируются с
использованием графовых моделей.
5. Тестирование
• В общем случае тестирование представляет
собой набор процедур и действий,
предназначенных для демонстрации
корректной работы объекта в заданных
режимах и внешних условиях.
• Цель тестирования — выявить наличие ошибок
или убедительно продемонстрировать их
отсутствие, что возможно лишь в отдельных
тривиальных случаях.
6. План тестирования должен содержать:
• формулировку целей тестирования;
• критерии качества тестирования,
позволяющие оценить его результаты;
• стратегию проведения тестирования,
обеспечивающую достижение заданных
критериев качества;
• потребности в ресурсах для достижения
заданного критерия качества при выбранной
стратегии.
7.
Для целей тестирования объект удобно представлять в виде
ориентированного графа 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 не являются узлами
ветвления.
8. Полное тестирование всех возможных маршрутов не реально
Поэтому на практике применяются критерии выбора тестов, не
гарантирующие полной проверки программы.
Общим требованием к этим критериям является достижение лишь
определенной степени полноты покрытия объекта или его компонент.
Как правило, эти критерии устанавливают требование по крайней мере
однократной проверки всех функций (критерий C0), всех его ветвей
(критерий C1), либо всех подпутей специального вида.
Самым распространенным критерием тестирования является критерий,
требующий по крайней мере однократной проверки каждой из ветвей
объекта (критерий C1).
Так, например, тестирование при приемке программного обеспечения
для ВВС США производится на основании этого критерия.
По ряду независимых оценок использование критерия C1 обеспечивает
обнаружение от 67% до 90% ошибок (для компьютерных программ).
9. Типы бизнес-процессов
• планируемые
• спонтанные (пример молокозавода)
10. Ошибки в потоках данных
создание информационных объектов (ИО) и/или их атрибутов,
не используемых в дальнейшей деятельности;
отсутствие и/или неполнота ИО и/или их атрибутов;
дублирование ИО и/или их атрибутов и, как следствие, их
несогласованность и противоречивость и др.
Специфика данных ошибок для бизнес-процесса
обуславливается наличием регламентов доступа к атрибутам
ИО, запрещающих или ограничивающих доступ при
выполнении ряда бизнес-операций. Так, например, такой
атрибут сотрудника как его зарплата на ряде предприятий
доступен только руководству и сотрудникам бухгалтерии.
11. Проблема
Основной проблемой при планировании процедуры
тестирования является проблема выбора критерия (стратегии)
тестирования, т.е. задача выделения тех частей объекта, которые
необходимо тестировать.
Известные критерии тестирования программ и
соответствующие алгоритмы выбора стратегий тестирования,
основанные на анализе графовой модели объекта, не
обеспечивают обнаружения рассматриваемых ошибок в потоках
данных бизнес-процессов.
Следовательно, при создании критерия тестирования бизнеспроцесса необходимо учитывать не только его структуру
управления, но и структуру его потоков данных.
12. Модель потоков данных бизнес-процесса
Модель потоков данных бизнеспроцесса
Для целей обнаружения ошибок в потоках данных в качестве
управляющего каркаса целесообразно использовать подграф
уровня операций графа бизнес-процесса G. Формально такой
подграф описывается как G1 (N, E, n0, R1, ER1), где
N, E и n0 имеют тот же смысл, что и в графе G (соответственно,
множество узлов, множество ребер и начальный узел);
R1R — множество информационных объектов (подмножество
множества ресурсов предприятия);
ER1ER — множество ребер использования информационных
объектов.
13.
С каждым из узлов такого подграфа
связаны три типа событий, касающихся
обработки информационных объектов:
• определение маски (прав доступа к
атрибутам ИО);
• определение ИО при заданной маске;
• использование ИО при заданной маске.
14.
Определение 1. Под определением маски будем понимать
введение или изменение прав доступа к любому ИО или его
атрибутам.
Определение 2. Некоторое определение маски dMi называется
живым в данной функции бизнес-процесса, если существует
маршрут из точки определения маски в данную точку бизнеспроцесса, на котором не встречается никакое другое определение
маски dMj.
Определение 3. Под определением ИО будем понимать любое
изменение его атрибутов при выполнении бизнес-функции или
бизнес-операции.
Определение 4. Определение ИО X называется живым в
некоторой точке (функции/операции) бизнес-процесса, если
существует маршрут из точки определения X в данную точку
бизнес-процесса, вдоль которого ИО X не переопределяется.
15. Модель потоков данных
• Определение 5. Множество всех живых определений
всех аргументов функции/операции называется
средой данных функции/операции .
• Таким образом на первом этапе построения модели
потоков данных бизнес-процесса строится среда
данных — множество всех тех определений каждого из
аргументов бизнес-операции, для которых существует
маршрут из точки определения аргумента в точку его
использования, на котором не встречается никакое
другое определение данного аргумента.
16. Модель потоков данных
Отметим, что в случае бизнес-операции с m аргументами (при m 1) такая модель
является неполной, так как выполнение данной операции в ряде случаев требует
одновременного использования n определений (m n 1) различных атрибутов ИО
из среды данных. Этот факт отражается нотацией контекста данных.
Определение 6. Элементарным контекстом данных операции , имеющей K
аргументов X1, X2, . XK называется множество определений ИО из списка
аргументов, для которых существует маршрут из входной точки бизнес-процесса
в точку , такой что все определения из КД( ) являются живыми при
выполнении операции .
Определение 7. Контекстом данных операции называется множество всех ее
элементарных контекстов.
Таким образом на втором этапе построения модели потоков данных бизнеспроцесса строится контекст данных — множество наборов из n определений
различных атрибутов, для которых существует маршрут из точки входа в бизнеспроцесс в рассматриваемую точку, на котором все элементы набора принадлежат
среде данных (т.е. не переопределяются).
17. Модель потоков данных
Заметим, что элементарный контекст не учитывает порядка выполнения
определений ИО, являющихся аргументами операции . Однако при выполнении
бизнес-процесса такой порядок предполагается. Этот факт отражается с
помощью нотации упорядоченного контекста данных.
Определение 8. Упорядоченным элементарным контекстом данных операции ,
имеющей K аргументов X1, X2, . XK называется последовательность таких
определений из элементарного контекста операции КД( ), что существует
маршрут из входной точки бизнес-процесса в точку , вдоль которого все эти
определения выполняются в порядке, предписанном заданной
последовательностью, и являются живыми при выполнении операции .
Определение 9. Упорядоченным контекстом данных операции называется
множество всех ее упорядоченных элементарных контекстов.
Таким образом на третьем уровне построения модели вводится упорядоченный
контекст данных — множество упорядоченных наборов из n определений
различных атрибутов ИО, для которых существует маршрут из точки входа в
бизнес-процесс в рассматриваемую точку, на котором все элементы набора
принадлежат среде данных и выполняются в порядке, предписываемом данным
набором.
18. Пример
m0
1
M=
2
X=
x1
3
Y=
y1
4
9
5
F(X,Y)
6
8
M=
m1
y2
Y=
7
X=
x2
19.
• Для данного примера среда данных операции
=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).
20.
• Контекст данных содержит следующие
элементарные контексты: КД = < (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).
21.
• Упорядоченный контекст данных включает
дополнительно к вышеперечисленным
элементарным контекстам один следующий
упорядоченный элементарный контекст: УКД
= КД < (y20, x20)>
• Соответствующий маршрут выглядит
следующим образом: (1,2,3,4,5,8,4,5,7,4,5).
22. Критерии тестирования
Критерий 1 требует, чтобы каждый элемент среды данных тестируемой
бизнес-операции был проверен по крайней мере однажды.
Критерий 2 требует, чтобы каждый элемент контекста данных
тестируемой бизнес-операции был проверен по крайней мере однажды.
Критерий 3 требует, чтобы каждый элемент упорядоченного контекста
данных тестируемой бизнес-операции был проверен по крайней мере
однажды.
Критерий 1’ требует, чтобы каждый элемент среды данных каждой
бизнес-операции был проверен по крайней мере однажды.
Критерий 2’ требует, чтобы каждый элемент контекста данных каждой
бизнес-операции был проверен по крайней мере однажды.
Критерий 3’ требует, чтобы каждый элемент упорядоченного контекста
данных каждой бизнес-операции был проверен по крайней мере
однажды.
23. Количество маршрутов
Бизнес-процесс
Критерий
Критерий C1
Перевозки
31
29
Ремонты и техническое
обслуживание
78
75
Обеспечение
безопасности движения
12
12
Материальнотехническое снабжение
68
61
24. Теорема о вложении критериев
Для удобства исследования предложенных критериев пронумеруем их
следующим образом: 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.
25. Что обеспечивает такое преимущество
Учет в моделях потоков данных различных
определений ИО и их одновременного
использования, а также порядка выполнения этих
определений, что позволяет обнаруживать более
тонкие ошибки при обработке данных в бизнеспроцессе за счет выделения более сложных
маршрутов тестирования.
Учет в моделях потоков данных определений маски,
моделирующей права и уровни доступа к ИО, что
обеспечивает более тщательное тестирование и
обнаружение широкого класса наиболее типичных
для бизнес-процесса ошибок.
26. Следствие из теоремы
• Будем говорить, что некоторый критерий 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.
27. Ациклические бизнес-процессы (60% от общего числа)
G1:
G2:
G4:
G3:
28. Следствия из теоремы
• Следствие 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.
29. Граф частичного упорядочивания критериев тестирования на основе операции «не хуже»
Критерий «все маршруты»
C4
C3
C2
Критерий Weyker 3
Критерий Weyker 2
Критерий Rapps 3
Критерий Корела
Критерий Rapps 2
Критерий Rapps 1
Критерий Weyker 1
C1
C0
30. Таким образом, предложенные критерии тестирования позволяют:
обеспечить обнаружение специфических для
бизнес-процессов ошибок в потоках данных,
связанных с их обработкой под различными
масками, обеспечивающими регламенты
доступа;
обеспечить выявление всех тех ошибок,
обнаружение которых может производиться
с помощью традиционных критериев,
основанных на анализе программных
графов и применяемых к бизнес-процессам.
Источник: ppt-online.org
