QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Тест дизайн

Static - Static Analysis

PreviousStatic - ReviewsNextDynamic - White box

Last updated 3 years ago

Was this helpful?

Статический анализ (static analysis): Анализ артефактов разработки программного обеспечения, таких как требования или программный код, проводимый без исполнения этих программных артефактов. Статический анализ обычно выполняется при помощи вспомогательных инструментов. (ISTQB)

Статический анализ - это анализ программных артефактов, таких как программный код (или требования, дизайн), выполняемый статически, т.е. без запуска и, очевидно, методом белого ящика. Основная цель этого анализа - как можно раньше найти ошибки, независимо от того, могут ли они вызывать отказы (failures). Как и в случае с обзорами (reviews), статический анализ обнаруживает ошибки (bugs), а не отказы. Обычно статический анализ проводят до формальной проверки, даже до unit testing, путём добавления этих проверок специалистами DevOps в пайплайн проекта. Статический анализ не связан с динамическими свойствами требований, дизайна и кода, такими как покрытие тестами (test coverage). Существует множество инструментов для статического анализа, которые в основном используются разработчиками до или во время тестирования компонентов или интеграции (чаще новые и измененные классы и функции), а также дизайнерами во время моделирования программного обеспечения. Инструменты могут отображать не только структурные атрибуты, такие как глубина вложенности или число цикломатической сложности и проверка на соответствие стандартам кодирования, но также графические изображения потока управления, взаимосвязи данных и количество отдельных путей от одной строки кода к другой. Информация может использоваться вплоть до формальных методов, которые математически подтверждают свойства данной программы.

Инструменты помогают в выявлении следующих дефектов:

  • Неиспользуемые переменные;

  • Части кода, которые никогда не выполнятся;

  • Бесконечные циклы;

  • Переменная с неопределенным значением;

  • Неправильный синтаксис;

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

  • Уязвимости безопасности, такие как проблемы безопасности, связанные с переполнением буфера, возникающим из-за невозможности проверить длину буфера перед копированием в буфер;

  • Различные типы нарушения стандартов программирования, как нарушения, создающие риск фактического сбоя, так и нарушения, которые усложняют тестирование, анализ и поддерживаемость кода;

Методы статического анализа:

  • Анализ управления (Control Analysis): фокусируется на изучении элементов управления, используемых в структуре вызовов, анализе потока управления и анализе переходов состояний (calling structure, control flow analysis and state transition analysis). Структура вызова связана с моделью путем идентификации вызовов и их структуры. Вызывающая структура может быть процессом, подпрограммой, функцией или методом. Анализ потока управления проверяет последовательность передачи управления и может выявить неэффективные конструкции в модели. Создается граф модели (CFG - Control Flow Graph), в котором условные ветви и стыки модели представлены узлами. По итогам также можно рассчитать цикломатическую сложность программы. Для анализа потока управления использованы: Абстрактная интерпретация, Удовлетворение ограничений, Типизация данных;

  • Анализ данных (Data Analysis): обеспечивает правильную работу с объектами данных, такими как структуры данных и связанные списки. Кроме того, этот метод также обеспечивает правильное использование определенных данных. Анализ данных включает два метода, а именно: зависимость данных и анализ потока данных (data dependency and data flow analysis). Зависимость данных необходима для оценки точности синхронизации между несколькими процессорами. Анализ потока данных проверяет определение и контекст переменных. Виды анализа потока данных:

    • Reaching Definitions;

    • Available Expressions;

    • Constant Propagation;

    • Very Busy Expressions;

    • Live Variables;

    • Use-Definition & Definition-Use;

  • Анализ неисправностей / отказов (Fault/Failure Analysis): анализирует неисправности (некорректный компонент) и отказ (некорректное поведение компонента модели) в модели. Этот метод использует описание преобразования ввода-вывода для определения условий, являющихся причиной сбоя. Для определения отказов в определенных условиях проверяется проектная спецификация модели (model design specification);

  • Анализ интерфейса (Interface Analysis): проверяет взаимодействующие и распределенные модели для проверки кода (This software verifies and verifies interactive and distribution simulations to check the code). Существует два основных метода анализа интерфейса, и анализ пользовательского интерфейса исследует интерфейсы подмоделей и определяет точность структуры интерфейса. Анализ пользовательского интерфейса исследует модель пользовательского интерфейса и меры предосторожности, предпринимаемые для предотвращения ошибок во время взаимодействия пользователя с моделью. Этот метод также фокусируется на том, насколько точно интерфейс интегрирован в общую модель и симуляцию.

