Теория

Продолжаем искать рецепт блюда "Алгоритм". В меню обусловленная и связная последовательность исполнения.

Задача

Мы поставили себе сложную задачу: сформулировать, что делает алгоритм способом решения наших задач, и какие процессы являются для него "действиями". Решение этой задачи получается объемным, и поэтому его описание разбито и будет представлено в виде серии статей.

В качестве основы для решения мы используем разбор существующего определения алгоритма, согласно которому алгоритм является "набором инструкций, описывающих порядок действий исполнителя для решения некоторой задачи". Целью нашего разбора является попытка избавиться от необходимости участия человека в процессе формирования и применения алгоритма. Один из наиболее известных шагов в этом направлении уже выполнен Аланом Тьюрингом, и в его результате мы избавились от необходимости участия человека для исполнения алгоритмов математических расчётов. И наш мир не стоит на месте: на текущий момент программисты способны "научить" компьютер исполнять много других полезных (и не очень полезных) алгоритмов.

Но мы не будем останавливаться на этом значительном успехе. Для дальнейшего движения необходимо рассматривать все понятия и процессы в определении алгоритма, которые неявно предполагают деятельность человека. В предыдущей статье серии (Часть 1) уже разобрано первое такое понятие "действие". Это необходимо, потому что человек при создании алгоритма волен сам находить и формировать набор "действий", с использованием которого он собирается решить задачу. В процессе анализа того, на какие признаки "действия" опирается человек в этом поиске и выборе, мы отметили, что важным, но не единственным таким признаком является Повторимость "действия". На основе этого признака появляется возможность как минимум процесс поиска "действий" передать нашему компьютеру. И в первом приближении это позволит отказаться от услуг человека в этой части работы с алгоритмом.

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

Группировка действий в алгоритм

Как можно объединить "действия" в алгоритм? Ведь не всякое объединение "действий" имеет тождественный результат? Это объединение должно как-то "описывать порядок". Для разбора основ такого объединения следует поискать разные примеры синтеза алгоритма, и для начала желательно, чтобы эти примеры были максимально просты по структуре. И только разобравшись с "тривиальными" ситуациями, следует пробовать перейти к более сложным.

В первой статье мы упоминали, что химические реакции являются "действиями". Давайте попробуем понаблюдать за работой химика. В его арсенале большое количество "действий" (химических реакций). Эти "действия" основываются на разных "объектах" химических веществах, а, вернее, на молекулах этих веществ. Рассмотрим ситуацию, когда учёный-химик пытается найти решение следующей задачи: . У химика уже есть в арсенале "действия", выделенные на основе признака повторимости:

Для решения поставленной задачи химик выбирает, упорядочивает и объединяет некоторые действия, и тем самым находит алгоритм: . Это решение полностью согласуется с выше приведенным определением алгоритма, в котором под словом исполнитель химик подразумевает себя и других химиков. При этом исполнение в химической лаборатории можно трактовать как управление последовательностью процессов описанных алгоритмом.

Обратим внимание, что алгоритм формирования химиком своего "алгоритма" достаточно прост и не требует большого труда написать автоматическую систему помогающую химику в его творческом поиске. На какие признаки будет опираться эта система? Конечно, главным признаком будет совпадение типов молекул в финальной стадии предшествующей реакции и в начальной стадии следующей реакции.

Построение дерева решений на этом признаке можно строить с двух сторон:

• от стартового вещества, указанного задачей, в прямой последовательности исполнения реакций;
• и от вещества , являющегося результатом поставленной задачи, с использованием обратной последовательности.

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

Алгоритм построения алгоритма для химика Прост!

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

В живой клетке также протекают цепочки химических реакций, но совершенно определенно можно утверждать, что никакой химик не контролирует там пробирками смешивание веществ. Это очень важное наблюдение, что сложная цепочка процессов (например, цикл Кальвина) может выполняться без "исполнителя" в том смысле, какой предлагается определением алгоритма. Это странно, и можно сказать, что это вовсе не имеет никакого отношения к алгоритму.

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

Если судить по процессам эволюции не нужен не только исполнитель. Ведь как подметил Дарвин, и подтвердили фактами многие его последователи: преобразование и развитие этих сложных цепочек процессов в клетке могут происходить самостоятельно, то есть без участия обозначенного выше химика. Это для нашего исследования алгоритма очень важно. А вот отсутствие привычного исполнителя не должно нас огорчать. Тем более что в живой клеточке он есть, только имеет структуру, отличающуюся от исполнителя-человека и исполнителя-компьютера. Нам даже полезно в текущем анализе, что структура исполнителя в клетке так сильно отличается. Полезно и то, что она очень проста. Попробуем обнаружить, где спрятался этот 'Демон Максвелла', и для этого рассмотрим, что в клетке контролирует последовательность исполнения химических реакций.

