тестирование. статьи. Виды Тестирования Программного Обеспечения Все виды тестирования программного обеспечения

Название	Виды Тестирования Программного Обеспечения Все виды тестирования программного обеспечения
Анкор	тестирование
Дата	06.04.2023
Размер	0.5 Mb.
Формат файла
Имя файла	статьи.docx
Тип	Рассказ #1043151

Виды Тестирования Программного Обеспечения

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

Функциональные
Нефункциональные
Связанные с изменениями

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

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:

Функциональное тестирование (Functional testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования

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

Все виды тестирования производительности:
- нагрузочное тестирование (Performance and Load Testing)
- стрессовое тестирование (Stress Testing)
- тестирование стабильности или надежности (Stability / Reliability Testing)
- объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)
Конфигурационное тестирование (Configuration Testing)
Тестирование безопасности (Security and Access Control Testing)

Связанные с изменениями виды тестирования

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

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Как искать баги — исследовательские туры Уиттакера

На моем курсе уже на второй день перед студентами стоит задача “Найти в системе 4 бага и оформить в баг-трекере”. Времени мало, работы много. Возникает разумный вопрос: “А как их искать, эти баги??”

Мне понятен этот вопрос. На первой работе я тестировала игры на мобильных телефонах. Про классы эквивалентности и граничные значения знать не знала, ведать не ведала. Мой начальник показывал мне, как играть в игрушку, и давал наставления: “Прочитай текст в инструкции, обязательно дойди до конца игры и посмотри на текст поздравления (о, как часто там находились баги на маленьких экранчиках Siemens, куда слово “Congratulations” просто не влезало!).

Тестирование игр на мобильных телефонах, у каждого
тестировщика на столе по несколько мобилок

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

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

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

А потом я стала тестировать систему, которую мы поддерживали несколько лет. Я изучила ее вдоль и поперек и… перестала видеть баги. Я внимательно проходила знакомый до боли сценарий и не видела проблем. А потом открывала bash.org и быстро сворачивала, когда мимо шагал начальник. В этот момент я тупо смотрела туда, куда внимательно вглядывалась 5 минут назад. И находила ошибку! Ошибку, которую не заметила за час тестирования! Это называется “замыленный взгляд” — проблема, которая мешает неначинающим тестировщикам находить баги.

Как сделать поиск багов систематическим? Джеймс Виттакер (James A. Whittaker) в книге “Exploratory Software testing” нашел выход и для новичков, и для экспертов.

Методика туров

Приложение — незнакомый город.

Тестировщик — турист.

Исследуйте ПО так, словно это — незнакомый город

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

Как пользоваться методикой

Выбрать тур из списка ниже.

Изучить его цели.

Поставить таймер на 2 часа (час, полчаса).

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

При необходимости повторить.

В каждом туре есть описание автора (низкий поклон Джеймсу за разрешение перевода и публикации) в вольном переводе + собственные примеры. Для примеров взят сайт Дадаты — https://dadata.ru.

Отправляемся в путь!

Компас — символ книги “Exploratory Software testing”.

Туры по деловому центру, Tours of the Business District

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

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

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

Тур по путеводителю. The Guidebook Tour

Денежный тур. The Money Tour

Тур по ориентирам. The Landmark Tour

Интеллектуальный тур, The Intellectual Tour

The FedEx Tour

Внеурочный тур, The After-Hour Tour

Тур сборщика мусора, The Garbage Collector Tour

Туры по историческим районам, Tours Through the Historical District

Исторические районы — части города, содержащие старые здания и достопримечательности. В Бостоне они разбросаны по всему городу и соединены только пешеходными тропами. В Кёльне есть "старый город" — одна часть города, которая не тронута современной экспансией.

В ПО исторические районы могут быть также слабо соединены, как в Бостоне или сосредоточены в одном месте, как в Кёльне. Исторические районы в ПО представляют собой:

унаследованный код (legacy code);
функции, созданные в предыдущих версиях;
исправления багов.

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

Туры по историческим районам проверяют старую функциональность и исправления ошибок.

Тур по плохому району, The Bad-Neighborhood Tour

Музейный тур, The Museum Tour

Тур предыдущей версии, The Prior Version Tour

Туры по развлекательным районам, Tours Through the Entertainment District

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

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

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

Тур актера второго плана, The Supporting Actor Tour

Тур глухого переулка. The Back Alley Tour

Тур полуночника. The All-Nighter Tour

Туры по туристическим районам, Tours Through the Tourist District

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

Туры по туристическим районам имеют несколько разновидностей. Это и короткие забеги для покупки сувениров, аналог кратких тест-кейсов для тестирования специфичных функций. Это и длинные поездки для посещения списка мест, которые хочется увидеть. Эти туры не о том, как заставить приложение работать, они о том, как посетить функциональность быстро… только чтобы сказать “мы тут были”!

