tech_test

tech_Test

Соображения по поводу тестирования.

Небольшое эссе, в котором изложены основные мысли неоторым вопросам тестирования.

Содержание

• Анализ ситуации

Анализ ситуации

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

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

Инструменты контроля деляется на:

• локальный контроль (измерение в ходе изготовления отдельной детали);
• сборочный контроль (измерения при сборке крупных узлов и агрегатов);
• контроль качества на выходе (проводится после сборки всего изделия из компоновочных узлов и агрегатов);

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

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

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

То, что Фредерик Брукс описал как "вспомогательные строительные леса".

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

Это приводит к тому, что стоимость средств контроля производства не просто кратно превышает по стоимости аналогичные средства в материальном производстве -- стоимость средств контроля в информационном производстве превышает стоимость средств материального производства на несколько порядков. Это нормально.

Состояние средств контроля в типовом проекте

Для подробного рассмотрения ситуации и её оценки следует рассмотреть ситуацию от частного к общему.

Юнит-тестирование и пакетное тестирование

Разработка юнит-тестов и юнит-тестирование должна проводиться инженером-разработчиком на этапе разработке юнитов (отдельных модулей). Степень покрытия тестами для подтверждения качества кода должна находиться в пределах 85-95%. В оответствии с результатми многих исследований покрытие тестами на уровне 50% ничего не доказывает -- как правило это прямая ветка исполнения, а интересуют именно граничные условия.

В проекте среднее покрытие тестами разнится крайне сильно -- от 0 до 95%. Отдельные сервисы покрыты тестами на 0%, отдельные даже более 95%, остальные в диапазоне приведённых значений. Отсутствие устойчивых показателей порождает ряд проблем на следующем уровне.

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

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

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

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

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