Исполнитель

Очевидно, что взаимодействие химических веществ в клетке происходит при контакте их молекул в процессе теплового движения. Эти процесс равномерно перемешивает свободные молекулы клетки и обеспечивает встречу тех, которые могут при контакте осуществить химическую трансформацию (реакцию). Что контролирует последовательность таких трансформации? Ответ прост это изменения концентрации молекул соответствующих веществ. Если концентрация мала (или этот элемент отсутствует в клетке), то реакция производства останавливается. Это не очень похоже на контроль исполнения алгоритма привычный программисту, но этот контроль работает, и циклические последовательности исполнения реакций в живой клетке происходят снова и снова и без нашего участия. В клетке можно найти более эффективную реализацию контроля исполнения, для этого нам нужно вспомнить об еще одном типе химических реакций.

Рассмотрим этот подарок природы программисту реакции, которые характеризуются использованием особенного участника. Этот участник не изменяется, но контролирует реакцию, присутствуя в ней от начала до конца взаимодействия.

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

Катализатор (необходимый компонент процесса, не изменяющийся в ходе выполнения и задающий способ преобразования других компонентов) это ещё химический, но уже более привычный нам "исполнитель алгоритма". Интересно, что если этот катализатор в дополнение имеет сложную структуру, объединяющую несколько более простых катализаторов, то он частично реализует смысл фразы "описание порядка" из терзаемого нами определения алгоритма.

Для нашего разбора одними из самых наглядных исполнителей-катализаторов в клетке являются цепочки ДНК и РНК. Если немного ориентироваться в клеточных процессах с участием ДНК(РНК), то можно, наблюдая за их исполнением, найти много интересных структурных алгоритмов. В следующем видео целая библиотека приемов программирования: параллельных процессов, работы с линейными списками, трансформациями структур, маркерами исполнения...

Даже не верится, что вся эта "программная" красота, у которой любой может поучиться написанию параллельных программ, исполняется на основе концентрации и линейной структуры ДНК. Именно этих двух компонентов. То есть "описание порядка", заданное в ДНК, трансформируется в "описание порядка", задаваемое концентрацией. В следующих статьях мы увидим, что и все "человеческие" алгоритмы используют эти две составляющие:

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

Отметим, что порядок исполнения в среде мы уже рассматривали ранее. Этот порядок повторяющиеся процессы среды, то есть "действия", которым была посвящена предыдущая статья.

Можно рассматривать процессы в живой клетке и далее. Тогда в дополнение к подсмотренному процессу контроля исполнения алгоритма мы найдем массу важных для программиста уже готовых алгоритмов и алгоритмов работы с алгоритмами:

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

Но отложим пока эти "вкусные" алгоритмы, и обязательно вернёмся к ним, когда расправимся с рецептом главного "блюда" программиста Алгоритма.

Выводы

Попробуем собрать всё, что мы отметили рассматривая пример химического "алгоритма".

• задаваемый определением алгоритма исполнитель не всегда является объектом;
• контроль исполнения, то есть "порядка действий", могут выполнять закономерности существующих процессов среды (таких как изменение концентрации молекул);
• контроль исполнения ("порядка действий") может основываться на структуре объекта (например, линейной структуре ДНК);
• если структура объекта контролирует исполнение алгоритма, и этот объект не изменяется в процессе исполнения то такой объект наиболее точно соответствует привычному смыслу слова "исполнитель" из определения алгоритма.

Чтобы разделять алгоритмы по способу контроля исполнения введём два термина, которые нам понадобятся в следующих статьях:

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

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

• взаимодействие со средой;
• начальный набор "действий";
• система учёта "полезности" изменения в среде в результате исполнения "действия".

Да, этот набор близок к системам автоматического управления. И это хорошо, ведь эта область научно проработана, а значит её методы будут помогать нам в работе.

Другим положительным моментом в контексте текущей статьи является то, что модели процессов синтеза алгоритма на уровне изменения цепочки ДНК уже успешно используются в науке причем с двух сторон:

• в биологии для расшифровки Генетического кода и для методов редактирования, внедрения и использования генов (Генной инженерии),
• в программировании для решения задач оптимизации с использованием Генетических алгоритмов (подвида Эволюционных алгоритмов).

