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) - это комбинация тест скриптов или тестовых наборов для последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).

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

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

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

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

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

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

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

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

• Базовые операции создания/чтения/изменения/удаления сущностей (так называемые 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 JavaScript support (which is constantly improving) and is able to work even with quite complex AJAX libraries, simulating either Firefox or Internet Explorer depending on the configuration you want to use. It is typically used for testing purposes or to retrieve information from web sites. HtmlUnit is not a generic unit testing framework. It is specifically a way to simulate a browser for testing purposes and is intended to be used within another testing framework such as JUnit or TestNG
HttpUnit	Written in Java, HttpUnit emulates the relevant portions of browser behavior, including form submission, JavaScript, basic http authentication, cookies and automatic page redirection, and allows Java test code to examine returned pages either as text, an XML DOM, or containers of forms, tables, and links. When combined with a framework such as JUnit, it is fairly easy to write tests that very quickly verify the functioning of a web site.
Watij	Watij (pronounced wattage) stands for Web Application Testing in Java. Watij is a pure Java API created to allow for the automation of web applications. Based on the simplicity of Watir and enhanced by the power of Java, Watij automates functional testing of web applications through a real browser. Currently Watij supports automating Internet Explorer on Windows only. Future plans are in place to support others like Mozilla.
Selenium	Selenium is a suite of tools to automate web app testing across many platforms.
Jamaleon	Jameleon is an automated testing framework that can be easily used by technical and non-technical users alike. One of the main concepts behind Jameleon is to create a group of keywords or tags that represent different screens of an application. All of the logic required to automate each particular screen can be defined in Java and mapped to these keywords. The keywords can then be organized with different data sets to form test scripts without requiring an in-depth knowledge of how the application works. The test scripts are then used to automate testing and to generate manual test case documentation.
Junit	JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.
Abbot	Abbot is a simple framework for unit and functional testing of Java GUIs. Facilitates generating user actions and examining component state. Supports recording and playback on any Java application.
Marathon	With Marathon you capture user interactions on the applications and also insert assertions to verify that correct processing is taking place. The generated raw script can be re-factored to modules for efficient reuse and maintainability. Replay the scripts either manually or integrate Marathon into your build process for automatic execution of the test suites.

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

Коммерческие инструменты для автоматизированного нагрузочного тестирования:

Hewlett-Packard (Mercury Interactive)	HP Performance Center (включает HP LoadRunner)
IBM Rational	Rational Performance Tester
Borland (Segue)	Silk Performer
SmartBear	LoadComplete Web Load Testing
Neotys	NeoLoad

 

Отдельным пунктом выделим бесплатные инструменты для автоматизированного нагрузочного тестирования:

• Jmeter - an Apache Jakarta project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services
• Grinder - a load testing framework that makes it easy to run a distributed test using many load injector machines. Test scripts are written in Jython, and HTTP scripts can be recorded easily from a browser session.

· Что подлежит автоматизированному тестированию

Автоматизация не есть вещью в себе, а является просто подходом к выполнению задач тестирования, эффективность которого по сравнению с ручным тестированием зависит от конкретных переменных проектного окружения: длительность проекта, готовность проекта к автоматизации на разных структурынх уровнях и т.д..

Автоматизировать можно и нужно только то, что автоматизации требует, а не те функциональные модули, где автоматизацию можно применить.

Что значит требует?
Занимает много времени при ручном тестировании (повторяется циклически многократно и/или требует множества автоматизируемых операций перед проверкой ключевой функциональности, как например проверка операции закрытия переода в биллинге, тестирование которой требует введения данных о потреблении услуг)

 

Может в перспективе с учётом затрат на приобретение и внедрение инструмента автоматизации окупиться в бюджете проекта. Финансовая окупаемость - это единственный фактор, который определяет целесообразность внедрения автоматизации тестирования ПО в проекте.

 

Зачастую на финансовую окупаемость может положительно влиять внедрение практик и инструментов автоматизированного тестирования на уровне компании, а не отдельно взятого проекта.

Что значит целесообразность внедрения на практике.
Модульное тестирование
Прогон всех модульных тестов на интеграционном окружении во время сборки версии системы является первым этапом автоматизации. Имеет ли смысл вкладывать ресурсы в модульное тестирование?

Если вопрос возник, культура разработки в проекте находится на достаточно низком уровне. Продукт приходит в тестирование стабильно сырым, исправление ошибок вызывает циклическое появление новых ошибок в связанном функционале.

 

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

 

При этом модульное тестирование не есть самоцель, а только инструмент предварительного контроля качества кода на модульном уровне.

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

 

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

 

· Автоматизация набора регрессионных тестов

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

1. Полный или основной тестовый набор, покрывающий всю функциональность тестовой области. Анализируется перед каждым прогоном полного цикла тестирования на предмет изменений в спецификациях и критических исправлений/доработках. Обновляется/актуализируется по результатам ревью.

2. Короткий список (обычно только позитивные тесты основанные на наиболее приоритетных сценариях использования).

 

Включается в цикл дымового тестирования или другими словами в набор тестов приёмочной фазы тестирования.

 

Составляется в процессе создания тестового набора.

 

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

 

Обновляется/актуализируется в момент актуализации основного тестового набора. Удобно вести в том же артефакте что и основной тестовый набор с возможностью автоматизированного включения в тестовый набор дымового/приёмочного тестирования.

Регрессионным тестовым набором системы, в моём понимании, является сумма всех наборов тестов всех тестовых областей.

 

Регрессионное тестирование, по сути, является функциональным тестированием с той разницей, что целью такого тестирования проверка отсуствия регрессии системы.

 

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

 

Если проведение полного цикла тестирования удобнее или нагляднее выносить в отдельный этап работ и называть его как-то надо:) то можно называть его и регрессионными тестами.

 

Только не надо потом думать над задачами автоматизации в разрезе этой привнесённой выделенности регрессионного тестирования.

Иногда в планы автоматизации может вмешиваться задача автоматизации тестирования какого-то выделенного компонента, например от стороннего разработчика, функционал которого как бы оборачивается прослойкой автоматизированных тестов, для снижения рисков связянных с неполным контролем качества поставляемого этим разработчиком модулей или компонентов.

 

Если таким компонентом является что-то, что используется в системе несколькими модулями системы, скорее всего прийдётся идти по принципу точечной автоматизации именно в разрезе автоматизации тестирования этого выделенного списка функций.

 

Например, уровень работы с базой данных может стать таким узким местом, если кому-то пришлось отказываться от поставляемых в составе СУБД драйверами.

Что попадает в набор тестов для автоматизации определяется всё тем же основным принципом экономической рациональности и в каждом конкретном тестовом наборе.