QA

ЧТО ТАКОЕ AD-HOC ТЕСТИРОВАНИЕ?

admin — Wed, 01 Jul 2020 15:26:24 GMT

Что же такое «Ad-hoc testing», то есть «Свободное или Интуитивное тестирование». Часто его путают с другим видом тестирования «Exploratory testing» – «Исследовательское тестирование».

Давайте, рассмотрим разницу между ними.

Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Оно не требует никакой документации, планирования, процессов, которых следует придерживаться при выполнении тестирования. Такой способ тестирования в большинстве случаев дает большее количество заведенных отчётов об ошибке. Это обусловлено тем, что тестировщик на первых шагах приступает к тестированию основной функциональной части продукта и выполняет как позитивные, так и негативные варианты возможных сценариев.

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

Виды свободного тестирования (ad-hoc testing):

Buddy testing – процесс, когда 2 человека, как правило разработчик и тестировщик, работают параллельно и находят дефекты в одном и том же модуле тестируемого продукта. Такой вид тестирования помогает тестировщику выполнять необходимые проверки, а разработчику исправлять множество дефектов на ранних этапах.
Pair testing – процесс, когда 2 тестировщика проверяют один модуль и помогают друг другу. К примеру, один может искать дефекты, а второй их документировать. Таким образом, у одного тестера будет функция, скажем так, обнаружителя, у другого – описателя.
Monkey testing – произвольное тестирование продукта с целью как можно быстрее, используя различные вариации входных данных, нарушить работу программы или вызвать ее остановку (простыми словами – сломать).

Различия между Buddy testing и Pair testing:

Buddy testing (Совместное тестирование) – это сочетание модульного тестирования и системного тестирования между разработчиком и тестировщиком.
Pair testing (Парное тестирование) – выполняется только тестировщиками с разным уровнем знаний и опыта (такое сочетание поможет поделиться взглядами и идеями).

Основные преимущества ad-hoc testing:

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

Пример свободного тестирования (Ad-hoc testing):

Ad-hoc тестирование мы часто используем в нашей жизни, возьмем, к примеру, обычный поход в супермаркет.

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

Если нам нужно провести ad-hoc тестирование интернет-магазина, то этот краткий список может помочь с тем, что нужно проверить:

все возможности сайта доступны без регистрации;
корректность отображения анимаций и картинок;
все возможности сайта доступны после регистрации;
процесс регистрации;
процесс добавления/удаления из корзины;
процесс оплаты покупок;
удобство в пользовании для новичков, простота, подсказки, помощь.

Также стоит отметить, что ad-hoc тестирование часто является любимым видом тестирования для тестировщиков, где можно проявить все свои знания и выполнить самые труднопредсказуемые сценарии, то есть предоставляется возможность чистой импровизации.

Способы повышения эффективности Ad-hoc тестирования

Приготовление. Проанализировать дефекты в похожих приложениях, таким образом повысив вероятность обнаружения подобных дефектов в тестируемом приложении.
Формирование черновика. Это не должен быть детальный план тестирования, а наброски, с чего начать и какие проблемы поискать.
Тестирование сессиями. Тестировать различный функционал продукта по очереди, т.е. не всё сразу. Это помогает лучше сфокусироваться и понять проблемы.
Уделять внимание целевым областям. В первую очередь проверить те области, которые не покрыты тест-дизайном и тестовой документацией.
Использование разных вспомогательных программ. Некоторые дефекты можно обнаружить, используя дебаггеры, профайлеры и мониторинги. Знание таких утилит помогает в тестировании.
Записывать результаты тестирования. Записи того, какие баги были найдены, в каких частях приложения их больше и т.п. Это может помочь как разработчикам, так и тестировщикам последующих версий приложения. Также можно записать то, что не работало, т.к. аналитикам может быть полезно увидеть, что работало хорошо.

Исследовательское тестирование (Exploratory testing)

Исследовательское тестирование (exploratory testing) — это одновременное изучение программного продукта, проектирование тестов и их выполнение. Это неформальный метод проектирования тестов, при котором тестировщик активно контролирует проектирование тестов в то время, как эти тесты выполняются, и использует полученную во время тестирования информацию для проектирования новых тестов.

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

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

Когда следует применять исследовательское тестирование?

Самые распространенные случаи:

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

Вывод

Описанные выше методы тестирования имеют основательные сходства и различия, поэтому стоит разделять эти две популярные методики в рамках тестирования. Разница между ad-hoc и exploratory testing в том, что теоретически, ad-hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определёнными техниками. При этом, определённые техники – это не только техники тестирования.

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

Как провести тестирование на безопасность: руководство для Manual QA

admin — Tue, 08 Oct 2019 20:08:46 GMT

Эта статья нацелена на подрастающее поколение QA и разработчиков, которым интересно узнать что-то об уязвимостях: с чего начать, какими инструментами можно пользоваться начинающему в этом деле (практические советы). В материале будет изложено то, что я хотел бы прочесть в начале своей карьеры Security QA.

Вступление

Когда я был Manual QA, мне всегда казалось, что искать уязвимости очень трудно, что этим могут заниматься только те люди, которые умеют программировать. Поэтому я выбрал сначала путь автоматизатора, так как зачастую QA развиваются именно в этом направлении. Но после более чем полутора лет в должности автомейшена мне стало скучно... Да-да, стало скучно, так как мне неинтересно было все время писать код и не общаться с командой девелоперов, продактами и другими членами команды, как я делал это, когда был мануальщиком.

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

Немного о себе: в тестировании я уже больше 7 лет, занимаюсь поиском уязвимостей больше 4 лет. Веду тренинги по тестированию безопасности. Помимо основной работы провожу аудиты по QA. Веду блог.

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

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

А вот и решения:

С первой проблемой мне помогли... даже не поверите кто — те же самые ловцы уязвимостей, которые атаковали нас и писали нам репорты о наших уязвимостях. Читая эти репорты, я параллельно гуглил и искал в статьях информацию о причинах возникновения и критичности данных уязвимостей. В итоге я составил для себя чек-лист массовости (насколько распространен этот вид уязвимости среди продуктов) и критичности (насколько опасно иметь такую уязвимость в зависимости от того, сколько бед, которые могут привести к потере доверия к бренду, можно натворить с ней на проекте).
Также решением первой и второй проблем стали мои выступления перед публикой на тему уязвимостей. За время подготовки к тому, чтобы учить кого-то чему-то, вы изучите материал настолько хорошо и настолько быстро, что сами удивитесь :-) У вас сразу появляется:
- дедлайн, к которому вы должны успеть подготовиться и хорошо изучить тему;
- стимул учить новое, так как перед вами стоит задача выступить перед публикой, а опозориться не сильно хочется, чтобы не показать, что вы чего-то не знаете в этой области, но что-то там вещаете;
- время. Скажете откуда? Да вы просто под психологическим воздействием, что нужно подготовиться к выступлению, меньше бездействуете (меньше времени уделяете просмотру видосов с котиками и остальными приколясами). Да и после работы вместо просиживания штанишек перед сериальчиком вы готовитесь к своему дебюту на сцене. Нормальный такой лайфхак? :-)
И самое главное: после того как вы ознакомились с какой-либо теорией о уязвимости, немедленно идите применять ее на практике, так как теория в голове без практики имеет способность пропадать, не подавая виду, быстро и бесследно. И это будет реально напрасно потраченное время. Попрактиковаться можно у себя на проекте с разрешения руководства — а я думаю, оно по-любому разрешит вам, так как хорошо, когда есть человек, который может проверить хоть на какую-то безопасность. Либо можно прогуглить Broken Web Application и по первой ссылке скачать себе приложение, запустить его на VirtualBox и применять там свои наработанные навыки.

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

А теперь давайте поговорим о самых распространенных уязвимостях, которые могут встретиться вам на пути, и о том, как их искать...

XSS

Это один из типов уязвимости web application, который дает скрипту возможность отрабатывать на страницу, написанную на JS. Такая уязвимость дает возможность злоумышленнику внедрить свой сценарий в работу вашего приложения. По статистике, 40% компаний, прошедших через сканеры, имеют эту уязвимость. В рейтинге OWASP Top 10 она на 7-м месте. Причина появления этой уязвимости — это доверие со стороны разработчика, что пользователь не будет вносить разнообразные куски кода на сайт.

Что же может сделать в своих целях ловец уязвимостей?