Здесь следует отметить, что "генетически-эволюционный" синтез алгоритмов (как тип алгоритма работы с алгоритмами) это не самый эффективный метод, который природа нам может продемонстрировать. У этого метода есть ограничения. Прежде всего они связаны с необходимостью перебора большого количества маленьких шагов изменений на большой выборке родственных исполнителей алгоритма. При этом полезность результата таких изменений никак не направляется согласно решаемой задаче и оценивается уже после совершения этих изменений, что приводит к "гибели" большей части проделанной работы (созданных, но нежизнеспособных алгоритмов). Это является недостатком только с одной стороны много "холостой" работы. Но это и достоинство: с точки зрения элементной базы, требуемой для построения такой системы работы с алгоритмами. Ведь каждый элемент и каждая операция в такой модели могут быть достаточно просты, и это не мешает системе работать изготавливать полезные алгоритмы.

Где же искать более эффективные методы работы с алгоритмом? Смотреть нужно в сторону более развитых живых организмов! В этом пути подсматривания у природы нас ждет две ключевые остановки: Память и Язык. Следующая статья серии будет посвящена синтезу алгоритма на основе процедур запоминания. Этот синтез насыщен приемами, более эффективен и, что очень странно, наименее научно проработан. Дополнительной пользой от рассмотрения синтеза алгоритма на основе памяти является возможность построить мостик между методами генетического синтеза алгоритмов и методами синтеза алгоритмов с использованием языка. Но не будем сильно забегать вперёд, ибо Память сама по себе очень полезна, и похоже описание её возможностей в алгоритмическом мире не помещается в формат одной следующей статьи.

Спасибо Вам за внимание.

Отзывы

Буду очень благодарен за отзывы, пожелания и предложения, так как они помогают мне скорректировать направление развития работы в этой области.

Отдельное волнение у меня есть по стилю повествования и форматированию, используемым в статье (кавычки, абзацы, курсив). Напишите, пожалуйста, если у Вас есть замечания к ним. Можно личным сообщением.

Ссылки

• Open source (GPL) проект: (Общая теория алгоритмов wiki)
• Заглавная статья темы "Разрабатываем теорию алгоритмов как проект с открытым исходным кодом": (Статья Хабр 0)
• Первая статья серии "Что такое алгоритм?! Действие"(Статья Хабр 1)
• Все рисунки к статье (кроме заглавного) сформированы сообществом Wikipedia. Лицензия (Creative Commons Attribution-Share Alike 4.0 International)

В современном мире основным источником информации о бытовом товаре для покупателя является интернет, посредством которого можно легко и быстро найти, сравнить, выбрать и даже купить модель товара того или иного типа. Однако мало кто из покупателей задумывается о том, что стоит за формированием контента, на основе которого он этот выбор делает.

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

Контент о товаре условно можно подразделить на несколько видов:

1. Общая информация (фото, видео, редакторский текст).
2. SEO (обвес для продвижения, поиска, сниппеты, микроразметка).
3. Техническое описание (характеристики).
4. Файлы документации.
5. Связанные товары (сопутствующие, зависимые, обязательные, альтернативные и т.п.).

Информационная модель

В данной статье мы рассмотрим контент третьего типа техническое описание (на самом деле, на основе этого контента можно получать почти все остальное).

Такой контент, как правило, представляет собой таблицу, состоящую из пар Атрибут: Значение. При этом под атрибутом следует понимать некоторое обособленное свойство группы близких по назначению товаров, отражающее их функциональные, физические и/или потребительские качества. Значение атрибута это реализация такого свойства в данном конкретном товаре (говоря алгебраическим языком, значение есть действие атрибута на товар).

Атрибуты могут быть числовыми, категориальными и текстовыми.

Числовой атрибут представляет собой линейную шкалу, с помощью которой товары можно сравнивать между собой как обычные действительные числа. Как правило, это физическая величина (вес, объем, частота, мощность и т.п.) с единицей измерения (масштабом), либо количественный атрибут (без масштаба). Числовой атрибут в каждом товаре реализуется в виде конкретного числового значения с конкретной единицей измерения. Иногда два числовых атрибута объединяют в один для реализации интервального значения (от и до).

Категориальный атрибут представляет собой конечный список токенов (слов, словосочетаний, наименований, обозначений и т.п.) и в каждом конкретном товаре реализуется некоторым (возможно, пустым) подмножеством данного списка.

Наконец, текстовый атрибут в качестве значений может принимать любой текст из заданного алфавита, т.е. является аналогом категориального атрибута, но с бесконечным множеством возможных значений (звезда Клини в данном алфавите).

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

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

Отсюда возникает дилемма: какой набор атрибутов, с одной стороны, достаточен для исчерпывающего (делающего его уникальным) описания одного товара, а с другой стороны, сколько вообще нужно атрибутов для того, чтобы адекватно описывать, сопоставлять и сравнивать товары в интернет-магазине или маркет-плейсе.

