С такими ситуациями роботу ещё далеко до человека, особенно с оценкой второго пункта, который можно более формально описать как: «выбери более безопасный вариант ДТП».
Отлично — убеждаемся, что у нашего изменённого варианта фото хеш не совпадает с тем, что был у оригинального и заливаем — фильтрация срабатывать перестаёт…
Под фильтрацией я имею ввиду фильтрацию контента, который выкладывается на фэйсбук и, соответственно, появляется на странице, или банится.
Ну тут получится сразу куча минусов — и свою коммерческую разработку в общий доступ выложить, и усложнить себе жизнь из-за поддержек старых версий и неудобности распространения новых, да и облегчить жизнь злоумышленнику, который пытается изменить фото так, чтобы оно прошло соответствующий фильтр…
Никто не мешает для мужчины сделать соответствующий коллаж из пляжной фотки и картинки с интернета с неадекватно низкими параметрами добавляемых деталей…
Интересный вектор атаки — забань все публичные фотки конкретного человека… Но и защита есть — сначала можно проверить наличие на фото контента 18+, потом уже убедиться, что такая фотка уже кем-то не выкладывалась, к примеру, пол года назад…
Упс, оказывается ниже в ветке уже есть подобные рассуждения…
На счёт изучать одну ветку знаний — один фреймворк, одну технологию и т.д. как можно лучше — вполне себе соглашусь, дело благое. Но языки программирования стоит подбирать под задачи, а не использовать тот самый «золотой молоток», который лучше всех знаешь.
1) Подключение к серверам у заказчика настроено по имени компьютера, при этом DNS-сервер по какой-то причине очень долго отвечает на каждый из запросов.
2) Маршрутизатор у заказчика не поддерживает аппаратно Multicast и не выдерживает нагрузки, если включен мультикаст-режим раздачи видео.
3) Компьютеры в сети заказчика получают адреса по DHCP, аренда IP-адреса у клиента истекает и ему выдаётся новый, настройки сохранены по связке IP-адреса и имени компьютера.
Примеры ошибок, при которой потребуются если уж не понимание всего стека, то как минимум знание основных сетевых протоколов и их особенностей:
1) При некоторой неизвестной конфигурации у одного из заказчиков подключение с клиентских компьютеров на сервер занимает очень много времени(порядка нескольких минут), в то время, как на тестовых конфигурациях такой проблемы не происходит. Задача тестировщику — воспроизвести ошибку в тестовой конфигурации.
2) При запуске одного из режимов воспроизведения видео на сервере происходит падение всей сети, в которую подключен видеосервер — перестают пинговаться компьютеры между собой, ни одно сетевое взаимодействие просто не работает. В тестовой сети подобной проблемы нет.
3) Жалоба от заказчика — иногда пользователь клиент-серверного ПО включает компьютер, подключается к серверу, а все его сохранённые настройки сбросились и имеют значение по умолчанию. После перенастройки всё может работать нормально, однако раз в несколько недель ситуация повторяется. Опять же — нужно воспроизвести проблему.
Еще чуть-чуть и мы дойдем до того, что тестер должен смотреть в код и видеть потенциальные слабые места
Я вам может быть страшную тайну открою, но кроме тестирования «чёрного ящика» — при котором, как вы и говорите, тестировщику даётся готовое ПО и он что-то в нём пытается сломать, есть ещё и тестирование «белого ящика», при котором есть возможность смотреть исходный код, и убеждаться, что все возможные сценарии и ветвления, заложенные в программу протестированы, и даже проверять конкретные вносимые правки, например перед релизом и при фиксах ранее протестированных мест…
Про задержки пакетов — для этого достаточно знать, где в девтулзах находится кнопочка троттлинг и быть немножко пользователем интернета
— нет, этого недостаточно, вы со своими примерами перешли в нагрузочное\стресс тестирование, где может вылезти ещё куча проблем, а конкретное место — работа при больших задержках пакетов — вы не проверили…
К сожалению, так же как и вы, многие разработчики(а частенько и менеджеры) и не догадываются о том, что тестирование это нечто большее, чем тыканье по кнопкам по тест-плану(который ещё кто-то должен составить)…
Вы сильно недооцениваете задачи и соответствующие требования к тестировщикам… К примеру, проверить функционал мобильного или веб приложения не понимая, как работает сеть, что такое задержки и потери пакетов и т.д. — уже не получится полностью, а потом у реальных пользователей, сидящих на 2G, а не на офисном вайфае в одной сети с сервером приложения начнутся проблемы…
И это только один из простейших примеров, если говорить про отлавливание плавающих ошибок или не дай бог о тестирование производительности — то опять же нужно понимать, как действует сеть, как действует железо, как и почему может вести себя та или иная операционная система иди даже файловая система и т.д. и т.п.
Аварийка поможет отмазаться только в случае, если ты стоишь там где запрещено, и по какой-то причине действительно не можешь уехать — двигатель завести не можешь, передачу ли воткнуть… Почему-то многие водители решают, что со включением аварийки на них ПДД в большей своей части перестаёт распространяться…
Ученые используют инфракрасную камеру для анализа теплочувствительности. Полученные данные обрабатываются, формируя тепловую карту для определенной части тела
— на сломаной руке тепловая карта будет отличаться, от здоровой, и меняться по мере выздоровления, разве нет?
Под фильтрацией я имею ввиду фильтрацию контента, который выкладывается на фэйсбук и, соответственно, появляется на странице, или банится.
Упс, оказывается ниже в ветке уже есть подобные рассуждения…
2) Маршрутизатор у заказчика не поддерживает аппаратно Multicast и не выдерживает нагрузки, если включен мультикаст-режим раздачи видео.
3) Компьютеры в сети заказчика получают адреса по DHCP, аренда IP-адреса у клиента истекает и ему выдаётся новый, настройки сохранены по связке IP-адреса и имени компьютера.
1) При некоторой неизвестной конфигурации у одного из заказчиков подключение с клиентских компьютеров на сервер занимает очень много времени(порядка нескольких минут), в то время, как на тестовых конфигурациях такой проблемы не происходит. Задача тестировщику — воспроизвести ошибку в тестовой конфигурации.
2) При запуске одного из режимов воспроизведения видео на сервере происходит падение всей сети, в которую подключен видеосервер — перестают пинговаться компьютеры между собой, ни одно сетевое взаимодействие просто не работает. В тестовой сети подобной проблемы нет.
3) Жалоба от заказчика — иногда пользователь клиент-серверного ПО включает компьютер, подключается к серверу, а все его сохранённые настройки сбросились и имеют значение по умолчанию. После перенастройки всё может работать нормально, однако раз в несколько недель ситуация повторяется. Опять же — нужно воспроизвести проблему.
— нет, этого недостаточно, вы со своими примерами перешли в нагрузочное\стресс тестирование, где может вылезти ещё куча проблем, а конкретное место — работа при больших задержках пакетов — вы не проверили…
К сожалению, так же как и вы, многие разработчики(а частенько и менеджеры) и не догадываются о том, что тестирование это нечто большее, чем тыканье по кнопкам по тест-плану(который ещё кто-то должен составить)…
И это только один из простейших примеров, если говорить про отлавливание плавающих ошибок или не дай бог о тестирование производительности — то опять же нужно понимать, как действует сеть, как действует железо, как и почему может вести себя та или иная операционная система иди даже файловая система и т.д. и т.п.