По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Хотим рассказать про операционную систему IOS, разработанную компанией Cisco. Cisco IOS или Internetwork Operating System (межсетевая операционная система) это программное обеспечение, которое используется в большинстве коммутаторов и маршрутизаторов Cisco (ранние версии коммутаторов работали на CatOS). IOS включает в себя функции маршрутизации, коммутации, межсетевого взаимодействия и телекоммуникаций, интегрированных в мультизадачную операционную систему.
Не все продукты Cisco используют IOS. Исключения составляют продукты безопасности ASA, которые используют операционную систему Linux и роутеры-маршрутизаторы, которые запускают IOS-XR. Cisco IOS включает в себя ряд различных операционных систем, работающих на различных сетевых устройствах. Существует много различных вариантов Cisco IOS: для коммутаторов, маршрутизаторов и других сетевых устройств Cisco, версии IOS для определенных сетевых устройств, наборы функций IOS, предоставляющие различные пакеты функций и сервисов.
Сам файл IOS имеет размер в несколько мегабайт и хранится в полупостоянной области памяти под названием flash. Флэш-память обеспечивает энергонезависимое хранилище. Это означает, что содержимое памяти не теряется, когда устройство теряет питание. Во многих устройствах Cisco IOS копируется из флэш-памяти в оперативное запоминающее устройство ОЗУ (RAM), когда устройство включено, затем IOS запускается из ОЗУ, когда устройство работает. ОЗУ имеет множество функций, включая хранение данных, которые используются устройством для поддержки сетевых операций. Работа IOS в ОЗУ повышает производительность устройства, однако ОЗУ считается энергозависимой памятью, поскольку данные теряются во время цикла питания. Цикл питания - это когда устройство намеренно или случайно отключается, а затем снова включается.
Управление устройствами с IOS происходит при помощи интерфейса командной строки (CLI), при подключении при помощи консольного кабеля, по Telnet, SSH либо при помощи AUX порта.
Названия версий Cisco IOS состоят из трех чисел, и нескольких символов a.b(c.d)e, где:
a – номер основной версии
b – номер младшей версии (незначительные изменения)
c – порядковый номер релиза
d – промежуточный номер сборки
e (ноль, одна или две буквы) – идентификатор последовательности выпуска программного обеспечения, такой как none (который обозначает основную линию), T (Technology), E (Enterprise), S (Service provider), XA специальный функционал, XB как другой специальный функционал и т. д.
Rebuild – часто ребилды выпускаются чтобы исправить одну конкретную проблему или уязвимость для данной версии IOS. Ребилды производятся либо для быстрого устранения проблемы, либо для удовлетворения потребностей клиентов, которые не хотят обновляться до более поздней крупной версии, поскольку они могут использовать критическую инфраструктуру на своих устройствах и, следовательно, предпочитают свести к минимуму изменения и риск.
Interim release – промежуточные выпуски, которые обычно производятся на еженедельной основе и образуют срез текущих наработок в области развития.
Maintenance release – протестированные версии, которые включают в себя усовершенствования и исправления ошибок. Компания Cisco рекомендует, по возможности, обновлять ПО до версии Maintenance.
Стадии развития:
Early Deployment (ED) – ранее развертывание, вводятся новые функции и платформы.
Limited Deployment (LD) – первоначальная лимитированная развертка, включают в себя исправления ошибок.
General Deployment (GD) – общее развертывание ОС, происходит тестирование, доработка и подготовка к выпуску окончательной версии. Такие выпуски, как правило, стабильны на всех платформах
Maintenance Deployment (MD) – эти выпуски используются для дополнительной поддержки, исправлений ошибок и постоянного обслуживания программного обеспечения.
Большинство устройств Cisco, которые используют IOS, также имеют один или несколько «наборов функций» или «пакетов» - Feature Set. Например, выпуски Cisco IOS, предназначенные для использования на коммутаторах Catalyst, доступны как «стандартные» версии (обеспечивающие только базовую IP-маршрутизацию), «расширенные» версии, которые предоставляют полную поддержку маршрутизации IPv4 и версии «расширенных IP-сервисов», которые предоставляют расширенные функции, а также поддержку IPv6.
Каждый отдельный feature set соответствует одной категории услуг помимо базового набора (IP Base – Static Routes, OSPF, RIP, EIGRP. ISIS, BGP, IMGP, PBR, Multicast):
IP-данные (Data – добавляет BFD, IP SLAs, IPX, L2TPv3, Mobile IP, MPLS, SCTP)
Голос (Unified Communications – CUBE, SRST, Voice Gateway, CUCME, DSP, VXML)
Безопасность и VPN (Security — Firewall, SSL VPN, DMVPN, IPS, GET VPN, IPSec)
Если вы забудете корректно настроить системное время на маршрутизаторах или коммутаторах Cisco, это может сыграть злую шутку. Просмотр лог – файлов или аудит в рамках безопасности может быть не реализуем, по причине невозможности установить точную дату события. В статье расскажем, как настроить корректную дату и время вручную, а также, как подключить NTP сервер к L2/L3 устройствам Cisco.
Ручная настройка
Устройства на базе Cisco IOS имеют два источника времени – железное/хардварное (hardware) и софтовое (программное) время. Первое, зачастую, в документации вендора именуется как «calendar time». Программное время, при загрузке девайса (по питанию) тянет время из железного, ставя его важнее в приоритете. Давайте проверим этот момент с помощью Cisco Packet Tracer:
en
show clock
Обратите внимание, в нашем выводе, *0:3:55.103 UTC Mon Mar 1 1993 помечена звездочкой сначала. Она говорит о том, что это время не вызывает доверия. Причина этого проста – оно синхронизировано с хардварного времени, это можно проверить командой show clock detail:
en
show clock
С помощью команды clock set (в привилегированном режиме, не в режиме глобальной конфигурации) мы можем в ручном режиме модифицировать время и дату:
en
conf t
clock set 13:12:00 23 august 2018
Обратите внимание, что источник времени сменился на «user configuration». Дело в том, что если мы перезагрузим наш девайс, время снова подтянется из хардварного источника (его можно проверить командой show calendar). Исправить это можно одной командой:
clock update-calendar
Готово :)
Лучший путь: настройка NTP
Дело в том, что бывают задачи, точность которых зависит от синхронизации сотых долей секунд на каждом из устройств в сети. В таком случае нам поможет синхронизация времени от единой точки по протоколу NTP (Network Time Protocol), а время они будут брать с NTP – сервера.
Перед настройкой, важно понять – откуда вы будете брать время. Есть некоторые публичные NTP, но конечно, гораздо безопаснее использовать сервер в собственном сетевом контуре. После того, как определитесь, приступаем к настройке NTP серверов:
en
conf t
ntp server 192.168.168.192
ntp server 192.168.168.193
Далее, мы уходим из среды Cisco Packet Tracer на железный маршрутизатор Cisco 2911, так как программный эмулятор ограничен в командах :)
Ждем, пока время не будет синхронизировано и проверяем:
Вы можете отслеживать этапы синхронизации командой show ntp associations - команда будет полезна для траблшутинга NTP;
show ntp status
У нас статус Clock is synchronized, stratum 2, reference is A.B.C.D. Значит все работает хорошо. Важно - настройка NTP, которую мы описали в статье, касается только софтового (программного) времени. Для того, чтобы синхронизировать хардварное (железное) время даем команду:
ntp update-calendar
Вы готовы к тому, чтобы узнать больше о различных видах тестирования программного обеспечения?
Как тестировщики, мы знаем о самых разных видах тестирования программного обеспечения. К ним относятся: функциональное тестирование, нефункциональное тестирование, автоматизированное тестирование, гибкое тестирование и их подвиды и другие.
Каждый из нас, изучая процесс тестирования, так или иначе сталкивался в несколькими видами тестирования. Вы могли слышать о некоторых из них или даже могли с ними работать, но маловероятно, что вы знаете обо всех видах тестирования, как и многие другие.
Каждый вид тестирования имеет свои характерные особенности, свои преимущества и недостатки. Тем не менее, в этой статье мы рассмотрели по большей части все виды тестирования программного обеспечения, которые мы используем на регулярной основе.
Давайте взглянем на них!!
Различные виды тестирования программного обеспечения
Ниже представлена общая классификация видов тестирования программного обеспечения.
Мы рассмотрим каждый вид во всех подробностях и приведем примеры.
Функциональное тестирование
Существует четыре основных вида функционального тестирования.
#1) Модульное тестирование
Модульное тестирование – это вид тестирования программного обеспечения, которое проводится на отдельно взятом модуле или компоненте, чтобы проверить внесенные правки. В большинстве случаев разработчики проводят модульное тестирование на этапе разработки приложения. В качестве модуля может выступать метод, функция, процедура или объект. Часто разработчики используют инструменты для автоматизации модульного тестирования, такие как NUnit, Xunit, JUnit.
Модульное тестирование – это важный этап разработки, поскольку на этапе модульного тестирования можно обнаружить большую часть ошибок.
Например, пусть у нас есть самое простое приложение-калькулятор. Разработчик может написать модульный тест для того, чтобы проверить правильность выполнения функций. Например, если пользователь введет два числа, будет ли верно посчитана сумма.
а) Тестирование методом «белого ящика»
Тестирование методом «белого ящика» – это методика тестирования, при которой тестировщику доступны внутренняя структура или код приложения. При таком подходе достаточно легко найти уязвимость в архитектуре приложения или недочеты в логике его функционирования. Примерами такой методики являются покрытие операторов и покрытие альтернатив/покрытие ветвей.
б) Gorilla Testing (Gorilla-тестирование)
Gorilla Testing – это методика тестирование, при которой тестировщик совместно с разработчиком (или отдельно от разработчика) досконально тестирует какой-либо конкретный модуль приложения со всех сторон. Gorilla Testing проводится для того, чтобы узнать, насколько ваше приложение устойчиво к сбоям.
Например, тестировщик тестирует сайт некой компании по страхованию домашних животных, которая предоставляет услугу покупки страхового полиса, жетона для питомца и пожизненного права членства. Тестировщик выбирает какой-то один модуль и концентрирует на нем свое внимание. Допустим, это модуль покупки страхового полиса. И он досконально тестирует его с помощью положительных и негативных сценариев тестирования.
#2) Интеграционное тестирование
Интеграционное тестирование – это разновидность тестирования программного обеспечения, при котором тестируются два и более сгруппированных модулей (как одно целое). При этом виде тестирования основной фокус внимания направлен на поиск неисправностей в интерфейсе, передаче данных и потоке данных между модулями. При интеграции модулей в систему используется либо нисходящий подход, либо восходящий.
Такой вид тестирования проводится при интеграции модулей системы или между системами. Например, пользователь приобретает билет на самолет на сайте любой авиакомпании. При покупке билета пользователи могут видеть информацию о рейсе и о платеже, но системы, которые предоставляют информацию о рейсе и обрабатывают платежи, - это две разные системы. Именно поэтому при интеграции веб-сайта авиакомпании и системы обработки платежей нужно проводить интеграционное тестирование.
а) Тестирование методом «серого ящика»
Из названия уже можно понять, что данная методика тестирования – это комбинация двух методик: тестирования методом «белого ящика» и тестирования методом «черного ящика». При таком подходе тестировщики видят внутреннюю структуру или код приложения только частично.
#3) Системное тестирование
Системное тестирование – это разновидность тестирования программного обеспечения, при котором тестировщику нужно проанализировать всю систему на соответствие определенным требованиям.
а) Сквозное тестирование
Методика сквозного тестирования подразумевает тестирование всей среды приложения в ситуации, близкой к реальной. Это может быть взаимодействие с базой данных, передач данных по сети или взаимодействие с другим оборудованием, приложениями или системами.
Например, тестировщику необходимо протестировать веб-сайт для страхования домашних животных. Сквозное тестирование подразумевает тестирование следующих аспектов: процесса покупки страхового полиса, жетона, функции добавления другого домашнего животного, обновления информации о кредитной карте в учетной записи пользователя, обновления информации об адресе пользователя, получения электронных писем с подтверждением заказа и условий договора страхования.
б) Тестирование методом «черного ящика»
Тестирование методом «черного ящика» – это методика тестирования программного обеспечения, при которой тестировщик не видит внутренней структуры, архитектуры или код тестируемой системы. Их задача – сосредоточиться лишь на вводе и выводе объектов тестирования.
в) Smoke-тестирование
Smoke-тестирование предназначено для проверки основных и критически важных функций тестируемой системы на предмет высокоэффективной работы.
Всякий раз, когда команда разработчиков предоставляет новую сборку, команда тестировщиков программного обеспечения должна проверить сборку и гарантировать, что в ней нет никаких серьезных проблем. Когда команда тестировщиков подтвердит стабильность сборки, будет проведено более детальное тестирование.
Например, тестировщику необходимо протестировать веб-сайт для страхования домашних животных. Основные функции данного сайта – покупка страхового полиса, добавление еще одного домашнего животного и предоставление расценок. С помощью smoke-тестирования можно проверить, все ли эти функции работают полноценно, прежде чем переходить к более детальному тестированию.
г) Санитарное тестирование
Санитарное тестирование проводится для того, чтобы убедиться, что все новодобавленные функции и правки в систему работают отлично. Санитарное тестирование проводится только на стабильной сборке. Этот вид тестирования является разновидностью регрессионного тестирования.
Например, тестировщику необходимо протестировать веб-сайт для страхования домашних животных. Были внесены изменения касательно скидки на покупку полиса на второго домашнего животного. Тогда санитарное тестирование проводится лишь для модуля покупки страхового полиса.
д) Happy-path-тестирование
Happy-path-тестирование сосредоточено на тестировании потоков «положительной логики» приложения. При таком тестировании не ищутся условия возникновения негативных последствий или ошибок. Основное внимание уделяется только корректным входным данных, которые влекут за собой положительные сценарии и, получая которые, приложение выдает ожидаемый результат.
е) Бездумное тестирование (Monkey Testing)
Тестировщик проводит бездумное тестирование, предполагая, что приложение будет использовать обезьяна, то есть вводить данные будет именно обезьяна, не знающая ничего и не понимая принцип работы приложения.
Цель бездумного тестирования – проверить, произойдет ли сбой приложения или системы при случайных входных данных. Бездумное тестирование выполняется случайным образом, тестовые случаи нигде не фиксируются, а также для проведения такого тестирования не нужно знать о том, как функционирует система.
#4) Приёмочное тестирование
Приёмочное тестирование – это разновидность тестирования программного обеспечения, при котором клиент/предприятие/заказчик тестируют программное обеспечения с помощью реальных бизнес-сценариев.
Клиент принимает программное обеспечение только в том случае, если все функции работают так, как надо. Приёмочное тестирование – это последний этап, после которого программное обеспечение отправляется в производство. Его еще называют пользовательское приёмочное тестирование (UAT - User Acceptance Testing).
а) Альфа-тестирование
Альфа-тестирование – это разновидность приёмочного тестирования. Оно проводится командой от организации для того, чтобы выявить как можно больше неполадок перед тем, как программное обеспечение будет выпущено.
Например, сайт страхования домашних животных проверяется с помощью UAT. Команда UAT будет прогонять реальные сценарии, такие как покупка страхового полиса, покупка годового права на членство, изменение адреса пользователя, передача права собственности на домашнее животное. Все будет происходить так, как если бы реальный пользователь использовал настоящий веб-сайт. Для прогона сценариев, связанных с платежами, команда может использовать данные тестовой кредитной карты.
б) Бета-тестирование
Бета-тестирование – это разновидность тестирования программного обеспечения. Его проводят клиент/заказчики. Бета-тестирование проводится в реальной среде перед выпуском продукта на рынок, где его смогут приобрести реальные конечные пользователи.
Бета-тестирование необходимо для того, чтобы убедиться, что в программном обеспечении или продукте не происходят какие-то серьезные сбои и что оно удовлетворяет всем требованиям с позиции конечного пользователя со стороны заказчика. Считается, что бета-тестирование прошло успешно, если клиент принял программное обеспечение.
Как правило, бета-тестирование проводится непосредственно конечными пользователями. Это тестирование является последним перед выпуском приложения для коммерческого использования. В большинстве случаев бета-версия программного обеспечения используется ограниченным числом пользователей и в конкретной области.
Выходит, что конечный пользователь использует программное обеспечение, составляет отчет об ошибках и отправляет его компании. И затем, прежде чем выпустить программное обеспечение в общемировых масштабах, компания должна решить эти проблемы.
в) Эксплуатационное приёмочное тестирование (OAT - Operational acceptance testing)
Эксплуатационное приёмочное тестирование системы выполняется либо группой эксплуатации, либо системными администраторами в среде промышленной эксплуатации. Цель такого тестирования – убедиться в том, что системные администраторы в состоянии обеспечить корректную работу системы для пользователей в реальных условиях.
OAT сосредоточено на следующих моментах:
тестирование резервного копирования и восстановления;
установка, удаление и обновление программного обеспечения;
процесс восстановления в случае катастрофы природного характера;
пользовательское управление;
сопровождение программного обеспечения.
Нефункциональное тестирование
Существует четыре основных вида нефункционального тестирования.
#1) Тестирование безопасности
Тестирование безопасности проводится специальной командой. Любые несанкционированные действия хакеров могут преодолеть защиту системы.
Тестирование безопасности необходимо для проверки программного обеспечения, приложения или веб-сайта на предмет хорошей защиты от внутренних и/или внешних угроз. Это тестирование включает в себя проверку того, насколько программное обеспечение защищено от различного рода вредоносных программ, вирусов, а также насколько безопасны и надежны процессы авторизации и аутентификации.
Помимо всего прочего, тестирование безопасности позволяет узнать, как программное обеспечение ведет себя при различных хакерских атаках и при внедрении вредоносных программ, а также как обеспечивается безопасность данных после такой хакерской атаки.
а) Тестирование на возможность проникновения в систему
Тестирование на возможность проникновения в систему – это разновидность тестирования безопасности. Оно проводится путем санкционированной кибератаки на систему. Его цель – выявить слабые места системы с точки зрения безопасности.
Тестирование выполняется привлеченными третьими лицами (исполнителями), которые также известны как «белые хакеры». Соответственно, данный вид тестирования еще можно назвать «этичным взломом». Исполнители выполняют различные операции, такие как SQL-инъекции, подтасовки URL-адресов, повышение привилегий, завершение сеанса, после чего предоставляют организации отчет.
Примечание: Никогда не проводите тестирование на возможность проникновения в систему на своем ноутбуке/компьютере. Для проведения тестирования на возможность проникновения в систему у вас обязательно должно быть письменное согласие.
#2) Тестирование рабочих характеристик
Тестирование рабочих характеристик – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки.
«Стабильность» - это способность приложения выдерживать ту или иную нагрузку. «Время отклика» - то, как быстро пользователи могут начать пользоваться приложением. Тестирование рабочих характеристик проводится с помощью специальных инструментов, например, Loader.IO, JMeter, LoadRunner и т.д.
а) Нагрузочное тестирование
Нагрузочное тестирование – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки, эквивалентной тому, что приложение будут использовать такое количество пользователей, которое было предусмотрено или меньшее.
Например, ваше приложение может обслуживать 100 пользователей одновременно с временем отклика 3 секунды. Тогда мы можем провести нагрузочное тестирование с применением нагрузки, эквивалентной 100 и менее пользователям. Целью такого тестирования является гарантия того, что приложение отвечает всем пользователям в течение 3 секунд.
б) Стресс-тестирование
Стресс-тестирование – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки, эквивалентной тому, что приложение будут использовать количество пользователей, превышающее предусмотренное.
Например, ваше приложение может обслуживать 1000 пользователей одновременно с временем отклика 4 секунды. Тогда мы можем провести стресс-тестирование с применением нагрузки, эквивалентной более чем 1000 пользователям. Протестируйте приложения, приложив нагрузку в 1100, 1200, 1300 пользователей, и посмотрите на время отклика. Цель данного тестирования заключается в проверке стабильности приложения при стрессовой нагрузке.
в) Тестирование масштабируемости
Тестирование масштабируемости – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки, эквивалентной тому, что приложение будут использовать количество пользователей, превышающее предусмотренное.
Например, ваше приложение может обслуживать 1000 пользователей одновременно с временем отклика 2 секунды. Тогда мы можем провести тестирование масштабируемости с применением нагрузки, эквивалентной более чем 1000 пользователям. Постепенно увеличивая нагрузку, можно выяснить, когда приложение даст сбой.
Допустим время отклика для моего приложения для различной нагрузки следующее:
1000 пользователей – 2 секунды
1400 пользователей – 2 секунды
4000 пользователей – 3 секунды
5000 пользователей – 45 секунд
5150 пользователей – сбой – Именно этот момент мы определяем при проведении тестирования масштабируемости
г) Объемное тестирование (тестирование большим количеством запросов)
Объемное тестирование - это проверка стабильности приложения и времени отклика системы с помощью отправки большого количества данных в базу данных. Фактически, с помощью этого тестирования можно проверить способность базы данных обрабатывать данные.
д) Тестирование износостойкости (продолжительное тестирование)
Тестирование износостойкости - это проверка стабильности приложения и времени отклика системы при непрерывном прикладывании нагрузки в течение длительного периода времени. Цель этого тестирования – убедиться, что приложение работает хорошо.
Например, аналогичные тесты проводят автомобильные компании с целью убедиться, что водитель сможет управлять автомобилем в течение нескольких часов без остановок, и это не повлечет никаких проблем.
#3) Тестирование практичности
Тестирование практичности – это тестирование приложения с позиции пользователя. Его цель – определить впечатления и ощущения от использования приложения, а также проверить, удобно ли взаимодействовать пользователю с приложением.
Например, есть какое-то мобильное приложение для торговли на бирже. Тестировщик проводит тестирование практичности для данного приложения. Он может проверить самые различные сценарии, например, удобно ли пользоваться мобильным приложением, используя лишь одну руку или нет, удобно ли, что полоса прокрутки вертикальная, не отталкивает ли тот факт, что цвет фона черный, а цены и названия акций отображаются красным или зеленым цветом.
Основная идея тестирования практичности таких приложений состоит в том, чтобы, когда пользователь открывал приложение, он видел все, что необходимо.
а) Исследовательское тестирование
Исследовательское тестирование – это обычное тестирование, которое проводит команда тестировщиков. Цель этого тестирования – анализ приложения и поиск неисправностей. Для того, чтобы проводить такие тестирования, тестировщикам нужны знания предметной области. Для руководства исследовательским тестированием используются концепции тестирования.
б) Кросс-браузерное тестирование
Кросс-браузерное тестирование – это тестирование приложения в различных браузерах, на разных операционных системах и мобильных устройствах с целью оценить впечатление и ощущение от использования приложения и его производительность.
Для чего нужно кросс-браузерное тестирование? Ответ прост: разные пользователи используют разные операционные системы, разные браузеры и разные мобильные устройства. Целью любой компании является обеспечить приятное впечатление от использования приложения независимо от того, на каком устройстве оно установлено.
Такой инструмент, как Browser Stack, позволяет протестировать приложение на всех версиях различных браузеров и всех мобильных устройствах. В ознакомительных целях можно воспользоваться бесплатной пробной версией Browser Stack (она предоставляется на несколько дней).
в) Тестирование доступности использования
Цель тестирования доступности использования – определить, могут ли люди с ограниченными возможностями использовать программное обеспечение или приложение.
Здесь под понятием «ограниченные возможности» понимается следующее: нарушение слуха, неспособность различать цвета (дальтонизм), умственные недостатки, слепота, пожилой возраст и другие инвалидные группы. Данный вид тестирования подразумевает проверку размера шрифта (подходит ли он для слабовидящих), проверку цвета и контрастности картинки (для людей с нарушением восприятия цвета) и т.д.
#4) Тестирование совместимости
Когда проводится тестирование совместимости, проверяется то, как программное обеспечение ведет себя и как оно работает в другой среде, на других веб-серверах, на другом оборудовании и в другой сетевой среде.
Тестирование совместимости гарантирует, что программное обеспечение может работать в различных конфигурациях, с разными базами данных, в разных браузерах и их версиях. Тестирование совместимости должна проводить группа тестировщиков.
Другие виды тестирования
Свободное тестирование
Название само по себе подразумевает, что данное тестирование выполняется бессистемно, то есть без какого-либо набора тестовых данных, а также без какого-либо плана или документации.
Цель свободного тестирования – выявить изъяны и «сломать» приложение путем выполнения любых действий в приложении.
Свободное тестирование – это способ поиска неисправностей без каких-либо формальностей. Это тестирование может провести любой участник проекта. Конечно, непросто выявить какие-то ошибки без тестовых данных, но иногда ошибки, которые были обнаружены с помощью свободного тестирования, могли быть не найдены с помощью существующий тестовых наборов.
Backend-тестирование
Каждый раз, когда данные вводятся в клиентской части приложения, они сохраняются в базе данных, и ее тестирование так и называется – тестирование базы данных, или backend-тестирование.
Существует много разных баз данных, таких как SQL Server, MySQL, Oracle и т.д. Тестирование базы данных подразумевает тестирование структуры таблиц, схемы, хранимой процедуры, структуры данных и т.д. При backend-тестировании тестировщики не используют графический интерфейс, они подключаются к базе данных напрямую с надлежащим доступом. Тем самым они могут с легкостью проверять данные с помощью всего нескольких запросов к базе.
В процессе backend-тестирования могут быть выявлены такие проблемы, как потеря данных, зависание программы, повреждение данных и т.д. Все эти проблемы обязательно должны быть устранены до того, как система будет запущена в производство.
Тестирование совместимости браузера
Это разновидность тестирования совместимости (которое описано ниже). Тестирование совместимости браузера проводится командой тестировщиков.
Тестирование совместимости браузера необходимо для веб-приложений. Оно гарантирует, что программное обеспечение сможет работать с любыми браузерами и операционными системами. С помощью этого тестирования также можно проверить, будет ли работать приложение во всех версиях различных браузеров.
Тестирование обратной совместимости
Тестирование обратной совместимости позволяет убедиться, что недавно разработанное или обновленное программное обеспечение будет хорошо работать в старой версии среды.
Тестирование обратной совместимости позволяет проверить, правильно ли работает новая версия программного обеспечения с файлами, которые были созданы более старой его версией. К проверяемым файлам относятся таблицы данных, файлы данных и структуры данных, которые были созданы более старой версией программного обеспечения. Если программное обеспечение было обновлено, то оно должно хорошо работать со своими предыдущими версиями.
Тестирование методом «черного ящика»
При таком тестировании внутренняя структура системы не учитывается. Все тесты основываются только на требованиях и функциональных характеристиках.
Тестирование граничных значений
Это тестирование проверяет, как ведет себя приложение на пограничном уровне.
Тестирование граничных значений необходимо для того, чтобы выявить изъяны на граничных значениях. Оно используется для тестирования различных диапазонов чисел. Для каждого такого диапазона есть верхняя и нижняя границы, и тестирование проводится именно на этих граничных значениях.
Если тестовый диапазон от 1 до 500, то тестирование граничных значений выполняется для значений 0, 1, 2, 499, 500 и 501.
Тестирование ветвей
Тестирование ветвей также известно, как «покрытие ветвей» или «покрытие альтернатив». Это разновидность тестирования методом «белого ящика» – одно из модульных тестирований. Он необходим для того, чтобы каждый возможный путь от точки принятия решений выполнился хотя бы один раз для 100% тестового покрытия.
Пример:
Read number A, B
If (A>B) then
Print(“A is greater”)
Else
Print(“B is greater”)
Здесь есть две ветки – if и else. Для 100% покрытия нам нужно провести 2 теста с разными значениями А и В.
Тест №1: А=10, В=5. Этот тест охватит ветвь if.
Тест№2: А=7, В=15. Этот тест охватит ветвь else.
Сравнительное тестирование
Сравнительное тестирование – это сравнение сильных и слабых сторон продукта с его предыдущими версиями или другими подобными продуктами.
Эквивалентное разбиение
Это разновидность тестирования методом «черного ящика». Для проведения этого тестирования выбирается набор групп и несколько значений или чисел. При этом вполне понятно, что все значения из этой группы генерируют один и тот же результат.
Цель данного тестирования – исключение тестовых наборов данных из определенных групп, которые генерируют один и тот же результат, но при этом не выявляют никаких неисправностей.
Допустим, что приложение принимает значения от -10 до +10. Затем для эквивалентного разбиения выбираются значения: ноль, одно положительное значение и одно отрицательное значение. И таким образом, эквивалентное разбиение для данного теста будет таким: от -10 до -1, 0 и от 1 до 10.
Типовое тестирование
Типовое тестирование – это тестирование в реальных условиях. Оно подразумевает использование реальных сценариев и сценариев, основанных на опыте тестировщиков.
Такой вид тестирования также известен, как «тестирование на основе опыта», поскольку здесь требуются определенный опыт тестироващика, например, он должен знать о том, как приложение работало раньше, как можно «сломать» приложение и какие ошибки могут быть в приложении такого типа.
Тестирование графического пользовательского интерфейса (GUI - Graphical User Interface)
Цель тестирования GUI – убедиться, что графический интерфейс соответствует всем бизнес-требованиям. Графический интерфейс приложения, который хочет видеть заказчик, описан в рабочей документации и изображен на макете.
Тестирование GUI включает в себя следующее: проверка размера кнопок и полей ввода, размещенных на экране, выравнивание текста, таблиц и содержимого в таблицах.
С помощью данного тестирования также можно проверить меню приложения. Меню необходимо проверять для того, чтобы убедиться, что при выборе меню или подменю страница не съезжает, а при наведении курсора мыши на меню или подменю выравнивание не исчезает.
Тестирование поэлементной компоновки
Тестирование поэлементной компоновки – это тестирование с восходящим подходом, то есть это непрерывное тестирование приложения с добавлением новых функций.
При этом функции и модули должны быть достаточно независимы, чтобы их можно было тестировать и отдельно друг от друга. Это тестирование проводят либо программисты, либо тестировщики.
Тестирование настройки/удаления приложения
Тестирование настройки приложения выполняется для того, чтобы убедиться, что приложение может быть установлено и настроено и работает так, как должно. Это тестирование – это этап тестирования, который предшествует первому взаимодействию пользователей с реальным приложением. Тестирование настройки приложения еще называют «предэксплуатационным тестированием».
Тестирование удаления приложения выполняется для того, чтобы убедиться, что после удаления все компоненты программного обеспечения будут удалены из системы.
Данные виды тестирования выполняются для полных, частичных или обновленных процессов настройки/удаления приложения в разных операционных системах и в разных аппаратных или программных средах.
Мутационное тестирование
Мутационное тестирование – это разновидность тестирования методом «белого ящика», при котором меняется исходный код программы, а затем проверяется, способны ли существующие тестовые примеры выявить ошибки в системе.
Изменения в исходном коде не столь значительны, поэтому они не влияют на все приложение, только на его отдельную часть, и тестовые примеры должны уметь выявлять эти ошибки в системе.
Негативное тестирование
Установка тестировщика очень проста: «Необходимо сломать систему/приложение». Это можно сделать с помощью негативного тестирования.
Методика негативного тестирования заключается в том, что тестировщик вводит неверные или недопустимые данные и проверяет, выдает ли система ошибку неверного ввода.
Загрузка любой страницы или системы не должна занимать много времени и должна поддерживаться даже при пиковой нагрузке. Для этого тестирования используются различные средства оценки производительности и нагрузки.
Тестирование восстановления
Это разновидность тестирования, которое проводят для того, чтобы проверить, как хорошо приложение или система восстанавливаются после сбоев или аварий.
Тестирование восстановления определяет, способна ли будет система продолжить свою работу после аварийной ситуации. Допустим, что приложение получает данные через сетевой кабель, и вдруг этот сетевой кабель был отключен.
Через какое-то время сетевой кабель подключают обратно; система должна снова начать получать данные оттуда, откуда получала ранее до потери связи.
Регрессионное тестирование
Регрессионное тестирование – это тестирование неизменяемых функций приложения. Оно необходимо для того, чтобы убедиться, что любые правки, добавление любых новых функций, удаление или обновление уже существующих функций не повлияет на работу приложения.
Важная часть регрессионного тестирования - определение границ регрессии. Для того, чтобы выделить эти границы регрессии, тестировщик должен определить границы приложения, в которых произошли те или иные изменения, и то, как эти изменения повлияли на приложение.
Тестирование на базе рисков
При данном виде тестирования тестируются функциональные характеристики или требования, исходя из их приоритета. Тестирование на базе рисков включает в себя тестирование критически важных функциональных характеристик, от которых в большей степени зависит коммерческая деятельность и вероятность сбоя которых достаточно велика.
Решения о приоритете основываются на потребностях компании-заказчика. Как только приоритет будет установлен для всех функций, начинается тестирование функций сначала с высоким приоритетом, затем – со средний, а после – с низким.
Функции с низким приоритетом могут и не тестироваться вовсе (все зависит от времени, которым располагает тестировщик). Тестирование на базе рисков проводится тогда, когда на тестирование всего программного обеспечения не так много времени, но при этом его необходимо выпустить вовремя.
Этот подход должен быть утвержден клиентом и высшим руководством организации.
Статическое тестирование
Статическое тестирование – это разновидность тестирования, которое не требует выполнения кода. Критический просмотр, пошаговый разбор и инспектирование – вот методы проведения статического тестирования. Статическое тестирование должны пройти такие вещи, как просмотр рабочей документации, спецификации требований заказчика, архитектура высокого и низкого уровня, синтаксис кода, стандарты присвоения имен переменным и т.д.
Статическое тестирование также применяется к тестовым примерам, планам и сценариям. Оно проводится для того, чтобы предотвратить появление ошибки, а не выявлять ее на более позднем этапе. Именно поэтому статическое тестирование оправдывает затраты на него.
Например, тестировщик тестирует веб-сайт для страхования домашних животных. Логика расчета стоимости услуг описана в документации. В рамках статического тестирования тестировщик может просмотреть код разработчика, который предназначен для расчета стоимости, и сравнить его с документацией, чтобы предотвратить ошибку в расчете.
Тестирование чувствительности к воздействие внешних факторов
Тестирование чувствительности к воздействию внешних факторов – это тестирование, которые подразумевает выявление слабых мест в программном обеспечении, оборудовании и сети. С помощью вредоносны программ хакер может получить контроль над системой, если она уязвима для такого рода атак, вирусов и «червей».
Перед выпуском приложения, необходимо убедиться, что оно прошло это тестирование, поскольку оно может обнаружить опасные для системы бреши в безопасности.
Заключение
Все вышеупомянутые разновидности тестирования программного обеспечения – лишь часть всего процесса тестирования.
Все-таки есть еще более 100 видов тестирований, но они используются не для всех типов проектов. Здесь мы рассмотрели самые распространенные виды тестирования программного обеспечения; именно их в основном используют в процессе тестирования.
Помимо всего прочего, существуют альтернативные понятия и процессы, которые используются в различных организациях, но основная идея везде одинакова. Все эти виды тестирования, процессы и методы их реализации постоянно меняются по мере того, как меняется проект, требования и область.