Как обычно, истина где-то посередине. Все товары необходимо разделить на группы таким образом, чтобы внутри каждой группы было как можно меньше малоиспользуемых атрибутов (крайний вариант: на каждый товар свой набор атрибутов) и в то же время количество этих групп должно быть как можно меньше, а их объем не должен сильно варьироваться от группы к группе (крайний вариант: единый набор атрибутов для всех товаров, т.е. одна группа товаров).

Обычно (и, как правило, эта логика оправдывается) принято подразделять товары на группы в соответствии с их функциями и потребительскими свойствами. Не стоит, например, искать одинаковые наборы атрибутов у микроволновой печи и бензиновой газонокосилки. В то же время, чайники и термопоты вполне могут быть объединены в одну группу товаров с одинаковым набором атрибутов.

Пара (Группа товаров: Набор атрибутов) называется информационной моделью (инфомоделью, моделью).

Таким образом, информационная модель представляет собой многомерное пространство (гиперкуб), измерениями в котором выступают атрибуты, а точками конкретные физические товары, а точнее, их представление в данной модели. Инфомодель эволюционирует во времени, т.к. пополняются списки значений категориальных атрибутов, добавляются новые атрибуты и единицы измерения.

Вариативность инфомоделей

Вспомним теперь о том, что товары, очень близкие по свойствам (одного назначения), производятся различными компаниями, количество которых может достигать нескольких сотен. У каждого производителя имеется свое собственное описание продукции, а значит, свое разбиение товаров на группы и своя информационная модель для каждой группы. Получается, что хотя производители и говорят практически об одном и том же, они пользуются разными формальными языками.

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

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

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

Таким образом, в общем случае мы имеем задачу двойного преобразования технического контента:

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

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

Трудности перевода

Перечислим некоторые из трудностей преобразования инфомоделей:

1. Разбиение товаров на группы у доверенных источников может отличаться.
2. Набор атрибутов в инфомоделях у всех доверенных источников разный (начиная от названий атрибутов и списочных значений и заканчивая используемыми физическими величинами).
3. Язык (человеческий) моделей также может быть разным.
4. Единицы измерения в числовом атрибуте могут указываться не в системе СИ и/или входить в название атрибута или в его значение.
5. Товары могут быть описаны недостаточно полно.
6. Значения могут быть ошибочными (даже у доверенных источников).
7. Клиентские фиды и каталоги сильно отличаются своими требованиями.

Из перечисленных проблем возникают вопросы-задачи, знакомые всем, кто занимается обработкой (больших) данных.

• Как организовать свою внутреннюю информационную модель, чтобы максимально точно вместить описания доверенных источников и максимально полно и адекватно сформировать данные для клиентских каталогов?
• Как очистить входные данные от шума?
• Как формализовать операторы преобразования информационных моделей на этапах импорта и экспорта?

Атомизированная модель

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

С другой стороны, чтобы максимально упростить синтез новых информационных моделей для клиентской стороны (экспорт), внутренняя модель также должна быть максимально структурирована и разбита на элементарные атрибуты так, чтобы операторы экспорта смогли бы сложить из них максимальное разнообразие внешних моделей (с понижением размерности инфомодели).

Такая атомизированная модель обладает рядом преимуществ по чисто комбинаторным причинам. Действительно, имея в арсенале всего три характеристики A, B, C, мы можем составить из них как минимум 5 (число Белла при n=3) непустых моделей ({A,B,C}, {A+B,C}, {A+C,B}, {A,B+C}, {A+B+C}). Эти комбинированные модели могут соответствовать разным внешним моделям, но при этом ложатся в одну внутреннюю модель.

Второе преимущество состоит в том, что такую модель легче модерировать. Если характеристика A задана всего один раз, то ее переименование, пополнение набора значений или единиц измерения, исправление ошибок производится также всего лишь один раз во внутренней системе. Если же мы внутреннюю модель сделаем такой, что в ней будут представлены все возможные комбинации из внешних моделей, то дальнейшее управление усложняется экспоненциально относительно атомизированной модели.

Очистка данных

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

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

Это же требование делает возможным процесс верификации данных. Дело в том, что все ошибаются, в том числе и сайты производителей. Чтобы выявить ошибки, нужно уметь производить сопоставление импортируемых данных между собой и с описаниями товаров из данной группы. А для корректного сопоставления нам снова требуется единая атомизированная модель. Только в том случае, когда мы можем сопоставить данные из различных источников в рамках одной инфомодели, мы можем также выявить некоторые ошибки и тем самым очистить данные (например, не пропускать в систему противоречащие друг другу значения или пропускать только наиболее вероятные альтернативы).

