Please enable JavaScript.

Coggle requires JavaScript to display documents.

Тестирование, Принцип 1 — Тестирование демонстрирует наличие дефектов …

- - - - Тестирование важно по нескольким причинам:
        1. Обеспечение качества:
        Находит и исправляет ошибки до выхода продукта.
        2. Снижение рисков:
        Позволяет минимизировать проблемы с некачественным ПО.
        3. Удовлетворение пользователей:
        Убедится, что продукт соответствует ожиданиям пользователей.
        4. Экономия ресурсов:
        Исправление ошибок на ранних стадиях дешевле, чем после релиза.
  - - - по позитивности сценария
        
        Позитивное тестирование – тестирование с применением сценариев, в которых ожидается нормальное, правильное поведение системы.
        Негативное тестирование - тестирование с применением сценариев, в которых ожидается нештатное поведение системы, неверное. Когда минимум одно используемое данное некорректно.
      - в зависимости от исполнителей
        
        Альфа-тестирование — это тестирование ранней версии программного продукта, которое может выполняться внутри организации-разработчика с частичным привлечением конечных пользователей. Участниками могут быть члены команды разработки и, например, сотрудники со стороны заказчика.
        Бета-тестирование — это тестирование программного обеспечения, которое выпускается для ограниченного числа пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения. Часто используется в производстве видеоигр, когда выпускается бета-версия игры для оценки пользователями.
      - по уровню функционального тестирования
        
        Нефункциональное тестирование – направлено на проверку соответствия свойств ПО с его нефункциональными требованиями.
        
        Тестирование производительности (performance testing) – комплекс видов тестирования целью которых является проверка работоспособности, стабильности, потребления ресурсов и других атрибутов в условиях других сценариев использования и нагрузок:
        -Нагрузочное — определение показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
        (Производительность в пределах нормы, например одновременное присутствие до 1000 пользователей на сайте)
        -Стресс (stress testing)- экстремальная нагрузка, в разы превышающая норму
        -Стабильность – проверка приложения при длительной работе. То есть происходит нагрузка нашей системы в пределах нормы.
        (на день, неделю, месяц и смотрим как она будет себя вести)
        -Объемное – тестирование при увеличенных объемах обрабатываемых данных
        (1000 пользователей отправляют одновременно сообщения или же загружают файлы)
        Инсталляционное тестирование – проверяет корректность установки, обновления и удаления приложения (например, установка через Play Market или с флешки).
        Тестирование удобства (Usability) – оценивает удобство и интуитивность интерфейса для пользователя, важное для его повторного использования.
        Тестирование безопасности – проверяет защиту системы от атак, вирусов и несанкционированного доступа к данным.
        Тестирование локализации и интернационализации – адаптация ПО к разным языкам, культурам и единицам измерения (например, сантиметры и дюймы).
        Тестирование доступности (Accessibility) – проверяет доступность для людей с ограниченными возможностями (например, субтитры, увеличение шрифта, аудиовоспроизведение текста).
        
        Функциональное тестирование – тестирование которое направлено на проверку соответствия функциональных требований ПО к его реальным характеристикам.
        
        Дымовое тестирование (smoke test) — тестирование, которое проводится после появления нового билда . Направлено на проверку готовности разработанного продукта к проведению расширенного тестирования и определения общего качества продукта.
        К примеру: Авторизуемся - производим выбор продукта – оплату - получаем подтверждение оплаты.
        Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
        пример – отправка сообщения в почтовом сервисе – изменение вида шрифта, цвета, размера и т.д
        Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
        например, вводить некорректные логин и пароль в окне авторизации, работать на многих вкладках одновременно, подгрузка файлов недопустимых размеров
      - по запуску кода на исполнение
        
        Статическое тестирование — это процесс, который не требует запуска кода. Оно направлено на обнаружение и устранение ошибок в сопроводительных документах, таких как требования к программному обеспечению. В этом контексте тестированию подлежат:
        Документы (например, тест-кейсы и архитектура приложения). Если появляется новый функционал, некоторые тест-кейсы могут стать неактуальными и требуют корректировки.
        Графические прототипы (эскизы интерфейса). При изменениях в интерфейсе необходимо обновлять и эскизы, добавляя новые элементы.
        Код приложения, который проверяется программистами в процессе аудита (code review) и с использованием методов тестирования на основе структур кода.
        Параметры среды исполнения и подготовленные тестовые данные.
        Динамическое тестирование проводится на работающей системе и требует запуска кода. Оно может охватывать как всё приложение (системное тестирование), так и отдельные взаимосвязанные модули (интеграционное тестирование).
        Основная цель динамического тестирования — проверить реальное поведение приложения. Это включает взаимодействие с продуктом, например, авторизацию на сайте или действия в компьютерной игре. Мы вводим необходимые условия и наблюдаем за результатом, чтобы убедиться, что функциональность работает как ожидается.
      - по уровню детализации приложения (Пирамида тестирования)
        
        Модульное тестирование (юнит-тестирование) направлено на проверку отдельных логически выделенных и изолированных элементов системы. Этот вид тестирования помогает выявить ошибки на ранних стадиях разработки, что существенно упрощает процесс исправления.
        Интеграционное тестирование проверяет корректность взаимодействия нескольких модулей, которые объединены в единое целое. На этом этапе выявляются проблемы, возникающие на стыках модулей, что позволяет убедиться в их совместной работе.
        Системное тестирование охватывает взаимодействие всех компонентов системы и может включать тестирование интерфейсов между различными системами. Это полная проверка приложения, позволяющая удостовериться в корректности выполнения всех бизнес-процессов.
        Приёмочное тестирование включает в себя тестирование на сдаче всего программного продукта или его части заказчику:
        Пользовательское e2e включает тестирование основного функционала конечными пользователями
        Эксплуатационное — проверку в условиях, имитирующих реальную эксплуатацию.
        Тестирование на соответствие контракту и стандартам.
      - по цели тестирования
        
        1)Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
        2)Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
        3) Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил
        Оно проводится:
        
        после появления нового билда (новой версии нашего продукта)
        
        тестирование того функционала в котором часто обнаруживаются дефекты
        
        плановое тестирование
        
        того функционала который часто меняется в ходе разработки
  - - - Цели:
        1)Придумать тесты которые смогли бы обнаружить наиболее серьезные ошибки для ПО
        2)Минимизация количества тестов
        
        Класс эквивалентности – входные данные которые обрабатываются нашим приложением одинаково или обработка которых приводит к одному и тому же результату.
        Анализ граничных значений - техника проверки поведения продукта на крайних (граничных) значениях входных данных.
        Попарное тестирование — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
        Пример: Предположим, система имеет два входных поля: возраст и доход. Негативное тестирование может включать комбинации, где возраст имеет отрицательное значение, а доход превышает допустимый предел, чтобы проверить, как система справляется с невалидными комбинациями.
        Тестирование на основе состояний и переходов — применяется для фиксирования требований и описания дизайна приложения.
        Таблицы принятия решений — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
  - - - Kanban — это метод управления проектами, основанный на конвейерной схеме. В Kanban есть общий backlog задач, которые выполняются поочередно. Задачи перемещаются через стадии: от разработки к тестированию, затем к релизу. Новую задачу можно взять только после завершения текущей.
      - Scrum — это методология, позволяющая одновременно работать над несколькими задачами, организованными в спринты. Каждый спринт представляет собой короткий период, в течение которого команда выполняет определённый объём работы. По его завершении заказчик получает готовый функционал.
        Например в спринте 10 задач из бэклога. Они разрабатываются параллельно или последовательно, проходя этапы анализа, разработки, тестирования и релиза.
  - - - 1. Реляционная (SQL) — как язык программирования, с помощью которого создают, преобразовывают и управляют данными в реляционных БД. Записи и связи между ними организованы при помощи таблиц. В таблицах есть поле для внешнего ключа со ссылками на другие таблицы.
        
        Целые числа (INT) - используются для хранения целочисленных значений. Например, идентификаторов, номеров заказов и т.п.
        Числа с плавающей точкой (FLOAT) - используются для представления вещественных чисел. Например, цены товара, процентные ставки и т.п.
        Строки (VARCHAR) - используются для хранения текстовой информации. Например, названия товаров, имена пользователей и т.п. Максимальная длина строки может быть разной в зависимости от СУБД.
        Дата и время (DATE, TIME, TIMESTAMP) - используются для работы с датами и временем. Например, дата заказа, время доставки и т.п.
        Логические значения (BOOLEAN) - используются для хранения логической информации. Например, “да/нет”, “истина/ложь” и т.п.
        Символьные строки фиксированной длины (CHAR) - используются для хранения символов фиксированной длины, например, коды валют, двухбуквенные коды стран и т.п.
        
        Основные запросы в БД
        
        SELECT - для выборки данных из таблицы.
        
        INSERT - для добавления новых записей в таблицу.
        
        UPDATE для изменения существующих записей в таблице.
        
        DELETE для удаления записей из таблицы.
        
        CREATE TABLE для создания новой таблицы.
        
        DROP TABLE для удаления таблицы из базы данных.
        
        JOIN для объединения данных из нескольких таблиц.
        
        GROUP BY для группировки данных и выполнения агрегатных функций.
        
        ORDER BY для сортировки данных в выборке.
        
        Основные операторы в БД
        
        AND, OR, NOT (логические операторы)
        
        IN, BETWEEN, LIKE (операторы сравнения)
        
        JOIN для объединения данных из нескольких таблиц.
        
        GROUP BY для группировки данных и выполнения агрегатных функций.
        
        ORDER BY для сортировки данных в выборке.
      - 2. Иерархическая - простейшая структура, где записи, как ветви, отходят от родителя. Объекты делятся на родителей (основные классы или категории объектов) и потомков (экземпляры этих классов или категорий). При этом у каждого потомка может быть не более одного родителя.
      - 3. Сетевая - эта технология развивает иерархический подход за счет моделирования сложных отношений между объектами. Здесь потомки могут иметь более одного родителя, однако ограничения иерархического подхода сохраняются.
    - - Первая нормальная форма (1НФ) диктует, что каждое поле вашей базы данных должно хранить только одно значение и что в одной базе данных не должно быть двух полей, одинаково хранящих информацию.
      - Ненормализованная (нулевая) форма (UNF) - это состояние перед любой нормализацией. В таблице присутствуют избыточные и сложные значения.
      - Вторая нормальная форма (2НФ)
        направлена на уменьшение избыточности, гарантируя, что каждое поле хранит информацию, которая говорит нам что-то о первичном ключе. Другими словами:
        1) Каждая база данных должна иметь только один первичный ключ
        2) Все непервичные ключи должны полностью зависеть от первичного ключа.
      - Третья нормальная форма (3НФ).
        База данных соответствует третьей нормальной форме, если в ней нет ни одной переходной зависимости. Переходная зависимость возникает, когда столбец B базе данных зависит от столбца A, который зависит от первичного ключа.
        Чтобы нормализовать базу данных в соответствии с третьей нормальной формой, необходимо удалить столбец B, который не зависит напрямую от первичного ключа, и хранить эту информацию во второй базе данных с собственным первичным ключом.
        База данных считается нормализованной после достижения третьей нормальной формы. Дальнейшие этапы нормализации усложняют структуру БД и могут нарушить функционал системы.
  - - - Атрибуты требований:
        Корректность: Требования точно описывают функционал.
        Непротиворечивость: Нет внутренних или внешних противоречий.
        Недвусмысленность: Формулировки однозначны.
        Полнота: Содержит всю нужную информацию для реализации.
        Прослеживаемость: Каждое требование имеет уникальный идентификатор.
        Приоритетность: Определяет значимость требований для управления ресурсами.
        Проверяемость: Можно однозначно оценить выполнение требований.
        Атомарность: Требование нельзя разделить без потери информации.
        Модифицируемость: Возможность вносить изменения в требования.
    - - Атрибуты тест-плана:
        -Объект тестирования
        -Цели
        -Сроки
        -Расписания работ
        -Критерии начала и окончания тестирования
        -Стратегию
        -Риски
        -Список проводимых работ
    - - Проект – здесь указывается название проекта, для которого мы пишем сценарии проверки;
        Цель проверки - здесь идет название модуля который будет проверять в данном документе;
        Идентификатор -это уникальный Идентификатор документа;
        Требования - ссылка на документ, на основании которого составлен данный документ;
        Дата проведения;
        Исполнитель;
        Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
        Тип тестов;
        Название проверок - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте;
        Результат проверки
    - - Название проекта
        Id – это уникальный Идентификатор, уникальный номер тест-кейса, в нашей системе, на одном проекте не должно быть 2-х одинаковых тест-кейсов
        Требования – ссылка на документ, на основании которого составлен данный документ
        Модуль – название модуля к которому относится данный функционал
        Название - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте
        Приоритет - показывает, на сколько важно проведение данного теста · P1 Высокий (High) · P2 Средний (Medium) · P3 Низкий (Low)
        Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
        Шаги-теста – самый главный атрибут нашего документа, в котором мы подробно расписываем все шаги прохождения нашего теста
        Ожидаемый результат – в данном атрибуте мы указываем, а какой именно результат мы ожидаем получить, после того как мы выполним данный шаг, очень важно писать результат по каждому шагу, а не один для всех шагов. Это позволит любому члену команды повторить данный тест.
    - - Как у тест-кейса,только добавляется:
        -Дата проведения теста
        -Исполнитель;
        -Статус
    - - -проект
        -название документа
        -ссылка на требования
        -цель проверки
        -дата проведения
        -исполнитель
        -среда тестирования
        -шаги теста
        -ожидаемый результат
        -фактический результат
        -статус бага
        -серьезность бага
        -приоритет устранения бага
        -прикрепленный файл
        
        Серьезность (severity) указывает на степень ущерба от дефекта:
        Blocker: Блокирует работу ПО, невозможно использовать.
        Critical: Критические ошибки, делают функционал неработоспособным или ведут к потере данных.
        Major: Серьезные, но не критичные ошибки, могут иметь обходные пути.
        Minor: Незначительные дефекты, не влияющие на функционал (например, ошибки дизайна).
        Trivial: Визуальные недостатки, не влияющие на функционал.
        Приоритет (priority) показывает, как быстро дефект должен быть исправлен, определяется менеджером или заказчиком:
        P1 (High): Критическая ошибка, требует срочного исправления.
        P2 (Medium): Не критичная, но должна быть решена.
        P3 (Low): Низкий приоритет, может быть исправлена позже.
    - - -Введение и описание продукта.
        -Список выполненных тестов и их результаты.
        -Обобщенные данные по покрытию тестами.
        -Обзор качества продукта.
        -Сводная информация о найденных ошибках и их статус.
        -Рекомендации по дальнейшему тестированию или улучшению продукта.