Server-Side Includes (SSI) Injection

⇐ Назад

В зависимости от типа операционной системы команды могут быть разными, как пример рассмотрим команду, которая выводит на экран список файлов в OS Linux:

< !--#exec cmd="ls" -->

Authorization Bypass

Пользователь А может получить доступ к документам пользователя Б. Допустим, есть реализация, где при просмотре своего профиля, содержащего конфеденциальную информацию, в URL страницы передается userID, а данном случае есть смысл попробовать подставить вместо своего userID номер другого пользователя. И если вы увидите его данные, значит вы нашли дефект.

· Что, кто и как выполняется автоматизированное тестирование?

Автоматизированное тестирование программного обеспечения (Software Automation Testing) - это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.

Специалист по автоматизированному тестированию программного обеспечения (Software Automation Tester) - это технический специалист (тестировщик или разработчик программного обеспечения), обеспечивающий создание, отладку и поддержку работоспособного состояния тест скриптов, тестовых наборов и инструментов для автоматизированного тестирования.

Инструмент для автоматизированного тестирования (Automation Test Tool) - это программное обеспечение, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.

Тест Скрипт (Test Script) - это набор инструкций, для автоматической проверки определенной части программного обеспечения.

Тестовый набор (Test Suite) - это комбинация тест скриптов, для проверки определенной части программного обеспечения, объединенной общей функциональностью или целями, преследуемыми запуском данного набора.

Тесты для запуска (Test Run) - это комбинация тест скриптов или тестовых наборов для последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).

· В каких случаях использование автоматизированного тестирования является нецелесообразным/целесообразным?

Спрашивая: «Что автоматизировать?», необходимо сначала ответить на вопрос: «Целесообразна ли автоматизация тестирования в условиях проекта».

Если ответ «ДА», то необходимо, исходя из требований к объекту тестирования, создать план, по которому будут разрабатываться автомати-зированные тесты.

Создавая подобный документ, вы должны четко представлять, "что автомати-зировать?", "как автоматизировать?" и "чем автоматизировать?".

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

Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД)
Часто используемая функциональность, риски от ошибок в которой достаточно высоки. Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение.
Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения)
Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации)
Длинные end-to-end сценарии
Проверка данных, требующих точных математических расчетов
Проверка правильности поиска данных

А также, многое другое, в зависимости от требований к тестируемой системе и возможностей выбранного инструмента для тестирования.

Для более эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие:

Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции - Create / Read / Update / Delete).

Пример: создание, удаление, просмотр и изменение данных о пользователе.

Типовые сценарии использования приложения, либо отдельные действия.

Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это так называемый end-to-end сценарий, который проверяет совокупность действий. Мы предлагаем вам использовать именно такие сценарии, так как они позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты.

Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную.

Пример: система создает некоторый xml файл, структуру которого необходимо проверить.

Это и есть та функциональность, от автоматизации тестирования которой, можно получить наибольшую отдачу.

· Подходы к автоматизации

В данном разделе рассмотрим аспекты, влияющие на выбор инструмента автоматизации тестирования.

Во первых, вы должны обратить внимание насколько хорошо инструмент для автоматизации распознает элементы управления в вашем приложении. В случае когда элементы не распознаются стоит поискать плагин, либо соответствующий модуль. Если такового нет – от инструмента лучше отказаться. Чем больше элементов может распознать инструмент – тем больше времени вы сэкономите на написании и поддержке скриптов!

Во-вторых, нужно обратить внимание на то сколько времени требуется на поддержку скриптов написанных с помощью выбранного инструмента. Для этого запишите простой скрипт который выбирает пункт меню, а потом представьте, что изменился пункт меню который необходимо выбрать. Если для восстановления работоспособности сценария вам придется перезаписать скрипт целиком, то инструмент не оптимален, так как реальные сценарии гораздо сложнее. Лучше всего тот инструмент, который позволяет вам вынести название кнопки в переменную в начале скрипта и быстро заменить ее значение. В идеале – описать меню как класс.

И последний момент на который нужно обратить внимание – насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код (поддержка ООП), насколько код читаем, насколько удобна среда разработки для рефакторинга (переработки кода) и т.п.

Лучше всего для принятия правильного решения об автоматизации отвечать на вопросы «Зачем? Что? Как?» именно в таком порядке. Это поможет избежать впустую потраченных времени нервов и финансов. С другой стороны вы сможете получить надежность, скорость и качество!!!

· Инструменты для автоматизации функционального тестирования

Выбор инструмента зачастую зависит от объекта тестирования и требований к тестовым сценариям, т.к. инструменты тестирования не могут поддерживать абсолютно все технологии, используемые при разработке приложений.

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

Например, GUI мы проверяем по средствам Mercury WinRunner,

бэкенд процессы - используя "java based test tools" или другие инструменты.

Рассмотрим инструменты для автоматизированного функционального тестирования от разных производителей:

Компания	Инструмент
Hewlett-Packard (Mercury Interactive)	QuickTest Professional, WinRunner
IBM Rational	Rational Robot, Rational Functional Tester
Borland (Segue)	SilkTest
AutomatedQA Corp	TestComplete
Microsoft	Microsoft VS 2005
OpenQA	Selenium

Отдельным пунктом также хочется выделить Java библиотеки для автоматизированного тестирования (java based test tools and libraries):

Инструмент	Описание
HtmlUnit	HtmlUnit is a "browser for Java programs". It models HTML documents and provides an API that allows you to invoke pages, fill out forms, click links, etc... just like you do in your "normal" browser. It has fairly good 9-73246.php" class="back_link" > ⇐ Назад 1 2 3 4 56