Анализ потока управления (Control Flow Analysis) и анализ потока данных (Data Flow Analysis) взаимозависимы: чтобы получить точные результаты для анализа потока данных, необходимо учитывать поток управления (поскольку порядок операций влияет на возможные значения данных в конкретном месте программы). Чтобы получить точные результаты для анализа потока управления, необходимо учитывать поток данных, поскольку поток динамического управления (решение, принимаемое во время выполнения) зависит от значений данных в конкретных местах программы. Однако эти два анализа преследуют разные цели.

Граф потока управления (Control Flow Graph)

Граф потока управления (CFG) - это графическое представление потока управления или вычислений во время выполнения программ или приложений. Графы потока управления в основном используются в статическом анализе, а также в приложениях-компиляторах, поскольку они могут точно представлять поток внутри программного модуля. Характеристики графа потока управления:

  • Граф потока управления процессно-ориентированный (process oriented);

  • Граф потока управления показывает все пути, которые можно пройти во время выполнения программы;

  • Рёбра в CFG изображают пути потока управления, а узлы в CFG изображают базовые блоки.

Цикломатическая сложность (Cyclomatic Complexity)

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

Определение из книги Ли Копланда - “A Practitioner's Guide to Software Test Design”, Главы 10:

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

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

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

M = E − N + 2P,

где:

  • M = цикломатическая сложность,

  • E = количество ребер в графе,

  • N = количество узлов в графе,

  • P = количество компонент связности.

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

M = E − N + P.

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

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

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

Цикломатическая сложность может быть распространена на программу с многочисленными точками выхода; в этом случае она равна

π − s + 2,

где:

  • π - число точек ветвления в программе,

  • s - число точек выхода.

Применение:

  • Ограничение сложности при разработке: одно из первоначально предложенных Маккейбом применений состоит в том, что необходимо ограничивать сложность программ во время их разработки. Он рекомендует, чтобы программистов обязывали вычислять сложность разрабатываемых ими модулей и разделять модули на более мелкие всякий раз, когда цикломатическая сложность этих модулей превысит 10. Эта практика была включена НИСТ-ом в методику структурного тестирования с замечанием, что со времени исходной публикации Маккейба выбор значения 10 получил весомые подтверждения, однако в некоторых случаях может быть целесообразно ослабить ограничение и разрешить модули со сложностью до 15. В данной методике признается, что иногда могут существовать причины для выхода за рамки согласованного лимита. Это сформулировано как рекомендация: «Для каждого модуля следует либо ограничивать цикломатическую сложность до согласованных пределов, либо предоставить письменное объяснение того, почему лимит был превышен»;

  • Применение при тестировании программного обеспечения: определение количества тестов, необходимых для полного покрытия кода. Цикломатическая сложность M имеет два свойства, для конкретного модуля:

    • M - оценка сверху для количества тестов, обеспечивающих покрытие условий (точек ветвления);

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

  • В составе других метрик: используется в качестве одного из параметров в индексе удобства сопровождения (англ. maintainability index).

Источники:

Доп. материал:

Граф потока управления - это граф;

.

могут быть
ориентированный
Полное описание возможных элементов графа
Types of Static Analysis Methods
Software Testing - Static Testing
Static program analysis
What is Static Analysis
Software Engineering - Control Flow Graph (CFG)
Цикломатическая сложность
Михаил Моисеев - “Формальные методы обеспечения качества ПО: Введение в статический анализ”
Y.N. Srikant - “Control Flow Analysis”
Levels in Data Flow Diagrams (DFD)
Control Flow Graph (CFG)
Static analysis tools
Podlodka #227 - Статический анализ кода
Архитектурное тестирование