ТУР КОЛЛЕКЦИОНЕРА. THE COLLECTOR`S TOUR

Тур одинокого бизнесмена, The Lonely Businessman Tour

Тур супермодели, The Supermodel Tour

The TOGOF Tour

Тур шотландского паба, The Scottish Pub Tour

Туры по отельным районам, Tours Through the Hotel District

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

ТУР, ОТМЕНЕННЫЙ ИЗ-ЗА ДОЖДЯ. THE RAINED-OUT TOUR

ТУР ДОМОСЕДА, THE COUCH POTATO TOUR

Туры по захудалым районам, Tours Through the Seedy District

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

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

ТУР САБОТАЖНИКА. THE SABOTEUR TOUR

Тур несоциального человека. The Antisocial Tour

Обсессивно-компульсивный тур, или тур невротика. The Obsessive-Compulsive Tour

Большое спасибо Джеймсу Виттакеру (James Whittaker aka @docjamesw) за разрешение на перевод и публикацию туров.

Здесь описана только одна глава из его книги “Exploratory Software testing”, рекомендую прочитать всю.

Большое спасибо Павлу Абдюшеву aka @ChipQA за помощь в переводе и редактуру текста.

Статья написана в помощь моим студентам, но будет полезна всем тестировщикам!

Следите за обновлениями ссылок в посте

Тестирование безопасности или Security and Access Control Testing

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

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

конфиденциальность
целостность
доступность

Конфиденциальность

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

Целостность

Существует два основных критерия при определении понятия целостности:

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

Доступность

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

Виды уязвимостей

В настоящее время наиболее распространенными видами уязвимости в безопасности программного обеспечения являются:

XSS (Cross-Site Scripting) - это вид уязвимости программного обеспечения (Web приложений), при которой, на генерированной сервером странице, выполняются вредоносные скрипты, с целью атаки клиента.
XSRF / CSRF (Request Forgery) - это вид уязвимости, позволяющий использовать недостатки HTTP протокола, при этом злоумышленники работают по следующей схеме: ссылка на вредоносный сайт устанавливается на странице, пользующейся доверием у пользователя, при переходе по вредоносной ссылке выполняется скрипт, сохраняющий личные данные пользователя (пароли, платежные данные и т.д.), либо отправляющий СПАМ сообщения от лица пользователя, либо изменяет доступ к учетной записи пользователя, для получения полного контроля над ней.
Code injections (SQL, PHP, ASP и т.д.) - это вид уязвимости, при котором становится возможно осуществить запуск исполняемого кода с целью получения доступа к системным ресурсам, несанкционированного доступа к данным либо выведения системы из строя.
Server-Side Includes (SSI) Injection - это вид уязвимости, использующий вставку серверных команд в HTML код или запуск их напрямую с сервера.
Authorization Bypass - это вид уязвимости, при котором возможно получить несанкционированный доступ к учетной записи или документам другого пользователя

Как тестировать ПО на безопасность?

Приведем примеры тестирования ПО на предмет уязвимости в системе безопасности. Для этого Вам необходимо проверить Ваше программное обеспечение на наличия известных видов уязвимостей:

XSS (Cross-Site Scripting)

Сами по себе XSS атаки могут быть очень разнообразными. Злоумышленники могут попытаться украсть ваши куки, перенаправить вас на сайт, где произойдет более серьезная атака, загрузить в память какой-либо вредоносный объект и т.д., всего навсего разместив вредоносный скрипт у вас на сайте. Как пример, можно рассмотреть следующий скрипт, выводящий на экран ваши куки:

либо скрипт делающий редирект на зараженную страницу:

либо создающий вредоносный объект с вирусом и т.п.:

Для просмотра большего количества примеров рекомендуем посетить страничку: XSS (Cross Site Scripting)...

XSRF / CSRF (Request Forgery)

Наиболее частыми CSRF атаками являются атаки использующие HTML тэг или Javascript объект image. Чаще всего атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт, таким образом, что при загрузке страницы осуществляется запрос, выполняющий вредоносный код. Примеры:

IMG SRC

SCRIPT SRC

Code injections (SQL, PHP, ASP и т.д.)

Вставки исполняемого кода рассмотрим на примере кода SQL.

Форма входа в систему имеет 2 поля - имя и пароль. Обработка происходит в базе данных через выполнение SQL запроса:

SELECT Username

FROM Users

WHERE Name = 'tester'

AND Password = 'testpass';

Вводим корректное имя ’tester’, а в поле пароль вводим строку:

testpass' OR '1'='1

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

SELECT Username

FROM Users

WHERE Name = 'tester'

AND Password = 'testpass' OR '1'='1';

Условие '1'='1' всегда будет истинным и поэтому SQL запрос всегда будет возвращать много значений.

Server-Side Includes (SSI) Injection

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

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

Authorization Bypass

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

Вывод

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