Изменить настройки (например, заменить бэкграунд сайта, всунуть, допустим, на задний фон скрин Joycasino, размещать рекламу через всплывающие попапы).
Стырить куки пользователя.
Фишинг (хакер может вставить поддельную форму для входа на страницу, которую вы посещаете, используя DOM, установив в атрибуты action этой формы отправку данных на свои собственные серваки).
Кейлогер (хакер может внедрить что-то типа отслеживания действий, выполняемых на клавиатуре пользователем, используя addEventListener, а потом отправить все эти нажатия клавиш на свой серверок, записав конфиденциальную информацию пользователя. Например, это могут быть пароли и номера кредитных карт. Стремно, согласитесь.

Бывает три типа XSS:

Непостоянные (отраженные) XSS.
Постоянные (хранимые) XSS.
XSS DOM-модели.

Рассмотрим каждую из них.

Непостоянные (отраженные) XSS

Этот класс XSS является самым распространенным на сайтах. Давайте смоделируем вектор атаки с помощью этого класса. Рассмотри это на примере специально подготовленной лаборатории по уязвимостям DVWA. У нас есть форма с инпутом, при этом инпут, как мы видим по исходному коду этой формы, не фильтруется никаким фильтратором. То есть переменная $_GET['name']принимает без перебора все, что в нее впишут. Соответственно, вписанный в этот инпут скрипт вызовет попап на этой странице со значением в нем цифры 1, после того как мы отправим на сервер запрос с этим скриптом. В итоге то, что мы отправили через этот инпут на сервер, передается GET-параметром в урле, так как эта форма общается с сервером по GET.





На следующей картинке мы можем увидеть результат:



Как мы видим, в урле наш JS-код, вызывающий тот самый попап, в который мы можем вписать любую информацию на текущей странице, где есть такая уязвимость. Каковы методы применения такой уязвимости, спросите вы? Приведу их ниже...



Допустим, SEO-менеджер изучил новый способ распространения рекламы — через попапы этой уязвимости. Он находит сайт, где эта уязвимость срабатывает, в нашем случае это bank.ua. Он дописывает в аргумент поиска после названия скрипт ')%3Balert('XSS')%3Bvar b=(', при этом браузером будет экранироваться попап, отображающий то, что в него напишет наш менеджер, так как данные не подвергаются обработке. Затем паренек просто распространяет весь этот урл через разные социальные сети. Если пользователь, который получит этот скрипт, внимательный, он просто может удалить добавленный в урл скрипт, и попап не выпрыгнет при открытии страницы банка, но если не заметил, то он, помимо открытия страницы сайта, получит вывод попапа, в котором будет информация, которую написал туда наш менеджер.

Хранимые (постоянные) XSS

Этот вид XSS уже считается более разрушительным типом атаки, чем предыдущий. Он возможен, когда ловцу уязвимостей удается закинуть на сервак скрипт JS, который будет выполняться в браузере каждый раз при заходе на запрашиваемую вами страницу. Самым простым примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате без ограничений. Другими словами, хранимый XSS возникает, когда разработчики осуществляют некорректную фильтрацию при сохранении входных данных в БД на сервере, а затем выводят эти же данные в браузер пользователя.

Примерчик на том же ресурсе DVWA:



В этот раз мы внедряем JS-скрипт () в поле Message, которое, как мы видим в коде, тоже не фильтруется нормальным образом от пользовательского ввода. После отправки этого скрипта на сервер он положится в базу на сервер и каждый раз будет вызываться при посещении этой страницы. Ах да... в этом случае будет не просто попап с выводом текста «111», а будет задействован еще и инпут, в которой можно что-то вписывать. А если хорошенько подумать над реализацией этого скрипта, то можно так подхачить его, что как будто выпрыгивает форма авторизации, в которую пользователь введет свои данные, а они будут отправлены на сервер злоумышленника. Как вам такой исход этой уязвимости?




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

DOM-модели XSS

А вот этот вид XSS самый опасный из всех. XSS в DOM-модели появляются на стороне клиента во время обработки данных внутри самого JavaScript. Этот тип XSS получил такое название, потому что нам нужна Document Object Model, чтобы сделать его. Как вы поняли, DOM — это сокращение. Через него можно получать доступ к содержимому HTML- и XML-документов, даже изменять содержимое: либо структуру документа, либо его оформление.

Что можно сделать с помощью этой уязвимости:


 Изменить страницу сайта (можно добавлять/заменять картинки, добавлять куски нового функционала и так далее).
 Можно воровать сессии, куки пользователя (своровав эти данные, злоумышленник может воспользоваться ими в своих целях: например, можно авторизоваться под этими данными и быть как будто тем пользователем).
 Кейлогер (заюзав скрипт на странице с уязвимостью, злоумышленник будет получать все данные, которые вводит пользователь на клавиатуре, находясь на зараженной странице).
 Мало того что можно сделать то, что описано выше, так еще можно и залезть в операционную систему с помощью уязвимости ms10_002_aurora, которая доступна для старых браузеров Safari и Internet Explorer 7. Вы скажете: «Да это же древние браузеры, кто ими будет пользоваться?» Но нет, давайте вспомним банковские конторы, которые заключили десятилетние контракты на использование этой версии браузера, — вот тут такие пользователи и попадутся на эту уязвимость.


Приведу пример, как можно своровать куки пользователя, а потом применить их у себя в браузере и стать этим пользователем, используя при этом инструмент BeEF:



Injection



А теперь перейдем к первой уязвимости из рейтинга OWASP Top 10 — к Injection. По статистике, ею заражено 28% компаний... Я рассматриваю ее позднее, так как эта уязвимость с каждым годом становится все менее распространенной, но остается наиболее критичной из всех, потому что с ее помощью можно увести всю вашу базу данных. Эта уязвимость делится на такие векторы для атаки:


 инъекции через запросы SQL, LDAP, XPath;
 инъекции через команды OS command;
 инъекции через синтаксический анализ XML.


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

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



Итак, тут мы видим форму, при заполнении которой введенные данные будут отправлены в SQL-запрос, и он вытянет нам ответ из базы данных. Если такой юзер есть в базе данных, то нас авторизует. Если нет, то нам скажет: сорян, зарегайся. То, что мы будем вводить в поле User, передается в переменную $username, а то, что введут в поле Pass, передается в переменную $password нашего SQL-запроса. А теперь рассмотрим то, что будет происходить при вводе значений в эти поля.



Давайте введем такие данные:


 в поле User — значение Svyat, которое, как мы видим (отмечено красной стрелкой), станет на место переменной $username;
 в поле Pass — значение 1234, которое, как мы видим (отмечено синей стрелкой), станет на место переменной $password.


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

Давайте теперь рассмотрим, что может сделать злоумышленник в нашем случае...



Тут злоумышленник совершает ход конем и целится в юзера admin. Давайте разберем подробнее, что он ввел:


 в поле User — значение admin, которое, как мы видим, станет на место переменной $username;
 в поле Pass — значение ' OR 100=100 --, которое, как мы видим, станет на место переменной $password.


А теперь давайте разберем, что происходит с переменной $password, когда в нее попадают данные такого рода, и как сервер обработает их.


 Символом кавычки ' из заданного значения ’ OR 100=100 — мы закрываем дефолтную кавычку данной переменной, оставив пароль незаполненным. Это видно на картинке выше.
 Затем переходим к слову OR из нашего значения ' OR 100=100 -- — оно говорит о том, что мы вызываем оператор OR, который будет выполнять свою функцию в SQL-запросе, так как предыдущей кавычкой мы закрыли нашу переменную.
 А выражение 100=100 из нашего значения ' OR 100=100 -- говорит серверу: даже если пароль не подошел, все равно прими за true, как будто он подошел для тебя, так как 100=100 является true.
 И напоследок символы -- из нашего значения ' OR 100=100 -- закомментируют дефолтную кавычку. То есть весь код, который находится после символов --, становится нерабочим. У каждой базы данных вызов операции, чтобы закомментировать код, происходит по-разному: бывает #, бывает —, бывает */.


Исходя из изложенного выше, SQL-запрос получил дополнительное условие, которое диктует серверу новые правила игры, заставляющие его авторизовать нас как пользователя системы, несмотря на то что мы не ввели правильный пароль. А так как это еще и пользователь-админ, мы имеем все привилегии управления приложением. В запрос добавлено значение OR 100=100, которое всегда будет оцениваться как true (так как 100 всегда равно 100, чтобы получить true, необязательно писать именно 100=100, можно взять любое значение, которое равно такому же значению). Теперь этот пользователь будет авторизован как администратор, даже если он не знает пароля. Это не прикольно, согласитесь. Но если есть такая уязвимость, то это может дойти и до такого случая, как на картинке ниже...



Если в поле Pass ввести значение '; DROP TABLE users --, а затем отправить на сервер, то можно вообще лишиться данных юзера в нашей базе, но опять же это если мы не фильтруем в нашем приложении то, что вводит пользователь.

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

Инструменты

Эту и другие уязвимости с OWASP Top 10 можно искать с помощью автоматизированного инструмента. С ним может справиться и Manual QA, достаточно знать, какие есть самые критические уязвимости, и уметь пользоваться инструментами для их поиска.

К инструментарию Penetration Tester можно отнести такие:

Бесплатные:


 OWASP ZAP;
 Nmap;
 Metasploit;
 SQLmap;
 Wireshark;
 Ettercap;
 BeEF.


Платные:


 Burp Suite;
 Acunetix;
 Charles;
 Veracode.


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

Что такое OWASP ZAP

Начнем с того, что OWASP ZAP — это в первую очередь инструмент, который достаточно прост в использовании для тестирования на проникновение в ваше приложение, а также для поиска уязвимостей в веб-приложениях. Программа предназначена как для пользователей, имеющих опыт работы в сфере информационной безопасности, таких как разработчики и мануальные QA, так и для начинающих.

Режимы OWASP ZAP

В ZAP есть несколько режимов работы, при которых он будет проводить сканирование:

1) Безопасный режим — в этом режиме нельзя совершить что-либо потенциально опасное для приложения.

2) Защищенный режим — в этом режиме пользователь (бот) может выполнять только вредоносные действия по URL-адресам, указанным в области браузера.

3) Стандартный режим — в этом режиме пользователь (бот) может делать все, что имеет значение для приложения.

4) Режим Attack — при нахождении новых узлов в области действия шпиона они активно сканируются, как только обнаруживаются.

Оповещение



После того как вы запустите сканер, все найденные ошибки OWASP ZAP будут отсортированы по степени серьезности уязвимостей и будут находиться на вкладке «Оповещение». Красным флажком будут отмечены самые серьезные, такие как XSS, SQL Injection и так далее, оранжевым — менее серьезные уязвимости типа CSRF и остальные малозначимые.

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

При этом откроется попап, в котором будет расписано:


 что это за уязвимость и на что она влияет;
 ее критичность;
 скрипт, с которым она воспроизводится;
 литература о том, как можно починить ее.




