exam_16

Участники:

• Консулова А. Д.
• Лякишева М. А.

Методы анализа 5M и 6M. Назначение и способы применения при оценке надежности организационно-технических систем.

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

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

• человек;
• машина;
• методы;
• материал;
• окружающая среда.

Последнее время стали выделять еще один фактор — измерения, и теперь диаграмма называется 6М.

Построение диаграммы начинается с формулировки проблемы – "голова рыбы”. От нее выстраивается горизонтальная линия к которой стрелками присоединяют основные причины – "ребра”. Последние, в свою очередь являются следствием других причин – вторичных. Вторичные причины и причины следующих порядков должны быть связаны с первопричинами таким образом:

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

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

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

Интеграционное тестирование

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

Задачей интеграционного тестирования является проверка разных модулей системы при их системном объединении.

Как правило, интеграционное тестирование имеет следующие подходы:

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

Интеграционное тестирование включает в себя следующие этапы:

• составление тест-плана;
• создание тест-кейсов и юз-кейсов;
• выполнение тестов после интеграции модулей;
• выполнение тестов после интеграции модулей;
• выявление ошибок и повторное тестирование после их исправления.

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

1. Система непрерывной интеграции производит мониторинг системы контроля версий.
2. При изменении исходных кодов в репозитории производится обновление локального хранилища.
3. Выполняются необходимые проверки и модульные тесты.
4. Исходные коды компилируются в готовые выполняемые модули.
5. Выполняются тесты интеграционного уровня.
6. Генерируется отчет о тестировании.

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

1. Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами:

$SectionNames = Введение, Текст статьи, Заключение, Литература

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

$IsCoverable = true

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

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

Однако интеграционное тестирование имеет некоторые ограничения. Например:

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

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

Список литературы:

1. sigma
2. a1qa
3. TestMatick