А это генерация эмоджи на https://clck.ru/YcANk 👇

Запрос: милый улыбающийся жук с яблоком

ну не знаю...

​​⚛️ Баг The Brain🤯

В конце 80-х и в 90-е зарождались многие термины и процессы тестирования и качества ПО.
В тоже время появлялись и новые баги.
Некоторым были присвоены имена.


Баг на картинке к посту назывался The Brain.
Считается первым вирусом для MS-DOS.
Он перезаписывал загрузочный сектор и замедлял компьютер до невозможности. Создатели этого бага — два пакистанских программиста.

Заражение компьютера происходило путём записи копии вируса в загрузочный сектор дискеты.
Старая информация переносилась в другой сектор и помечалась как «повреждённая». Метка тома изменялась на «©Brain», а в загрузочном секторе отображался текст, который видно на картинке.

Вирус замедлял работу дискеты и делал 7 килобайт памяти недоступными для DOS. Brain был написан пакистанцами Базитом и Амжадом Фарук Альви, жившими в то время в Лахоре.

Brain «не умел» работать с разделами жёстких дисков, поэтому в него была встроена проверка, не позволявшая ему заражать жёсткий диск. Это отличает его от многих вирусов того времени, которые не обращали внимание на разделы, что приводило к уничтожению данных. Благодаря относительной «миролюбивости» вирус часто оставался незамеченным, особенно, когда пользователь не обращал внимание на замедление работы дискет.
Вирус также содержал сообщение с адресом, контактными телефонами создателей и предупреждением о заражении.

Произошло это в 1986 году. Именно тогда стала очевидной возможность существования вирусов, уязвимостей и прочих вещей, которые сейчас кажутся данностью.

Вирус The Brain попал в десятки стран и заразил тысячи компьютеров. Он был доказательством того, что софт мог быть написан злоумышленниками и быть вредоносным. 

Это было одним из шагов к тому, чтобы задуматься над тестированием ПО.

#дляинформации

Отпустило так отпустило

⚛️Метрики тестирования

Если вы прямо сейчас думаете, какие метрики внедрить у себя на проекте, то вам будет особенно полезен данный пост🔥

Для остальных: читаем, вспоминаем, какие метрики есть - когда-то они и вам тоже понадобятся 😄

Итак, несколько наиболее полезных, на мой взгляд, метрик по тестированию:


1️⃣Тестовое покрытие требования
🐞
Общее количество тестов/ Общее количество требований
🐞

Назначение метрики: определить, все ли требования покрыты тестами.

Актуально, когда требования разбиты на атомарные.
Или внутри требование разбито на подпункты, по которым удобно рассчитать примерное количество тезисов/атомарных требований.
--------------------------

2️⃣Плотность дефектов
🐞
Количество дефектов в отдельном модуле/Общее количество дефектов в ПО
🐞

Насчитываем долю дефектов, приходящихся на модуль в течение итерации или релиза.

Назначение метрики: подсветить, в каком модуле больше всего проблем. В дальнейшем, информацию можно использовать при планировании работ и анализе рисков.
--------------------------

3️⃣Коэффициент регрессии
🐞
Количество дефектов в старом функционале/ Общее количество дефектов(вместе с новым функционалом)
🐞

Назначение метрики: показать, на что уходят усилия команды: занимаемся ли мы больше созданием и отладкой новых фич или основную часть времени вынуждены латать уже существующие части ПО.
--------------------------

4️⃣Коэффициент повторно открытых дефектов
🐞
Количество повторно обнаруженных дефектов/Общее количество ошибок, включая ранее исправленные и новые
🐞

Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля.
--------------------------

5️⃣Эффективность тестов и тестовых наборов
🐞
Количество обнаруженных ошибок/Количество кейсов в тестовом наборе
🐞

Назначение метрики: показать как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.
--------------------------

6️⃣Коэффициент ошибок, пропущенных на продуктовый стенд
🐞
Количество ошибок, обнаруженных после выпуска релиза/Общее количество ошибок, обнаруженных до и после релиза
🐞

Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок - какая доля дефектов была отфильтрована, а какая прошла на продуктовый стенд.
--------------------------

7️⃣Доля неподтвержденных (отклоненных) дефектов
🐞
Число дефектов, непринятых к исправлению/Общее количество зарегестрированных дефектов
🐞

Назначение метрики: показать сколько дефектов было заведено «вхолостую».

Источник: https://clck.ru/Ez9wo

#метрики_тестирования

⚛️Вакансия мечты 😅
Вакансию на популярном портале можно изучить тут https://clck.ru/sYkCy

#изжизни #вашипосты

фото к посту выше👇

⚛️Возможно вы уже знаете тягу автора канала к ИИ, нейросетям и киберпанку.
Ловите залипательное видео от нейросети:
https://clck.ru/sc3zW

#новости_технологий #изжизни

