#рекомендации для прочтения и изучения
Техники тест-дизайна:
📌Классы эквивалентности и граничные значения
📌Таблицы решений и их применение в тестировании
📌Методология разработки тестовых случаев на основе сценариев использования
📌Техника попарного тестирования
📌Предугадывание ошибок
📌Таблица состояний и переходов - часть 1 и Таблица состояний и переходов -часть 2
📌Эквивалентное разбиение, Граничные значения, Таблица принятия решений, Причина и следствие, Попарное тестирование, Предугадывание ошибок
📌Расшифровка понятий по техникам тест-дизайна
📌Обзор техник тест-дизайна: все вышеупомянутые техники, а также Тестирование и покрытие операторов, Тестирование и покрытие условий, Исследовательское тестирование, Тестирование на основе чек-листов
Дополнительная информация:
Чит-лист – список повторяющихся проверок.
Примеры проверок для тестирования формы регистрации.
Техники тест-дизайна:
📌Классы эквивалентности и граничные значения
📌Таблицы решений и их применение в тестировании
📌Методология разработки тестовых случаев на основе сценариев использования
📌Техника попарного тестирования
📌Предугадывание ошибок
📌Таблица состояний и переходов - часть 1 и Таблица состояний и переходов -часть 2
📌Эквивалентное разбиение, Граничные значения, Таблица принятия решений, Причина и следствие, Попарное тестирование, Предугадывание ошибок
📌Расшифровка понятий по техникам тест-дизайна
📌Обзор техник тест-дизайна: все вышеупомянутые техники, а также Тестирование и покрытие операторов, Тестирование и покрытие условий, Исследовательское тестирование, Тестирование на основе чек-листов
Дополнительная информация:
Чит-лист – список повторяющихся проверок.
Примеры проверок для тестирования формы регистрации.
Извиняюсь за небольшое отсутствие, включаюсь в процесс изучения и повторения😄😄😄
#выжимкаинформации из одной презентации про #дефекты
В реальности далеко не все найденные дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается до следующего релиза.
🖍Причина 1 – Нехватка времени.
В любом проекте приходится иметь дело с огромным количеством программных свойств. Людей, которые эти свойства могли бы записать в код и протестировать, как правило не хватает, не говоря уже о времени для завершения работ.
🖍Причина 2 – Дефект вовсе не дефект.
Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!» или «Это не дефект, а фича!» или «Это не баг, а фича!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы.
🖍Причина 3 – Устранять неисправность слишком рискованно.
К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных.
🖍Причина 4 – Это того не стоит.
Дефекты, которые будут проявляться очень редко или в малоиспользуемых функциях, могут быть оставлены без изменений. Дефекты, которые можно обойти или предотвратить, так же часто не устраняются. Все сводится к оценке рисков.
🖍Причина 5 – Неэффективный отчет о дефектах.
Тестировщик недостаточно обосновал необходимость устранения определенного дефекта. В результате, дефект не был воспринят как таковой, был воспринят как не препятствующий выпуску продукта, как слишком рискованный для устранения или просто как не стоящий усилий по устранению.
#выжимкаинформации из одной презентации про #дефекты
В реальности далеко не все найденные дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается до следующего релиза.
🖍Причина 1 – Нехватка времени.
В любом проекте приходится иметь дело с огромным количеством программных свойств. Людей, которые эти свойства могли бы записать в код и протестировать, как правило не хватает, не говоря уже о времени для завершения работ.
🖍Причина 2 – Дефект вовсе не дефект.
Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!» или «Это не дефект, а фича!» или «Это не баг, а фича!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы.
🖍Причина 3 – Устранять неисправность слишком рискованно.
К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных.
🖍Причина 4 – Это того не стоит.
Дефекты, которые будут проявляться очень редко или в малоиспользуемых функциях, могут быть оставлены без изменений. Дефекты, которые можно обойти или предотвратить, так же часто не устраняются. Все сводится к оценке рисков.
🖍Причина 5 – Неэффективный отчет о дефектах.
Тестировщик недостаточно обосновал необходимость устранения определенного дефекта. В результате, дефект не был воспринят как таковой, был воспринят как не препятствующий выпуску продукта, как слишком рискованный для устранения или просто как не стоящий усилий по устранению.
Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую необходимо протестировать.
Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.
🧰анализируем требования и выделяем для себя следующие нюансы:
⚙️какие из полей обязательные для заполнения?
⚙️имеют ли поля ограничения по длине или по размерности (границы)?
⚙️какие из полей имеют специальные форматы?
🧰Бывает:
💻Тестирование форм без спецификации
💻Проверка полей на основе технической документации
💻Тестирование текстовых полей + автоматизация
🧰Определяют:
📌Текстовое поле ввода для буквенных данных
📌Текстовое поле ввода для числовых данных
📌Поле ввода для дробных чисел
📌Текстовое поле для ввода процентов (%)
📌Поля ввода для даты
📌Поле ввода для времени
📌Текстовые поля ввода определенного формата (например, адрес электронной почты)
📌Ниспадающие списки с заранее определенным набором данных
📌Таблицы (списки)
📌Переключатели (Флажки, Радиокнопки)
📌Диалоговые окна с кнопками Да, Нет, Отмена
🧰Тестовые сценарии для проверки функциональности систем
🎈Вход в систему
🎈Фильтр и поиск
🎈Генерация отчетов
🎈Создание, редактирование и удаление сущности
🎈Сортировка списков
🎈Экспорт, печать, открытие файлов
🧰Чит-лист для проверки поля:
🏮Пустое поле
🏮Корректное значение
🏮Граничные значения
🏮Отрицательные числа
🏮Ноль
🏮Числа со знаком +
🏮Спецсимволы
🏮Дробные числа с разделителем "точка"
🏮Дробные числа с разделителем "запятая"
🏮Условие: должны приниматься или не приниматься буквы
🏮Условие: должны приниматься или не приниматься спецсимволы
🏮Условие: должны приниматься или не приниматься числа
🏮Научная запись, в виде экспоненты, логарифма, тригонометрических функций, суммы...
🏮Шестнадцатеричная система счисления
🧰последовательный подход к разработке тестовых случаев (тест кейсов), используя самые простейшие техники тест дизайна:
Эквивалентное Разделение (Equivalence Partitioning)
Анализ Граничных Значений (Boundary Value Analysis)
Предугадывание ошибки (Error Guessing)
Причина / Следствие (Cause/Effect)
Необходимая информация для прочтения:
Тестирование текстового поля
Самые простые и эффективные способы тестирования поля ввода текста
Тестирование полей ввода (Чит-листы)
Практическое применение техник тест дизайна при разработке тест кейсов
Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.
🧰анализируем требования и выделяем для себя следующие нюансы:
⚙️какие из полей обязательные для заполнения?
⚙️имеют ли поля ограничения по длине или по размерности (границы)?
⚙️какие из полей имеют специальные форматы?
🧰Бывает:
💻Тестирование форм без спецификации
💻Проверка полей на основе технической документации
💻Тестирование текстовых полей + автоматизация
🧰Определяют:
📌Текстовое поле ввода для буквенных данных
📌Текстовое поле ввода для числовых данных
📌Поле ввода для дробных чисел
📌Текстовое поле для ввода процентов (%)
📌Поля ввода для даты
📌Поле ввода для времени
📌Текстовые поля ввода определенного формата (например, адрес электронной почты)
📌Ниспадающие списки с заранее определенным набором данных
📌Таблицы (списки)
📌Переключатели (Флажки, Радиокнопки)
📌Диалоговые окна с кнопками Да, Нет, Отмена
🧰Тестовые сценарии для проверки функциональности систем
🎈Вход в систему
🎈Фильтр и поиск
🎈Генерация отчетов
🎈Создание, редактирование и удаление сущности
🎈Сортировка списков
🎈Экспорт, печать, открытие файлов
🧰Чит-лист для проверки поля:
🏮Пустое поле
🏮Корректное значение
🏮Граничные значения
🏮Отрицательные числа
🏮Ноль
🏮Числа со знаком +
🏮Спецсимволы
🏮Дробные числа с разделителем "точка"
🏮Дробные числа с разделителем "запятая"
🏮Условие: должны приниматься или не приниматься буквы
🏮Условие: должны приниматься или не приниматься спецсимволы
🏮Условие: должны приниматься или не приниматься числа
🏮Научная запись, в виде экспоненты, логарифма, тригонометрических функций, суммы...
🏮Шестнадцатеричная система счисления
🧰последовательный подход к разработке тестовых случаев (тест кейсов), используя самые простейшие техники тест дизайна:
Эквивалентное Разделение (Equivalence Partitioning)
Анализ Граничных Значений (Boundary Value Analysis)
Предугадывание ошибки (Error Guessing)
Причина / Следствие (Cause/Effect)
Необходимая информация для прочтения:
Тестирование текстового поля
Самые простые и эффективные способы тестирования поля ввода текста
Тестирование полей ввода (Чит-листы)
Практическое применение техник тест дизайна при разработке тест кейсов
‼️Завтра проведу тестирование на закрепление знаний!
📚 ProTestingInfo 🔷 Канал по тестированию 📚
Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую необходимо протестировать. Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить…
Из данных ссылок можно ознакомиться с различными проверками такими как:
🔷Нажать на кнопку «Готово», без предварительного заполнения формы.
🔷Несколько раз нажать на клавишу пробела внутри формы, а затем кликнуть на кнопку подтверждения.
🔷Проанализировать, сколько можно ввести символов в форму, с последующим нажатием кнопки «Готово».
🔷Ввести минус, затем ввести максимальное количество цифр и нажать на клавишу подтверждения.
🔹Ввести все доступные специальные символы и нажать на кнопку отправки формы. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
🔷Попробуйте ввести символы, которые технически не относятся к ASCII, разные эмоджи и нажмите на Submit. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
🔷Испытайте возможность выполнения межсайтового скриптинга. Для этого нужно ввести такой сценарий: <noscript>alert(«I hacked this!»)</noscript>. Если после нажатия на кнопку отправки формы отобразится всплывающий поп-ап, значит данное текстовое поле максимально уязвимо для XSS-атаки.
🔷Проверьте возможность ввода SQL-инъекции. Введите FOO’); DROP TABLE USERS. Но ни в коем случае не совершайте подобные манипуляции с базами данных сайтов, которые уже запущенны онлайн.
Найдите возможность и время ознакомиться с информацией😉
🔷Нажать на кнопку «Готово», без предварительного заполнения формы.
🔷Несколько раз нажать на клавишу пробела внутри формы, а затем кликнуть на кнопку подтверждения.
🔷Проанализировать, сколько можно ввести символов в форму, с последующим нажатием кнопки «Готово».
🔷Ввести минус, затем ввести максимальное количество цифр и нажать на клавишу подтверждения.
🔹Ввести все доступные специальные символы и нажать на кнопку отправки формы. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
🔷Попробуйте ввести символы, которые технически не относятся к ASCII, разные эмоджи и нажмите на Submit. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.
🔷Испытайте возможность выполнения межсайтового скриптинга. Для этого нужно ввести такой сценарий: <noscript>alert(«I hacked this!»)</noscript>. Если после нажатия на кнопку отправки формы отобразится всплывающий поп-ап, значит данное текстовое поле максимально уязвимо для XSS-атаки.
🔷Проверьте возможность ввода SQL-инъекции. Введите FOO’); DROP TABLE USERS. Но ни в коем случае не совершайте подобные манипуляции с базами данных сайтов, которые уже запущенны онлайн.
Найдите возможность и время ознакомиться с информацией😉
🔷Наглядное руководство по каждому типу тестов🔷
https://zen.yandex.ru/media/nuancesprog/nagliadnoe-rukovodstvo-po-kajdomu-tipu-testov-5f38f69e970749285441744f
Все, что написано на изображениях, представляет собой скромное субъективное мнение и интерпретацию автора😄.
https://zen.yandex.ru/media/nuancesprog/nagliadnoe-rukovodstvo-po-kajdomu-tipu-testov-5f38f69e970749285441744f
Все, что написано на изображениях, представляет собой скромное субъективное мнение и интерпретацию автора😄.
#тестыдлязакреплениязнаний - будет 10 тестов 🧑🏻💻👨🏼💻