tech_test

tech_test

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

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

Материал распространяется под лицензией BSD-2.

Содержание

• tech_test
  • Содержание
  • Анализ ситуации
  • Состояние средств контроля в типовом проекте
  • Юнит-тестирование и пакетное тестирование
  • Интеграционное тестирование
  • Пользовательское тестирование
  • Сбор информации в ходе эксплуатации
  • Оценка зрелости процессов
  • Оценка степени контроля качества разработки
  • Абстрагирование тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользовательское тестирование

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

• откровенные ошибки, заложенные на уровне ТЗ;
• откровенные ошибки, пропущенные в ходе тестирования;
• пожелания, связанные с интерфейсом пользователя;
• пожелания, связанные с работой инетерфейса пользователя.

Первые две категории являются критическими. Если такие ошибки дожили до этапа приёмо-сдаточных испытаний -- это означает, что системы тестирования на проекте просто нет.

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

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

Сбор информации в ходе эксплуатации

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

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

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

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

Оценка зрелости процессов

Оценку зрелости процессов следует производить по таблице, как указано по ссылке.

Каждый следующий уровень в каждой конретной ситуации может иметь свой вес. Но обще принятой практикой вляется увеличение количества баллов *2 от предыдущего уровня.

Таким образом уровни зрелости процессов имеют весовые коэффициенты: 1, 2, 4, 8, 16, 32.

Диапазон оценок по такой шкале примерно 27 дБ.

Оценка степени контроля качества разработки

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

По юнит-тестированию следует оценивать покрытие функций:

• Функция покрыта тестами на 0%: -2 балла
• Функция покрыта тестами до 60%: -1 балл
• Функция покрыта тестами 60-84%: +1 балла
• Функция покрыта тестами более 85%: +4 балла

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

• более 85%: хорошо;
• 60-85%: удовлетворительно;
• если есть хотя бы одна функция с покрытием менее 50% -- неудовлетворительно.

При интеграционном тестировании следует контролировать количетво тестов по функционалу.

В ходе текущей разработки покрытие тестами менее 85% следует считать неудовлетворительным. Если в ходе интеграционного тестирования из общег очисла тестов проходит менее 90% следует считать результаты неудовлетворительными.

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

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

Абстрагирование тестирования

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

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

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

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

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

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

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