Почему инфомодель не может быть всеобъемлющей?

Ранее мы уже отмечали, что при создании инфомодели необходимо соблюдать некоторый баланс между полнотой модели и глубиной разделения товаров на группы. Обсудим этот момент подробнее.

Очевидно, что делать одну модель для одного или 10 товаров неразумно хотя бы ввиду сопоставления затрат на создание модели и эффекта от ее использования. Из всего вышесказанного должно быть уже очевидно, что создание инфомодели дело хлопотное и затратное как по времени, так и по интеллектуальным ресурсам. Если при наличии 1000 товаров в каталоге создавать группы по 10 товаров, то нам потребуется 100 моделей, каждую из которых нужно создать и поддерживать.

Здесь, конечно, есть свои приемы экономии. Например, многие атрибуты (вроде частоты или веса) встречаются во многих моделях. Поэтому их создание и настройку проще вынести в отдельный каталог атрибутов, а модель собирать из них как лего.

Но ведь помимо создания модели потребуется еще произвести построение операторов импорта/экспорта, забирающих и отдающих контент во внешние модели. А в этих внешних моделях, как правило, категоризация (разбиение на группы) происходит по своим принципам. Потребуется создать несколько сотен операторов ради одной-двух внешних моделей. Это опять-таки накладно и весьма избыточно.

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

ОК, почему же тогда не создать модель, которая включит все товары каталога? Одна модель требует одного акта творения и, казалось бы, сильно экономит на поддержке.

Однако и у этой крайности есть свои недостатки. Во-первых, эта модель получится крайне разреженной. Вспомним, что товар в инфомодели это вектор значений атрибутов. Если модель очень широкая, то может оказаться, что каждый товар использует 1-2% атрибутов, хотя все вместе товары используют 100% атрибутов.

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

С точки зрения Data Science к такому информационному пространству следует применить алгоритмы понижения размерности, выкинув все незначащие атрибуты и распилив это единое пространство на несколько независимых подпространств, размерность которых будет в разы ниже исходной. Но это и есть не что иное, как переход к группам товаров со схожей информационной моделью (категоризация).

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

В-третьих, если внутренняя модель используется для заполнения описаний руками, то контент-менеджер будет вынужден подолгу обозревать инфомодель в поисках нужного ему атрибута для простановки значения. А это огромная потеря времени и ресурсов компании.

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

Таким образом, чаще всего информационные модели строятся на группах очень схожих товаров, соблюдая паритет между всеобъемлемостью и тривиальностью модели. Когда мы имеем дело с товарной группой, где отличие по заполненности модели у товаров составляет 5-10%, мы не только упрощаем себе жизнь в плане управления моделью и привязки к ней операторов импорта/экспорта, но получаем еще ряд бонусов.

Избыточная атомизация модели

В попытках построить максимально элементарную инфомодель можно дойти до такого типа модели, который называется Да/Нет-моделью. В такой модели существует ровно два вида атрибутов числовые (с единицами измерения) и категориальные с одинаковым списком значений {Да,Нет}. Очевидно, что любой категориальный атрибут сводится к совокупности Да/Нет-атрибутов. Для этого достаточно взять список значений данного категориального атрибута и превратить его в одноименный список атрибутов. Тогда, если в товаре данное значение исходного атрибута присутствует, одноименный Да/Нет-атрибут принимает значение Да, а в противном случае Нет.

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

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

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

Еще одно применение Да/Нет-модели это сопоставление с каким-то внешним каталогом, модель которого имеет такой же тип. В этом случае импорт контента немного усложнится: сначала оператор импорта выполнит заливку во внутреннюю Да/Нет-модель, затем другой оператор произведет сопоставление данных с нативной внутренней моделью, содержащей списочные категориальные атрибуты.

Бонусы атомизированной модели

Для начала заметим, что если инфомодель соответствует такой группе товаров, у которых заполнены примерно одни и те же атрибуты, то такие товары легко сравнивать между собой. А это очень важный аспект выбора товара покупателем.

Далее, если модель максимально декомпозирована, то и сравнение товаров в ней, и любая аналитика по имеющемуся контенту (статистический обсчет товарной группы) будут максимально детальными. Пользуясь атомизированной моделью, вы можете как под микроскопом выявить отличия в описаниях товаров, локализовать ошибочные значения, исключить неоднозначное толкование атрибутов, производить поиск зависимых атрибутов и вычислять отсутствующие знания о товаре.

