В самом начале составляла этот пост! Важно ознакомиться!
Forwarded from 📚 ProTestingInfo 🔷 Канал по тестированию 📚
#требование
‼️Если применить к этой классификации популярное разделение требований на функциональные и нефункциональные, то к последним следует отнести все перечисленные выше группы кроме первой
🖍Functionality - функциональных требований: свойства, особенности, безопасность и др.
🖍Usability - требования к юзабилити: человеческий фактор, эстетичность, последовательность, документация и др.
🖍Reliability - требования к надежности: частота возможных отказов, отказоустойчивость, восстанавливаемость, предсказуемости, устойчивости и др.
🖍Performance - требования к производительности: время отклика, использование ресурсов, эффективность, производительность, масштабируемость и др.
🖍Supportability - поддержка требования: умение поддержать, ремонтопригодность, гибкость, модифицируемость, модульность, расширяемость, способность к локализации и др.
‼️+. Ограничения
🖍Ограничения проектирования: ограничения на технологии (например, «Хранение необходимо реализовать с помощью реляционной БД»), процесс или методология разработки, средства разработки (документация — в MS Word»),
🖍Ограничения реализации, разработки, построение, написания программного кода: стандарты разработки, стандарты качества ПО, в т.ч. кода, языки программирования, средства разработки, ресурсные ограничения, лицензионные ограничения, ограничения на техническое обеспечение,
🖍Требования к интерфейсам — ограничения накладываемые необходимостью взаимодействия с другими системами: форматы данных, протоколы взаимодействия, внешние системы,
🖍Физические ограничения, накладываемые на технические (аппаратные) средства и окружение системы: форма, размер, вес, температурный режим, влажность, ограничения на вибрацию
FYI – https://sysana.wordpress.com/2010/09/16/furps/
https://studme.org/226097/informatika/klassifikatsiya_trebovaniy_furps
‼️Если применить к этой классификации популярное разделение требований на функциональные и нефункциональные, то к последним следует отнести все перечисленные выше группы кроме первой
🖍Functionality - функциональных требований: свойства, особенности, безопасность и др.
🖍Usability - требования к юзабилити: человеческий фактор, эстетичность, последовательность, документация и др.
🖍Reliability - требования к надежности: частота возможных отказов, отказоустойчивость, восстанавливаемость, предсказуемости, устойчивости и др.
🖍Performance - требования к производительности: время отклика, использование ресурсов, эффективность, производительность, масштабируемость и др.
🖍Supportability - поддержка требования: умение поддержать, ремонтопригодность, гибкость, модифицируемость, модульность, расширяемость, способность к локализации и др.
‼️+. Ограничения
🖍Ограничения проектирования: ограничения на технологии (например, «Хранение необходимо реализовать с помощью реляционной БД»), процесс или методология разработки, средства разработки (документация — в MS Word»),
🖍Ограничения реализации, разработки, построение, написания программного кода: стандарты разработки, стандарты качества ПО, в т.ч. кода, языки программирования, средства разработки, ресурсные ограничения, лицензионные ограничения, ограничения на техническое обеспечение,
🖍Требования к интерфейсам — ограничения накладываемые необходимостью взаимодействия с другими системами: форматы данных, протоколы взаимодействия, внешние системы,
🖍Физические ограничения, накладываемые на технические (аппаратные) средства и окружение системы: форма, размер, вес, температурный режим, влажность, ограничения на вибрацию
FYI – https://sysana.wordpress.com/2010/09/16/furps/
https://studme.org/226097/informatika/klassifikatsiya_trebovaniy_furps
SkillsCup.com
Требования к системе: классификация FURPS+
Классификация требований к системе FURPS+ была разработана Робертом Грэйди (Robert Grady) из Hewlett-Packard и предложена в 1992 году. Сокращение FURPS расшифровывается так: Functionality, функцион…
🔥6👍3
Начало поста:
Требование - это "условие или возможность, которым должна соответствовать система".
🔷Существует много разновидностей требований. Одна из классификаций требований называется моделью FURPS+ , где FURPS - первые буквы названий категорий требований на английском языке.
🔶Классификация требований к системе FURPS+ была разработана Робертом Грэйди (Robert Grady) из Hewlett-Packard и предложена в 1992 год
🔹Functionality (функциональные требования)
🔹Usability (требования к удобству работы)
🔹Reliability (требования к надежности)
🔹Performance (требования к производительности)
🔹Supportability (требования к простоте поддержки)
Знак плюса "+" в аббревиатуре FURPS+ охватывает дополнительные категории требований:
🔸ограничения на структуру проекта
🔸требования к реализации
🔸требования к интерфейсу
🔸физические требования.
Требование - это "условие или возможность, которым должна соответствовать система".
🔷Существует много разновидностей требований. Одна из классификаций требований называется моделью FURPS+ , где FURPS - первые буквы названий категорий требований на английском языке.
🔶Классификация требований к системе FURPS+ была разработана Робертом Грэйди (Robert Grady) из Hewlett-Packard и предложена в 1992 год
🔹Functionality (функциональные требования)
🔹Usability (требования к удобству работы)
🔹Reliability (требования к надежности)
🔹Performance (требования к производительности)
🔹Supportability (требования к простоте поддержки)
Знак плюса "+" в аббревиатуре FURPS+ охватывает дополнительные категории требований:
🔸ограничения на структуру проекта
🔸требования к реализации
🔸требования к интерфейсу
🔸физические требования.
👍13🔥4
👍9👏1
ПРИМЕРЫ интеграционного тестирования...
Хочу поблагодарить за вопросы, которые пишите мне для разбора.
И вот был следующий вопрос: "Добрый день! Подскажите, что значит высокоуровневые и низкоуровневые модули?" после того как я запостила информацию про расшифровку понятий. И тут я поняла, что общими фразами как-то понятно , но нет примеров... Согласны???
Давайте разберемся.
Интеграционное тестирование - тестирование связи между модулями и тестирование связи между частями ПО.
Целью данного уровня тестирования является выявление дефектов взаимодействия между этими программными модулями при их интеграции.
#Driver, #Stub - эмулируемые компоненты системы.
#Драйвер (Driver) - это заглушка, которая отправляет запросы к нашей тестируемой системе (или другим образом управляет).
#Заглушка (Stub) - это заглушка, которая получает запросы от системы и отправляет какой-то "вшитый" ответ.
И заглушки, и драйверы являются фиктивными модулями и создаются только для тестовых целей.
#Заглушки используются при тестировании сверху вниз, когда основной модуль готов к тестированию, но подмодули еще не готовы. Таким образом, на простом языке заглушки - это «вызываемые» программы, которые вызываются для проверки функциональности основного модуля.
Например, в ситуации, когда у одного есть три разных модуля: Login, Home, User. Предположим, модуль входа в систему готов к тестированию, но два второстепенных модуля Home и User, которые вызываются модулем входа, еще не готовы для тестирования. В это время написан кусок фиктивного кода, который имитирует вызываемые методы Home и User. Эти фиктивные фрагменты кода являются заглушками.
Или
Например, ситуация, в которой веб-приложение готово, но база данных ещё не готова, и вместо базы данных делают временно заглушку. Вместо базы данных будет использована заглушка.
#Драйверы являются «вызывающими» программами. Драйверы используются при восходящем тестировании (Снизу вверх). Драйверы - это фиктивный код, который используется, когда подмодули готовы, но основной модуль еще не готов. Возьмем тот же пример, что и выше. Предположим, на этот раз модули User и Home готовы, но модуль Login не готов к тестированию. Теперь, когда Home и User возвращают значения из модуля Login, создается фиктивный фрагмент кода, имитирующий модуль Login. Этот фиктивный код затем называется Driver.
Пример: https://ru.qaz.wiki/wiki/Test_stub
На моём опыте было реализовано приложение, в котором была разработана имитация логина в систему, так как нужна была внешняя интеграция с другой системой, поэтому сначала разрабатывались нижние модули: личный кабинет пользователя, список сущностей и их создание, обновление и удаление и т.д.
#теория https://news.1rj.ru/str/protestinginfo/427
Хочу поблагодарить за вопросы, которые пишите мне для разбора.
И вот был следующий вопрос: "Добрый день! Подскажите, что значит высокоуровневые и низкоуровневые модули?" после того как я запостила информацию про расшифровку понятий. И тут я поняла, что общими фразами как-то понятно , но нет примеров... Согласны???
Давайте разберемся.
Интеграционное тестирование - тестирование связи между модулями и тестирование связи между частями ПО.
Целью данного уровня тестирования является выявление дефектов взаимодействия между этими программными модулями при их интеграции.
#Driver, #Stub - эмулируемые компоненты системы.
#Драйвер (Driver) - это заглушка, которая отправляет запросы к нашей тестируемой системе (или другим образом управляет).
#Заглушка (Stub) - это заглушка, которая получает запросы от системы и отправляет какой-то "вшитый" ответ.
И заглушки, и драйверы являются фиктивными модулями и создаются только для тестовых целей.
#Заглушки используются при тестировании сверху вниз, когда основной модуль готов к тестированию, но подмодули еще не готовы. Таким образом, на простом языке заглушки - это «вызываемые» программы, которые вызываются для проверки функциональности основного модуля.
Например, в ситуации, когда у одного есть три разных модуля: Login, Home, User. Предположим, модуль входа в систему готов к тестированию, но два второстепенных модуля Home и User, которые вызываются модулем входа, еще не готовы для тестирования. В это время написан кусок фиктивного кода, который имитирует вызываемые методы Home и User. Эти фиктивные фрагменты кода являются заглушками.
Или
Например, ситуация, в которой веб-приложение готово, но база данных ещё не готова, и вместо базы данных делают временно заглушку. Вместо базы данных будет использована заглушка.
#Драйверы являются «вызывающими» программами. Драйверы используются при восходящем тестировании (Снизу вверх). Драйверы - это фиктивный код, который используется, когда подмодули готовы, но основной модуль еще не готов. Возьмем тот же пример, что и выше. Предположим, на этот раз модули User и Home готовы, но модуль Login не готов к тестированию. Теперь, когда Home и User возвращают значения из модуля Login, создается фиктивный фрагмент кода, имитирующий модуль Login. Этот фиктивный код затем называется Driver.
Пример: https://ru.qaz.wiki/wiki/Test_stub
На моём опыте было реализовано приложение, в котором была разработана имитация логина в систему, так как нужна была внешняя интеграция с другой системой, поэтому сначала разрабатывались нижние модули: личный кабинет пользователя, список сущностей и их создание, обновление и удаление и т.д.
#теория https://news.1rj.ru/str/protestinginfo/427
Telegram
📚 ProTestingInfo 🔷 Канал по тестированию 📚
Инкрементальный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами . Заглушки и драйверы не реализуют всю логику программирования программного модуля, а только моделируют обмен данными с вызывающим модулем.
Заглушка :…
Заглушка :…
👍21❤6👎1🕊1
Всем хорошего дня.
В нельзяграме начну тесты для закрепления знаний , будет 6 тестов по теории тестирования (лайтовых), а затем здесь продолжу.
В нельзяграме начну тесты для закрепления знаний , будет 6 тестов по теории тестирования (лайтовых), а затем здесь продолжу.
👍16
Как расшифровывается QC?
Anonymous Quiz
1%
Quality Content
97%
Quality Control
1%
Quality Condition
1%
Quality Configuration
🔥4🐳3👍1
Каждое требование должно иметь уникальный идентификатор.
Что за атрибут требования?
Что за атрибут требования?
Anonymous Quiz
15%
Приоритетность
10%
Проверяемость
34%
Прослеживаемость
40%
Единичность
🔥6🤔3⚡2👍1👎1
По какому часто встречаемому шаблону составляется пользовательская история?
Anonymous Quiz
69%
«Как [пользователь], я хочу […], чтобы […]»
21%
«Как [пользователь], я сделаю […], чтобы […]»
8%
«Как [пользователь], я буду […], чтобы […]»
2%
«Как [пользователь], я умею […], чтобы […]»
👍5🔥3👏2🏆1
В этой технике тест-дизайна подразумевается ввод условий, для получения ответа от системы ?
Что за техника тест-дизайна?
Что за техника тест-дизайна?
Anonymous Quiz
9%
Доменный анализ
8%
Предугадывание ошибки
54%
Причина / Следствие
29%
Тестирование на основе состояний и переходов
🌚10👏5👎1
Определение требований .pdf
326.3 KB
Повторяем. Обязательно продолжу тестирование по этой теме.
👍19
#повторение:
Шаблоны матрицы трассируемости бывают разными, все зависит от процессов тестирования в проекте. Порой такая матрица необходима в проекте, даже с минимальным количеством требований.
😊На картинке представлен шаблон собственного сочинения.
По опыту скажу в одном из проектов у нас была прям очень огромная матрица соответствия требований, где были требования и тестовые сценарии всех релизов и она имела крутую структуру, что новичку была понятна. (Я постараюсь показать кусочек этой таблицы ). А я как раз была младшим специалистом.
🔵Общее определение из источников интернета:
Матрица соответствия требований (Requirements Traceability Matrix - RTM)
Матрица трассировки или матрица трассабилити или
Матрица трассируемости
это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках строк таблицы расположены требования, а в заголовках колонок – тестовые сценарии или наоборот. На пересечении – отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы.
Матрица соответствия требований используется для валидации покрытия требований по продукту тестами. Цель состоит в том, чтобы выяснить какие требования «покрыты» тестами, а какие нет, и есть ли в системе избыточное тестирование.
Матрица позволяет контролировать реализацию требований, отслеживать, что все требования разработаны и протестированы и ничего не пропущено.
Матрица помогает команде QA отслеживать, есть ли долг по тестовой документации, и какие именно требования еще не покрыты тест-кейсами.
#теория
Шаблоны матрицы трассируемости бывают разными, все зависит от процессов тестирования в проекте. Порой такая матрица необходима в проекте, даже с минимальным количеством требований.
😊На картинке представлен шаблон собственного сочинения.
По опыту скажу в одном из проектов у нас была прям очень огромная матрица соответствия требований, где были требования и тестовые сценарии всех релизов и она имела крутую структуру, что новичку была понятна. (
🔵Общее определение из источников интернета:
Матрица соответствия требований (Requirements Traceability Matrix - RTM)
Матрица трассировки или матрица трассабилити или
Матрица трассируемости
это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках строк таблицы расположены требования, а в заголовках колонок – тестовые сценарии или наоборот. На пересечении – отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы.
Матрица соответствия требований используется для валидации покрытия требований по продукту тестами. Цель состоит в том, чтобы выяснить какие требования «покрыты» тестами, а какие нет, и есть ли в системе избыточное тестирование.
Матрица позволяет контролировать реализацию требований, отслеживать, что все требования разработаны и протестированы и ничего не пропущено.
Матрица помогает команде QA отслеживать, есть ли долг по тестовой документации, и какие именно требования еще не покрыты тест-кейсами.
#теория
👍26❤6
Прошлый мой Рилс про случай «Когда наврал в резюме…» набрал 1,1 млн просмотров, удалила, так как познакомилась с этим парнем, и по его просьбе удалила.
«Слабое звено» телепередача не даёт мне покоя.
И возникла ещё давно идея на рилс в нельзяграме.
Готовьтесь к собеседованиям
Есть время, просмотрите😁
«Слабое звено» телепередача не даёт мне покоя.
И возникла ещё давно идея на рилс в нельзяграме.
Готовьтесь к собеседованиям
Есть время, просмотрите
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣5❤4🔥1👏1
Привет всем! Так, извиняюсь за задержку, задач по работе в Сбере стало больше.
Каждый день по 2 консультации с менти на разбор разных тем. Стараюсь также успевать проверять домашки, ещё 4 работы в ожидании. Конечно, сейчас с поиском работы сложновато, и все же не сдаёмся, главное закреплять свои знания каждый день!
Сейчас обещанные тесты по теме «Третования».
Кстати я разместила свой пост на vc.ru, хотя вы с этой уже информацией ознакомлены, просто собрала все шаблоны по API в одном месте.
Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности
Каждый день по 2 консультации с менти на разбор разных тем. Стараюсь также успевать проверять домашки, ещё 4 работы в ожидании. Конечно, сейчас с поиском работы сложновато, и все же не сдаёмся, главное закреплять свои знания каждый день!
Сейчас обещанные тесты по теме «Третования».
Кстати я разместила свой пост на vc.ru, хотя вы с этой уже информацией ознакомлены, просто собрала все шаблоны по API в одном месте.
Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности
vc.ru
Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности — ProTestingInfo QA на vc.ru
Привет всем!
👍23❤8❤🔥1👏1
Существует следующая классификация требований, в которой определено три уровня требований: бизнес-требования, пользовательские требования, функциональные требования. Это уровни требований называют уровни требований по…
Anonymous Quiz
50%
Вигерсу
30%
Вагнеру
20%
Вольтеру
😱7👍3👎2❤1🌚1💯1
С точки зрения требований про сценарий использования.
Какие разделы может себя включать сценарий использования?
Какие разделы может себя включать сценарий использования?
Anonymous Quiz
20%
Название, предусловие, функциональный сценарий, нефункциональный сценарий, исключение, расширение
33%
Название, предусловие, ожидаемый сценарий, фактический сценарий, исключение, расширение
48%
Название, предусловие, основной сценарий, альтернативный сценарий, исключение, расширение
👍6🥰2🌚1
В рамках UC (use cases - сценариев использования) как называют несколько разных пользовательских ролей и/или внешние сервисы, которые будут интегрироваться с проектируемой системой?
Дать точное понятие согласно UC.
Дать точное понятие согласно UC.
Anonymous Quiz
33%
Клиенты
35%
Акторы
32%
Субъекты
👍2👎1🔥1👏1