По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вы готовы к тому, чтобы узнать больше о различных видах тестирования программного обеспечения?
Как тестировщики, мы знаем о самых разных видах тестирования программного обеспечения. К ним относятся: функциональное тестирование, нефункциональное тестирование, автоматизированное тестирование, гибкое тестирование и их подвиды и другие.
Каждый из нас, изучая процесс тестирования, так или иначе сталкивался в несколькими видами тестирования. Вы могли слышать о некоторых из них или даже могли с ними работать, но маловероятно, что вы знаете обо всех видах тестирования, как и многие другие.
Каждый вид тестирования имеет свои характерные особенности, свои преимущества и недостатки. Тем не менее, в этой статье мы рассмотрели по большей части все виды тестирования программного обеспечения, которые мы используем на регулярной основе.
Давайте взглянем на них!!
Различные виды тестирования программного обеспечения
Ниже представлена общая классификация видов тестирования программного обеспечения.
Мы рассмотрим каждый вид во всех подробностях и приведем примеры.
Функциональное тестирование
Существует четыре основных вида функционального тестирования.
#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 видов тестирований, но они используются не для всех типов проектов. Здесь мы рассмотрели самые распространенные виды тестирования программного обеспечения; именно их в основном используют в процессе тестирования.
Помимо всего прочего, существуют альтернативные понятия и процессы, которые используются в различных организациях, но основная идея везде одинакова. Все эти виды тестирования, процессы и методы их реализации постоянно меняются по мере того, как меняется проект, требования и область.
Когда администратор является единственным администратором АТС, то проблем с выяснением причин кто и что сломал не возникает, так как административный аккаунт один и им пользуется только один человек.
А вот когда администраторов много, да ещё необходимо разграничивать права доступа в зависимости от выполняемых обязанностей, тогда как раз и встает вопрос о персональных аккаунтах для администраторов.
Для этого можно создавать как персональные профайлы (под единичные доступы), так и групповые (например, для сотрудников, выполняющих ограниченные функции – проверка состояния транков, создание абонентов, настройка Call Center и так далее).
Стоит заметить, что первые 19 профайлов являются системными и их менять или удалять не стоит. Для новых профайлов следует использовать номера с 20.
Выполнение в терминале или консоли GEDI
Для начала надо создать новый профайл командой:
add user-profile-by-category НОМЕР
или
add user-profile НОМЕР
В открывшемся окне выставляем параметры, которые нам необходимы.
User Profile Name – имя профайла. Служит для идентификации уровня доступа (имя пользователя или имя группы пользователей, для которых и создается данный профайл).
Shell Access? – разрешен ли данному профайлу доступ в командную строку системы
В терминале это выглядит так:
А в консоли GEDI это будет немного поудобнее, тем более, что выставление параметров можно выполнять при помощи мыши, при этом по нажатию правой кнопки показывается подсказка по значениям в конкретном поле:
На первой странице выставляются общие (групповые для функций) права на доступ. Более детальные разрешения выставляются на последующих страницах. Однако без выставления прав на группу нельзя выставить права на функцию, входящую в эту группу.
Например, нельзя разрешить настраивать абонентов или транки, не разрешив при этом группу Maintenance (G) на первой странице. Но можно разрешить доступ только к абонентам, но запретив доступ к транкам.
Чтобы не открывать все группы, можно найти необходимую функцию, посмотреть в какую группу (категорию) входит данная функция и на первой странице разрешить именно эту группу.
Разрешение r позволяет только просматривать без возможности создания или внесение изменений в настройки.
Разрешение w дополнительно позволяет ещё и создавать, изменять и удалять настройки.
Разрешение m позволяет выполнять дополнительные действия по обслуживанию (трассировки, включение/выключение абонентов или транков и так далее)
Обычно создают профайл для полного доступа администраторов (с включением всех групп (категорий) и правами доступа wm) и профайлы с ограниченным доступом для других пользователей, выполняющих некоторое задачи (например, 1-линия для создания абонентов, служба мониторинга для просмотра статусов абонентов или транков и так далее).
После установки всей настроек сохраняем настройки путем нажатия F3 в терминале или Enter (F3) в консоли GEDI.
Выполняется в web-браузере
Подключаемся к Avaya Communication Manager по IP-адресу, заходим под учетной записью dadmin (если она у нас единственная) или под учетной записью «полного» администратора (если ранее был создан такой аккаунт).
Далее Administration → Server (Maintenace) → Security → Administrator Accounts → Add Login и создаем уже сами аккаунты:
Сначала выбираем уровень доступа. В зависимости от выбранного уровня предоставляются разные права, не настраиваемые в профайле.
Вот пример предоставляемых прав для 2-х администраторов:
Для уровня «полного» администратора выбираем Privileged Administrator.
Login name – создаваемый логин, по которому будет осуществляться авторизация.
Additional groups (profile) – в выпадающем списке выбираем созданный ранее профайл.
Enter password or key – вводим пароль для входа.
Re-enter password or key – подтверждаем введенный ранее пароль.
Как правило пользователь должен сам создавать и помнить свои пароли, поэтому
Force password/key change on next login – отмечаем в Yes. Тогда при первом входе пользователю будет предложено для продолжения работы сменить пароль на новый.
Далее подтверждаем введенные данные Submit.
Для добавления доступа к Web-настройкам созданный ранее профайл надо добавить через Administration → Server (Maintenace) → Security → Web Access Mask.
Нажимаем Add, потом вводим номер нашего созданного профайла и выбираем какую маску доступа будем применять или сразу будем применять все включено/выключено.
После сохранения убеждаемся, что вновь добавленная маска применилась, выбираем её, заходим в нее нажав Change и проверяем/добавляем/удаляем необходимые настройки.
Далее заходим под созданной учетной записью и проверяем уровень доступа по доступным командам. После проверки полного доступа рекомендуется сменить пароль для учетной записи dadmin и не выдавать этот логин никому.
Дальше в логах на СМ мы можем просмотреть историю входов, введенных команд и выполненных действий по каждому логину.
Подключения прибора
Для подключения прибора к измеряемому потоку используются разъемы на задней (или верхней) стенке прибора:
Tx OUTliUT выход, или передача прибора подключить к Rx (прием) измеряемого потока;
Rx INliUT вход, или прием прибора подключить к Tx (передача) измеряемого потока.
На левой стенке расположен разъем EXT PWR для подключения адаптера внешнего питания. Прибор продолжительное время (несколько часов) может работать от встроенных аккумуляторов.
Включение прибора
Нажать клавишу <On> - через 2-3 секунды прибор включится.
В правом верхнем углу указано название текущего меню.
В нижней части дисплея указано назначение функциональных клавиш в данном режиме (смотри рисунок). При включении прибора отображается главное меню "Main menu".
Если вы не знаете, в каком меню находитесь и что делать дальше, нажмите кнопку <Main menu>. Далее, следуйте инструкции.
Контроль потока и подключения
В главном меню (Main menu) нажать кнопку <-more-> (клавиша S6), до появления в левом нижнем углу пункта меню <Monit>. Выбрав данный пункт (клавишей S1), вы попадаете в меню мониторинга, где возможно контролирование потока и отдельного канального интервала. В правом верхнем углу отображается состояние потока:
No signal нет сигнала на входе прибора. Возможно перепутаны прием/передача оборудования, или неисправен соединительный шнур;
AIS сигнал удаленной аварии. На дальнем конце измеряемый поток не нагружен;
Frame sync loss потеря цикловой синхронизации. Прибор принимает не тот сигнал, который передает. Возможно отсутствует шлейф на дальнем конце, или подключен не тот поток.
*Words* - "слова". Аварии отсутствуют - прибор принимает передаваемый им сигнал и готов к проведению измерений.
Проведение измерений
Для измерения потока E1 необходимо выполнить следующее:
Выйти в главное меню нажатием кнопки <MAIN MENU>
Нажать Menu1, основные параметры, убедиться, что выставлены параметры:
Первый столбец:
[Mode] режим, возможны значения:
RX/TX прием/передача, измерения по завороту;
RX прием, измерения на рабочем потоке, параллельно;
THROUGH через, поток пропускается через прибор;
DELAY.
Для измерений по завороту необходимо выбрать режим RX/TX
[Interface] - G.703 интерфейс G.703;
[Line code] - HDB3линейный код HDB3;
[Framing] - liCM30формат кадра ИКМ-30;
liCM-31 с использованием 16-го ки;
OFFбез цикловой структуры.
Рекомендации по выбору режима: выставить PCM-31. Если прибор не может засинхронизироваться, возникает аварийная сигнализация переключить в режим PCM-30. При невозможности проведения измерений в данном режиме возможно(но не рекомендуется) проведение измерений без цикловой структуры (режим OFF).
[Termination] 75/120Ω - сопротивление интерфейса 75/120 Ом;
[Tx Clc src] - INTERNисточник синхронизации передачи внутренний или FROM RX от сигнала приема;
[Kblis] - 2048 скорость передачи 2048 кбит/с;
Второй столбец:
[V.11 slot] - OFF ввод/вывод данных в какой-либо канальный интервал посредством интерфейса V.11 откл.;
[Rx slots] - канальные интервалы, по которым производится измерения, принимает значения:
OFF откл;
1(С1) - 1 канальный интервал (можно использовать любой ки от 1 до 31, не заблокированный в данном режиме);
nx64 несколько канальных интервалов, в данном режиме возможен выбор нескольких или всех канальных интервалов для проведения измерений. При выборе пункта <nx64> открывается меню "Rx Slots (BERT)", в котором производится выбор канальных интервалов:
ALL выбрать все
Clear очистить выбор (действие, обратное предыдущему)
Select выбрать ки, обозначенный курсором
De-select отменить выбор ки, обозначенного курсором
Return возврат в предыдущее меню
Рекомендации по выбору ки: как правило, измерения проводятся по полному потоку, то есть должны быть выбраны все канальные интервалы, последовательность действий: <Rx slots> <nx64> <ALL> <Return>
[Rx audio] OFF канальный интервал, который будет прослушиваться через встроенный динамик. Возможно указание любого ки, или отключение опции.На ход измерений не влияет;
[Rx signaling] OFF;
[Tx slots] - канальные интервалы, по которым передается тестовая последовательность. Возможны режимы:
OFF - откл. передача не осуществляется;
USER - по выбору пользователя;
AS RX - в соответствии с приемом. Выбраны те канальные интервалы, которые контролируются по приему;
IDLE - свободно, передается последовательность IDLE (задается в следующем меню, обозначает неиспользуемые ки);
1(С1) - 1 канальный интервал (можно использовать любой ки от 1 до 31, не заблокированный в данном режиме).
Рекомендации по выбору ки: рекомендуется выбрать режим <AS RX>
Примечание: в режиме Framing OFF параметры второго столбца отсутствуют. В режиме Framing PCM31 параметр Rx signaling отсутствует.
Перейти в следующее меню menu2, параметры тестовой последовательности:
Параметры по умолчанию:
[Idle liattern] 0110 1010;
[Bert liattern] 215 -1;
[Bert signaling] 1010;
[Idle signaling] 1010;
Bits/Block - 1000;
NFAS/NMFAS - norm;
Tx logic - norm;
Rx logic - norm.
Некоторые параметры могут отсутствовать в зависимости от выбора режима Framing. Ничего изменять не нужно.
Перейти в следующее меню menu3, проконтролировать параметры:
[Current test] - текущее измерение, при многократных измерениях для сохранения результатов номер измерения следует поменять на следующий.
Например, если произведено измерение под № 5, то при следующем измерении следует установить №6. Тогда в ячейке №5 результаты сохранятся;
[Timer] - On таймер включен.
В меню Timer необходимо задать продолжительность тестирования, для этого необходимо навести указатель на пункт Timer, нажать <edit> - откроется timer menu:
[Start time] - manual запуск теста - вручную;
[Duration] - продолжительность.
Userзадана пользователем, далее необходимо указать продолжительность тестирования: 0 days (дни) 0 hrs (часы) 15 mins (минуты). При необходимости возможен режим Continпродолжительный, до остановки пользователем. Далее нажать Return, чтобы вернуться в предыдущее меню.
[Autolirint] - Off - автоматическая печать выключена;
G.821 - ITU-T - контроль по протоколу G.821 включен, согласно рекомендации ITU-T;
[Alarms] All on - контроль аварий все аварии;
[Resolution] - HRS/MINS - частота записи результатов часы/минуты;
[Beelier] - Off;
[Err inject] - Ratio - ввод ошибок.
Нажать кнопку <Run> - запуск. Начнутся измерения.
На экране появляется информация о производимых измерениях: правая часть экрана краткая информация о параметрах измерений, левая часть экрана надпись ОКили присутствующие аварии и зафиксированные ошибки.
RX/TX - режим измерений;
G.703, liCM31 - основные параметры измерений;
Rx - звездочкой обозначены измеряемые канальные интервалы, если стоит точка канальный интервал пропускается;
Total seconds - время в секундах, прошедшее с начала измерений;
Bit err ratio - коэффициент битовых ошибок.
Перенос результатов измерений в ПК
По завершении измерений на экране отображаются краткие результаты. Для переноса измерений на компьютер необходимо:
Выключить прибор и перенести его к месту установки компьютера.
Подключить прибор к компьютеру, для этого: порт V.24/RS-232 прибора (с правой стороны) подключить через переходной соединительный кабель к com-порту компьютера.
Запустить на компьютере программу HyperTerminal. (В программе HyperTerminal должен быть задан номер com-порта, к которому подключен прибор и параметры соединения: скорость 9600 бит/с; биты данных 8, четность нет; стоповые биты 1; управление потоком Xon/Xoff)
Включить прибор.
Найти пункт меню "Memory". Если его нет, можно нажать кнопку <more>, для отображения других возможностей меню до появления нужной кнопки.
В меню "Memory" отображаются все сохраненные результаты, установить курсор на нужном пункте (можно определить по дате и времени измерений)
Нажать <Results>, на экране появятся результаты измерений, нажать кнопку <Print>, результаты будут переданы в окно HyperTerminal. Из окна программы результаты можно скопировать и вставить в любой текстовый документ: WordPad (блокнот) или Microsoft Word.
_____________________________________________________________________________
ACTERNA E1 SERVICE TESTER EST-125 09:32 11 Mar 2011
_____________________________________________________________________________
Printout of menu settings
*Setup Menu 1*
Mode RX/TX
Interface G.703
Line code HDB3
Framing PCM31C
Termination 75/120 Ohm
Tx Clk source INTERN
kbps 2048
V.11 OFF
Rx slots BERT-Rx 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
Rx audio OFF
Tx slots AS RX
*Setup Menu 2*
Idle pattern 0000 0000
BERT pattern 2^15-1
Bits/Block 1000
Rx logic NORM
Tx logic NORM
*Setup Menu 3*
Autoprint OFF
G.821 ITU-T
Multiframe ITU-T
Alarms USER
Resolution HRS/MINS
*Alarm Display*
AIS ON
Fr Sync ON
All ones ON
All zeros ON
Patt loss ON
Patt Inv
Slip ON
Dist Fr ON
Bit error ON
CRC err ON
FAS err ON
Code err ON
_____________________________________________________________________________
ACTERNA E1 SERVICE TESTER EST-125 09:33 11 Mar 2011
_____________________________________________________________________________
Printout of test results for test number 2
Start time 09:25 10 Mar 2011
Stop time 09:25 11 Mar 2011
Total test time (seconds) 86400
Line rate 2047994
Total code errors received 0
Total mean Code Error Ratio 0.000E 0
Bit rate 1983995
Total bits received 1.174E 11
Total errors received 0
Total mean Bit Error Ratio 0.000E 0
Total blocks received 1.174E 8
Total block errors received 0
Total mean Block Error Ratio 0.000E 0
Seconds of no signal 0
Seconds of AIS
Seconds of pattern sync loss 0
Seconds of Pattern Inverted 0
Seconds of all ones 0
Seconds of all zeros 0
Seconds of slip 0
Seconds of frame sync loss 0
Seconds of distant frame alarm 0
Total FAS word errors 0
Total number of frames 0
Total number of frames 6.912E 8
Total mean FAS word error ratio 0.000E 0
Total CRC word errors 0
Available time 86400 100.00000%
Unavailable time 0 0.00000%
Error free seconds 86400 100.00000%
Errored seconds PASS 0 0.00000%
Severely errored seconds PASS 0 0.00000%
Severely errored seconds PASS 0 0.00000%