Выше уже отмечалось, что атомизированная модель позволяет порождать большое количество комбинаций атрибутов, что упрощает создание операторов экспорта во внешние модели. Чем мельче элементарный квант модели, тем точнее мы можем выстроить правила экспорта данных для их соответствия требованиям заказчика или маркетплейса.

Ряд бонусов атомизированной модели проявляется тогда, когда мы говорим о системе управления контентом и ее интерфейсах.

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

Можно также запретить вводить дробные значения для атрибутов количества или ограничить число знаков после запятой для значений частоты процессора.

В случае категориальных атрибутов часто используется ограничение на количество одновременно вводимых значений. Так, атрибуты подтипа селект позволяют выбрать только одно значение.

Наконец, можно выполнять перекрестную проверку значений и/или восполнение знаний о товаре. А именно, из физических соображений можно связать атрибуты формулами так, что если часть введенных значений позволяет однозначно вычислить остальные, то мы можем либо автоматически заполнить недостающие атрибуты, либо проверить правильность их заполнения.

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

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

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

Подводя итоги, зафиксируем тезисно основные выводы:

• Информационная модель у каждого своя, поэтому для адекватного взаимодействия инфомоделей нужно создавать внутреннюю принимающую модель.
• Внутренняя модель должна быть атомизированной, аналитической.
• Больше числовых атрибутов, меньше текстовых!
• Модель должна соответствовать группе однотипных товаров так, чтобы отличие между товарами группы по количеству используемых атрибутов было не более 5-10%.
• Группы товаров не должны быть мелкими.
• Язык (человеческий) внутренней модели и подключаемых доверенных источников должен быть английским, а система мер СИ.
• Модель Да/Нет использовать с осторожностью, а лучше вообще не использовать.

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

Перейдем к основным понятиям.

Тестирование программного обеспечения (Software Testing) проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Почему требуется тестирование ПО?

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

Принципы тестирования

• Принцип 1 Тестирование демонстрирует наличие дефектов (Testing shows presence of defects). Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но не гарантирует их отсутствия.
• Принцип 2 Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible). Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
• Принцип 3 Раннее тестирование (Early testing). Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки ПО или системы, и должны быть сфокусированы на определенных целях.
• Принцип 4 Скопление дефектов (Defects clustering). Разные модули системы могут содержать разное количество дефектов то есть плотность скопления дефектов в разных частях кода может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей.
• Принцип 5 Парадокс пестицида (Pesticide paradox). Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот парадокс пестицида, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
• Принцип 6 Тестирование зависит от контекста (Testing is concept depending). Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA Quality Assurance) и контроль качества (QC Quality Control) эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) Контроль качества продукта анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:

• проверка готовности ПО к релизу;
• проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) Обеспечение качества продукта изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

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

Верификация (verification) это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation) это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение торможение, когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение торможение. Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения верификации программа сработала, с точки зрения валидации нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

1. Проектная документация включает в себя всё, что относится к проекту в целом.
2. Продуктовая документация часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.

Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

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

Программный продукт проходит следующие стадии:

1. анализ требований к проекту;
2. проектирование;
3. реализация;
4. тестирование продукта;
5. внедрение и поддержка.

Требования

Требования это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

Требования к требованиям:

1. Корректность каждое требование должно точно описывать желаемый функционал.
2. Проверяемость требование должно быть сформулировано так, чтобы существовали способы однозначной проверки, выполнено оно или нет.
3. Полнота каждое требование должно содержать всю информацию, необходимую разработчику, чтобы правильно спроектировать и реализовать требуемую функциональность.
4. Недвусмысленность требование описано без неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание.
5. Непротиворечивость требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность приоритет требования представляет собой количественную оценку степени значимости (важности) требования.
7. Атомарность требование нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
8. Модифицируемость характеризует простоту внесения изменений в отдельные требования и в набор требований.
9. Прослеживаемость у каждого требования должен быть уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) это документ, описывающий ситуацию, которая привела к обнаружению дефекта, с указанием причин и ожидаемого результата.

Атрибуты отчета о дефекте:

1. Уникальный идентификатор (ID) присваивается автоматически, может содержать в себе данные о требовании, на которое ссылается дефект.
2. Тема (краткое описание, Summary) кратко сформулированная суть дефекта по правилу Что? Где? Когда?
3. Подробное описание (Description) более широкое описание сути дефекта (при необходимости).
4. Шаги для воспроизведения (Steps To Reproduce) последовательное описание действий, которые привели к выявлению дефекта (которые нужно выполнить для воспроизведения дефекта). Описываются максимально подробно, с указанием конкретных вводимых значений.
5. Фактический результат (Actual result) указывается, что не так работает, в каком месте продукта и при каких условиях. Описывая фактический результат, необходимо ответить на три вопроса: что? где? когда?
6. Ожидаемый результат (Expected result) указывается, как именно должна работать система по мнению тестировщика, основанному на требованиях и прочей проектной документации.
7. Вложения (Attachments) скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта (срочность, Priority) указывает на очерёдность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправить дефект.
10. Статус (Status) определяет текущее состояние дефекта. Отражает жизненный цикл дефекта от начального состояния до завершения. Названия статусов дефектов могут быть разными в разных баг-трекинговых системах.
11. Окружение (environment) указывается окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

