Прежде всего хотелось бы сказать, что математика помогает привести наши мысли в порядок и эффективно развивает логическое мышление, а это одни из самых необходимых качеств участников разработки программного обеспечения. Говоря о тестировании, то оно в основном касается поведения системы, что ортогонально структурному представлению, общему для разработчиков программного обеспечения. Разница между структурным и поведенческим представлениями заключается в том, что структурное фокусируется на том что представляет собой программное обеспечение, а поведенческое представление учитывает что программное обеспечение делает.
Одна из трудностей тестировщиков заключается в том, что базовая техническая документация или руководство по разработке программного обеспечения обычно пишутся разработчиками и для разработчиков, и в основном акцент делается на структурную, а не на поведенческую информацию. Конечно, как структурные, так и поведенческие части очень важны для тестирования, так как ошибки программирования можно найти в каждой из этих частей. Вот почему мы будем говорить о дискретных математических методах, чтобы показать связь между структурой программы и ее поведением.
В своей повседневной работе инженеры по обеспечению качества (QA) программного обеспечения работают с операциями формул, поведением функций и структурами данных. Они всегда контролируют и проверяют постоянно меняющееся состояние систем, поэтому им необходимо иметь алгоритмическое и математическое мышление для понимания логики программного обеспечения.
Если разработчик использует математический подход в своей работе, в результате все логические операции будут связаны друг с другом, действия будут следовать логической цепочке, а каждая функция будет рассматриваться структурно.
Дискретная математика помогает нам найти оптимальное решение в различных ситуациях. Например, можно найти наиболее подходящий набор тестовых случаев (Test cases), не охватывая все возможные варианты. Более того, дискретная математика помогает нам визуализировать точную часть программного обеспечения, которая была реализована и покрыта тестами.
К сожалению, мы не живем в идеальном мире, и ожидаемые реальные результаты применения программного обеспечения и фактические результаты могут отличаться. Итак, главная цель отдела обеспечения качества (QA) — максимально эффективно охватить как можно больше тестовых случаев.
Чтобы показать вам эту концепцию более подробно, мы создали следующую диаграмму Венна с примером, который мы ранее обрисовали в общих чертах:
Приведенная выше диаграмма Венна описывает множество ситуаций, тем самым помогает проиллюстрировать и определить наборы ситуаций. Например, это может помочь нам увидеть разницу между наборами объектов. Дискретная математика помогает анализировать и оптимизировать наборы действий, которые могут влиять на разрабатываемое программное обеспечение.
Теория множеств
Используя принципы теории базовых множеств, мы можем создать псевдокод, чтобы проиллюстрировать все возможные случаи для приложения «Next Day» (программа, которая вычисляет, какой день будет следующим, используя введенную дату):
M1={month:month has 30 days}
M2={month:month has 31 days except December}
M3={month:month is February}
M4={month:month is December}
D1={day:1<=day<=28}
D2={day:1<=day<=29}
D3={day:1<=day<=30}
D4={day:1<=day<=31}
Y1={year:year is a leap year}
Y2={year:year is not a leap year}Этот псевдокод уже подготовлен для разработки и тестирования приложения, поэтому тестировщики также могут применять все возможные контрольные примеры, основываясь этими данными. Использование данных в этом формате помогает увеличить скорость разработки и снижает возможность ошибки.
Теория графов
Большая часть дискретной математики — это так называемая «теория графов», которая изучает графы. Графы используются для представления связи между некоторыми объектами или данными, и компьютерная сеть является подходящим примером графа.
Графы также имеют основополагающее значение для процесса разработки программного обеспечения. Например, используя граф мы можем разложить сложные функции на несколько более мелких частей, что помогает нам более эффективно понимать бизнес-логику.
Графы могут быть направленными и ненаправленными, это означает, что мы можем перемещаться от узла к узлу в одном направлении или в обоих направлениях (в случае ориентированного графа), или мы не можем перемещаться от одного узла к другому (если граф является направленным строго в одном направлении)
Итак, давайте вернемся к тестированию программного обеспечения и представим, что у нас есть поток некоторого процесса (например, перемещение задачи в какой-то системе отслеживания задач); у нас есть условие некоторой задачи, и мы можем переместить ее на другой этап (ориентированный граф), или мы можем достичь некоторой точки, где мы ничего не можем сделать с сущностью (неориентированный граф). При таком подходе к визуализации мы можем легко собрать набор всех возможных действий, доступных для этой сущности:
Давайте продолжим и посмотрим на матрицу смежности, которая может быть построена на основе неориентированного графа. В приведенном ниже примере элементы матрицы смежности указывают, являются ли пары вершин смежными или нет:
Теперь представьте, что узлы являются условиями некоторых сущностей, и если мы построим матрицу смежности для этого графа (набора сущностей), мы увидим конечный набор действий, которые мы можем предпринять. Например, изменение статуса с узла «0» на узел «1» доступно, потому что они связаны друг с другом. Но сущность «0» не может быть изменена на стадию «2» или «3», как мы можем видеть из нашей матрицы — в ячейках прописан «ноль». Используя эту матрицу, мы можем исключить ненужные наборы этапов сущности и сократить набор тестовых случаев.
Еще одна матрица, которую мы можем использовать для сбора тестовых случаев, — это матрица инцидентности, которая показывает отношения между двумя классами объектов. На следующем рисунке мы видим неориентированный граф и его матрицу инцидентности: «1», «2», «3» и «4» являются узлами (сущностями), «e1», «e2», «e3» «e4» — ребра графа, а матрица иллюстрирует сущности и действия, которые мы можем с ними сделать. С узлом «1» мы можем выполнять действия «e1», «e2» и «e3», но действие «e4» недоступно для узла «1.». Этот метод очень помогает при создании набора тестовых случаев.
Представим, что тестировщик получил список сущностей и действий, которые можно проводить с этими сущностями. С помощью этой матрицы он может сократить набор тестовых случаев. Сокращение количества тестов является очень важной частью процесса тестирования программного обеспечения. Тестирование программного обеспечения в значительной степени зависит от сокращения количества тестовых случаев, и при таком подходе охват тестированием и избежание избыточности максимально увеличены.
Цель тестировщиков программного обеспечения — охватить продукт, используя эффективные контрольные примеры, которые позволяют тестировать все возможные комбинации действий. Тестировщики могут добиться успеха, прилагая минимальные усилия, используя подходы дискретной математики (алгоритмы), чтобы найти оптимальный набор тестовых случаев и максимизировать эффективность процесса тестирования программного обеспечения.
Дискретная математика также помогает нам понять, как на самом деле создается программное обеспечение, потому что все программное обеспечение использует алгоритмы и методы дискретной математики и математической логики. Поэтому, если мы понимаем, как это работает, мы можем найти ошибки или проблемы внутри программы, которые не могут быть обнаружены со стороны пользователя.
Сети Петри
Давайте рассмотрим пример того, как приложение работает на микросервисной технологии с помощью «Сетей Петри» (динамический граф):
Здесь мы видим, что система имеет начальное состояние и должна получить некоторый сигнал, который отправляется из другой службы (появляется маркер). В зависимости от полученного результата должно быть выполнено следующее действие. Таким образом, сеть Петри иллюстрирует динамику всей системы. Если какая-либо проблема существует, мы сможем локализовать дефект быстрее.
Нейронные сети
Искусственные нейронные сети также основаны на принципах графа. Они имитируют возможности обработки информации нейронами человеческого мозга. Каждая часть нейронной системы основана на графе, который содержит «входные» узлы, «скрытый» слой и «выходные» узлы.
Некоторые данные поступают на входной слой, а алгоритмы скрытого слоя обрабатывают эти данные и отправляют результат на выходной этап. Таким образом, нейронная сеть может выполнять действия на основе этих данных. Нейронные сети также состоят из множества похожих графов с другой логикой, поэтому они могут принимать решения на основе входных параметров.
Миллениум Тестирование
Наш последний пример использования дискретной математики в тестировании включает построение процесса тестирования программного обеспечения. В настоящее время существует множество методологий и подходов называемые «millenium testing», которые были разработаны задолго до их фактического использования, начиная с 2000-х годов, когда разработка программного обеспечения начала стремительно развиваться.
BDD (Behavior Driven Development) является частью так называемого Millenium тестирования, эта методология является расширением TDD (Test Driven Development). BDD позволяет тестировщикам устанавливать более тесную связь между критериями приемки для данной функции и тестами, используемыми для проверки этой функциональности. BDD может преобразовывать структурированные операторы на естественном языке в исполняемые тесты, тем самым вносит больше ясности и понимания бизнес стороне и стороне разработки, так как они начинают говорить на одном общем языке. Основная структура рабочего процесса BDD также основана на динамическом графе (Petri Net).
Как видно из этой структуры, каждый процесс сопровождается другим процессом, и он не может переместиться на следующий этап, пока предыдущий этап не будет завершен. Еще раз, принципы дискретной математики помогают нам понять процесс более эффективно.
В заключение хотелось бы еще раз перечислить преимущества применения дискретной математики в процессе разработки программного обеспечения:
- Помощь в понимании бизнес-логики требуемой функциональности
- Упрощение возможности делить сложные задачи на более простые
- Предоставление специалистам возможности проводить эффективное тестирование с меньшими усилиями
- Помощь в понимании и визуализации структуры всего, что мы хотим
Приведенные выше примеры демонстрируют, как дискретная математика может быть использована для эффективного повышения производительности тестирования. Каждый аспект дискретной математики может помочь разработчикам понять общий рабочий порядок программного обеспечения и его принципы в течение всего жизненного цикла разработки программного обеспечения.
Комментарии (5)
Gutt
15.05.2019 15:50Осталось приспособить дискретную математику к тестированию
заголовков статей
lxsmkv
16.05.2019 03:02+1Похоже на какую-то курсовую работу. На три с минусом. Если взять некоторые предложения, то поверхностность жутко бросается в глаза:
Некоторые данные поступают на входной слой, а алгоритмы скрытого слоя обрабатывают эти данные и отправляют результат на выходной этап. Таким образом, нейронная сеть может выполнять действия на основе этих данных. Нейронные сети также состоят из множества похожих графов с другой логикой, поэтому они могут принимать решения на основе входных параметров.
Илидискретная математика помогает нам визуализировать точную часть программного обеспечения, которая была реализована и покрыта тестами.
Никак не обьяснено как вы применяете этот метод. В чем вы меряете требования, наблюдаемое поведение и тестовые сценарии. И почему наблюдаемое поведение одельное множество? Если требования и тестовые сценаии еще и можно как-то количественно охарактеризовать, то как количественно охарактеризовать «наблюдаемые поведения системы»?
…
Чтобы показать вам эту концепцию более подробно, мы создали следующую диаграмму Венна с примером, который мы ранее обрисовали в общих чертах
Мысли так и путаются, заплетаются. Как будто писали второпях, пытаясь затронуть как можно больше инструментов, но ни один не раскрыт хоть сколько-нибудь полно.
Надеюсь, что тестовое покрытие у вас не такое поверхностное как эта статья ;)
Практически сложность применения в том, что у нас нет машинно читаемой спецификации, у нас нет графа состояний системы. Если начать чертить граф состояний и переходов, то можно его чертить до пенсии, а спецификации постоянно меняются. Тестирование в это время будет стоять на месте.
Практически, комбинаторику и графы можно применять для оптимизации тестовых данных (pairwise), для достижения взаимопонимания между участниками команды (граф состояний и переходов) по отдельно взятой части приложения. Но никак нельзя в тестировании ставить академический подход во главу угла.
Про т.н. «тестирование на основе модели» есть достатчно много статей, но я не встречал ни одного проекта где бы оно практически применялось.
В нашей системе более миллиона строк кода, если заглянуть хотя бы в один класс, и попытаться очертить сколько состояний содержит этот класс начинает кружиться голова, а классов десятки тысяч. И код постоянно меняется.
Пока одни чертят графики другие находят баги. Вообще, попытка формализировать систему, нацеленную на широкий круг потребителей (т.е. не какую-то специальную систему управления, а пользовательское приложение) говорит о том, что вы не пытаетесь понять пользователя и назначение системы, а пытаетесь спрятаться за теорией.
У нас на проекте тоже есть такой чувак, который пытается выстроить тестирование по учебнику. Только вот «по дырочкам никогда не рвется». Нам не нужны все случаи нам нужны критические случаи, сложные случаи, неочевидные случаи. Можно долго чертить графы состояний и переходов, а потом выяснить что приложение даже не запускается. Вот где ужас.
Удивительно, но ребенок находит проблемы в системе безо всяких математических моделей:
При подготовке полета «Аполлона-8», первого пилотируемого космического корабля, добравшегося до орбиты Луны, Маргарет Гамильтон удалось обнаружить серьезную уязвимость, но никто не поверил, что она представляет реальную угрозу. Найти эту уязвимость помогла дочь Гамильтон, которая играла с симулятором компьютера «Аполлона-8», пока ее мать работала. В какой-то момент она включила последовательность P01, запускаемую перед стартом космического корабля, когда симулятор был уже в «полете». Запуск P01 в неподходящий момент привел к сбою; и хотя у космонавтов нет никаких причин допускать такую ошибку, Гамильтон решила добавить несколько строчек кода — сделать своего рода «защиту от дурака». В NASA воспротивились, сочтя, что прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться. Тогда Гамильтон включила строчку «Не запускайте P01 во время полета» в документацию, но и это показалось руководству излишней мерой предосторожности.
Маргарет Гамильтон: «Пацаны, я вас на Луну отправлю»
Вскоре после рождества в 1968 году, когда «Аполлон-8» должен был покинуть орбиту Луны и отправиться на Землю, астронавт Джеймс Ловелл сделал именно то, чего от него никак не ждали — по ошибке запустил P01
Тестировщик это человек, думающий не столько о полном покрытии в соответствии с математической моделью, сколько о конечном пользователе. Классный тестировщик, эффективный тестировщик, это тот, который «знает куда ударить». Понимая принцип устройства приложения, он интуитивно чувствует, где скорее всего недогляд.
saege5b
16.05.2019 10:14Идеальный тестерЛюбой сотрудник некрупной IT-компании подтвердит, что четверг – самый скучный день недели. В самом деле — в понедельник все разгребают пришедшую за выходные почту, ругаются с поставщиками кофе и воды для кулера, и курят на лестнице, рассказывая друг другу анекдоты для борьбы со сном и похмельем. Во вторник задачи розданы, силы свежи, и код пишется на одном дыхании. В среду количество полезной работы за единицу времени достигает своего апогея… Пятница, естественно, проходит под знаком ожидания чьего-нибудь дня рождения или просто пивной вечеринки, поэтому квака начинается с самого утра, и большинство народу даже не делает вид, что работает. Те немногие, кто затрудняется имитацией деятельности, держат Экслера или RSDN открытым в пятом окне эксплорера, чтобы в таскбаре не было видно адреса.
А вот четверг – это момент кризиса. Переход от работы к удовольствию. Начинать читать обзоры фильмов еще рановато, а работать не дают мысли о завтрашней пятнице.
Этот четверг ничем не отличался от обычных. Часов с 12 я начал испытывать просто нестерпимое желание найти повод поотлынивать. Поэтому когда в аське всплыл вопрос шефа «Не хочешь пособеседовать тестеров?», я долго не думал.
Напрягаться я не собирался, благо «собеседников» и без меня было вполне достаточно – технический директор, директор по маркетингу и главный (он же единственный) сисадмин.
Заливая четвертую за сегодня кружку Nescafe Gold водой из кулера (наш народ зовет эту жидкость смолой, за цвет, вкус и консистенцию), я пообщался с директорами и выяснил, что, во-первых, место у нас одно, а во-вторых, кандидатов двое. Такой высокий конкурс директор по маркетингу объяснял грамотным проведением рекрутинговой кампании (он сам составлял макет объявления для нашего сайта), а технический директор – замедлением падения курса доллара. Поскольку мы работаем на заказчиков, не говорящих по-русски, за курсом доллара наши сотрудники следят пристальнее, чем ребята из Редмонда за курсом акций Microsoft.
Налив себе кофе, мы переместились в конференц-зал.
Первым кандидатом оказалась симпатичная девушка в джинсах и свитере. Я пропустил мимо ушей ее резюме, обратив внимание лишь на упоминание какого-то сертификата Quality Assurance Engineer. Во время собеседования девушка вела себя довольно-таки уверенно, то и дело поминала Transition Phase, CMM, ISO9000 и трехлетний опыт работы. Все это время я смотрел в окно и думал о том, что сидеть она будет в комнате через коридор, и что я не смогу использовать обычный лексикон при объяснении тонких моментов тест-плана.
Вторым был парень-студент, во взгляде которого читалась острейшая нужда в денежных средствах. На этот раз я принял участие в собеседовании и узнал, что он – гениальный программист и веб-дизайнер, что у него даже есть свой сайт, и что он сейчас пишет IDE для PHP на MAC. Я бы выяснил, почему он предпочитает MAC, но поймал взгляд технического директора и свернул беседу.
После ухода кандидатов мы несколько минут поспорили о проблемах девушек в чисто мужских коллективах и проблемах излишней амбициозности читателей журнала ксакеп, и сошлись на том, что «теперь хоть матов будет меньше», — девушка была очевидным выбором. Мы уже направились к выходу, когда у технического зазвонил мобильник. Обменявшись парой реплик со своим собеседником, технический зажал микрофон рукой и шепотом известил нас о том, что у входа в офис ждет еще один кандидат. Мы переглянулись. Решение было уже принято, но как-то неудобно было давать от ворот поворот человеку, не поленившемуся притащиться к нам на окраину. Технический велел охране впустить, и мы вернулись в конференц-зал.
Третий кандидат выглядел немного моложе моих лет. Улыбнувшись, он представился и сел в кресло, бросив папку на стол. Маркетинговый директор порылся у себя в бумагах и спросил:
— Извините, я что-то не вижу вашего резюме. Вы не присылали его нам?
— Присылал, — ответил кандидат, с интересом оглядываясь вокруг, — Но у вас почтовый сервер глючит.
Это было не очень хорошее начало. Мы все-таки IT-компания, и достаточно тщательно следим за тем, чтобы у нас все работало. Если у него нет резюме – пусть так и скажет и не тратит наше время. Технический директор с некоторой даже обидой спросил:
— Может быть, проблема все же не в сервере? Со связью что-нибудь, или почтовый клиент не сработал? Вы, кстати, не с мейл.ру отправляли?
— Нет, — ответил кандидат, продолжая оглядываться. Его внимание привлекла настольная лампа. Щелкнув пару раз выключателем, он сказал: «Смотрите-ка!» – и полез под стол. Лампа вспыхнула и перегорела. Кандидат вылез из-под стола и продолжил:
— Если оставить выключатель в промежуточном положении, а потом включить шнур в розетку, лампа перегорит!
— Спасибо. Может быть, вы принесли резюме с собой? — поинтересовался я.
— Да, конечно, вот оно, — он подал лист А4, — а вот это — распечатка ответа вашего почтового сервера, — он подал еще один лист.
Сисадмин с интересом взял его из моих рук и пробежал глазами:
— Но!.. А как?.. Странно… Я сейчас! — с этими словами он почти выбежал из комнаты.
Директора тем временем изучали резюме. Я смотрел на кандидата. Он повернулся назад, и что-то настраивал в кресле. Это было обычное пятилапое офисное чудовище на колесиках, распространитель сколиоза и отложения солей. Наконец в кресле что-то щелкнуло, и потенциальный тестер оказался на полу. Это, казалось, ничуть его не расстроило:
— Я так и знал! Дефект в системе регулировки пневматического амортизатора. Если отогнуть ручку вверх, а потом вбок…
— Принеси ему стул, — попросил меня технический директор, и я вышел из комнаты.
В коридоре я встретил сисадмина. На его лице было такое выражение, как если бы он обнаружил пиво в одной из бутылей для кулера.
— Что там с почтовиком? — спросил я.
— Ты будешь смеяться. В его письме MIME-boundary нарушает RFC 2046. Ничего страшного, но наш сервер падает при приеме такого текста! Измени хотя бы один символ – все пройдет нормально. Я посмотрел в логи – сервер падал четыре раза в понедельник. Судя по всему, именно из-за этого товарища.
Вернувшись, мы застали технического директора за попытками задвинуть жалюзи. Кандидат увлеченно объяснял, каким именно способом он сумел их заклинить. Маркетинговый директор смотрел на него уже почти с ненавистью. За какие-то пять минут это чудо сумело сломать лампу, кресло, жалюзи и продемонстировать багу в нашем почтовике.
— А вот стол у вас хороший, основательный! — сказал кандидат. Как говорил Оззи Осборн, «я начал понимать, что приходит время прощаться».
— Мы с вами свяжемся, до свидания.
— Можно, я от вас позвоню? — спросил этот демон разрушения.
— НЕТ! — ответил технический директор таким голосом, что кандидат мгновенно исчез.
Налив себе еще немного кофе, мы обсудили результаты собеседования. Увы, девушка не прошла.
Сертификат QA Engineer не заменит природного таланта — с таким парнем в команде нам просто не удастся сдать софт, если в нем будет хотя бы один баг.
Завтра пятница, значит – знакомство с новым членом коллектива. Пиво и бильярд в Потерянном Кластере. Пожалуй, я лучше пойду в Пива.NET — пусть попса, но мало ли что он захочет протестировать в баре…Letsifer
16.05.2019 06:29Говоря о тестировании то оно в основном касается поведения системы что ортогонально структурному представлению, общему для разработчиков программного обеспечения.
Запятые пропущены перед то и перед что, из-за чего это предложение удалось понять только раза с 3-4, исправьте, пожалуйста =)
akryukov
Спасибо, что затронули эту тему. Очень важно показать применимость теории графов в реальной работе. Я как то размышлял по этому поводу и проводил семинар на работе.
Теперь критика. Считаю что тема в статье не раскрыта.
Не увидел терминов "Критический путь", "классы эквивалентности". Не упомянуто применение комбинаторики в тестировании, хотя это тоже часть дискретной математики.
Вы описали отличие результатов математического подхода. Однако не упомянули, за счет чего достигаются такие результаты. Какие конкретно действия должен делать разработчик, какими принципами он должен руководствоваться чтобы получился "математический подход"?
В разделе про теорию множеств
вы рисуете сову. Как именно вы использовали упомянутую теорию, чтобы сформулировать эти тестовые сценарии?
Почему требования к программе Next Day вы написали в скобках? Выглядит как будто они совсем не важны.
В каком именно формате? Вы не описали нотацию. Я, конечно, могу ее додумать самостоятельно. Но раз уж вы предлагаете формат, описывайте его до конца.
В разделе по теории графов не понятно зачем нам матрицы смежности и матрицы инцидентности. Нам ведь нужно в итоге получить тестовые сценарии. Как сформулировать тесты, используя эти матрицы?
Вы упомянули нейронные сети, но ничего не сказали про то, как их тестировать. Ну допустим там граф. Что дальше?
Вам не удалось раскрыть, как именно связана дискретная математика, миллениум тестирование и BDD.