Авторизация



Если в вашем проекте присутствует авторизация, то те ссылки, которые доступны для авторизированного пользователя, не будут доступны для OWASP ZAP без выполненной настройки юзера (бота), под которым наш сканер сможет зайти для выполнения поиска уязвимостей на тех страницах, которые доступны для авторизованного юзера. Для того чтобы быстро настроить этого юзера, кликаем по иконке встроенного браузера. При этом откроется сам браузер, в котором введены настройки прокси для обмена данными (request и response). То есть OWASP ZAP становится посредником, запросы, которые вы посылаете в браузере на сервер, сначала идут на OWASP ZAP, а с него — на сервер.

Так же происходит и в обратном порядке: ответ от сервера будет тоже сначала идти на OWASP ZAP, а уже с него — в браузер. Таким образом, вы сможете мониторить весь трафик. Затем выполните авторизацию на сайте, который собираетесь тестировать, через этот браузер.



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



Когда мы расхлопнем эту папку, мы увидим иерархию нашего приложения. Здесь мы и увидим наш запрос POST, с которым авторизовались. И если мы будем видеть, что, помимо нужного нам хоста, загрузились еще и другие ресурсы, которые интегрированы в наше веб-приложение, типа разных соцсетей, чтобы не тратить время на сканирование и их — так как нужно же проверять наш проект, а не другие :) — нам нужно задать «контекст» только для одной папки, которую мы хотим проверить. Для этого выбираем нужную папку и включаем ее в контекст.



После того как мы задали папке контекст, мы должны найти в ней запрос, который выполнялся на авторизацию, а затем создать юзера для этого метода, выбрав пункт «Использовать как контекст», а там — пункт Form-based.







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



В этом случае нам надо выбрать в первом ДД username, во втором — password. Нажимаем OK. На POST-запросе у вас появится иконка двери.

Затем надо создать самого бота (юзера), задать ему креденшелы, которые он будет вводить в те инпуты, настроенные нами ранее. Для этого заходим в раздел Users и в этом разделе добавляем нашего пользователя, который сможет авторизоваться.



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

Теперь нам надо показать OWASP ZAP какой-то локатор (XPath) на странице авторизованного юзера, чтобы сканер понимал, что авторизация прошла успешно. Для этого нам надо зайти на ответ, полученный от сервера, с HTML-разметкой, которую получает авторизованный юзер. Затем находим какой-то локатор, к которому привяжем наш сканер. Этот локатор OWASP будет искать после выполнения авторизации и понимать, успешно ли он прошел авторизацию на сайте.



Этот локатор вставляем в раздел аутентификации, в котором мы задавали параметры входа, — в инпут Regex pattern identified in Logged.



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



После этого в выпадающем списке находим нашего пользователя, под которым зайдет сканер.



И вуаля! Пошло сканирование вашего проекта на всевозможные уязвимости.

Но помните: никакая из программ не может гарантировать, что будут найдены все уязвимости. Найденные уязвимости могут быть и false-positive, то, что найдет сканер, по-любому надо проверять руками.

Подытожим

Теперь вы знаете:


 о двух уязвимостях;
 с помощью какого инструмента можно искать уязвимости;
 где можно практиковаться в поиске уязвимостей.


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

И помните: все показанное выше сделано в целях обучения! Применять на своих проектах можно только с разрешения.



Связь с владельцем
admin — Mon, 20 May 2019 15:18:55 GMT
sysanin@ukr.net


Web Push Changes to Chrome on Android
admin — Wed, 22 Nov 2017 10:27:41 GMT
https://onesignal.com/blog/web-push-changes-to-chrome-on-android/

On Dec 5th, the permission prompt for notifications in Chrome on Android devices will change from a the current slide-up browser prompt (left) to a full screen browser popup (right) --



Google is making this change to discourage websites from showing the browser notification permission prompt when users first visit a website.

What OneSignal is changing in response

For OneSignal clients that are currently showing the browser’s notification permission prompt when a user first loads a website, we will be introducing a OneSignal slide-up permission box. The browser’s new full-screen permission prompt will be shown only after a user clicks "Allow" on the OneSignal permission box.

This double opt-in can be seen in the following video:



This only affects users with devices running Chrome on Android. No changes are being made to other browsers or platforms at this time.

This change is intended to improve upon the initial user experience for users when they are prompted to grant or deny push permission to a website.

OneSignal supports customizing this slide-up prompt text and language - just follow these instructions to get started. Or, if you’d like to learn about other ways users can opt-in to notifications you can read more in our customizing permission prompts documentation.

For Wordpress users, all customization options are available in the OneSignal settings page in your Wordpress dashboard without needing to modify any code.


Первый тест-кейс с использованием TestNG
admin — Fri, 08 Sep 2017 10:41:27 GMT
http://autoqa.org/testng-framework/pervyj-test-kejs-s-ispolzovaniem-testng.html

Проделайте следующие шаги:

1) В контекстном меню созданного пакета выберите TestNG и выберите “TestNG Class”.



 

2) Назовите класс “TestNG”. Выберите следующие аннотации – “@BeforeMethod“, “@AfterMethod” и нажмите Finish.



 

3) Новосозданный класс должен выглядить следующим образом.



Время написать первый тест-кейс с помощью TestNG.

 

5) Воспользуемся тест-кейсом и разделим его на три части.

@BeforeMethod : Запуск Firefox и переход по URL

@Test : Ввод имени пользователя и пароля, отображение информации в консоле и Log out