• Блокирующий (S1 Blocker)
  тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
• Критический (S2 Critical)
  критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
• Значительный (S3 Major)
  не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
• Незначительный (S4 Minor)
  часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 Trivial)
  почти всегда дефекты на GUI опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

• P1 Высокий (High)
  Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критичным для проекта.
• P2 Средний (Medium)
  Ошибка должна быть исправлена, ее наличие не является критичным, но требует обязательного решения.
• P3 Низкий (Low)
  Ошибка должна быть исправлена, но ее наличие не является критичным и не требует срочного решения.

Существует пять базовых типов задач:

• Эпик (epic) большая задача, на решение которой команде нужно несколько спринтов.
• История (story) часть большой задачи (эпика), которую команда может решить за 1 спринт.
• Задача (task) техническая задача, которую делает один из членов команды.
• Под-задача (sub-task) часть истории / задачи, которая описывает минимальный объем работы члена команды.
• Баг (bug) задача, которая описывает ошибку в системе.

Тестовые среды

• Среда разработки (Development Env) в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.
• Среда тестирования (Test Env) в этой среде работают тестировщики. Тут тестируются новые билды. Здесь тестировщики проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования.
• Интеграционная среда (Integration Env) иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды также, как и в случае со средой тестирования.
• Превью среда (Preview, Preprod Env) в идеале, это среда идентичная или максимально приближенная к продакшену: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к боевым. Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят приемочное тестирование (User Acceptance Testing (UAT)), а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.
• Продакшн среда (Production Env) среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3.

Основные фазы тестирования

• Pre-Alpha: ПО является прототипом. Пользовательский интерфейс завершен. Но не все функции завершены. На данном этапе ПО не публикуется.
• Alpha: является ранней версией программного продукта. Цель вовлечь клиента в процесс разработки. Хороший Альфа-тест должен иметь четко определенный план тестирования с комплексными тестовыми примерами. Это дает лучшее представление о надежности программного обеспечения на ранних стадиях. В некоторых случаях тестирование может быть передано на аутсорс.
• Beta: ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
• Release Candidate (RC): основываясь на отзывах Beta Test, вы вносите изменения в ПО и хотите проверить исправления ошибок. На этом этапе вы не хотите вносить радикальные изменения в функциональность, а просто проверяете наличие ошибок. RC также может быть выпущен для общественности.
• Release: все работает, ПО выпущено для общественности.

Основные виды тестирования ПО

Вид тестирования это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

1. Классификация по запуску кода на исполнение:
   
   • Статическое тестирование при статическом тестировании код не выполняется. Вы вручную проверяете код, документы требований и проектные документы на наличие ошибок. Отсюда и название статичный. Основная цель этого тестирования повысить качество программных продуктов путем выявления ошибок на ранних этапах цикла разработки.
   • Динамическое тестирование при динамическом тестировании выполняется код. Оно проверяет функциональное поведение ПО, использование памяти / процессора и общую производительность системы. Основная цель этого тестирования подтвердить, что программный продукт работает в соответствии с требованиями бизнеса. Динамическое тестирование выполняется на всех уровнях тестирования, и это может быть либо тестирование черного, либо белого ящика.
   
   
2. Классификация по доступу к коду и архитектуре:
   
   • Тестирование белого ящика метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
   • Тестирование серого ящика метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
   • Тестирование чёрного ящика также известное как тестирование, основанное на спецификации или тестирование поведения техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
   
   
3. Классификация по уровню детализации приложения:
   
   • Модульное тестирование модульные тесты используются для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками.
   • Интеграционное тестирование предназначено для проверки насколько хорошо два или более модулей ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
   • Системное тестирование процесс тестирования системы в целом, чтобы проверить, соответствует ли она установленным требованиям.
   • Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
   
   
4. Классификация по степени автоматизации:
   
   • Ручное тестирование.
   • Автоматизированное тестирование.
   
   
5. Классификация по принципам работы с приложением
   
   • Позитивное тестирование тестирование, при котором используются только корректные данные.
   • Негативное тестирование тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
   
   
