Техники тест-дизайна (Software testing techniques)

● Cтатические (Static):

○ Reviews:

■ Неформальное ревью (Informal review)

■ Прохождение (Walkthrough)

■ Техническое ревью (Technical Review)

■ Инспекция (Inspection)

○ Статический анализ (Static Analysis):

■ Поток данных (Data Flow)

■ Поток управления (Control Flow)

■ Путь (Path)

■ Стандарты (Standards)

● Динамические (Dynamic):

○ Белый ящик (White-box, Structure-Based)

■ Выражение (Statement)

■ Решение (Decision)

■ Ветвь (Branch)

■ Условие (Condition)

■ Конечный автомат (FSM)

○ Основанные на опыте (Experience-based):

■ Предугадывание ошибки (Error Guessing - EG);

■ Исследовательское тестирование (Exploratory testing);

■ Ad-hoc testing;

■ Attack Testing;

○ Черный ящик (Black-box, Specification-based):

■ Эквивалентное Разделение (Equivalence Partitioning - EP)

■ Анализ Граничных Значений (Boundary Value Analysis - BVA)

■ Комбинаторные техники (Combinatorial Test Techniques)

■ Переходы между состояниями (State transition)

■ Случаи использования (Use case testing)

■ Domain testing

■ Decision Table Testing

■ Classification Tree Method

■ State Transition Testing

■ Cause-Effect Graphing

■ Scenario Testing

■ Random Testing

■ Syntax Testing

■ Check List Based Testing

■ Risk-Based Testing

■ User Journey Test

Источники:

● What is Test design? or How to specify test cases?

● What Is Test Design Actually?

● Максим Дорофеев - Lecture 12. Test Design

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

● Copeland Lee - “A Practitioner's Guide to Software Test Design” + перевод

● Rikard Edgren - The little black book on test design + перевод

● Test Design: A Survey of Black Box Software Testing Techniques (видеолекции + доп.материалы)

● Борис Бейзер - “Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем”

● Hillel - Техники тест-дизайна (доклад с примерами)

● Лекция 3: Критерии выбора тестов

● NIXMultiConf: Игорь Ямшанов - Приоритезация: начни с самого важного

● Armando1514/Software-testing-techniques

● The ABCs of Acceptance Test Design

Static -> Reviews

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

Экспертные обзоры (Peer Reviews): Рецензирование - это стандартизированный метод проверки правильности исходного кода (методом белого ящика) при разработке программного обеспечения, который проводится для выявления дефектов на ранних этапах жизненного цикла и которые не могут быть обнаружены с помощью методов тестирования черного ящика.

Прохождение/просмотр/пошаговый разбор (walkthrough): это метод проведения неформального группового / индивидуального просмотра. В walkthrough автор описывает и объясняет рабочий продукт на неформальной встрече своим коллегам или руководителю, чтобы получить обратную связь. Здесь проверяется применимость предложенного решения для рабочего продукта. Либо рабочий продукт проверяется на наличие дефектов несколькими лицами, кроме человека, который его фактически произвел;

Технический обзор (Technical Review): Это метод более высокого уровня по сравнению с inspection или walkthrough, поскольку он также включает в себя управление. Этот метод используется для оценки (assess and evaluate) продукта путем проверки его соответствия стандартам разработки, руководствам и спецификациям. У него нет определенного процесса, и большая часть работы выполняется модератором, как описано ниже:

● Модератор собирает и раздает материал и документацию всем членам команды;

● Модератор также готовит набор показателей для оценки продукта в соответствии со спецификациями и уже установленными стандартами и гайдлайнами:

○ последовательность;

○ документация;

○ соблюдение стандартов;

○ полнота;

○ определение проблемы и требования (? problem definition and requirements);

● Результаты фиксируются в документе, который включает как дефекты, так и предложения;

● Наконец, устраняются дефекты и учитываются предложения по улучшению продукта;

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

Software inspection process:

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

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

● Индивидуальная подготовка участников: на этом этапе члены инспекционной группы индивидуально готовятся к инспекционной встрече, изучая материалы, предоставленные на более ранних этапах. Члены команды выявляют потенциальные ошибки или недочеты в продукте и записывают их в журнал. Журнал передается модератору. Затем модератор собирает все журналы, полученные от участников, и отправляет их автору. Инспектор - лицо, ответственное за проверку и выявление ошибок и несоответствий в документах или программах, проверяет продукт и записывает все обнаруженные в нем проблемы (как общие, так и специфические). Инспектор записывает проблемы или issues в журнал вместе со временем, затраченным на подготовку. Модератор просматривает логи, чтобы проверить, готова ли команда к инспекционной встрече или нет. Наконец, модератор отправляет автору все скомпилированные логи;

● Инспекционная встреча (Inspection Meeting): на этом этапе автор обсуждает вопросы, поднятые членами команды в скомпилированном журнале. Участники приходят к решению, является ли поднятый вопрос ошибкой или нет. Модератор завершает встречу и подводит итоги встречи - это список ошибок, обнаруженных в продукте, которые должен устранить автор.

● Переделка: доработка проводится автором согласно сводному списку, представленному модератором на предыдущем этапе. Автор исправляет все ошибки и сообщает модератору;

● Follow – up: модератор проверяет, все ли ошибки устранены или нет. Затем модератор готовит отчет. Если все ошибки исправлены и устранены, модератор выпускает документ. В противном случае в отчет добавляются нерешенные вопросы и назначается еще одно инспекционное собрание;

Источники:

● Software Testing Techniques

● Types of Static Testing

● Explain peer review

● Static Testing Techniques

Static -> Static Analysis

Статический анализ - это анализ программных артефактов, таких как программный код (или требования, дизайн), выполняемый статически, т.е. без запуска и, очевидно, методом белого ящика. Основная цель этого анализа - как можно раньше найти ошибки, независимо от того, могут ли они вызывать отказы (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) взаимозависимы: чтобы получить точные результаты для анализа потока данных, необходимо учитывать поток управления (поскольку порядок операций влияет на возможные значения данных в конкретном месте программы). Чтобы получить точные результаты для анализа потока управления, необходимо учитывать поток данных, поскольку поток динамического управления (решение, принимаемое во время выполнения) зависит от значений данных в конкретных местах программы. Однако эти два анализа преследуют разные цели.