@AfterMethod : Закрытие браузера




 
 
 
 1

 2

 3

 4

 5

 6

 7

 8

 9

 10

 11

 12

 13

 14

 15

 16

 17

 18

 19

 20

 21

 22

 23

 24

 25

 26

 27

 28

 29

 30

 31

 32

 33

 34

 35

 36

 37

 38

 39

 40

 41

 42

 43

 44

 45

 46

 47

 48

 49

 50

 51

 52

 53

 54

 55

 56

 57

 58

 59

 60

 61

 62

 63

 64

 65

 66

 67
 
 
 package automationFramework;

  

 import java.util.concurrent.TimeUnit;

  

 import org.openqa.selenium.By;

 import org.openqa.selenium.WebDriver;

 import org.openqa.selenium.firefox.FirefoxDriver;

 import org.testng.annotations.Test;

 import org.testng.annotations.BeforeMethod;

 import org.testng.annotations.AfterMethod;

  

 public class TestNG {

 public WebDriver driver;

 @Test

 public void main() {

 // Find the element that's ID attribute is 'user_login' (Username)

 // Enter Username on the element found by above desc.

 driver.findElement(By.id("user_login")).sendKeys("subscriber");

 // Find the element that's ID attribute is 'user_pass' (Password)

 // Enter Password on the element found by the above desc.

 driver.findElement(By.id("user_pass")).sendKeys("2016subscriberpasssword2016ok");

 // Now submit the form. WebDriver will find the form for us from the element

 driver.findElement(By.id("wp-submit")).click();

 if (driver.findElement(By.id("profile-page")).isDisplayed())

 {

 // Print a Log In message to the screen

 System.out.println("Login successfully.");

 }

 }

 @BeforeMethod

 public void beforeMethod() {

 // Create a new instance of the Firefox driver

 driver = new FirefoxDriver();

 //Put a Implicit wait, this means that any search for elements on the page could take the time the implicit wait is set for before throwing exception

 driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

 //Launch the Wordpress Admin site

 driver.get("http://autoqa.pp.ua/wp-admin");

 }

 @AfterMethod

 public void afterMethod() {

 // Close the driver

 driver.quit();

 }

 }
 
 
 






6) Запустите тест-кейс с помощью команды Run As -> TestNG Test.

 



Результаты запуска Testng тест-кейса

 

7) После завершения выполнения тест-кейса перейдите в окно результата запуска TestNg Result.



Он отображает “passed : 1″. Это означает, что тест-кейс выполнилcя успешно и Passed.

Еще есть три вкладки: “All Tests”, “Failed Tests” и “Summary”. Нажмите “All Tests”.



Здесь присутствует информация о том, какой метод запускался и время выполнения.

 

8) TestNG также генерирует HTML отчет. Чтобы его просмотреть, перейдите в директорию проекта и в папку test-output.

 

9) Откройте “emailable-report.html” в браузере.



 

10) TestNG также создает “index.html”, размещенный в папке test-output. Этот репорт позволяет перейти по ссылкам Groups и Reporter Output.






Установка sikuli
admin — Mon, 14 Dec 2015 14:14:21 GMT
Sikuli — это API позволяющая писать на Jython сценарии автоматизации опираясь на визуальную составляющую любой программы/сайта и т.д. Особенно приятна для автоматизации Flash.

 

Почитать можно тут http://www.sikuli.org/downloadrc3.html , но лучше сразу вот по этой инструкции:

 

 



 
 
 
 

 down vote
 
 
 
 Finally got this working, here is what I did,

 
 
 Download the sikuli set-up Jar from

 "https://launchpad.net/sikuli/sikulix/1.0.1/+download/sikuli-setup.jar"
 
 
 Save this jar in a folder 'SikuliSetup',now create a sub directory

 'Downloads' which will come into picture later.
 
 
 Run the above Jar, this will generate two files under the above directory.
 
 
 Now run the 'runSetup.bat' file generated from above setup. This will start the setup, now select the 4th and 6th option in the 'sikulisetup' pop-up and click on 'setup Now'.
 
 
 The above step will fail for most people due to default security issues.
 
 
 If the above step fails then you need to download an offline version of this jar from this URL

 "https://launchpadlibrarian.net/156273987/Sukuli-1.0.1-Offline-Setup-Java-option3-option4.zip".
 
 
 UnZip the above file and copy the '1.0.1-3.jar' file to 'Downloads'

 directory created under the 'SikuliSetup' directory previously.
 
 
 Now run the 'runSetup.bat' file again, this will generate a new jar file 'sikuli-java' and its dependent libraries under 'lib' folder.
 
 
 That's it, now copy this jar 'sikuli-java.jar' to your java build path in eclipse.
 
 
 Now Java will use this sikuli libraries without any issues.
 
 
 Once after you setup the jar file under build path, restart the

 system and login again.
 
 
 
 
 
 



http://stackoverflow.com/questions/29409094/how-to-generate-64-bit-version-of-sikuli-jar 

 

 


Операции в Java
admin — Thu, 16 Jul 2015 13:30:57 GMT
Операции

 

Над целочисленными типами

 


 операторы сравнения (>, <, >=, <=) и равенства (==, !=)
 унарные операторы (+, -)
 мультипликативные (*, /, %) и аддитивные (+, -) операторы
 инкремент (++) и декремент (--) в префиксной и постфиксной формах
 знаковые (>>, <<) и без знаковые (>>>) операторы сдвига
 побитовые операторы (~, &, ^, |)
 условный оператор (? : )
 оператор приведения типов


 

Над Floating-Point типами



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

 

Над логическим типом

 


 операторы равенства (== и !=)
 логические операторы (!,&, |, ^)
 условные логические операторы (&&, ||)
 условный оператор (? : )


 

Преобразование



Существует три типа преобразований:

 


 расширяющее преобразование (widening)
 суживающее преобразование (narrowing)
 widening + narrowing (преобразование byte к char, сначала byte преобразовываем в int, а потом int — в char)


 

Расширяющее преобразование



Если оба типа совместимы и длина целевого типа больше длины исходного типа выполняется расширяющее преобразование (напримерbyte преобразуется в int). Следующая таблица демонстрирует все возможные расширяющее преобразования. Курсовом помечены типы, преобразования в которые, возможно, приведут к потери данных.


 
 
 byte
 short, int, long, float, double
 
 
 short
 int, long, float, double
 
 
 char
 int, long, float, double
 
 
 int
 long, float, double
 
 
 long
 float, double
 
 
 float
 double (если использовать strictfp потери данных не будет)
 
 


Суживающее преобразование



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


 
 
 short
 byte, char
 
 
 char
 byte, short
 
 
 int
 byte, short, char
 
 
 long
 int, byte, short, char
 
 
 float
 long, int, byte, short, char
 
 
 double
 float, long, int, byte, short, char
 
 




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

 

byte a = (byte)128; // - 128
byte b = (byte)42; // привидение возможно, но, в данном случаи, в нем нет необходимости

int i1 = (int)1e20f; // 2147483647
int i2 = (int)Float.NaN; // 0

float f1 = (float)-1e100; // -Infinity
float f2 = (float)1e-50; // 0.0


 

Продвижение



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

 

int a = 100;
float b = 50.0f;
double c = 50.0;

double result = a - b + c; // 100.0
// на самом деле: result = (double)((float)a - b) + c;




Правила продвижения хорошо демонстрирует следующая диаграмма:

 



 

Классы-обертки