6. Классификация по уровню функционального тестирования:
   
   • Дымовое тестирование (smoke test) короткий цикл тестов, выполняемый для каждой новой сборки для подтверждения того, что ПО стартует и выполняет основные функции без критических и блокирующих дефектов.
   • Тестирование критического пути (critical path) направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   • Расширенное тестирование (extended) направлено на исследование всей заявленной в требованиях функциональности.
   
   
7. Классификация в зависимости от исполнителей:
   
   • Альфа-тестирование является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
   • Бета-тестирование ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
   
   
8. Классификация в зависимости от целей тестирования:
   
   • Функциональное тестирование (functional testing) направлено на проверку корректности работы функциональности приложения (корректность реализации функциональных требований).
   • Нефункциональное тестирование (non-functional testing) анализ атрибутов качества компонента или системы, не относящихся к функциональности, то есть проверка, как работает система.
     
     1. Тестирование производительности (performance testing) определение работоспособности, стабильности, потребления ресурсов в условиях различных сценариев использования и нагрузок.
     2. Нагрузочное тестирование (load testing) оценка поведения системы при возрастающей нагрузке, а также для определения нагрузки, которую способны выдержать компонент или система.
     3. Тестирование масштабируемости (scalability testing) тестирование программного обеспечения для измерения возможностей масштабирования.
     4. Объёмное тестирование (volume testing) тестирование, при котором система испытывается на больших объёмах данных.
     5. Стрессовое тестирование (stress testing) вид тестирования производительности, оценивающий систему на граничных значениях рабочих нагрузок или за их пределами.
     6. Инсталляционное тестирование (installation testing) тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
     7. Тестирование интерфейса (GUI/UI testing) проверка требований к пользовательскому интерфейсу.
     8. Тестирование удобства использования (usability testing) проверка того, насколько легко конечный пользователь системы может понять и освоить интерфейс.
     9. Тестирование локализации (localization testing) проверка адаптации программного обеспечения для нового места эксплуатации (например, при смене языка).
     10. Тестирование безопасности (security testing) тестирование программного продукта, чтобы определить его защищённость.
     11. Тестирование надёжности (reliability testing) тестирование способности приложения выполнять свои функции в заданных условиях на протяжении заданного времени.
     12. Регрессионное тестирование (regression testing) тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
     13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
   
   

Тест-дизайн это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна:

1. Тестирование на основе классов эквивалентности (equivalence partitioning) техника тест-дизайна на основе метода чёрного ящика. Помогает разрабатывать и выполнять меньше тест-кейсов, при этом сохраняя достаточное тестовое покрытие.
2. Техника анализа граничных значений (boundary value testing) проверка поведения продукта на крайних значениях входных данных.
3. Попарное тестирование (pairwise testing) разработка тестов методом чёрного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
4. Тестирование на основе состояний и переходов (State-Transition Testing) применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing) способ компактного представления модели со сложной логикой. А ещё это техника тестирования чёрного ящика, которая применяется для систем со сложной логикой.
6. Исследовательское тестирование (Exploratory Testing) это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки.
7. Доменный анализ (Domain Analysis Testing) это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования.
8. Сценарий использования (Use Case Testing) Use Case описывает сценарий взаимодействия двух и более участников (как правило пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя.

Типы тестирования

Тестирование белого ящика метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика это:
тестирование, основанное на анализе внутренней структуры компонента или системы;
тест-дизайн, основанный на технике белого ящика процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему белый ящик? Тестируемая программа для тестировщика прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

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

Тестовая документация

Тест план (Test Plan) это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Тест план должен отвечать на следующие вопросы:

• Что надо тестировать?
• Что будете тестировать?
• Как будете тестировать?
• Когда будете тестировать?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Основные пункты тест плана:

В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:
a) Идентификатор тест плана (Test plan identifier);
b) Введение (Introduction);
c) Объект тестирования (Test items);
d) Функции, которые будут протестированы (Features to be tested;)
e) Функции, которые не будут протестированы (Features not to be tested);
f) Тестовые подходы (Approach);
g) Критерии прохождения тестирования (Item pass/fail criteria);
h) Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
i) Результаты тестирования (Test deliverables);
j) Задачи тестирования (Testing tasks);
k) Ресурсы системы (Environmental needs);
l) Обязанности (Responsibilities);
m) Роли и ответственность (Staffing and training needs);
n) Расписание (Schedule);
o) Оценка рисков (Risks and contingencies);
p) Согласования (Approvals).

Чек-лист (check list) это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions) список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps) список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (PostConditions) что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.