Сегодня мы поговорим о тестировании безопасности веб-приложений. Сам я инженер по тестированию, по образованию – специалист по информационной безопасности, а по жизни – параноик.
В то время, когда я учился в университете, было не принято преподавать какие-то реальные вещи (читай – потребности отрасли), касающиеся защиты и компрометации информационных систем. Конечно, это можно было бы списать на бюрократию и сложности внедрения новых методик, но я думаю, что там, как и везде, просто больше любят бумажки – оттуда и безопасность у нас — «бумажная». В работе же необходимы практические навыки и знания.
1. СНАРУЖИ
Ни для кого не секрет, что количество сетевых атак неуклонно растет. Каждый день их совершается около 1000, подсчитать же их число за год практически невозможно (это наглядно видно из статьи Стива Моргана). Атакам подвергаются самые разные сетевые ресурсы – от сайта местного провайдера до федерального размера (агентурной) торговой сети суши и атомных станций. Можно даже посмотреть на интерактивную карту кибератак в режиме онлайн.
И каждый уязвим. И каждый отдает себе отчет об этом риске. И каждый думает, что это не про него. Что уж там душой кривить – мы так привыкли. Нежелание признавать риски приводит к нежелательным последствиям.
Давайте рассмотрим безопасность подробнее, ведь «в действительности все не так, как на самом деле» (с).
Рано или поздно каждый специалист в сфере автоматизированного тестирования сталкивается с необходимостью ускорять тестовые прогоны, идя для этого на всевозможные ухищрения, в том числе прибегая к инфраструктурным решениям.
Последнее время трендом стало использование инструмента виртуализации Docker, и именно о нём будет данный доклад, а также о ряде других лайф-хаков, которые сыграли большое значение в решении задачи по ускорению прогонов на практике.
В рамках доклада вы получите ответы на следующие вопросы:
что такое Docker, и в каких случаях он позволяет оптимизировать тестовые запуски
как избавиться от классических «болезней» при параллельном выполнении автотестов
как получить достаточное количество окружений для параллельных запусков, изрядно при этом сэкономив
как привнести динамику в жизнь проекта и, в случае необходимости, без труда мигрировать между серверами?
Если бы на модные словечки века проводился конкурс (хоть я и не думаю, что тестированию уже стукнуло сто лет), я почти на 100% уверен, что выиграла бы автоматизация тестирования. Если вы читаете про тестирование или слушаете подкасты, это обычно «автоматизация то», «автоматизация се», «автоматизируйте все».
Оно безусловно чрезмерно употребляется и чрезмерно злоупотребляется, и я готов спорить, что куча людей, дающих советы по автоматизации, не имеют ни малейшего представления, о чем они, черт возьми, говорят. Или, как минимум, их заявления демонстрируют полнейшее непонимание цели автоматизации.
То, что термины «тест-автоматизация» и «автоматизированное тестирование» во многом ошибочны, то, что «автоматизировать» тестирование, в сущности, нельзя, то, что мы можем автоматизировать только его часть, обсуждалось множество раз, бла, бла, бла, я не буду это повторять, и мне скучно говорить об этом снова и снова. Мысль, которая ударила меня как молния, состоит в том, что автоматизации тестирования не существует – есть «тестирование» и есть «автоматизация». Мне кажется, что наше мышление еще недостаточно развилось для того, чтобы мы эффективно их комбинировали. Сейчас покажу.
Я заметил, что тема тестирования производительности все еще остается не до конца понятной для большинства тест-инженеров. Мы стремимся сфокусировать внимание на функциональном аспекте тестирования, оставляя производительность, масштабирование и настройку на усмотрение разработчиков. Разве не является стабильность существенной составляющей качества программного продукта? Особенно во времена распределенной обработки данных, когда мы масштабируем приложения независимо друг от друга и всецело рассчитываем на внедрение интеграций по HTTP протоколу. Другим существенным фактором является возможность расширения систем. Для того, чтобы справиться с увеличением трафика, мы должны быть осведомлены об ограничениях пропускной способности.
Существует несколько хорошо известных тестировщикам инструментов, таких как JMeter, Gatling, Tsung и т.д. И хотя они довольно просты в использовании, анализ полученных результатов и выводы на их основании представляют для тестировщиков сложность. Во время проведения собеседований на позицию QA инженера я часто встречаю кандидатов, утверждающих, что у них есть опыт в области тестирования производительности, но, по факту, не обладающих знаниями метрик и основных понятий с ним связанным. Поскольку основной задачей тестирования производительности является не знание инструментария, а данные, полученные с его помощью, цель этой статьи - рассмотреть основные аспекты этой сферы тестирования.
Каждый руководитель должен понимать, на что способна его команда в целом и каждый сотрудник в отдельности. Понимание это достигается применением тех или иных техник, и сейчас я расскажу Вам о своей практике на примере одного из проектов, на котором я работал еще до поступления в ЛК.
Итак, меня назначили на должность тимлида группы тестирования, состоящей из 8 человек (далее «команда»): 1 ведущего, 3 старших и 4 «обычных» специалистов. Имея экспертные знания о продукте, я пока еще не представлял уровень подготовки членов команды, из-за чего не был уверен в качестве тестирования сложных задач и не мог правильно выделить время на их проверку. Задача выбора исполнителя для каждой доработки и оценки трудозатрат решалась непросто и далеко не всегда эффективно. Работа шла по схеме «сами берите в работу те задачи, которые лучше знаете».
Аддоны к браузерам вряд ли пригодятся в автоматизации тестирования web-систем, но при ручном тестировании они могут оказаться полезны. К примеру, можно заполнять элементы на выбранной странице, исходя из своих условий и входных данных. Ниже рассмотрено создание такого аддона для Firefox и Chrome без претензий на красоту кода.
Задача: разработать аддон для Firefox и расширение для Chrome со следующей функциональностью:
1. В тулбаре появляется кнопка (иконка).
2. При нажатии на эту кнопку анализируется URL активной страницы (вкладки). Если URL – один из заранее заданных URLs, то при нажатии на кнопку тулбара скрипт берет пару “пользователь-пароль” из опций в зависимости от URL и заполняет поля ввода логина и пароля на странице. Далее скрипт нажимает кнопку логина.
"Обращайтесь с читателями так, как вы хотели бы, чтобы обращались с вами. Пишите Gherkin так, что люди, не знающие фичу, поймут, о чем это".
Хороший Gherkin (как и любой язык, основанный на specification-by-example) неразрывно связан с созданием хороших заголовков для поведенческих сценариев. Заголовок – это лицо сценария: он резюмирует суть поведения. Хорошие заголовки серьезно облегчают сотрудничество в команде, а плохие – затрудняют его. Но что же делает заголовок "хорошим"? Вот несколько неплохих советов.
Тестирование на проникновение является одной из методик выявления областей системы, уязвимых для вторжения и компрометации целостности и достоверности со стороны неавторизованных и злонамеренных пользователей или сущностей. Процесс тестирования проникновения включает в себя умышленные санкционированные атаки на систему, способные выявить как ее наиболее слабые области, так и пробелы в защите от сторонних проникновений, и тем самым улучшить атрибуты безопасности.
Данная методика также может быть использована в качестве дополнения к другим методам проверки для оценки эффективности комплекса защиты системы от различных типов неожиданных вредоносных атак.
Сегодня утром я получила письмо, которое, в частности, гласило:
У меня появилась возможность попробовать себя в роли тест-тренера на моем нынешнем рабочем месте (6-7 команд из 4-5 разработчиков).
У меня состоялась встреча с руководителем разработки, и она хочет, чтобы я стала практически тест-консультантом. Она ожидает от меня создания системы, в которой я задаю командам вопросы, вскрывающие ключевые проблемы тестирования. Она также хочет иметь ключевые метрики, которыми можно измерять успех.
Мой вопрос в том, есть ли у вас набор вопросов или подход, позволяющий командам открыть для себя свои крупнейшие проблемы тестирования? Можете ли вы подсказать, что почитать на эту тему, или какой-либо подход?
Вот лично мой подход к старту карьеры в роли тест-тренера.
На тренинге Вы получите исчерпывающие ответы на наиболее актуальные вопросы построения эффективной, минимизирующей усилия / траты Архитектуры того или иного решения Автоматизации тестирования.
На тренинге Вы научитесь выбирать метрики и инструменты работы с ними, внедрять их на проекте, сможете с нуля разработать ROI калькулятор и узнать как эффективно его использовать.
Благодаря тренингу Вы научитесь проводить собеседования, делегировать задачи и ответственность, мотивировать команду, развивать сотрудников, налаживать коммуникации и эффективно управлять своим временем.
Описание и подробную программу можно посмотреть по ссылкам выше.