Для представления примитивных типов как объектов было сделаны классы-обертки (wrapper classes). Какие преимущества дают нам классы-обертки?

 


 возможность использования объектов классов-оберток в качестве параметров к методам или как generic-параметры
 возможность использования констант, которые отвечают за границы соответствующего типа данных (MIN_VALUE и MAX_VALUE)
 возможность использования методов для преобразования в другие примитивные типы, конвертации между системами счисления




Wrapper-классов восемь, по одному на каждый примитивный тип:


 
 
 Примитивный тип
 Класс-обертка
 
 
 boolean
 Boolean
 
 
 byte
 Byte
 
 
 char
 Character
 
 
 float
 Float
 
 
 int
 Integer
 
 
 long
 Long
 
 
 short
 Short
 
 
 double
 Double
 
 


Почти все классы (кроме Boolean и Character) унаследованы от абстрактного класса Number и являются сравнимыми (реализуют интерфейс Comparable). Иерархия, примерно, такая:



 

// существует несколько способов создания
Integer i1 = new Integer("10");
Integer i2 = new Integer(10);
Integer i3 = Integer.valueOf(10);
Integer i4 = Integer.valueOf("10", 10); // можно указать систему счисления, только для оберток целочисленных примитивных типов

Character c1 = new Character('c'); // тут только один способ

// получаем значения примитивных типов
int i5 = i1.intValue();
char c2 = c1.charValue();


 

Автоупаковка и распаковка



В версии JDK 5 были введены два важных средства:

 


 Автоупаковка (autoboxing) — процесс автоматического инкапсулирования примитивного типа в соответствующий класс-обертку. Отпадает необходимость явно создавать объект.
 Распаковка (unboxing) — процесс автоматического извлечения примитивного типа с соответствующего класса-обертки. Отпадает необходимость явного вызова метода для получения примитивного типа.




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

 

public static void main(String... s) {
 Integer i1 = 10; // автоупаковка - Integer.valueOf(10)
 int i2 = i1; // распаковка - i1.intValue()

 method(10); // автоупаковка в объект класса Integer - Integer.valueOf(10)

 ++i1; // распаковка - i1.intValue(), автоупаковка - Integer.valueOf(i1.intValue() + 1)
}

private static int method(Integer i) {
 return i; // распаковка объекта, принятого как параметр - i.intValue()
}


 

Некоторые полезные методы

 

Integer i1 = 128;
i1.compareTo(5); // 1, то есть i.intValue() > Integer.valueOf(5)

Integer.decode("0xabc"); // не работает с двоичными литералами
Integer.parseInt("10", 3); // работает с любой системой счисления [2, 36]

// метод преобразования
i1.byteValue(); // (byte)i.intValue()

// методы проверки
Float f = 20.5f;
Boolean badFloat = f.isInfinite() || f.isNaN(); // false, автоупаковка boolean

// преобразование в строку
f.toString();




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


Литералы
admin — Thu, 16 Jul 2015 13:30:05 GMT
Литералы



Значения примитивных типов данных в большинстве случаев инициализируются с помощью литералов. Рассмотрим их.

 

Целочисленные литералы



Наиболее часто используемые литералы. Любое целочисленное значение является числовым литералом (например, -10, 10 — десятичные значения). Можно использовать восьмеричные, шестнадцатеричные и двоичные литералы:

 

// десятичный литерал, числа [0, 9], не начинается с 0
int decimal = 10; // 10
// восьмеричный литерал начинается с 0, далее числа [0, 7]
int octal = 010; // 8
// шестнадцатеричный литерал начинается с 0x или 0Х, далее числа [0, 9] и символы [a-f]
int hexadecimal = 0x10; // 16
// двоичный литерал начинается с Оb или 0B, далее числа [0, 1]
int binary = 0b10; // 2




Все целочисленные литералы представляют значения int. Если значение литерала лежит в диапазоне byte, short или char, то его можно присвоить переменной этого типа без приведения типов. Для создания литерала типа long, необходимо явно указать компилятору, дополнив литерал буквой 'l' или 'L':

 

byte b1 = 127;
byte b2 = 128; // ошибка

short s1 = -32768;
short s2 = -32769; // ошибка

char c1 = 0;
char c2 = -1; // ошибка

long l1 = 10l;
long l2 = 0x7fffffffffffffffL; // максимальное значение типа long


 

Литералы с плавающей точкой



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

 

// стандартная форма
double d1 = 0.; // эквивалентно .0 или 0.0;
double d2 = 0.125;
// экспоненциальная форма - используется символ 'e' или 'E'
// после него степень числа 10, на которую следует умножить данное число
double d3 = 125E+10; // если степень положительная, '+' можно упустить
double d4 = 1.25e-10;




Всех литералам с плавающей точкой по-умолчанию присваивается тип double. Поэтому чтобы создать литерал типа float, нужно после литерала указать букву 'f' или 'F'. К литералам также можно добавлять букву 'd' или 'D', сообщая, что это литерал типа double, но зачем?

 

double d1 = 0.125;
float f2 = 0.125f;




Можно использовать шестнадцатеричные литералы с плавающей точкой, например:

 

// P - двоичный порядок, что обозначает степень числа 2, на которое следует умножить данное число
double d = 0x10.P10d; // конечно, можно и без 'd' 
float f = 0x20.P10f;




Для удобности чтения длинных литералов в 7 версии языка была добавлена возможность использовать символ '_' внутри литерала:

 

// можно делать любые комбинации с использованием любого количества символов '_'
int phone = 111__111__111;
int bin = 0b1000_1000_1000;
double dollars = 23_000.450__500;
// не допускается использовать символ '_' в конце или начале литерала, также не можно разрывать '0x' и '0b'


 

Символьные литералы



Символьные литералы заключаются в одинарные кавычки. Все отображаемые символы можно задавать таким способом. Если символ нельзя ввести непосредственно, используют управляющее последовательности начинающиеся с символа '\'. Хотя все эти последовательности можно заменить соответствующим Unicode кодом. Также символьный литерал можно создать используя восьмеричную ('\xxx') и шестнадцатеричную форму ('\uxxxx').

 

char h = 'a'; // стандартная форма
char a = '\001'; // восьмеричная форма
char c = '\u0001'; // шестнадцатеричная форма 




Существуют также строковые литералы. Информацию о них можно получить тут.

 

Логические литералы



С логическими операторами все просто. Существует только два логических литерала:

 

boolean yes = true; // истина
boolean no = false; // ложь




