Полезная информация :👏
#postman
https://proglib.io/p/api-dlya-qa-uchimsya-testirovaniyu-po-bez-dostupa-k-kodu-2020-12-10
#postman
https://proglib.io/p/api-dlya-qa-uchimsya-testirovaniyu-po-bez-dostupa-k-kodu-2020-12-10
Библиотека программиста
👨🔧️ API для QA: учимся тестированию ПО без доступа к коду
При обучении тестировщику стоит освоить API для QA, ведь на реальных проектах часто приходится работать с продуктом без доступа к исходному коду. На примере базовых запросов рассмотрим популярный инструмент Postman, позволяющий делать это даже новичкам.
Внимательно посмотрите схему, всегда продукт можно сделать или быстро, или дёшево, или качественно. Но есть границы:
🖍быстро и качественно это дорого.
🖍 качественно и дёшево это долго
🖍 дёшево и быстро это криво, с дефектами.
В таком виде представляется проект 😌
Утопия 😱🤯 лучше до такого не доводить #проект )).
🖍быстро и качественно это дорого.
🖍 качественно и дёшево это долго
🖍 дёшево и быстро это криво, с дефектами.
В таком виде представляется проект 😌
Утопия 😱🤯 лучше до такого не доводить #проект )).
Представляю выжимку интересных мыслей про проект из интернета для вашего внимания (FYI - for your information). Немного не по теме канала, но это первое, с чем вы столкнетесь на работе в позиции тестировщика.
❗️ИТ-проект – это краткосрочное усилие по созданию уникального продукта, сервиса или среды, например, замещение старых сервисов новыми, разработка коммерческого сайта, создание новых видов настольных компьютеров или слияние баз данных. Процессы управления ИТ-проектами в компании часто имеют сложный и многоступенчатый характер.
‼️🖍Все проекты ограничены тремя факторами: время, стоимость, объем. 👍Для того, чтобы проект был успешным, эти три ограничения должны быть в равновесии. Если эти ограничения находятся вне баланса, проект движется к катастрофе.🙈
«Быстро» и «медленно» – достаточно субъективные термины: то, что кажется медленным для вашей организации, может полностью удовлетворять по скорости другую. Важно установить разумные временные рамки для завершения ИТ-проекта на основании объема работы, ожидаемых результатов и условий проекта.
🖍🖍Все проекты, включая ИТ, проходят через 5 основных фаз жизненного цикла: инициация, планирование, выполнение, мониторинг и контроль, завершение. Каждая фаза содержит процессы, которые двигают проект от идеи до реализации.
🖍🖍Практически любой проект разработки включает в себя следующие работы:
требования; анализ; проектирование; кодирование; тестирование
‼️ИТ-Проект в узком понимании - это запланированные и задокументированные работы, связанные с оценкой, выбором, модернизацией, адаптацией, настройкой, внедрением, тестированием, описанием, интеграцией
информационных систем в определённой бизнес-области
Планирование и документирование - весьма важные составляющие ИТ-Проекта.
🖍🖍 Руководитель ИТ-проектов – сотрудник, целью которого является сопровождение конкретного проекта от планирования до реализации. Критерием успеха здесь является соответствие результата поставленным задачам.
‼️Суть проекта может заключаться в разработке новой информационной системы или во внедрении уже существующей системы в компании. В один период времени руководитель ИТ-проектов может заниматься одним крупным проектом или несколькими небольшими. В любом случае его труд является разносторонним, ему приходится все время переключаться с одной задачи на другую и одновременно удерживать перед глазами общую картину.
‼️Существует три основных подхода для управления ИТ-проектами.
🖍Первый основан на традиционном управлении проектами. Он работает на любом ИТ-проекте независимо от используемых технологий или продолжительности работы над проектом.
🖍Второй подход называется «экстремальным программированием». Иногда для него используют аббревиатуру XP (не спутайте с операционной системой Windows). Экстремальное программирование – это подход к управлению проектом, созданный специально для разработки программного обеспечения. XP использует модель разработки ПО, включающую пользователей, клиентов и программистов в 4 итеративные фазы: планирование, написание кода, разработка дизайна и тестирование.
🖍Scrum – метод, лидирующий в применении к ИТ-проектам. Этот подход, названный в честь термина регби, также использует итерации планирования, кодирования, выполнения и тестирования программного обеспечения. Scrum использует свой собственный язык и имеет свои правила относительно встреч, соответствия ключевым этапам и периодам планирования деятельности.
#проект
❗️ИТ-проект – это краткосрочное усилие по созданию уникального продукта, сервиса или среды, например, замещение старых сервисов новыми, разработка коммерческого сайта, создание новых видов настольных компьютеров или слияние баз данных. Процессы управления ИТ-проектами в компании часто имеют сложный и многоступенчатый характер.
‼️🖍Все проекты ограничены тремя факторами: время, стоимость, объем. 👍Для того, чтобы проект был успешным, эти три ограничения должны быть в равновесии. Если эти ограничения находятся вне баланса, проект движется к катастрофе.🙈
«Быстро» и «медленно» – достаточно субъективные термины: то, что кажется медленным для вашей организации, может полностью удовлетворять по скорости другую. Важно установить разумные временные рамки для завершения ИТ-проекта на основании объема работы, ожидаемых результатов и условий проекта.
🖍🖍Все проекты, включая ИТ, проходят через 5 основных фаз жизненного цикла: инициация, планирование, выполнение, мониторинг и контроль, завершение. Каждая фаза содержит процессы, которые двигают проект от идеи до реализации.
🖍🖍Практически любой проект разработки включает в себя следующие работы:
требования; анализ; проектирование; кодирование; тестирование
‼️ИТ-Проект в узком понимании - это запланированные и задокументированные работы, связанные с оценкой, выбором, модернизацией, адаптацией, настройкой, внедрением, тестированием, описанием, интеграцией
информационных систем в определённой бизнес-области
Планирование и документирование - весьма важные составляющие ИТ-Проекта.
🖍🖍 Руководитель ИТ-проектов – сотрудник, целью которого является сопровождение конкретного проекта от планирования до реализации. Критерием успеха здесь является соответствие результата поставленным задачам.
‼️Суть проекта может заключаться в разработке новой информационной системы или во внедрении уже существующей системы в компании. В один период времени руководитель ИТ-проектов может заниматься одним крупным проектом или несколькими небольшими. В любом случае его труд является разносторонним, ему приходится все время переключаться с одной задачи на другую и одновременно удерживать перед глазами общую картину.
‼️Существует три основных подхода для управления ИТ-проектами.
🖍Первый основан на традиционном управлении проектами. Он работает на любом ИТ-проекте независимо от используемых технологий или продолжительности работы над проектом.
🖍Второй подход называется «экстремальным программированием». Иногда для него используют аббревиатуру XP (не спутайте с операционной системой Windows). Экстремальное программирование – это подход к управлению проектом, созданный специально для разработки программного обеспечения. XP использует модель разработки ПО, включающую пользователей, клиентов и программистов в 4 итеративные фазы: планирование, написание кода, разработка дизайна и тестирование.
🖍Scrum – метод, лидирующий в применении к ИТ-проектам. Этот подход, названный в честь термина регби, также использует итерации планирования, кодирования, выполнения и тестирования программного обеспечения. Scrum использует свой собственный язык и имеет свои правила относительно встреч, соответствия ключевым этапам и периодам планирования деятельности.
#проект
❤2
#Тестовыйсценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата
Test Case - тест-кейс - тестовый случай - Test Scenario - тестовый сценарий
🔷Чего не должно быть в тест-кейсе:
🔸Зависимостей от других тест-кейсов
🔸Нечеткой формулировки шагов или ожидаемого результата
🔸Отсутствия необходимой для прохождения тест-кейса информации
🔸Излишней детализации
🔷Рекомендации:
🖍Набор тестов не должен быть избыточным
🖍Проверяет интересующую часть
🖍Не затрагивает те части, которые не интересуют на данном этапе
🖍Не пересекается с другими тестами
🖍Не слишком сложен и не слишком прост
🖍Определяет соответствие спецификации
🔷Отделение тестовой процедуры от тестовых данных
🔹Процедура является
описанием последовательности шагов для выполнения теста, описанием правил навигации
🔹Тестовые данные -любые данные, заносимые пользователем в форму или в поле, переменная часть теста
😌Запомнить!
*⃣Каждый тест должен ссылаться на требование
*⃣Каждое требование должно быть проверяемым и должно иметь тест
*⃣Тестирование проводится планово!
*⃣Принцип Парето - Всё проверить нельзя!
*⃣Начинать с малого и наращивать взаимосвязь с другими тестами
*⃣Не забывать про нефункциональные требования
🔷Наборы тестовых сценариев - это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test noscript)), так и независимыми (Test suite)
🔷Наиболее часто выделяемыми наборами являются:
🔹Набор тестовых сценариев для Smoke-test(дымовое тестирование
🔹План приёмо-сдаточных испытаний
🖍Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.
🖍План приёмо-сдаточных испытаний (ПСИ) - документ, включающий в себя набор определенных тестовых сценариев, после положительного прохождения которого заказчик подписывает акт приемо-передачи (сдачи-приемки).
Test Case - тест-кейс - тестовый случай - Test Scenario - тестовый сценарий
🔷Чего не должно быть в тест-кейсе:
🔸Зависимостей от других тест-кейсов
🔸Нечеткой формулировки шагов или ожидаемого результата
🔸Отсутствия необходимой для прохождения тест-кейса информации
🔸Излишней детализации
🔷Рекомендации:
🖍Набор тестов не должен быть избыточным
🖍Проверяет интересующую часть
🖍Не затрагивает те части, которые не интересуют на данном этапе
🖍Не пересекается с другими тестами
🖍Не слишком сложен и не слишком прост
🖍Определяет соответствие спецификации
🔷Отделение тестовой процедуры от тестовых данных
🔹Процедура является
описанием последовательности шагов для выполнения теста, описанием правил навигации
🔹Тестовые данные -любые данные, заносимые пользователем в форму или в поле, переменная часть теста
😌Запомнить!
*⃣Каждый тест должен ссылаться на требование
*⃣Каждое требование должно быть проверяемым и должно иметь тест
*⃣Тестирование проводится планово!
*⃣Принцип Парето - Всё проверить нельзя!
*⃣Начинать с малого и наращивать взаимосвязь с другими тестами
*⃣Не забывать про нефункциональные требования
🔷Наборы тестовых сценариев - это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test noscript)), так и независимыми (Test suite)
🔷Наиболее часто выделяемыми наборами являются:
🔹Набор тестовых сценариев для Smoke-test(дымовое тестирование
🔹План приёмо-сдаточных испытаний
🖍Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.
🖍План приёмо-сдаточных испытаний (ПСИ) - документ, включающий в себя набор определенных тестовых сценариев, после положительного прохождения которого заказчик подписывает акт приемо-передачи (сдачи-приемки).
#теория
🖍Прокси-сервер (от англ. proxy — представитель, сетях, выполняющий роль посредника между пользователем и целевым сервером (при этом о посредничестве могут как знать, так и не знать обе стороны), позволяющий клиентам как выполнять косвенные запросы (принимая и передавая их через прокси-сервер) к другим сетевым службам, так и получать ответы. Работает это так, что пользователь, подключаясь к прокси-серверу передает свой запрос, который находится на другом сервере и прокси-сервер либо помогает подключиться к желаемому серверу, получая соответствующий ресурс, либо если он обладает собственным кэшем, возвращает ответ из него.
🖍VPN ( от англ. «Virtual Private Network» - виртуальная частная сеть) - это метод подключения, предоставляющий множество дополнительных преимуществ безопасности, особенно для пользователей, которые используют публичные точки доступа. При подключении к интернету без VPN трафик в свободном виде передается с компьютера на сервера провайдера, после чего отправляется дальше. В таком виде данные уязвимы для атак и вмешательств третьих лиц на промежуточной стадии. Данная технология не даёт другим сайтам собирать информацию о вас. VPN нужен для обхода блокировок. Благодаря VPN ваша личная информация будет защищена при использовании Wi-fi в общественных местах.
🖍Пинг ( от aнгл. ping) представляет собой отрезок времени, который проходит между запросом и ответом на сервер. Ping оценивается в миллисекундах.
Выбрать утилиту «Пинг хоста» и указать адрес, пинг до которого нужно посчитать
🖍Токенизация — это технология, которая позволяет обезопасить электронные платежи с помощью надежной системы шифрования данных. Расплачиваясь картой,
покупатель не передает продавцу свои платежные реквизиты. Вся карточная
информацияшифруется и превращается в т.н. токен, который выглядит как
случайная комбинация символов 123a4567@1b234c5de6789000.
🖍Прокси-сервер (от англ. proxy — представитель, сетях, выполняющий роль посредника между пользователем и целевым сервером (при этом о посредничестве могут как знать, так и не знать обе стороны), позволяющий клиентам как выполнять косвенные запросы (принимая и передавая их через прокси-сервер) к другим сетевым службам, так и получать ответы. Работает это так, что пользователь, подключаясь к прокси-серверу передает свой запрос, который находится на другом сервере и прокси-сервер либо помогает подключиться к желаемому серверу, получая соответствующий ресурс, либо если он обладает собственным кэшем, возвращает ответ из него.
🖍VPN ( от англ. «Virtual Private Network» - виртуальная частная сеть) - это метод подключения, предоставляющий множество дополнительных преимуществ безопасности, особенно для пользователей, которые используют публичные точки доступа. При подключении к интернету без VPN трафик в свободном виде передается с компьютера на сервера провайдера, после чего отправляется дальше. В таком виде данные уязвимы для атак и вмешательств третьих лиц на промежуточной стадии. Данная технология не даёт другим сайтам собирать информацию о вас. VPN нужен для обхода блокировок. Благодаря VPN ваша личная информация будет защищена при использовании Wi-fi в общественных местах.
🖍Пинг ( от aнгл. ping) представляет собой отрезок времени, который проходит между запросом и ответом на сервер. Ping оценивается в миллисекундах.
Выбрать утилиту «Пинг хоста» и указать адрес, пинг до которого нужно посчитать
🖍Токенизация — это технология, которая позволяет обезопасить электронные платежи с помощью надежной системы шифрования данных. Расплачиваясь картой,
покупатель не передает продавцу свои платежные реквизиты. Вся карточная
информацияшифруется и превращается в т.н. токен, который выглядит как
случайная комбинация символов 123a4567@1b234c5de6789000.
#требование
‼️Если применить к этой классификации популярное разделение требований на функциональные и нефункциональные, то к последним следует отнести все перечисленные выше группы кроме первой
🖍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, функцион…
Сем Канер: хороший #тестовыйсценарий
🖍Эффективный. Под эффективностью я понимаю вероятность того, что дефект, если он есть, будет обнаружен. Заметьте, что Тест 1 может быть более эффективным, чем Тест 2 для одного дефекта и менее эффективным, чем Тест 2 для другого дефекта
🖍С высокой долей вероятности даст важные результаты. Значительной является та проблема, на устранение которой вызовет протесты со стороны влиятельного заинтересованного лица (Заинтересованное лицо (ЗЛ) – человек, который заинтересован в продукте. Влиятельное ЗЛ – человек, чье мнение или предпочтения могут оказать влияние на продукт)
🖍Правдоподобный. Правдоподобный тест будет с большей долей вероятности положительно воспринят программистом или влиятельным ЗЛ. Дефект, который проявляется лишь в превышении каких-либо предельно допустимых параметров, может стать поводом для сомнений в правдоподобности теста: «Никто не станет этого делать». Тест считается правдоподобным, если некоторые (или все) ЗЛ сходятся во мнении, что он реалистичный.Описывает события, с которыми клиент будет сталкиваться чаще всего. Совокупность тестов охватывает наиболее вероятные события. Подборка тестов должна отражать реальные варианты. Наиболее популярные совокупности действий должны получить большее или более тщательное покрытие (я говорю о совокупности действий, т.к. предполагаю, что многие функции используются в сочетании друг с другом и мы можем отследить сочетания, в которых они используются, а так же порядок, в котором они применяются, и отобразить эту специфичную информацию в нашем анализе)
🖍Легкость оценки. Должен давать ответ на вопрос: программа прошла тест или нет? #Тестировщик должен суметь быстро на основе сценария ответить на этот вопрос. И данная оценка должна будет соответствовать истинному положению вещей.Чем сложнее оценка, тем больше времени на нее уходит и тем больше шансов, что что-то останется незамеченным. Оценивая программу по сложной методике, тестировщик будет искать более простые обходные пути. Эти обходные пути, как правило, не дают точного результата (т.е. пропускают очевидные #дефекты или помечают корректный код как некорректный)
🖍Полезен в поиске неполадок. Например, многоэтапные автоматизированные тесты часто приводят к сбою в тестируемой системе, не давая при этом достаточной информации о тестовых условиях, необходимых для воспроизведения проблемы. Такие тесты не подходят для поиска неполадок. Тесты, которые сложно повторить, мало используются в поиске неполадок. Тесты, которые сложно исполнить, вряд ли корректно сработают в следующий раз, когда вы будете искать дефект, выявившийся при первом прогоне теста.
🖍Информативен. Ценность теста заключается в том, чему он нас учит. Чаще тест, который программа проходит, учит нас большему, чем тест, который программа проваливает, но
информативный тест всегда чему-нибудь нас да учит (дает больше уверенности) и не важно, прошла программа тест или нет.
Например, если мы успешно исполнили тест на нескольких сборках, мы ожидаем, что программа пройдет тест и на этот раз. Еще одно прохождение многократно использованного теста программой никак не повлияет на наш образ программы.
🖍Понятие классов эквивалентности так же имеет отношение к информативности. При разработке тестовых примеров может возникнуть такая ситуация, в которой различные входные значения приводят к одним и тем же реакциям системы. Если при
этом такие входные значения имеют что-то общее, то возможно объединение таких значений в классы эквивалентности, т.е. выполнение эквивалентного разбиения множества допустимых
входных значений. При тестировании достаточно выполнить только один тестовый пример для каждого класса
эквивалентности.
#теория
🖍Эффективный. Под эффективностью я понимаю вероятность того, что дефект, если он есть, будет обнаружен. Заметьте, что Тест 1 может быть более эффективным, чем Тест 2 для одного дефекта и менее эффективным, чем Тест 2 для другого дефекта
🖍С высокой долей вероятности даст важные результаты. Значительной является та проблема, на устранение которой вызовет протесты со стороны влиятельного заинтересованного лица (Заинтересованное лицо (ЗЛ) – человек, который заинтересован в продукте. Влиятельное ЗЛ – человек, чье мнение или предпочтения могут оказать влияние на продукт)
🖍Правдоподобный. Правдоподобный тест будет с большей долей вероятности положительно воспринят программистом или влиятельным ЗЛ. Дефект, который проявляется лишь в превышении каких-либо предельно допустимых параметров, может стать поводом для сомнений в правдоподобности теста: «Никто не станет этого делать». Тест считается правдоподобным, если некоторые (или все) ЗЛ сходятся во мнении, что он реалистичный.Описывает события, с которыми клиент будет сталкиваться чаще всего. Совокупность тестов охватывает наиболее вероятные события. Подборка тестов должна отражать реальные варианты. Наиболее популярные совокупности действий должны получить большее или более тщательное покрытие (я говорю о совокупности действий, т.к. предполагаю, что многие функции используются в сочетании друг с другом и мы можем отследить сочетания, в которых они используются, а так же порядок, в котором они применяются, и отобразить эту специфичную информацию в нашем анализе)
🖍Легкость оценки. Должен давать ответ на вопрос: программа прошла тест или нет? #Тестировщик должен суметь быстро на основе сценария ответить на этот вопрос. И данная оценка должна будет соответствовать истинному положению вещей.Чем сложнее оценка, тем больше времени на нее уходит и тем больше шансов, что что-то останется незамеченным. Оценивая программу по сложной методике, тестировщик будет искать более простые обходные пути. Эти обходные пути, как правило, не дают точного результата (т.е. пропускают очевидные #дефекты или помечают корректный код как некорректный)
🖍Полезен в поиске неполадок. Например, многоэтапные автоматизированные тесты часто приводят к сбою в тестируемой системе, не давая при этом достаточной информации о тестовых условиях, необходимых для воспроизведения проблемы. Такие тесты не подходят для поиска неполадок. Тесты, которые сложно повторить, мало используются в поиске неполадок. Тесты, которые сложно исполнить, вряд ли корректно сработают в следующий раз, когда вы будете искать дефект, выявившийся при первом прогоне теста.
🖍Информативен. Ценность теста заключается в том, чему он нас учит. Чаще тест, который программа проходит, учит нас большему, чем тест, который программа проваливает, но
информативный тест всегда чему-нибудь нас да учит (дает больше уверенности) и не важно, прошла программа тест или нет.
Например, если мы успешно исполнили тест на нескольких сборках, мы ожидаем, что программа пройдет тест и на этот раз. Еще одно прохождение многократно использованного теста программой никак не повлияет на наш образ программы.
🖍Понятие классов эквивалентности так же имеет отношение к информативности. При разработке тестовых примеров может возникнуть такая ситуация, в которой различные входные значения приводят к одним и тем же реакциям системы. Если при
этом такие входные значения имеют что-то общее, то возможно объединение таких значений в классы эквивалентности, т.е. выполнение эквивалентного разбиения множества допустимых
входных значений. При тестировании достаточно выполнить только один тестовый пример для каждого класса
эквивалентности.
#теория
👍3
🖍Не является избыточно сложным. Сложный тест использует большое количество функций, переменных или других атрибутов тестируемого ПО. Сложность нежелательна в случаях, когда программа подверглась многочисленным переменам или при тестировании множества новых функций за раз. Если программа содержит много дефектов, она провалит сложный тест так быстро, что вы не успеете его толком прогнать.
Группы тестирования, которые в значительной степени полагаются на сложные тесты, жалуются на дефекты, которые блокируют дальнейшее тестирование. Такие дефекты мешают исполнению теста и не дают тестировщикам узнать что-либо о других аспектах программы, которые должны быть выявлены в ходе данных тестов. Поэтому, на начальной стадии тестирования желательно пользоваться простыми тестами. По мере же роста стабильности программы или (в экстремальном программировании или в эволюционной модели разработки) по мере добавления в программу более стабильных функций, должна увеличиваться и сложность исполняемых тестов.
Большой долей вероятности поможет тестировщику или программисту понять некоторые
аспекты программы, заказчика или среды. Иногда мы выполняем тесты для того, чтобы понять продукт, понять принцип его работы или возможные риски. Позже мытможем разработать тесты, которые выявили бы недостатки продукта, но на ранней стадии тестирования нас больше
интересует два вопроса: что это и как это тестировать.
Многие тесты, подобные этому, не будут использоваться повторно. Однако в проектах, основанных на результатах тестирования, изменения в коде программы зачастую делаются для пробы, в целях экспериментирования. При
этом ожидается, что набор (модульных) тестов предупредит программиста о побочных эффектах. В таких условиях, тест может проектироваться для извещения об изменениях в производительности, о разности в погрешности округления или других изменениях, которые не являются дефектами. Неожиданное изменение поведения программы может стать сигналом программисту о том, что модель, отображающая его код или изменения в коде, неполна или ошибочна и требует дополнительного тестирования и поиска неполадок.
Группы тестирования, которые в значительной степени полагаются на сложные тесты, жалуются на дефекты, которые блокируют дальнейшее тестирование. Такие дефекты мешают исполнению теста и не дают тестировщикам узнать что-либо о других аспектах программы, которые должны быть выявлены в ходе данных тестов. Поэтому, на начальной стадии тестирования желательно пользоваться простыми тестами. По мере же роста стабильности программы или (в экстремальном программировании или в эволюционной модели разработки) по мере добавления в программу более стабильных функций, должна увеличиваться и сложность исполняемых тестов.
Большой долей вероятности поможет тестировщику или программисту понять некоторые
аспекты программы, заказчика или среды. Иногда мы выполняем тесты для того, чтобы понять продукт, понять принцип его работы или возможные риски. Позже мытможем разработать тесты, которые выявили бы недостатки продукта, но на ранней стадии тестирования нас больше
интересует два вопроса: что это и как это тестировать.
Многие тесты, подобные этому, не будут использоваться повторно. Однако в проектах, основанных на результатах тестирования, изменения в коде программы зачастую делаются для пробы, в целях экспериментирования. При
этом ожидается, что набор (модульных) тестов предупредит программиста о побочных эффектах. В таких условиях, тест может проектироваться для извещения об изменениях в производительности, о разности в погрешности округления или других изменениях, которые не являются дефектами. Неожиданное изменение поведения программы может стать сигналом программисту о том, что модель, отображающая его код или изменения в коде, неполна или ошибочна и требует дополнительного тестирования и поиска неполадок.
#Postman — удобный HTTP-клиент для тестирования веб-сайтов. Он позволяет сформировать и отправить HTTP-запросы, чтобы протестировать API
Из Обзор способов и протоколов аутентификации в веб-приложениях :
под идентификацией понимают получение вашей учетной записи (identity) по username или email;
под аутентификацией — проверку, что вы знаете пароль от этой учетной записи,
а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.
Хорошим примером использования API может служить процесс быстрой регистрации в различных приложениях используя аккаунт любой из предложенной социальной сети, когда посредствам специального API социальной сети (например, Вконтакте, Facebook) сторонние компании получают возможность использовать специальный код и #API для предоставления Вам оперативного и упрощенного доступа к их продукту.
Из Обзор способов и протоколов аутентификации в веб-приложениях :
под идентификацией понимают получение вашей учетной записи (identity) по username или email;
под аутентификацией — проверку, что вы знаете пароль от этой учетной записи,
а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.
Хорошим примером использования API может служить процесс быстрой регистрации в различных приложениях используя аккаунт любой из предложенной социальной сети, когда посредствам специального API социальной сети (например, Вконтакте, Facebook) сторонние компании получают возможность использовать специальный код и #API для предоставления Вам оперативного и упрощенного доступа к их продукту.
Хабр
Обзор способов и протоколов аутентификации в веб-приложениях
Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь...
Media is too big
VIEW IN TELEGRAM
Внимание: здесь я использую интерфейс приложения, для того, чтобы протестировать #API.
Но есть случаи, когда не зная #UI, нужно протестировать АPI, тем самым знать токен авторизации и идентификатор клиента и это совсем другая тема. И здесь краткий обзор.
понятия:
#API (Application Programming Interface) представляет собой совокупность различных инструментов, функций, реализованных в виде интерфейса для создания новых приложений, благодаря которому одна программа будет взаимодействовать с другой.
#JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка JavaScript
JSON основан на двух структурах данных:
✨ Коллекция пар ключ/значение. В разных языках, эта концепция реализована как объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив.
✨ Упорядоченный список значений. В большинстве языков это реализовано как массив, вектор, список или последовательность
#видео
Но есть случаи, когда не зная #UI, нужно протестировать АPI, тем самым знать токен авторизации и идентификатор клиента и это совсем другая тема. И здесь краткий обзор.
понятия:
#API (Application Programming Interface) представляет собой совокупность различных инструментов, функций, реализованных в виде интерфейса для создания новых приложений, благодаря которому одна программа будет взаимодействовать с другой.
#JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка JavaScript
JSON основан на двух структурах данных:
✨ Коллекция пар ключ/значение. В разных языках, эта концепция реализована как объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив.
✨ Упорядоченный список значений. В большинстве языков это реализовано как массив, вектор, список или последовательность
#видео
Про #Postman :
Postman - помощь в тестировании REST API
Postman - Быстрый Старт для Разработки и Тестирования
Postman – ваш помощник в тестировании API
Postman - помощь в тестировании REST API
Postman - Быстрый Старт для Разработки и Тестирования
Postman – ваш помощник в тестировании API
automated-testing.info
Postman - помощь в тестировании REST API
Последних несколько лет преимущественно занимаюсь тестированием API. И хочу поделиться с вами опытом использования такого инструмента как POSTMAN. Зачем нужен POSTMAN В повседневном рутинном процессе тестирования, когда на dev енв появляется новый функционал…
#HttpStatusCode с твич документации ✨
Плюс информация https://dev.twitch.tv/docs/authentication
https://dev.twitch.tv/docs/api
Плюс информация https://dev.twitch.tv/docs/authentication
https://dev.twitch.tv/docs/api