Китайская ирония в сфере технологичных вещей, облегчающих жизнь👇

Целая подборка гениальных человечных изобретений от китайского гения. Туфли-капканы, регулирующие высоту каблуки и унитаз-качели — все для народа!

⚛️Полезная шпаргалка.
Коды ответов для REST-запроса или любого HTTP-запроса.

🏓Ответы 100
Ответы уровня 100 означают, что запрос должен продолжаться. Наиболее частый тип такого ответа – это просто 100 Continue. Это может использоваться при объемных запросах, давая серверу возможность остановить большой запрос до того, как будет передан слишком большой объем данных. Возможно, при тестировании вашего API вы с этим не столкнетесь – сервер продолжит отвечать, завершит этот процесс "за кулисами" и выдаст ответ-200.

🏓Ответы 200
Ответы уровня 200 обозначают успех запроса. Наиболее распространенный ответ – это 200 OK, который просто означает, что все прошло как ожидалось. Вот другие примеры запросов этого уровня:

201 Created – такой ответ означает, что в результате запроса создан некий новый ресурс. К примеру, GET-запрос может создать запись в логе, демонстрирующую дату, время и содержание запроса.

202 Accepted – этот ответ значит, что запрос был принят, но еще не завершен. Например, это изменение базы данных, которое нуждается в одобрении перед тем, как повлиять на базу непосредственно.

204 No Content – это значит, что запрос был успешно обработан, и не вернул никаких данных. Этот ответ может прийти на PUT-запрос, когда содержание изменилось, но разработчик не видел необходимости отдавать в ответе какие-то данные. Ответ 200 OK тоже может не возвращать данные, если так решил разработчик, но 204 не возвращает их никогда.

🏓Ответы 300
Ответы уровня 300 говорят о перемещении ресурса. Наиболее частый из таких ответов – это 301 Moved Permanently. Этот ответ должен включать новый URL в заголовке, чтобы клиент понимал, куда в следующий раз обращаться с запросом.

🏓Ответы 400
Ответы уровня 400 обозначают, что с запросом было что-то не так. Наиболее частый из них – 400 Bad Request, обычно применяемый, когда запрос неверно сформулирован или по какой-то причине неправилен. К примеру, в нем отсутствуют необходимые данные, или произошла ошибка валидации этих данных. Другие распространенные варианты ответов-400:

401 Unauthorized – обычно отдается, если у клиента нет соответствующей аутентификации для запроса, к примеру, токена JWT или куки.

403 Forbidden – отдается, если у клиента есть аутентификация, но нет прав на просмотр ресурса. К примеру, пользователь залогинен и может запрашивать свои данные, но не может запрашивать чужие.

404 Not Found – возвращается, если клиент запрашивает специфический ресурс, а сервер не может его найти. Например, запрашивается пользователь с ID 100, отсутствующий в базе данных.

409 Conflict – отдается, если запрос заставляет данные конфликтовать друг с другом. К примеру, клиент пытается осуществить POST-запрос для создания ресурса с ID, который уже используется.

🏓Ответы 500
Ответы уровня 500 значат, что что-то пошло не так на серверной стороне. Чаще всего встречается ответ 500 Internal Server Error, использующийся для обозначения разнообразных проблем. Например, запрос пытался добавить запись в базу данных, которая не может обработать такую запись, потому что в ней слишком много символов, или у записи неверный тип. Другие ответы уровня 500 могут быть такими:

502 Bad Gateway – происходит, если сервер, отвечающий на запрос, должен сделать запрос к другому серверу, а другой сервер возвращает невалидный ответ.

503 Service Unavailable – такой ответ возвращается, если отвечающий сервер по какой-то причине недоступен. Он обычно более полезен, нежели общий ответ 500, потому что сигнализирует, что проблема с доступностью сервера, а не с базой.

Пускай это будет здесь, потому что поиск полезного материалла порой занимает много времени, а данная информация очень часто бывает нужна.
Особенно тем, кто начинает работу с тестированием API.

Источник: https://inlnk.ru/oeMzZK

#коды_ответов #api #http

⚛️Слезы единорога

Представьте, что для вас в системе есть черный ящик(прямо совсем черный - вы вообще не понимаете как он работает и как выглядит). Но знаете, что ваша знакомая часть ПО с ним как-то взаимодействует.

И вот, вы задаете вопрос из ряда «расскажите, что там произошло в черном ящике» знающим коллегам?

Вам отвечают на этот очень волнующий вопрос, но ответ настолько ВНЕ вашего контекста, что вы большую часть из него просто не понимаете.

Можно офигеть в конец, и начать рвать бумажки. Потому что лучше понять вы сейчас не сможете.

И тогда предлагаю просто представлять прекрасного плачущего единорога))
Такое существо долго плакать не может - даже в воображении. И его всегда хочется утешить.
Этим и займитесь))

P.S. Пошла утешать своего единорога..🙃

#it_йога #изжизни