Логические литералы можно присваивать только переменным типа boolean. Также важно понимать, что false не равен 0, а true не равен 1. Преобразовать переменную типа boolean в другие примитивные типы не выйдет.


Примитивные типы в Java
admin — Thu, 16 Jul 2015 13:29:11 GMT
http://habrahabr.ru/post/261315/

Примитивные типы в Java — важная, часто используемая часть языка, которая требует особого обращения. В этой публикации попробуем ответить на все вопросы связанные с примитивными типами, механизмом их работы, обработкой. Статья предназначена как для новичков, которые только стали на тернистый путь изучения Java (к ним отношусь и я), так и для людей, достаточно знакомым с языком, которые смогут освежить знания и, надеюсь, найдут что-то интересное для себя.




 

Примитивные типы



Примитивные типы немного нарушают объектную ориентированность языка Java, так так представляют одиночные (простые) значения. Эта особенность объясняется желанием обеспечить максимальную эффективность. Создавать объект простой переменной с помощью new недостаточно эффективно, так как new перемещает объект в кучу. Вместо этого создается «автоматическая» переменная, которая не является ссылкой на объект. Переменная хранит единственное значение и располагается в стеке. Стек — это область хранения данных, расположена в RAM. Процессор имеет прямой доступ до этой области через указатель на стек, поэтому стек — очень быстрый и эффективный способ хранения данных. По скорости стек уступает только регистрам (логично, так как регистры расположены внутри процессора).

Все размеры примитивных типов строго фиксированы и не зависят от машинной архитектуры. Это одна с причин улучшенной переносимости Java-программ.

В Java определено восемь примитивных типов, которые можно разбить на четыре группы:


 
 
 Целые числа
 Числа с плавающей точкой
 Символы
 Логические значения
 
 
 byte, short, int, long
 float, double
 char
 boolean
 
 


Целые числа



Для целых чисел определены четыре примитивных типа: byte, short, int, long. Все эти типы представляют целочисленные значения со знаком: положительные или отрицательные. В Java нет положительных целочисленных значений без знака (unsigned). Как было сказано раньше, все размеры примитивных типов фиксированы:


 
 
 Тип
 Длина в байтах
 Длина в битах
 Диапазон
 
 
 byte
 1
 8
 [-128, 127] или [-2⁷, 2⁷-1]
 
 
 short
 2
 16
 [-32768, 32767] или [-2¹⁵, 2¹⁵-1]
 
 
 int
 4
 32
 [-2147483648, 2147483647] или [-2³¹, 2³¹-1]
 
 
 long
 8
 64
 [-9223372036854775808, 9223372036854775807] или [-2⁶³, 2⁶³-1]
 
 


Наименьшим целочисленным типом является byte. Переменные этого типа очень удобны для работы с потоками ввода-вывода и при манипулировании двоичными данными. Далее идет тип short, который применяется реже всех остальных типов. Наиболее часто употребляемым типом является int. Его постоянно используют в циклах, для индексации массивов. Может показаться, что использование типов byte и short в местах, где не требуется широкий диапазон значений, будет более эффективным чем использование int. Но это не так, потому что при вычислении выражений значения типа byte или short будут преобразованы в int (мы еще вернемся к этому вопросу). Когда длины типа int недостаточно для хранения значения, нужно использовать long. Его диапазон значений достаточно велик, что делает long удобным при работе с большими целыми числами.

 

Числа с плавающей точкой



Числа с плавающей точкой (или действительные числа) представлены типами float и double. Используются для хранения значений с точностью до определенного знака после десятичной точки.


 
 
 Тип
 Длина в байтах
 Длина в битах
 Диапазон
 
 
 float
 4
 32
 [1.4e^-45, 3.4028235e³⁸]
 
 
 double
 8
 64
 [4.9e^-324, 1.7976931348623157³⁰⁸]
 
 


Тип float определяет числовое значение с плавающей точкой одинарной точности. Этот тип используется, когда нужно числовое значение с дробной частью, но без особой точности. Тип double используется для хранений значений с плавающей точкой двойной точности. Обработка значений двойной точности выполняется быстрее, чем обработка значений одинарной точности. Поэтому большинство математических функций класса java.lang.Math возвращают значения типа double. Эффективнее всего использоватьdouble, когда требуется сохранить точность многократно повторяющихся вычислений или манипулировать большими числами.

 

Символы



В спецификации примитивный тип char принадлежит к целочисленным типам (или integral types), но поскольку он играет немного другую роль, можно выделить для него собственную категорию. Его роль — представлять символы Unicode. Для хранения символов требуется 16 бит. Странно, ведь для представления символов основных языков (например, английского, французского, испанского) достаточно 8 бит. Но такая цена интернационализации. Unicode использует полный набор международных символов на всех известных языках мира.


 
 
 Тип
 Длина в байтах
 Длина в битах
 Диапазон
 
 
 char
 2
 16
 ['\u0000', '\uffff'] или [0, 65535]
 
 


Логические азначения



Примитивный тип boolean предназначен для хранения логических значений. Данный тип может принимать одно из двух возможных значений: true (истина) или false (ложь). Значения boolean возвращаются со всех логических операций (например, операции сравнения). Является обязательным при построении циклов, операторов (например, for, if).

 

 


12 Tools That I Use for Writing Unit and Integration Tests
admin — Thu, 16 Jul 2015 12:09:08 GMT
http://www.petrikainulainen.net/programming/testing/12-tools-that-i-use-for-writing-unit-and-integration-tests/

I think that software development is more than just a job. I see myself as an artisan who is trying to get better every day. The “easiest way” to do this is to find a few good tools and find the answers to these questions:


 When should I use the tool X?
 How should I use the tool X?


Automated testing is a very important part of software development, but I haven’t seen a lot of blog posts that let you to take a peek into the toolbox of another developers.

This blog post lets you to take a peek into my toolbox. I will reveal 12 tools that I use for writing unit and integration tests. I will also provide links to other interesting webpages that help you to understand how you can use them.

Let’s get started.

Taking a Peek Into My Toolbox

Before we can use the tools that are described in this blog post, we have to create a build that can run both unit and integration tests. I have written two blog posts that describe how we can do this:


 Integration Testing with Maven describes how we can create a Maven build that has different directories for unit and integration tests.
 Getting Started With Gradle: Integration Testing With the TestSets Plugin describes how we can create a Gradle build that has different directories for unit and integration tests.


We are now ready to take closer look at my toolbox. I have divided my tools into different categories that makes this blog post easier to read.

