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

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

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

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

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

Преимущества статического тестирования:

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

Типы статического тестирования:

1. Проверка программного обеспечения:

Процесс проверки выполняется на ранних этапах SLDC и применяется к определенной части продукта, такой как SRS, код, дизайн продукта. и т. д. Он включает в себя ручное изучение различных компонентов продукта на более ранних этапах. Процесс проверки программного обеспечения состоит из шести этапов, а именно:

• Планирование инспекционной встречи -
  • На этом этапе основное внимание уделяется определению продукта, подлежащего проверке, и цели этой проверки.
  • На этом этапе назначается модератор, который управляет всем процессом проверки.
  • Назначенный модератор проверяет, готов товар к проверке или нет. Модератор также выбирает инспекционную группу и назначает им их роли.
  • Модератор также планирует инспекционную встречу и раздает необходимые материалы инспекционной группе.
• Обзор -
  • На этом этапе инспекционной группе предоставляется вся справочная информация для инспекционного совещания.
  • Автор, который является кодировщиком или дизайнером, ответственным за разработку продукта, представляет свою логику и рассуждения о продукте, включая функции продукта, его предполагаемое назначение и подход или концепцию, использованные при его разработке.
  • Удостоверяется, что каждый член инспекционной группы понял и знаком с задачами и целью инспекционного совещания, которое должно быть проведено.
• Индивидуальная подготовка участников -
  • На этом этапе члены инспекционной группы индивидуально готовятся к инспекционной встрече, изучая материалы, предоставленные на более ранних этапах.
  • Члены команды выявляют потенциальные ошибки или недочеты в продукте и записывают их в журнал. Журнал наконец передан модератору. Затем модератор собирает все журналы, полученные от участников, и отправляет их автору.
  • Инспектор - лицо, ответственное за проверку и выявление ошибок и несоответствий в документах или программах, проверяет продукт и записывает все обнаруженные в нем проблемы (как общие, так и специфические). Инспектор записывает проблемы или проблемы в журнал вместе со временем, затраченным на подготовку.
  • Модератор просматривает логи, чтобы проверить, готова ли команда к инспекционной встрече или нет.
  • Наконец, модератор отправляет автору все скомпилированные логи.
• Инспекционная встреча -
  • На этом этапе автор обсуждает вопросы, поднятые членами команды в скомпилированном журнале.
  • Участники приходят к решению, является ли поднятый вопрос ошибкой.
  • Модератор завершает встречу и подводит итоги встречи - это список ошибок, обнаруженных в продукте, которые должен устранить автор.
• Переделка -
  • Доработка проводится автором согласно сводному списку, представленному модератором на предыдущем этапе.
  • Автор исправляет все ошибки и сообщает модератору
• Следовать за -
  • Модератор проверяет, все ли ошибки устранены или нет. Затем модератор готовит отчет. Если все ошибки исправлены и устранены, модератор выпускает документ.
  • В противном случае в отчет добавляются нерешенные вопросы и назначается еще одно инспекционное собрание.

2. Структурированные пошаговые руководства:
Этот тип статического тестирования менее формален и не столь строг по своей природе. Он имеет более простой процесс по сравнению с процессом проверки. Он включает следующие четыре этапа:

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

3. Технические обзоры:

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

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

Вниманию читателя! Не переставай учиться сейчас. Получите все важные концепции теории CS для собеседований SDE с курсом теории CS по доступной для студентов цене и будьте готовы к отрасли.