По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Мы уже рассказывали об опасности атак на системы IP-телефонии, о том, как можно использовать скомпрометированную систему и кому это может быть выгодно. В данной статье, подробно разберём один из способов атак на системы, работающие по протоколу SIP, через генерацию вредоносного пакета и последующую компрометацию учётной записи. Вы убедитесь, что провести подобную атаку - совсем не сложно. Инструменты для её осуществления не являются какой-то сверхсекретной разработкой и находятся в свободном доступе. Цель данной статьи - показать, к чему может привести недостаточное внимание, уделённое вопросам безопасности при настройке систем IP-телефонии и как просто это могут использовать злоумышленники. Внимание! Информация, представленная в данной статье, носит исключительно ознакомительный характер. Компания Мерион Нетворкс не несёт ответственности за последствия применения техник и способов, описанных в данном материале. Напоминаем, что неправомерный доступ к компьютерной информации преследуется по закону и влечет за собой уголовную ответственность. Атака, о которой мы поговорим, связана с процессом аутентификации по протоколу SIP, а именно - с получением информации из заголовков SIP пакета и её последующая обработка для извлечения учётных данных. Чтобы понять её суть и определить, какие системы уязвимы к данной атаке, нужно вспомнить как происходит SIP аутентификация. Как показано на рисунке: Клиент отправляет запрос регистрации на сервер; Сервер сообщает о необходимости зарегистрироваться и запрашивает данные для аутентификации; Клиент повторно отправляет запрос регистрации, но на этот раз со строкой Authorization, в которой указаны учётные данные; Сервер проверяет учётные данные в локальной базе и если есть совпадения – разрешает регистрацию. В стандартном процессе SIP аутентификации все запросы клиентов и ответы от сервера идут в строгой последовательности. Пользователь просто вводит учётные данные и клиент сам формирует пакеты для отправки на сервер, которые он может обработать. Если учётные данные не верны, то сервер не разрешит регистрацию и дальнейшее взаимодействие для осуществления звонков. Однако, злоумышленник, используя специальные инструменты, может сам решать какие отправлять пакеты и более того - осуществлять их формирование. Наверное, Вы догадались, что ключевым моментом процесса SIP аутентификации является отправка клиентом повторного запроса REGISTER, который также содержит учётные данные для регистрации на сервере. Как раз в этот момент, наш потенциальный злоумышленник и нанесёт свой удар. Давайте рассмотрим, что из себя представляет строка Authorization в повторном запросе REGISTER. Как видно на рисунке, заголовок Authorization включает в себя следующие поля: Authentication Scheme - метод аутентификации; Поскольку SIP многое унаследовал от протокола HTTP, то и схема аутентификации в нём основана на HTTP аутентификации, которая также называется Дайджест (Digest) аутентификация. Эта схема применяется серверами для обработки учётных данных от клиентов. При этом, часть учётных данных передаётся в виде хэш-сумм, которые сервер комбинирует с открытыми данными и вычисляет пароль для данного клиента. Это значительно повышает уровень безопасности, но как мы убедимся в дальнейшем – не помогает при некорректной настройке учётной записи. Username - имя пользователя, заданное на сервере. В нашем случае – это внутренний номер 3354; Realm - параметр, определяющий подключение к серверу телефонии; Как правило, администратор VoIP сервера сам настраивает realm и транслирует его пользователю, который хочет осуществить подключение. Например, у провайдеров облачных услуг это может быть строка вида domain.com, в сервере Asterisk, по-умолчанию значение этой строки - asterisk. Nonce Value - рандомно сгенерированная сервером, уникальная строка, при формировании ответа 401 в сторону клиента. В дальнейшем используется сервером в вычислениях после получения учетных данных от клиента, должна совпадать с тем, что пришло от сервера; Authentication URI - унифицированный идентификатор ресурса. В нашем случае, ресурсом является сервер, расположенный по адресу 123.45.67.89, обращение к нему происходит по протоколу SIP, по порту 5060. Digest Authentication Response - ответ от клиента, посчитанный на основании данных, полученных от сервера. На основании этого значения сервер в том числе сверяет пароль, который задан клиенту. Согласно RFC 2069, который описывает HTTP дайджест аутентификацию, response вычисляется следующим образом: HA1 = MD5(username:realm:password) HA2 = MD5(method:digestURI) response = MD5(HA1:nonce:HA2) Как видите, на основании MD5 хэш-сумм полей: username, realm, password (да, это пароль клиента), method, digestURI и nonce высчитывается тот самый заветный response, от которого зависит регистрация клиента на сервере, а следовательно, и возможность осуществлять им вызовы. Algorithm - алгоритм, по которому высчитывался response Догадываетесь о чём идёт речь? О том, что если злоумышленник заполучит полную строку Authorization, то он может вычислить пароль клиента, зарегистрироваться на сервере и спокойно звонить куда ему вздумается. Пространство для данной атаки достаточно обширное. Дело в том, что клиент может передавать строку авторизации в нескольких запросах – в уже известном нам REGISTER, INVITE или BYE. Атакующему не составит труда притвориться “сервером” и затребовать от клиента аутентификации. Для этого, атакующий направит в сторону клиента, созданный с помощью специальной программы вредоносный SIP пакет с ответом 401 Unauthorized, который будет содержать строку, заставляющую клиента отправить учётные данные. Данная строка должна содержать realm и nonce . Выглядит эта строка следующим образом: Таким образом, атака может выглядеть следующим образом: С точки зрения атакуемого, это будет выглядеть как простой звонок, на другой стороне трубки которого будет тишина. Он даже не будет подозревать о том, что его учётные данные вот-вот утекут к злоумышленнику. Атакующий в нужный момент разорвёт соединение, отправив BYE и затем сформированный вредоносный пакет. Нагляднее всего приводить в пример прямое взаимодействие между клиентами. Такой сценарий становится, когда есть возможность отправлять SIP запросы напрямую до оконечного клиента. Например, когда телефон выставлен в открытую сеть по SIP порту. Помимо этого, уязвимости подвержены сервера, разрешающие прямое взаимодействия между оконечными клиентами. Лучше всего, пропускать все запросы через Proxy-сервер. Итак, данной атаке могут быть подвержены: IP-телефоны с открытыми в интернет SIP-портами; IP-телефоны, отвечающие на запросы INVITE от неизвестных серверов; IP-АТС, разрешающие запросы INVITE напрямую до клиентов.; Заполучив полную строку Authorization атакующий может в оффлайн режиме подобрать пароль к учётной записи. Для этого ему нужно подать на вход специального скрипта, который перебирает хэш-суммы по словарям, перехваченные данные: username, realm, method, digestURI, nonce и наконец - response. На выходе он получит пароль от учётной записи. Если пароль слабый или, ещё хуже, совпадает с username, то время перебора не превысит 1 секунды. Чтобы этого не случилось, даже если злоумышленник перехватит необходимую информацию, используйте стойкие пароли к учётным записям, да и вообще везде, где только можно. В этом Вам может помочь наш генератор паролей.
img
Первая часть статьи доступна по ссылке: Базовая настройка коммутатора Cisco - часть 1 Защита доступа в пользовательском режиме с помощью локальных имен пользователей и паролей Коммутаторы Cisco поддерживают два других метода безопасного входа, которые используют пары имя пользователя / пароль вместо общего пароля без ввода имени пользователя. Первый метод, использует ввод локального имени пользователя и пароля. Происходит настройка пары имя пользователя / пароль локально-то есть в конфигурации коммутатора. Коммутаторы поддерживают режим локального имени пользователя / пароля для входа по консоли, по Telnet и даже по SSH, но не изменяют пароль от привилегированного режима (enable), используемый для входа в режим enable. Настройки для перехода от использования простых общих паролей к использованию локальных имен пользователей/паролей требует лишь небольших изменений конфигурации, как показано на рис.3. На рисунке показаны два ПК, пытающиеся получить доступ к пользовательскому режиму. Один из ПК подключен по консольному кабелю в пользовательский режим через линию console 0, а другой ПК по Telnet, соединяющийся через терминальные линии vty 0 15. Оба ПК не имеют паролей для входа, и задано имя пользователя для обоих ПК - " local." На рисунке в Пользовательском режиме используется две команды: 1- username ulanbaby secret box 2- username landy secret box Глядя на настройки на рисунке, видно, во-первых, коммутатору, необходимо задать пару имя пользователя/пароль. Для их создания, в режиме глобальной конфигурации, введите команду создания имени пользователя и зашифрованного пароля -username <имя пользователя> secret <пароль>. Затем, чтобы включить тип безопасности входа с проверкой логина (имени пользователя ) по консоли или Telnet, просто добавьте команду login local. По сути, эта команда означает " использовать локальный список имен пользователей для входа в систему." Вы также можете использовать команду no password, чтобы очистить все оставшиеся команды паролей из консоли или режима vty, потому что эти команды не нужны при использовании локальных имен пользователей и паролей. Ниже подробно описаны шаги для настройки доступа к к коммутатору с использованием логина и пароля: Шаг 1. В режиме глобальной конфигурации используйте команду username <имя пользователя > secret <пароль>, чтобы создать одну или несколько пар имя пользователя/пароль в локальной базе коммутатора. Шаг 2. Настройте консоль на использование пар имя пользователя / пароль из локальной базы коммутатора: используйте команду line con 0 для входа в режим конфигурации консоли. используйте подкоманду login local, чтобы разрешить коммутатору запрашивать имя пользователя и пароль, совпадающие со списком локальных имен пользователей/паролей. (необязательно) используйте подкоманду no password для удаления всех существующих простых общих паролей, просто для оптимизации конфигурации. Шаг 3. Настройте Telnet (vty) для использования пар имя пользователя / пароль из локальной базы коммутатора: 1. используйте команду line vty 0 15 для входа в режим конфигурации vty для всех 16 терминальных линий vty (пронумерованных от 0 до 15). 2. используйте подкоманду login local, чтобы разрешить коммутатору запрашивать имя пользователя и пароль для всех входящих пользователей Telnet, со списком локальных имен пользователей/паролей. 3. (необязательно) используйте подкоманду no password для удаления всех существующих простых общих паролей, просто для оптимизации конфигурации. При попытке подключиться по Telnet к коммутатору, настроенному как показано на рисунке, пользователю будет предложено сначала ввести имя пользователя, а затем пароль, как показано в Примере 4. Пара имя пользователя / пароль должна быть в локальной базе коммутатора.В противном случае вход в систему будет отклонен. В примере 4 коммутаторы Cisco не отображает символы при вводе пароля по соображениям безопасности. Защита доступа в пользовательском режиме с помощью внешних серверов аутентификации В конце примера 4 показано одно из многочисленных улучшений безопасности, когда требуется, чтобы каждый пользователь входил под своим собственным именем пользователя. Также в конце примера показано, как пользователь входит в режим конфигурации (configure terminal), а затем сразу же покидает его (end). Обратите внимание, что при выходе пользователя из режима конфигурации коммутатор генерирует сообщение журнала (log). Если пользователь вошел в систему с именем пользователя, сообщение журнала (log) идентифицирует это имя пользователя; В примере сгенерировано сообщение журнала по имени "ulanbaby". Однако использование имени пользователя / пароля, настроенного непосредственно на коммутаторе, не всегда удобно при администрировании. Например, каждому коммутатору и маршрутизатору требуется настройка для всех пользователей, которым может потребоваться войти на устройства. Затем, когда возникнет необходимость внесения изменений в настройки, например, изменение паролей для усиления безопасности, настройки всех устройств должны быть изменены. Лучшим вариантом было бы использовать инструменты, подобные тем, которые используются для многих других функций входа в ИТ. Эти инструменты обеспечивают центральное место для безопасного хранения всех пар имя пользователя / пароль, с инструментами, чтобы заставить пользователей регулярно менять свои пароли, инструменты, чтобы отключать пользователей, когда они завершают сеанс работы, и так далее. Коммутаторы Cisco позволяют именно этот вариант, используя внешний сервер, называемый сервером аутентификации, авторизации и учета (authentication, authorization, and accounting)(AAA). Эти серверы содержат имена пользователей / пароли. Сегодня многие существующие сети используют AAA-серверы для входа на коммутаторы и маршрутизаторы. Да для настройки данного входа по паре имя пользователя / пароль необходимо произвести дополнительные настройки коммутатора. При использовании AAA-сервера для аутентификации коммутатор (или маршрутизатор) просто отправляет сообщение на AAA-сервер, спрашивая, разрешены ли имя пользователя и пароль, и AAA-сервер отвечает. На рисунке показано, что пользователь сначала вводит имя пользователя / пароль, коммутатор запрашивает AAA-сервер, а сервер отвечает коммутатору, заявляя, что имя пользователя/пароль действительны. На рисунке процесс начинается с того, что ПК " А " отправляет регистрационную информацию через Telnet или SSH на коммутатор SW1. Коммутатор передает полученную информацию на сервер "AAA" через RADIUS или TACACS+. Сервер отправляет подтверждение коммутатору, который, в свою очередь, отправляет приглашение (разрешение) на ввод команды в пользовательскую систему. Хотя на рисунке показана общая идея, обратите внимание, что информация поступает с помощью нескольких различных протоколов. Слева, соединение между Пользователем и коммутатором или маршрутизатором использует Telnet или SSH. Справа коммутатор и AAA-сервер обычно используют протокол RADIUS или TACACS+, оба из которых шифруют пароли, при передаче данных по сети. Настройка защищенного удаленного доступа по SSHl До сих пор мы рассматривали доступ к коммутатору по консоли и Telnet, в основном игнорируя SSH. У Telnet есть один серьезный недостаток: все данные в сеансе Telnet передаются в открытом виде, включая обмен паролями. Таким образом, любой, кто может перехватывать сообщения между Пользователем и коммутатором (man-in-the-middle attack), может видеть пароли. SSH шифрует все данные, передаваемые между SSH-клиентом и сервером, защищая данные и пароли. SSH может использовать тот же метод аутентификации локального входа, что и Telnet, с настроенными именем пользователя и паролем в локальной базе коммутатора. (SSH не работает с методами аутентификации, которые не используют имя пользователя, например только общие пароли.) Итак, в настройке доступа для локальных пользователей по Telnet, как показано ранее на рисунке, также включена локальная аутентификация по имени пользователя для входящих соединений SSH. На рисунке показан один пример настройки того, что требуется для поддержки SSH. Рисунок повторяет конфигурацию создания локального пользователя, (см. рисунок) для подключения по Telnet. На скриншоте показаны три дополнительные команды, необходимые для завершения настройки SSH на коммутаторе. На рисунке показаны три дополнительные команды, необходимые для завершения настройки SSH на коммутаторе. На рисунке показан листинг настройки SSH. Для настройки SSH на рисунке, отображаются команды: hostname sw-1 (задает имя коммутатору) ip domain-name testing.com (команда использует полное доменное имя sw-1.testing.com) crypto key generate rsa. Для локальной конфигурации имени пользователя (например, Telnet) отображаются следующие команд: username ulanbaby secret box username landy secret man line vty 0 15 login local IOS использует три команды: две для конфигурации SSH, а также одну команду для создания ключей шифрования SSH. Сервер SSH использует полное доменное имя коммутатора в качестве входных данных для создания этого ключа. Коммутатор создает полное доменное имя из имени хоста и доменного имени коммутатора. Рисунок 5 начинается с установки обоих значений (на тот случай, если они еще не настроены). Затем третья команда, команда crypto key generate rsa, генерирует ключи шифрования SSH. IOS по умолчанию использует SSH-сервер. Кроме того, IOS по умолчанию разрешает SSH-соединения по vty. Просмотр настроек в режиме конфигурации, шаг за шагом, может быть особенно полезен при настройке SSH. Обратите внимание, в частности, что в этом примере команда crypto key запрашивает у пользователя модуль ключа; вы также можете добавить параметр modulus modulus-value в конец команды crypto key, чтобы добавить этот параметр в команду. В примере 5 показан порядок настройки ssh ( такие же команды, что и на рис. 5) Ключ шифрования является последним шагом. Ранее упоминалось, что одним полезным значением по умолчанию было то, что коммутатор по умолчанию поддерживает как SSH, так и Telnet на линиях vty. Однако, поскольку Telnet не безопасный протокол передачи данных, то вы можете отключить Telnet, чтобы обеспечить более жесткую политику безопасности. Для управления тем, какие протоколы коммутатор поддерживает на своих линиях vty, используйте подкоманду transport input {all | none / telnet / ssh} vty в режиме vty со следующими опциями: transport input all or transport input telnet ssh поддержка как Telnet, так и SSH transport input none: не поддерживается ни один протокол transport input telnet: поддержка только Telnet transport input ssh: поддержка только SSH В завершении этой части статьи о SSH, расписана пошаговая инструкция настройки коммутатора Cisco для поддержки SSH с использованием локальных имен пользователей. (Поддержка SSH в IOS может быть настроена несколькими способами; эта пошаговая инструкция показывает один простой способ ее настройки.) Процесс, показанный здесь, заканчивается инструкцией настройки локального имени пользователя на линиях vty, как было обсуждено ранее в первой части данной серии статей. Шаг 1. Настройте коммутатор так, чтобы он генерировал совпадающую пару открытых и закрытых ключей для шифрования: если еще не настроено, задайте командой hostnamename имя для этого коммутатора в режиме глобальной конфигурации. Если еще не настроено, задайте командой ip domain-namename доменное имя для коммутатора в режиме глобальной конфигурации. Используйте команду crypto key generate rsa в режиме глобальной конфигурации (или команду crypto key generate RSA modulus modulus-value, чтобы избежать запроса модуля ключа) для генерации ключей. (Используйте по крайней мере 768-битный ключ для поддержки SSH версии 2.) Шаг 2. (Необязательно) используйте команду ip ssh version 2 в режиме глобальной конфигурации, чтобы переопределить значение по умолчанию для поддержки обеих версий протокола удаленного доступа SSH 1 и 2, так что бы разрешены были только соединения SSHv2. Шаг 3. (Необязательно) если вы еще не настроили нужный параметр, задайте на линии vty для работы по SSH и Telnet.: используйте команду transport input ssh в режиме конфигурации линий vty, чтобы разрешить только SSH. используйте команду transport input all (по умолчанию) или команду transport input telnet ssh в режиме конфигурации линий vty, чтобы разрешить как SSH, так и Telnet. Шаг 4. Используйте различные команды в режиме конфигурации линий vty для настройки локальной аутентификации имени пользователя, как описано ранее в этой статье. На маршрутизаторах Cisco часто по умолчанию настроен параметр transport input none. Поэтому необходимо добавить подкоманду transport input line для включения Telnet и / или SSH в маршрутизаторе. Для просмотра информации о состояния SSH на коммутаторе используются две команды. Во-первых, команда show ip ssh выводит информацию о состоянии самого SSH-сервера. Затем команда show ssh выводит информацию о каждом клиенте SSH, подключенном в данный момент к коммутатору. В пример 6 показаны примеры работы каждой из команд, причем пользователь ULANBABY в данный момент подключен к коммутатору.
img
Техническое собеседование – это один из важнейших этапов в процессе поиска работы. Это не просто шанс продемонстрировать, насколько ваши навыки и опыт соответствуют должности, на которую вы претендуете, но и возможность узнать больше о вашем потенциальном работодателе и команде, с которой вы будете работать. В процессе технического собеседования на должность специалиста по обеспечению качества (QA-специалиста) вам могут задавать вопросы, связанные с разработкой программного обеспечения, чтобы проверить ваши знания. Вопросы, связанные с тестированием программного обеспечения, различными инструментами, которые используются для контроля качества, и тем, как выявлять проблемы в жизненном цикле разработки - все это может быть. Для того, чтобы помочь вам подготовиться, ниже представлен список из 15 наиболее распространенных вопросов, которые задают на собеседовании на должность QA-специалиста, а также советы о том, как на них лучше отвечать. 1. QA – это то же самое, что и тестирование программного обеспечение? Ваш ответ на вопрос такого типа должен включать тот факт, что QA больше фокусируется на анализе процесса разработки программного обеспечения, в то время как тестирование программного обеспечения больше связано с изучением того, как функционируют отдельные элементы приложения. 2. Объясните разницу между терминами «сборка» и «релиз». В контексте тестирования качества эти два термина, как правило, относятся к числам, которые используются для обозначения программного обеспечения. Номер сборки предоставляется группой разработчиков группе тестировщиков для маркировки программного обеспечения. Номер релиза предоставляется заказчику либо командой разработчиков, либо командой тестировщиков. 3. Что означает термин «тестовое обеспечение» или testware? Этот термин используется многими отделами тестирования программного обеспечения, поэтому таких вопросов стоит ожидать. Ваш ответ должен содержать тот факт, что тестовое обеспечение – это артефакты, которые люди используют для создания и запуска тестов, такие как тестовые случаи, планы тестирования и тестовые данные. 4. Что означают термины «утечка багов» (bug leakage) и «релиз багов» (bug release)? Релиз багов – это преднамеренное действие, а утечка багов – случайное. Релиз багов подразумевает, что при отправке приложения команде тестировщиков разработчики знали, что оно содержит ошибки. Но они могут быть не критичными, поэтому можно проводить релиз. Утечка багов подразумевает, что группа тестировщиков не выявила ошибку, и конечный пользователь получает приложение с ошибкой. 5. Что означает «тестирование на основе данных»? Это не самый простой вопрос, так как тестирование на основе данных в контексте контроля качества означает нечто иное. Тестирование на основе данных относится к среде автоматического тестирования, которая проверяет результаты на основе различных входных значений. Эти значения считываются непосредственно из файлов с данными – Excel, файлов CSV, баз данных и других. 6. Что входит в стратегию тестирования? Правильный ответ на данный вопрос продемонстрирует ваше знание концепций высокоуровневого тестирования. При ответе на этот вопрос убедитесь, что вы не забыли упомянуть, что стратегия тестирования включает в себя формирования обзора, составление набора ресурсов, определение области применения и составление графика вашего тестирования и задействованных инструментов. 7. Какие существуют типы тестирования программного обеспечения? При ответе на этот вопрос вы можете упомянуть несколько из следующих классов тестирований, чтобы продемонстрировать, что вы всесторонне понимаете, что такое тестирование программного обеспечение: Интеграционное тестирование. Понимание того, как различные компоненты приложения работают вместе. Регрессионное тестирование. Оценка того, как новые функции влияют на функциональность приложения. Функциональное тестирование. Использование реальных сценариев для того, чтобы проверить, насколько хорошо приложение выполняет то, для чего оно предназначено. Стресс-тестирование. Цель стресс-теста – выяснить, сколько может выдержать приложение, прежде чем сломается, независимо от того, реалистичен сценарий или нет. Тестирование производительности. То же, что и стресс-тест, но отличие в том, что мы пытаемся выяснить, с чем приложение может справиться в реальной ситуации. Юнит-тестирование. Тестирование наименьшей единицы приложения, которую вы можете протестировать. Тестирование белого ящик.а Изучение того, как функционируют внутренние структуры приложения. Тестирование черного ящика. Тестирование без изучения внутренних функций приложения. Smoke-тестирование. Набор предварительных тестов для оценки базовой функциональности, часто проводится перед выпуском или более всесторонним тестированием. 8. Что включают в себя термины «тестирование ветвей» (branch testing) и «граничные испытания» (boundary testing)? Хоть тестирование ветвей и граничные испытания могут показаться чем-то одинаковым, они все же затрагивают разные аспекты тестирования приложений. При тестировании ветвей вы тестируете разные ветви кода. А граничные испытания подразумевают тестирование предельных условий приложения. 9. Что входит в формирование тестовых случаев (тест-кейсов) и планов тестирований? Это важная тема, на которой следует сосредоточится при подготовке к собеседованию на должность QA-специалиста, поскольку то, как вы понимаете эту тему, показывает, насколько вы понимаете принципы, лежащие в основе этой работы. В своем ответе вы должны упомянуть следующее: Цели Сфера применения Контекст Тестирование фрейма Причины проведения тестирования Факторы риска Ожидаемые результаты Критерии для начала/завершения 10. Что подразумевается под Agile-тестированием? Agile – один из недавних терминов, которые стали использовать разработчики по всему миру. Agile-тестирование – это тестирование, в котором используются методологии Agile. Одно из главных отличий – вы не ждете, пока ваша команда разработчиков закончит писать код. Здесь процессы написания программного кода и тестирования проходят одновременно, что предполагает, что тестировщики должны взаимодействовать с несколькими разными членами команды и клиентами. 11. Что означает термин «тест-кейс»? Тест-кейс – это один из основных строительных блоков процесса обеспечения качества. Это касается шагов, сред применения, результатов и предварительных условий, связанных со средой тестирования. 12. Что означает термин «аудит качества»? Аудит качества – это систематическая оценка эффективности системы контроля качества. Иными словами, аудит качества – это проверка того, насколько хорошо качество поддерживается на протяжении всего процесса разработки. 13. Какие инструменты обычно используют тестировщики? Инструменты, которые использует тестировщик для своей работы, могут различаться в зависимости от типа проекта, над которым он работает. Но вот некоторые инструменты, которые вы можете упомянуть в своем ответе: Firebug, OpenSGTA, панель инструментов веб-разработчика для Firefox, Selenium, Postman, WinSCP и YSlow для Firebug. 14. Что такое сценарий использования (use case)? Сценарий использования или юзкейс – это еще один центральный элемент процесса контроля качества, поэтому важно быть готовым к ответу на этот вопрос. Сценарий использования – это документ, в котором описываются действия, которые должен предпринять пользователь, и реакции системы. Он используется для изучения того, как работает конкретный элемент приложения. 15. Что означает термин «свободное тестирование»? Свободное тестирование – это популярный метод тестирования, который используют многие команды контроля качества, даже несмотря на то, что они используют его не всегда. При таком методе тестировщик пытается сломать систему, случайным образом выполняя различные функции.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59