I give you 12 tools that I use for writing unit and integration tests:

Running Tests

JUnit is a framework that I use for writing both unit and integration tests. I like JUnit because it is the most popular testing framework for Java programming language. In other words, it has a lot extensions and it is easy to find solutions to your problems.

NestedRunner is a JUnit runner that allows us to run test methods placed in nested inner classes. I like NestedRunner because of the following reasons:


 We can replace long method names with BDD style class hierarchy.
 We can remove duplicate code by moving that code to setup methods and putting these methods to the correct inner classes.
 We can link the constants with the test cases that use them by declaring the constants in the correct inner class.


junit-dataprovider is a JUnit runner that allows us to write parametrized tests by using a TestNG like data provider. This is a huge improvement over the default way of writing parametrized tests that pretty much sucks.

Additional Reading:


 Unit Testing with JUnit describes how we can write unit tests with JUnit 4.X.
 Writing Clean Tests: Small Is Beautiful describes how we can solve the problems found from “clean” unit tests.
 junit-dataprovider: Getting Started describes how we can start using junit-dataprovider.
 junit-dataprovider: Features describes the features of the junit-dataprovider.
 Alternative to JUnit Parametrized Classes: junit-dataprovider describes how we can replace the standard parametrized tests with tests that use the junit-dataprovider.


Mocking, Stubbing, and Faking Stuff

Mockito is the most popular mocking framework for writing unit tests. I like it because it has a simple API, a lot of useful features, and excellent documentation.

Greenmail is an in-memory email server that supports SMTP, POP3, and IMAP with SSL socket support. I like it because it is really easy to use. When I was looking for a “fake” email server, I tried several alternatives and Greenmail was the only one that worked as I wanted.

MockFtpServer is a library that provides two different FTP server implementations (fake/stub) that areuseful for testing different scenarios. If we need test code that interacts with a FTP server, MockFtpServer is our weapon of choice.

Additional Reading:


 Mockito Reference Manual is an excellent example of a reference documentation that actually helps you to get the job done.
 Integration Testing IMAP, SMTP and POP3 with Greenmail describes how you can write integration tests for code that sends email messages.
 FakeFtpServer – Getting Started describes how you can use the FakeFtpServer.
 StubFtpServer – Getting Started describes how you can use the StubFtpServer.
 FakeFtpServer or StubFtpServer? helps you to decide which FTP server implementation you should use in your tests.


Writing Assertions

Hamcrest provides matchers that we can use to write assertions for our unit and integration tests. I use it when I need to write assertions for unit or integration tests that use the Spring MVC Test framework.

AssertJ provides a fluent API for writing assertions that have helpful error messages. It improves the readability of our test code and helps us to transform our test cases into executable specifications that speak the correct domain-specific language.

Additional Reading:


 The Hamcrest Tutorial describes how you can get started with Hamcrest.
 Using Hamcrest for testing describes how you can use regular Hamcrest matchers in your unit tests and extend its capabilities by creating custom matchers.
 AssertJ Core Overview provides an overview to AssertJ Core.
 Turning Assertions Into a Domain-Specific Language describes how we can create custom AssertJ assertions.
 Writing Clean Tests: Replace Assertions With a Domain-Specific Language describes why we should replace regular JUnit assertions with custom assertions that use the correct domain-specific language.


Testing Data Access Code

H2 is a very fast in-memory database that is useful for writing integration tests that are run in the local development environment.

DbUnit is a JUnit extension that can be used to initialize the database into a known state before each integration test and ensure that the database contains the correct data. DbUnit has its warts, but it is a very useful tool because it helps us to separate the test data creation from the tested code.

Additional Reading:


 DbUnit Core Components describes the core components of DbUnit. If we want to write tests that use DbUnit, we should know what these components are.
 DbUnit Best Practices provides five rules that help us to write better tests for our data access code.
 Writing Tests for Data Access Code helps us to write deterministic data access tests which test the right thing, are easy to read, and easy to maintain.


Testing Spring Applications

Spring Test is the Swiss army knife of writing automated tests to Spring applications. It provides a first class support for writing unit and integration tests to Spring powered applications.

Spring Test DbUnit integrates DbUnit with the Spring Test Framework. If we need to write data access tests for a Spring application that uses relational database, Spring Test DbUnit helps us to do it.

Additional Reading:


 The Spring Framework Reference Manual: 11. Testing describes every feature of the Spring Test framework.
 Spring MVC Test Tutorial describes how we can write unit and integration tests for Spring MVC controllers.
 Spring Data JPA Tutorial: Integration Testing describes we you can write data access tests for our Spring powered repositories.
 Spring From the Trenches: Using Null Values in DbUnit Datasets describes how we can use null values in our DbUnit datasets when we are writing data access tests for a Spring application.
 Spring From the Trenches: Resetting Auto Increment Columns Before Each Test Method describes how we can reset the auto increment columns before each test method when we are writing data access tests for a Spring application.


What Testing Tools Do You Use?

I have now revealed the tools that I use for writing unit and integration tests. I challenge you to do the same. You can participate in this challenge by following these simple steps:


 If you have a blog, you can write a blog post and leave a comment to this blog post.
 If you don’t have a blog, you can leave a comment to this blog post.


Why should you do this?

Well, if helping other people isn’t enough for you, I promise to help you to get more readers by linking to your blog post, tweeting it, and sharing it with the Java Testing Society.

byte	short, int, long, float, double
short	int, long, float, double
char	int, long, float, double
int	long, float, double
long	float, double
float	double (если использовать strictfp потери данных не будет)

short	byte, char
char	byte, short
int	byte, short, char
long	int, byte, short, char
float	long, int, byte, short, char
double	float, long, int, byte, short, char

Примитивный тип	Класс-обертка
boolean	Boolean
byte	Byte
char	Character
float	Float
int	Integer
long	Long
short	Short
double	Double

Тип	Длина в байтах	Длина в битах	Диапазон
byte	1	8	[-128, 127] или [-2⁷, 2⁷-1]
short	2	16	[-32768, 32767] или [-2¹⁵, 2¹⁵-1]
int	4	32	[-2147483648, 2147483647] или [-2³¹, 2³¹-1]
long	8	64	[-9223372036854775808, 9223372036854775807] или [-2⁶³, 2⁶³-1]

Тип	Длина в байтах	Длина в битах	Диапазон
float	4	32	[1.4e^-45, 3.4028235e³⁸]
double	8	64	[4.9e^-324, 1.7976931348623157³⁰⁸]