пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вполне вероятно, что, даже если вы проработали в сфере разработки программного обеспечения в качестве тестировщика ПО более 10 лет, вы все равно успели наделать немало ошибок. Совершать ошибки – это неплохо. Как правило, люди учатся именно на своих ошибках – совершенствуют свои методы работы и навыки. Особенно это касается тестировщиков программного обеспечения, которые только начали свой путь в этой области. Они совершают более простые ошибки, но, как я уже говорил, ошибки могут пойти во благо.
В этой статье я поделюсь с вами тремя самыми большими ошибками, которые допускают при тестировании программного обеспечения. Причем эти ошибки люди совершают независимо от опыта работы тестировщиком. Эта статья предназначена для того, чтобы уберечь вас от этих ошибок. Итак, давайте приступим!
Ошибка при тестировании ПО №1: не задаете вопросы
Я считаю, что одна из САМЫХ больших ошибок заключается в том, что тестировщики ПО не задают достаточное количество вопросов (или не задают их вовсе) на этапе разработки продукта. Мы все понимаем, что чем позднее мы обнаруживаем ошибку или проблему, тем дороже/сложнее обходится ее исправление. Именно поэтому тестировщики ПО должны как можно раньше вовлекаться в жизненный цикл разработки ПО.
Если мы говорим о самом хорошем раскладе, то тестировщики должны вовлекаться уже на этапах исследования продукта, объединяться с руководителями по программному продукту, проектировщиками и конструкторами взаимодействия, которые работают над новыми системами и функциями, чтобы иметь возможность задавать вопросы о способности к тестированию, удобстве использования и потенциальных технических проблемах, которые они уже могли заметить. Под техническими проблемами я имею в виду, скорее, нефункциональные проблемы, с которыми может столкнуться приложение. Например, проблемы с производительностью, вопросы безопасности, проблемы обеспечения доступности, и это лишь некоторые из них.
Как мне кажется, тестировщик ПО должен тесно сотрудничать с руководителем по программному продукту на всех этапах исследования, а также с командой разработчиков на этапе реализации и тестирования. Тестировщик ПО должен быть частью команды разработчиков, должен присутствовать на их ежедневных докладах, совещаниях по доработке, планированию и анализу, чтобы всегда иметь возможность задать необходимые вопросы.
Вот так выглядят стандартные вопросы, которые тестировщик ПО обязан задать:
Знаем ли мы, для кого создается новая функция?
Известны ли нам какие-то технические ограничения со стороны пользователя, например, ограничения, касающиеся устройства, Интернет-соединения пользователей и т.д.?
Как мы можем протестировать эту функцию на наших промежуточных системах?
Есть ли у нас какой-то регламент, который необходимо соблюдать?
Есть ли какие-то вопросы потенциальной защиты данных, которые необходимо обсудить?
Этот список – это лишь часть вопросов, которые нужно задать. Список вопросов зависит от продукта, который вы разрабатываете и тестируете, и в зависимости от специфики вашего продукта, он может выглядеть совершенно по-разному.
Помимо всего прочего, здесь большую роль играет опыт тестировщика ПО. Опытный тестировщик задает совершенно иные вопросы, так как имеет довольно большой багаж знаний о технологиях, который он приобрел за годы своей работы. Зато новички могут задавать «более простые» вопросы на свежую голову, так как они не знают историю продукта. И то, и другое может быть полезным.
Ошибка при тестировании ПО №2: попытка автоматизировать абсолютно все
Вторая ошибка – это склонность к автоматизации абсолютно всего. В последнее время я довольно часто наблюдал такую ошибку во многих командах и организациях. Как правило, такая философия присуща людям, которые не понимают, для чего на самом деле нужна автоматизация и что от нее требуется.
Прежде чем приступить к автоматизации, команда должна обсудить все компоненты архитектуры ПО. Некоторые части приложения могут все еще находиться в стадии интенсивной разработки и быть неготовыми для того, чтобы их тестировали автоматически. В то же время в приложении могут быть части, которые имеют критически важное значения для продукта, и здесь следует уделить куда как больше внимания автоматизации и тестированию качества. А могут быть программные продукта, жизненный цикл которых ограничен, например, маркетинговые целевые страницы или специальные страницы событий, доступ к которым прекращается через несколько дней или недель. В таком случае автоматизация будет абсолютно бесполезной и лишь потратит ваше время.
В связи с этим, первый шаг перед написанием автоматического тестирования – оценка риска продукта и формулировка правильных вопросов.
Как только команда определит, какие части можно протестировать автоматически, она должна снова обсудить, на каком уровне необходимо реализовывать автоматические тестирования. В этой ситуации вам может помочь пирамида тест-автоматизации.
Если вы грамотно выполните автоматизацию, то поможете команде смело вносить изменения в код и быстрее отправлять его в производство.
Ошибка при тестировании ПО №3: повторное использование одних и тех же тестовых данных
Третья ошибка – повторное использование одних и тех же тестовых данных. Я раньше сталкивался с такой ошибкой и сам совершал ее в первые года работы тестировщиком ПО. Я снова и снова использовал одни и те же тестовые данные в цикле тестирования. Тогда я на собственном горьком опыте понял, что это была плохая идея.
Программные продукты слепо доверяют данным. Эти данные могут вводить пользователи. Это может быть текст, изображение, речь или данные, передаваемые в определенном формате между системами. Кроме того, в качестве тестовых данных могут быть выбраны конкретные состояния или конфигурации тестируемой системы.
После того, как вы воспользовались тестовыми данными в тестовом цикле, они измени свое состояние. Вполне вероятно, что пользователь ввел уже другие данные, изменилось состояние или конфигурация системы. Когда кто-то в следующий раз попробует выполнить тестирование с теми же данными, он не сможет гарантировать, что система ведет себя как положено, так как она доверяет тестовым данным, которые уже использовались. А это может серьезно повлиять на результаты тестирования и на продукт, который вы выпускаете.
Для того, чтобы протестировать приложение, команда разработчиков ПО должна определить данные, которые будет обрабатывать ПО. Следующим этапом команда должна сгенерировать тестовые данные для цикла разработки и тестирования для того, чтобы проверить, работает ли продукт так, как предполагалось. Генерация тестовых данных – это непростая задача. Этот процесс может оказаться довольно трудным; все зависит от сложности системы и технологий, которые были задействованы.
В идеале команда может сгенерировать тестовые данные с помощью сценария. После чего эти тестовые данные можно использовать для проведения какого-то определенного тестирования, а потом удалить или вернуть в исходное состояние.
Хорошая стратегия генерации тестовых данных – это ключ к успеху современных программных приложений. Не стоит ее недооценивать, а время, которое вы на это потратите, будет того стоить.
Ошибки – это хорошо
В этой статье я пробежался по трем ошибкам, которые совершают при тестировании ПО и которые я, как инженер по тестированию ПО, встречал в разных командах и организациях за последние несколько лет. Конечно же, когда дело доходит до тестирования ПО, команда или отдельный взятый человек могут совершить гораздо больше ошибок.
Все мы люди, и все мы совершаем ошибки, и я не считаю, что это плохо. Мы учимся на своих ошибках и, таким образом, совершенствуем свои навыки и пополняем багаж знаний. В идеале было бы здорово, чтобы команды была честна и поделилась своими ошибками с другими компаниями, чтобы избавить их от предрассудков, связанных с неудачами.
Возможность эксплуатации уязвимости OpenSLP может быть устранена при помощи решения CVE-2019-5544, если следовать шагам, описанным в разделе решения в данной статье.
Предупреждение: Данное обходное решение применимо только для ESXi. Не используйте это временное решение c другими программами VMware.
Техническое влияние: С данным решением клиенты CIM, которые применяют SLP протокол для поиска сервисов через порт 427, не смогут подключиться к программе.
Решение
Для реализации данного решения для CVE-2019-5544 соблюдайте следующие шаги:
Остановите протокол обнаружения сервисов на ESXi хосте с помощью данной команды:
/etc/init.d/slpd stop
Протокол обнаружения сервисов может быть остановлен только когда сервис не используется. Используйте следующие команды для просмотра рабочего состояния протокола обнаружения сервиса Deamon:
esxcli system slp stats get
Для отключения сервиса SLP выполните следующую команду:
esxcli network firewall ruleset set -r CIMSLP -e 0
Чтобы внести это изменение, сохранитесь перед перезагрузкой:
chkconfig slpd off
Проверьте, чтобы сохранилось:
chkconfig --list | grep slpd
output: slpd off
Для того, чтобы удалить обходное решение CVE-2019-5544, выполните следующие шаги:
Чтобы включить набор правил сервиса SLP, выполните следующую команду:
esxcli network firewall ruleset set -r CIMSLP -e 1
Для изменения текущей информации о запуске сервиса slpd выполните следующую команду:
chkconfig slpd on
Введите следующую команду, чтобы проверить изменения после предыдущего шага:
chkconfig --list | grep slpd
output: slpd on
Введите следующую команду для того ,чтобы включить SLP:
/etc/init.d/slpd start
Деактивируйте и разблокируйте агента CIM
Данный модуль позволяет создавать директории пользователей, которые будут доступны для абонентов через другие модули, например, IVR. Можно создать директорию, содержащую в себе всех сотрудников компании или по одной директории для каждого из департаментов компании. Кроме того, можно обозначит правила маршрутизации вызова для пользователя, когда выбирается определенный сотрудник в директории – к примеру, если кто-то введёт номер генерального директора, вызов отправится на его секретаря.
/p>
Другими словами, данный модуль позволяет иметь Вам корпоративное IVR меню, с помощью которого, сотрудники, зная только имя своего коллеги смогут дозвониться до него через модуль Directory.
Настройка модуля
Для доступа к данному модулю необходимо в меню выбрать Applications –> Directory
Далее необходимо нажать на кнопку + Add Directory и появится окно создания директории
Ниже опишем значащие поля:
Directory Name – понятное название директории, к примеру – «Support», или «Sales»
Directory Description – развёрнутое описание директории
CallerID Name Prefix – префикс, добавляемый к Caller ID звонящего, когда звонок идёт через директорию. К примеру, можно ввести префикс «DIR-», что бы понимать какие звонки пришли из директории
Alert Info – опциональное поле, может быть использовано для посылки сообщения «ALERT_INFO» на SIP устройства, поддерживающие подобную функцию.
Announcement – звуковое приветствие для попавших в директорию. Сообщение по умолчанию – «Welcome to the directory. Please enter the first three or more letters of the party's first or last name, using your touch-tone keypad. Use the 1 key for punctuation. Press 0 to exit the directory and obtain further assistance (Добро пожаловать в директорию. Наберите первые 3 или более букв, которые содержатся в имени или фамилии абонента, используя клавиши на вашем телефоне. Для пробела используйте клавишу 1, и 0 для выхода из директории.)» Данное приветствие рекомендуется сменить на ваше собственное используя модуль System Recordings.
Invalid Retries – количество попыток неудачного набора/ввода имени абонента
Invalid Retry Recording – запись, которая проигрывается при получении неверного имени. Сообщение по дефолту «I’m sorry, there’s no entry matching the keys you have entered. (Извините, но введённая комбинация клавиш не существует)». Данную запись так же можно заменить на вашу собственную с помощью модуля System Recordings
Invalid Recording – Сообщение, которое проигрывается звонящему при нажатии кнопки 0 или если кончились попытки набора. Стандартное сообщение – «We are now transferring you out of the directory. Please hold on for further assistance.(В данный момент ваш вызов направляется вне директории. Ожидайте для дальнейшей информации.)
Invalid Destination – направление для перенаправления вызовов, в случае если истекло количество попыток или был нажат 0. Данное условие может быть отменено функцией «Return to IVR»
Return to IVR – Yes/No (отправлять или нет абонента обратно на IVR, при условии если вызов пришел с IVR.) Если вызов пришел с IVR, то установка в «Yes» отменяет значение поля «Invalid Destination»
Announce Extension – Yes/No – Озвучивать или не озвучивать номер экстеншена, на который будет направлен вызов. Данная функция может быть полезна для уточнения номера экстеншенов при прямом наборе в дальнейшем.
При добавлении новой сущности в директорию с помощью выпадающего меню, есть выбор из 3 опций: All Users – добавление всех существующих экстеншенов на АТС, Custom Entry (для определения конкретной строки набора, может быть полезно для указания номера сотового телефона или какого-нибудь внешнего ресурса), Extension (просто номер отдельного экстеншена).
Ниже пример добавления экстеншена в группу
Далее рассмотрим поля при добавлении экстеншена:
Name – автоматически устанавливается таким же, как и имя экстеншена. К примеру, если имя Ivan, то для набора первых трёх букв потребуется набрать «482» на клавиатуре телефона.
Name Announcement – какой звуковой файл проигрывается при совпадении – например, приветствие для электронной почты, имя или системная запись.
Dial – номер для набора, по умолчанию это тот же экстеншен. Однако, это поле может быть изменено на любой другой номер, как в примере, описанном выше – с генеральным директором и его ассистентом.
На этом всё, для применения изменений необходимо нажать на кнопку Submit и затем Apply Config.