Вид тестирования при котором выполняется минимальный набор тестов для выявления явных ошибок

Виды тестирования

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

Ad-hoc тестирование

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

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

Приемочное тестирование

Приемочное тестирование – это формальный вид тестирования программного обеспечения, который выполняется конечным потребителем, когда разработчики предоставили запрашиваемые услуги. Целью этого тестирования является проверка соответствия ПО бизнес-требованиям потребителей и требованиям, представленным ранее. Приемочные тестирования обычно документируются в начале работы (в agile) и помогают тестировщикам и разработчикам улучшить свои знания и умения в данной области.

Что такое приемочное тестирование в Agile?

Тестирование доступности

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

Agile тестирование

Agile Testing – это вид тестирования программного обеспечения, который учитывает гибкий подход и методы разработки программного обеспечения. В среде разработки Agile тестирование является неотъемлемой частью разработки ПО и выполняется параллельно с написанием кода. Agile тестирование позволяет проводить постепенное написание кода и его тестирование.

Тестирование API

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

Автоматизированное тестирование

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

Парное тестирование

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

Бета-тестирование

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

Тестирование Черного Ящика

Тестирование черного ящика – это вид тестирования программного обеспечения, когда от тестировщиков не требуется знать кодировку или внутреннюю структуру программного обеспечения. Метод тестирования «черного ящика» основан на тестировании ПО с различными входами и сравнении результатов с ожидаемыми.

Тестирование обратной совместимости

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

Тестирование граничных значений

Тестирование граничных значений – это вид тестирования, основанный на концепции «агрегации ошибок на границах». Тестирование проводится методом тщательного тестирования дефектов в граничных значениях. Если в поле принимается значение от 1 до 100, то тестирование выполняется для значений 0, 1, 2, 99, 100 и 101.

Метод тестирования “большой взрыв”

Это один из подходов интеграционного тестирования. Метод тестирования “большой взрыв” основывается на том, что все или большинство модулей разрабатываются и затем соединяются вместе.

Интеграционное тестирование Снизу вверх (восходящее тестирование)

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

Тестирование ветвей

Является методом тестирования белого ящика для разработки тестовых сценариев для тестирования кода для каждого условия ветвления. Применяется во время модульного тестирования.

Тестирование совместимости браузера

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

Тестирование совместимости

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

Тестирование компонентов

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

Тестирование покрытия условий

Тестирование покрытия условий – это методика тестирования, используемая во время модульного тестирования, где разработчик тестирует все условия, такие как if, if-else, case и т. д. в тестируемом модуле кода.

Динамическое тестирование

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

Тестирование покрытия решения

Это методика тестирования, которая используется в модульном тестировании. Цель тестирования покрытия решения состоит в том, чтобы осуществить и проверить каждый блок принятия решения в коде, например. If, if-else, case.

Сквозное тестирование

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

Исследовательское тестирование

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

Эквивалентное разбиение

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

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

Функциональное тестирование – формальный тип тестирования, выполняемый тестировщиками. Функциональное тестирование сосредоточено на тестировании программного обеспечения на основе документа о состоянии, случаев и требований. Функциональное тестирование является типом тестирования «черного ящика» и не требует знаний внутренней работы программного обеспечения, в отличие от тестирования «белого ящика».

Fuzz тестирование

Fuzz testing или fuzzing – это методика тестирования программного обеспечения, которая включает тестирование с непредвиденными или случайными исходными данными. Программное обеспечение тестируется на предмет ошибок или сообщений об ошибках, которые появляются из-за ошибок при вводе данных.

Тестирование графического интерфейса пользователя

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

Тестирование методом “стеклянного ящика”

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

Gorilla тестирование (хаотическое тестирование)

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

Тестирование благоприятного пути

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

Интеграционное тестирование

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

Тестирование интерфейса

Тестирование интерфейса необходимо, когда программное обеспечение обеспечивает поддержку одного или нескольких интерфейсов, таких как «Графический интерфейс пользователя», «Интерфейс командной строки» или «Интерфейс прикладного программирования», чтобы взаимодействовать со своими пользователями или другим программным обеспечением. Интерфейсы служат средой для ПО, чтобы принимать входные данные от пользователя и предоставлять выходные данные пользователю. Подход к тестированию интерфейса зависит от типа тестируемого интерфейса, такого как GUI или API или CLI.

Тестирование интернационализации

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

Тестирование на основе ключевых слов

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

Нагрузочное тестирование

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

Тестирование локализации

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

Отрицательное тестирование

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

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

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

Парное тестирование

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

Тестирование производительности

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

Тестирование безопасности

Является одним из видов тестирования безопасности. Тестирование проникновения проводится для проверки того, как защищенное программное обеспечение и его среда (оборудование, операционная система и сеть) подвергаются атакам со стороны внешнего или внутреннего злоумышленника. Нарушитель может быть человеком / хакером или вредоносными программами. Pentest использует методы насильственного вторжения (путем грубой силы атаки) или использования уязвимости для получения доступа к ПО или данным, или оборудованию с целью разоблачения способов кражи, манипулирования или повреждения данных, файлов ПО или конфигурации. Тестирование безопасности – это способ этичного взлома: опытный тестировщик безопасности будет использовать те же методы и инструменты, что и хакер, но намерение тестировщика – идентифицировать уязвимость и исправить ее до того, как настоящий хакер или вредоносная программа использует уязвимость в своих целях.

Регрессионное тестирование

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

Повторное тестирование

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

Тестирование на основе рисков

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

Smoke тестирование (тестирование “на дым”)

Это вид тестирования, который выполняется тестировщиками ПО для проверки, является ли новая сборка, предоставленная командой разработчиков, достаточно стабильной, т. е. работают так ли основные функции, как ожидается, для проведения дальнейшего или подробного тестирования. Smoke тестирование предназначено для обнаружения дефектов «show stopper», которые могут препятствовать тестированию приложения в деталях. Smoke тестирование также известно как тестирование проверки сборки.

Тестирование защищенности

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

Тестирование работоспособности

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

Тестирование масштабируемости

Представляет собой нефункциональный тест, предназначенный для тестирования одного из атрибутов качества ПО, то есть «Масштабируемость». Тест масштабируемости не ориентирован только на одну или несколько функций ПО, а не на производительность ПО в целом. Тестирование масштабируемости обычно выполняется командой разработчиков. Цель тестирования масштабируемости – проверить способность ПО увеличиваться с увеличением пользователей, увеличивать транзакции, увеличивать размер базы данных и т. д. Не обязательно, чтобы производительность ПО возрастала с увеличением конфигурации оборудования. Тесты масштабируемости помогают выяснить, как гораздо большую рабочую нагрузку ПО может поддерживать с расширением базы пользователей, транзакций, хранения данных и т.д.,

Тестирование стабильности

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

Статическое тестирование

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

Стресс-тестирование

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

Тестирование системы

Включает в себя несколько видов тестирования ПО, которые позволят проверить программное обеспечение в целом (программное обеспечение, аппаратное обеспечение и сеть) в соответствии с требованиями, для которых он был создан. Для завершения тестирования системы выполняются различные виды тестов (GUI-тестирование, функциональное тестирование, регрессионное тестирование, тестирование дыма, нагрузочное тестирование, стресс-тестирование, тестирование безопасности, стресс-тестирование, ad-hoc тестирование и т. д.).

Нагрузочное тестирование

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

Тестирование интеграции системы

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

Модульное тестирование

Это вид тестирования, который выполняется разработчиками ПО. Модульное тестирование следует методу тестирования белых полей, где разработчик будет тестировать модули исходного кода, такие как операторы, ветви, функции, методы, интерфейс в ООП (объектно-ориентированное программирование). Модульное тестирование обычно включает в себя разработку драйверов. Модульные тесты – идеальные варианты для автоматизации. Автоматизированные тесты могут выполняться как единичные регрессионные тесты для новых версий или новых версий ПО. Существует множество полезных фреймов, таких как Junit, Nunit и т. д., которые могут сделать модульное тестирование более эффективным.

Тестирование удобства использования

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

Приемочное тестирование пользователя

Приемочное тестирование пользователя является обязательным для любого проекта. Оно выполняется клиентами / конечными пользователями ПО. Приемочное тестирование позволяет специалистам от клиента тестировать ПО в соответствии с реальными бизнес-сценариями или реальными сценариями и проверять соответствие ПО их бизнес-требованиям.

Тестирование объема

Является нефункциональным видом тестирования, выполняемым группой инженеров по производительности. Тестирование объема – один из видов тестирования производительности. Тестирование объема выполняется для того, чтобы проверить ПО на надежность при работе с различными размерами данных, которые принимаются и обрабатываются программным обеспечением. Например, если вы собираетесь тестировать слово Microsoft, то проверка объема будет заключаться в том, чтобы увидеть, может ли MS Word открыть, сохранить и работать с файлами разных размеров (от 10 до 100 МБ).

Тестирование уязвимости

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

Тестирование методом “белого ящика”

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

Хочу отметить, что помогут познакомиться с данными методами тестирования  наши курсы Тестирования ПО в Минске .

Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!

Записаться сейчас / Бесплатная консультация

Table of Contents

Completing a software project is not sufficient, we also need to test it. But exactly why should we care about testing a software application?

Software testing is about checking if the software works properly and if it meets the written requirements specifications.

The basic goals of software tests are to eliminate bugs and to enhance various aspects of the software, such as performance, user experience, security, and so on. A great deal of testing can amazingly improve the overall quality of the software, which will lead to great customer satisfaction.

But is software testing essential? What if we don’t do this?

Nowadays, software applications are used everywhere — hospitals, traffic, shops, business organizations, etc. So not testing the software at all is dangerous. It’s dangerous in the sense that it can cause severe harm, such as security breach, loss of money, and even deaths in some cases. Delivering or launching an application without testing it very well will cause many small or big problems for the users.

Looking to learn Software Testing? Udemy’s The Complete 2023 Software Testing Bootcamp online course will surely prove to a great starting point for you.

Types of Software Testing

Software testing is generally classified into two main broad categories: functional testing and non-functional testing. There is also another general type of testing called maintenance testing.

1. Functional Testing

Functional testing involves the testing of the functional aspects of a software application. When you’re performing functional tests, you have to test each and every functionality. You need to see whether you’re getting the desired results or not.

There are several types of functional testing, such as:

• Unit testing
• Integration testing
• End-to-end testing
• Smoke testing
• Sanity testing
• Regression testing
• Acceptance testing
• White box testing
• Black box testing
• Interface testing

Functional tests are performed both manually and using automation tools. For this kind of testing, manual testing is easy, but you should use tools when necessary.

Some tools that you can use for functional testing are Micro Focus UFT (previously known as QTP, and UFT stands for Unified Functional Testing), Selenium, JUnit, soapUI, Watir, etc.

2. Non-functional Testing

Non-functional testing is the testing of non-functional aspects of an application, such as performance, reliability, usability, security, and so on. Non-functional tests are performed after the functional tests.

With non-functional testing, you can improve your software’s quality to a great extent. Functional tests also improve the quality, but with non-functional tests, you have the opportunity to make your software even better. Non-functional testing allows you to polish the software. This kind of testing is not about whether the software works or not. Rather, it’s about how well the software runs, and many other things.

Non-functional tests are not generally run manually. In fact, it’s difficult to perform this kind of tests manually. So these tests are usually executed using tools.

There are several types of non-functional testing, such as:

• Performance testing
• Security testing
• Load testing
• Failover testing
• Compatibility testing
• Usability testing
• Scalability testing
• Volume testing
• Stress testing
• Maintainability testing
• Compliance testing
• Efficiency testing
• Reliability testing
• Endurance testing
• Disaster recovery testing
• Localization testing
• Internationalization testing

Note that explaining all the types of software testing is beyond the scope of this article.

Different Types of Software Testing

This article explains only some of the most common types of software testing.

1. Unit Testing

Testing each component or module of your software project is known as unit testing. To perform this kind of testing, knowledge of programming is necessary. So only programmers do this kind of tests, not testers.

You have to do a great deal of unit testing as you should test each and every unit of code in your project.

2. Integration testing

After integrating the modules, you need to see if the combined modules work together or not. This type of testing is known as integration testing. You need to perform fewer integration tests than unit tests.

Some good tools for unit and integration testing are Jasmine, Mocha, etc.

3. End-to-end Testing

End-to-end testing is the functional testing of the entire software system. When you test the complete software system, such testing is called end-to-end testing. You need to perform fewer end-to-end tests than integration tests.

Cucumber, Protractor, Jasmine, Karma, SpecFlow, etc. are some great end-to-end testing tools.

4. User Interface Testing

User interface testing involves the testing of the application’s user interface. The aim of UI tests is to check whether the user interfaces have been developed according to what is described in the requirements specifications document.

By running UI tests, you can make the application’s user interfaces more user-friendly and appealing to the eyes.

Some great automated user interface testing tools are Monkey test for Android, Saucelabs, and Protractor.

5. Accessibility testing

Testing whether your software is accessible to disabled people or not is termed as accessible testing. For this type of tests, you need to check if disabled people such as those who are color blind, blind, and deaf can use your application.

The right choice of color and contrast need to be made to make your software accessible to color-blind people.

6. Alpha testing

Alpha testing is a kind of testing to look for all the errors and issues in the entire software. This kind of test is done at the last phase of app development and is performed at the place of the developers, before launching the product or before delivering it to the client to ensure that the user/client gets an error-free software application.

Alpha testing is run before the beta testing, which means that after performing alpha testing, you need to run beta testing.

Alpha testing is not performed in the real environment. Rather, this kind of tests is done by creating a virtual environment that resembles a real environment.

7. Beta testing

As said earlier, beta testing takes place after alpha testing. Beta testing is done before the launch of the product. It is carried out in a real user environment by a limited number of actual customers or users, in order to be certain that the software is completely error-free and it functions smoothly. After collecting feedback and constructive criticism from those users, some changes are made to make the software better.

So when the software is under beta testing, it is called beta version of the software. After this testing is complete, the software is released to the public.

As the name suggests, ad-hoc testing is a kind of testing that is performed in an ad-hoc manner, without using any test cases, plans, documentation, or systems. Unlike all other types of testing, this kind of testing is not carried out in a systematic manner.

Although finding errors can be difficult without using test cases, there are technical issues that are easily detected through an ad-hoc test, but are hard to find through other testing approaches that use test cases.

This informal type of software testing can be executed by any person involved with the project.

9. Compatibility testing

Compatibility testing involves compatibility checking of the software with different operating systems, web browsers, network environments, hardware, and so on. It checks whether the developed software application is working fine with different configurations.

To give you a few examples, if the software is a Windows app, it should be checked whether it is compatible with different versions of the Windows operating system. If it’s a web application, it is tested whether the app is easily accessible from different versions of the widely-used web browsers. And if it’s an Android app, it should be checked whether it is working well with all the commonly used versions of the Android operating system.

10. Backward compatibility testing

Backward compatibility testing is carried out to test if a brand new or an updated version of an application is compatible with the previous versions of the environments (such as operating systems and web browsers) on which the software runs. Sometimes, some application is updated specifically to match the standard and style of a newer, more modern environment. In that case, support for backward compatibility is necessary.

Backward compatibility testing ensures that all those who are using the older versions of a particular environment can use your software.

11. Browser compatibility testing

As the name says, browser compatibility testing checks a web application for browser compatibility. More specifically, it is tested whether the web app can easily be accessed from all versions of the major web browsers.

It is a specific form of compatibility testing, while compatibility testing checks for general compatibility.

Some popular tools to check browser compatibility include CrossBrowserTesting.com, LamdaTest, Browsershots, Experitest, Turbo Browser Sandbox, Ranorex Studio, Browsera, etc.

12. Performance testing

Performance tests are run to check if the software’s performance is good or not. There are performance testing tools that analyze your app’s performance and show you the performance issues. By fixing those issues, you’ll be able to increase the performance of your software application.

Some great performance testing tools, also known as load testing tools, for web applications are WebLOAD, LoadView, NeoLoad, LoadNinja, Appvance, LoadRunner, Apache JMeter, Loadster, LoadImpact, Testing Anywhere, SmartMeter.io, Tricentis Flood, Rational Performance Tester, LoadComplete, etc.

13. Load testing

Load testing is one kind of performance testing that tests how much load a system can take before the software performance begins to degrade. By running load tests, we can know the capacity of taking load of a system.

You can run load tests using tools like LoadRunner, WebLoad, JMeter, etc.

14. Recovery testing

Recovery testing involves the checking of whether the application can recover from crashes and how well it recovers. In this kind of tests, testers observe how well the software can come back to the normal flow of execution. Crashes can happen anytime. Even if your software is of exceptional quality, crashes may happen. You don’t know when they may take place and annoy the users.

So you have to implement mechanisms that will recover the software application quickly and that will make the application run smoothly again.

15. Regression testing

If you need to make changes in any component, module, or function, you have to see if the whole system functions properly after those modifications. Testing of the whole system after such modifications is known as regression testing.

16. Agile testing

Carried out by the QA team, Agile testing is a type of testing that is conducted according to the rules of agile methodology. This kind of testing is done from the actual customers’ viewpoint.

Some useful tools that you can use for Agile testing are JIRA, PractiTest, JunoOne, VersionOne, TestRail, SoapUI, etc.

17. API testing

Just like unit testing, API testing is also a code-level testing type. The basic difference between unit testing and API testing is that unit testing is performed by the development team whereas API testing is handled by the QA team.

18. Black box testing

Performed by the QA team of a company, black box testing is a testing technique that involves the checking of the application’s functionality without having any technical knowledge of the application, like the knowledge of the code’s logic, how the code works, knowledge of the internal structure, etc.

19. White box testing

Performed by the development team, white box testing is a testing method that requires a good understanding of the application’s code. It requires great knowledge of the app’s internal logic.

20. Security testing

Security tests are performed to ensure the security of your application, in order that security breaches can be prevented. Security experts run this kind of tests to see how much your software is secure from attacks and to find security issues so that the app’s security can be strengthened.

The top website security testing tools include Grabber, Arachni, Iron Wasp, Nogotofail, SQLMap, W3af, Wapiti, Wfuzz, Zed Attack Proxy, etc.

21. Usability testing

Testing the user-friendliness of an app is known as usability testing. It involves the checking of how much usable or user-friendly the app is. It is tested whether any user can easily use your software without getting stuck.

One of the best ways to test the usability of your software is to invite a few people to use your software. See if they can do certain things in your app without taking any help from you.

Take a look at these useful usability testing tools: Optimizely, Qualaroo, Crazy Egg, Usabilla, Clicktale, Five Second Test, Chalkmark, UXtweak.

22. Scalability testing

Scalability testing verifies whether the software is scalable or not. In other words, it checks if your app performs well when the number of users, amount of data, or the number of transactions increases significantly. A software application that is not scalable may cause great business loss.

23. Reliability testing

Reliability testing is a type of software testing that verifies if the software is reliable or not. In other words, it checks whether the software runs error-free and that one can rely on it.

For example, if a user’s important information stored in the database of the software gets suddenly deleted after a few months because of some error in the code, we can say that the software is not reliable.

24. Acceptance testing

The client who will purchase your software will perform acceptance testing (also known as User Acceptance Testing) to see if the software can be accepted or not by checking whether your software meets all the client’s requirements and preferences. If your software doesn’t meet all the requirements or if your client doesn’t like something in the app, they may request you to make changes before accepting the project.

Final words

This article explained several types of software testing. Keep in mind that you don’t need to perform all of these tests mentioned in this post for your software project. What kinds of tests you should run depends on the type of software you’re building and other factors.

Besides performing tests, measuring the effectiveness of the tests is also important, and test coverage tells the effectiveness of your tests. Istanbul is a good tool for measuring test coverage, used for JavaScript software projects.

There can be undetected errors in your application even after it’s launched, which will annoy the users and will cause problems for them. Real-time error-checking tools such as Sentry and Newrelic will automatically find errors and notify you, so you don’t need to tell your users to report bugs.

You can also use automated code grading tools. Automated code grading tools like sonarqube and codebeat help you amazingly improve the quality of your code by showing issues in your application. These tools will help you fix bugs in less time. After analyzing your code, these tools give you useful reports with valuable information required for code quality enhancement.

You can use programs called linters to check if the code of your software project meets the specified coding convention rules. A linter actually saves you a lot of time as manually checking the code written by several developers is a very time-consuming process.

You can find linters for almost any programming language. Take a look at these popular linters: TypeScript TSlint, JavaScript ESLint, Sass/SCSS sass-lint, Python pylint/flake8, Bash ShellCheck, Go golang lint, etc. Code editors such as Visual Studio Code let you configure linting.

People are also reading:

• Best Software Testing Courses
• Best Software Testing Certifications
• Best Automation Testing Tools
• Best Penetration Testing Certifications
• What is Software Testing Life Cycle?
• Manual Testing Interview Questions
• What is Selenium IDE?
• What is Selenium WebDriver?
• Best Selenium Testing Interview Questions
• What is Selenium?
• Best Web Development IDE
• Security Testing Tools
• Software Testing Tools
• Best Blockchain Courses

Table of Contents

Completing a software project is not sufficient, we also need to test it. But exactly why should we care about testing a software application?

Software testing is about checking if the software works properly and if it meets the written requirements specifications.

The basic goals of software tests are to eliminate bugs and to enhance various aspects of the software, such as performance, user experience, security, and so on. A great deal of testing can amazingly improve the overall quality of the software, which will lead to great customer satisfaction.

But is software testing essential? What if we don’t do this?

Nowadays, software applications are used everywhere — hospitals, traffic, shops, business organizations, etc. So not testing the software at all is dangerous. It’s dangerous in the sense that it can cause severe harm, such as security breach, loss of money, and even deaths in some cases. Delivering or launching an application without testing it very well will cause many small or big problems for the users.

Looking to learn Software Testing? Udemy’s The Complete 2023 Software Testing Bootcamp online course will surely prove to a great starting point for you.

Types of Software Testing

Software testing is generally classified into two main broad categories: functional testing and non-functional testing. There is also another general type of testing called maintenance testing.

1. Functional Testing

Functional testing involves the testing of the functional aspects of a software application. When you’re performing functional tests, you have to test each and every functionality. You need to see whether you’re getting the desired results or not.

There are several types of functional testing, such as:

• Unit testing
• Integration testing
• End-to-end testing
• Smoke testing
• Sanity testing
• Regression testing
• Acceptance testing
• White box testing
• Black box testing
• Interface testing

Functional tests are performed both manually and using automation tools. For this kind of testing, manual testing is easy, but you should use tools when necessary.

Some tools that you can use for functional testing are Micro Focus UFT (previously known as QTP, and UFT stands for Unified Functional Testing), Selenium, JUnit, soapUI, Watir, etc.

2. Non-functional Testing

Non-functional testing is the testing of non-functional aspects of an application, such as performance, reliability, usability, security, and so on. Non-functional tests are performed after the functional tests.

With non-functional testing, you can improve your software’s quality to a great extent. Functional tests also improve the quality, but with non-functional tests, you have the opportunity to make your software even better. Non-functional testing allows you to polish the software. This kind of testing is not about whether the software works or not. Rather, it’s about how well the software runs, and many other things.

Non-functional tests are not generally run manually. In fact, it’s difficult to perform this kind of tests manually. So these tests are usually executed using tools.

There are several types of non-functional testing, such as:

• Performance testing
• Security testing
• Load testing
• Failover testing
• Compatibility testing
• Usability testing
• Scalability testing
• Volume testing
• Stress testing
• Maintainability testing
• Compliance testing
• Efficiency testing
• Reliability testing
• Endurance testing
• Disaster recovery testing
• Localization testing
• Internationalization testing

Note that explaining all the types of software testing is beyond the scope of this article.

Different Types of Software Testing

This article explains only some of the most common types of software testing.

1. Unit Testing

Testing each component or module of your software project is known as unit testing. To perform this kind of testing, knowledge of programming is necessary. So only programmers do this kind of tests, not testers.

You have to do a great deal of unit testing as you should test each and every unit of code in your project.

2. Integration testing

After integrating the modules, you need to see if the combined modules work together or not. This type of testing is known as integration testing. You need to perform fewer integration tests than unit tests.

Some good tools for unit and integration testing are Jasmine, Mocha, etc.

3. End-to-end Testing

End-to-end testing is the functional testing of the entire software system. When you test the complete software system, such testing is called end-to-end testing. You need to perform fewer end-to-end tests than integration tests.

Cucumber, Protractor, Jasmine, Karma, SpecFlow, etc. are some great end-to-end testing tools.

4. User Interface Testing

User interface testing involves the testing of the application’s user interface. The aim of UI tests is to check whether the user interfaces have been developed according to what is described in the requirements specifications document.

By running UI tests, you can make the application’s user interfaces more user-friendly and appealing to the eyes.

Some great automated user interface testing tools are Monkey test for Android, Saucelabs, and Protractor.

5. Accessibility testing

Testing whether your software is accessible to disabled people or not is termed as accessible testing. For this type of tests, you need to check if disabled people such as those who are color blind, blind, and deaf can use your application.

The right choice of color and contrast need to be made to make your software accessible to color-blind people.

6. Alpha testing

Alpha testing is a kind of testing to look for all the errors and issues in the entire software. This kind of test is done at the last phase of app development and is performed at the place of the developers, before launching the product or before delivering it to the client to ensure that the user/client gets an error-free software application.

Alpha testing is run before the beta testing, which means that after performing alpha testing, you need to run beta testing.

Alpha testing is not performed in the real environment. Rather, this kind of tests is done by creating a virtual environment that resembles a real environment.

7. Beta testing

As said earlier, beta testing takes place after alpha testing. Beta testing is done before the launch of the product. It is carried out in a real user environment by a limited number of actual customers or users, in order to be certain that the software is completely error-free and it functions smoothly. After collecting feedback and constructive criticism from those users, some changes are made to make the software better.

So when the software is under beta testing, it is called beta version of the software. After this testing is complete, the software is released to the public.

As the name suggests, ad-hoc testing is a kind of testing that is performed in an ad-hoc manner, without using any test cases, plans, documentation, or systems. Unlike all other types of testing, this kind of testing is not carried out in a systematic manner.

Although finding errors can be difficult without using test cases, there are technical issues that are easily detected through an ad-hoc test, but are hard to find through other testing approaches that use test cases.

This informal type of software testing can be executed by any person involved with the project.

9. Compatibility testing

Compatibility testing involves compatibility checking of the software with different operating systems, web browsers, network environments, hardware, and so on. It checks whether the developed software application is working fine with different configurations.

To give you a few examples, if the software is a Windows app, it should be checked whether it is compatible with different versions of the Windows operating system. If it’s a web application, it is tested whether the app is easily accessible from different versions of the widely-used web browsers. And if it’s an Android app, it should be checked whether it is working well with all the commonly used versions of the Android operating system.

10. Backward compatibility testing

Backward compatibility testing is carried out to test if a brand new or an updated version of an application is compatible with the previous versions of the environments (such as operating systems and web browsers) on which the software runs. Sometimes, some application is updated specifically to match the standard and style of a newer, more modern environment. In that case, support for backward compatibility is necessary.

Backward compatibility testing ensures that all those who are using the older versions of a particular environment can use your software.

11. Browser compatibility testing

As the name says, browser compatibility testing checks a web application for browser compatibility. More specifically, it is tested whether the web app can easily be accessed from all versions of the major web browsers.

It is a specific form of compatibility testing, while compatibility testing checks for general compatibility.

Some popular tools to check browser compatibility include CrossBrowserTesting.com, LamdaTest, Browsershots, Experitest, Turbo Browser Sandbox, Ranorex Studio, Browsera, etc.

12. Performance testing

Performance tests are run to check if the software’s performance is good or not. There are performance testing tools that analyze your app’s performance and show you the performance issues. By fixing those issues, you’ll be able to increase the performance of your software application.

Some great performance testing tools, also known as load testing tools, for web applications are WebLOAD, LoadView, NeoLoad, LoadNinja, Appvance, LoadRunner, Apache JMeter, Loadster, LoadImpact, Testing Anywhere, SmartMeter.io, Tricentis Flood, Rational Performance Tester, LoadComplete, etc.

13. Load testing

Load testing is one kind of performance testing that tests how much load a system can take before the software performance begins to degrade. By running load tests, we can know the capacity of taking load of a system.

You can run load tests using tools like LoadRunner, WebLoad, JMeter, etc.

14. Recovery testing

Recovery testing involves the checking of whether the application can recover from crashes and how well it recovers. In this kind of tests, testers observe how well the software can come back to the normal flow of execution. Crashes can happen anytime. Even if your software is of exceptional quality, crashes may happen. You don’t know when they may take place and annoy the users.

So you have to implement mechanisms that will recover the software application quickly and that will make the application run smoothly again.

15. Regression testing

If you need to make changes in any component, module, or function, you have to see if the whole system functions properly after those modifications. Testing of the whole system after such modifications is known as regression testing.

16. Agile testing

Carried out by the QA team, Agile testing is a type of testing that is conducted according to the rules of agile methodology. This kind of testing is done from the actual customers’ viewpoint.

Some useful tools that you can use for Agile testing are JIRA, PractiTest, JunoOne, VersionOne, TestRail, SoapUI, etc.

17. API testing

Just like unit testing, API testing is also a code-level testing type. The basic difference between unit testing and API testing is that unit testing is performed by the development team whereas API testing is handled by the QA team.

18. Black box testing

Performed by the QA team of a company, black box testing is a testing technique that involves the checking of the application’s functionality without having any technical knowledge of the application, like the knowledge of the code’s logic, how the code works, knowledge of the internal structure, etc.

19. White box testing

Performed by the development team, white box testing is a testing method that requires a good understanding of the application’s code. It requires great knowledge of the app’s internal logic.

20. Security testing

Security tests are performed to ensure the security of your application, in order that security breaches can be prevented. Security experts run this kind of tests to see how much your software is secure from attacks and to find security issues so that the app’s security can be strengthened.

The top website security testing tools include Grabber, Arachni, Iron Wasp, Nogotofail, SQLMap, W3af, Wapiti, Wfuzz, Zed Attack Proxy, etc.

21. Usability testing

Testing the user-friendliness of an app is known as usability testing. It involves the checking of how much usable or user-friendly the app is. It is tested whether any user can easily use your software without getting stuck.

One of the best ways to test the usability of your software is to invite a few people to use your software. See if they can do certain things in your app without taking any help from you.

Take a look at these useful usability testing tools: Optimizely, Qualaroo, Crazy Egg, Usabilla, Clicktale, Five Second Test, Chalkmark, UXtweak.

22. Scalability testing

Scalability testing verifies whether the software is scalable or not. In other words, it checks if your app performs well when the number of users, amount of data, or the number of transactions increases significantly. A software application that is not scalable may cause great business loss.

23. Reliability testing

Reliability testing is a type of software testing that verifies if the software is reliable or not. In other words, it checks whether the software runs error-free and that one can rely on it.

For example, if a user’s important information stored in the database of the software gets suddenly deleted after a few months because of some error in the code, we can say that the software is not reliable.

24. Acceptance testing

The client who will purchase your software will perform acceptance testing (also known as User Acceptance Testing) to see if the software can be accepted or not by checking whether your software meets all the client’s requirements and preferences. If your software doesn’t meet all the requirements or if your client doesn’t like something in the app, they may request you to make changes before accepting the project.

Final words

This article explained several types of software testing. Keep in mind that you don’t need to perform all of these tests mentioned in this post for your software project. What kinds of tests you should run depends on the type of software you’re building and other factors.

Besides performing tests, measuring the effectiveness of the tests is also important, and test coverage tells the effectiveness of your tests. Istanbul is a good tool for measuring test coverage, used for JavaScript software projects.

There can be undetected errors in your application even after it’s launched, which will annoy the users and will cause problems for them. Real-time error-checking tools such as Sentry and Newrelic will automatically find errors and notify you, so you don’t need to tell your users to report bugs.

You can also use automated code grading tools. Automated code grading tools like sonarqube and codebeat help you amazingly improve the quality of your code by showing issues in your application. These tools will help you fix bugs in less time. After analyzing your code, these tools give you useful reports with valuable information required for code quality enhancement.

You can use programs called linters to check if the code of your software project meets the specified coding convention rules. A linter actually saves you a lot of time as manually checking the code written by several developers is a very time-consuming process.

You can find linters for almost any programming language. Take a look at these popular linters: TypeScript TSlint, JavaScript ESLint, Sass/SCSS sass-lint, Python pylint/flake8, Bash ShellCheck, Go golang lint, etc. Code editors such as Visual Studio Code let you configure linting.

People are also reading:

• Best Software Testing Courses
• Best Software Testing Certifications
• Best Automation Testing Tools
• Best Penetration Testing Certifications
• What is Software Testing Life Cycle?
• Manual Testing Interview Questions
• What is Selenium IDE?
• What is Selenium WebDriver?
• Best Selenium Testing Interview Questions
• What is Selenium?
• Best Web Development IDE
• Security Testing Tools
• Software Testing Tools
• Best Blockchain Courses

Критического пути (critical path test) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при стандартном их использовании. Чаще всего на практике на данном уровне тестирования проверяется основная масса требований к продукту. Пример: возможность набора текста, вставки картинок, возможность войти на сайт, создать запись, и т.д. Для данного вида тестирования пишутся наиболее подробные и глубокие тест-кейсы, чтобы покрыть всю возможную функциональность приложения. Тест критического пути может быть как позитивным, так и негативным: · Позитивный тест критического пути — это проверка работоспособности функций программного продукта, с которыми пользователь сталкивается ежедневно. · Негативный тест критического пути — это проверка всевозможных вариантов нестандартного использования функциональности, используемой пользователем каждый день. Тест критического пути является одним из самых распространенных видов функционального тестирования. Частота проведения данного тестирования обусловлена в первую очередь необходимостью периодической проверки всего приложения в сжатые сроки. А также позволяет выявить самые быстро находимые дефекты и исправить приложение в более сжатые сроки.

Медиаблог / Тестирование программ: что это такое и зачем нужно

21 декабря 2022

Тестирование программ: что это такое и зачем нужно

Построить карьеру в IT можно не только с позиции разработчика. Создание программного обеспечения начинается с разработки, но большую часть времени занимает тестирование. Что это такое, как устроено и за что платят деньги тестировщикам — рассказываем в статье.

I. Виды тестирования по цели

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

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

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

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

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

2. Тестирование безопасности (Security and Access Control Testing)

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

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

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

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

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

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

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

Исследование производительности на высоких, предельных, стрессовых нагрузках.

Стрессовое тестирование ( Stress Testing )

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

Объемное тестирование ( Volume Testing )

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования — Load Testing — тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

2. Тестирование установки (Installation Testing)

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

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

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

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

3. Тестирование удобства пользования (Usability Testing)

Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того, чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее, является неотъемлемой частью тестирования любых массовых продуктов.

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

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

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

Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).

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

Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

II. Виды тестирования по степени автоматизации

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

Тем не менее, перед тем как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость.

Мифы о ручном тестировании:

– кто угодно может провести ручное тестирование

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

– автоматизированное тестирование мощнее ручного

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

– ручное тестирование – это просто

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

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

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

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

Существует несколько основных видов автоматизированного тестирования:

– автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты);

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

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

Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.

III. Виды тестирования по запуску кода

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:

1. Обзоры (Review)

2. Статический анализ (Static Analysis)

Обзоры

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

В свою очередь обзоры делятся на:

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

— неиспользуемые переменные,

— мертвый код,

— бесконечные циклы,

— переменные с неопределенными значениями,

— неправильный синтаксис.

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

Модульное тестирование(Unit-testing) —
уровень тестирования, на котором
тестируется минимально возможный для
тестирования компонент, например,
отдельный класс или функция. На этом
уровне применяются методы «белого
ящика». В современных проектах модульное
тестирование («юнит-тестинг») осуществляется
разработчиками.

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

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

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

Интеграционное тестирование(Integration
testing) – уровень тестирования, на котором
отдельные программные модули объединяются
и тестируются в группе. Обычно
интеграционное тестирование проводится
после модульного тестирования (юнит-тесты
для модулей должны быть выполнены и
найденные ошибки исправлены).

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

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

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

Системное тестирование(System
testing)— это
тестирование программного обеспечения,
выполняемое на полной, интегрированной
системе, с целью проверки соответствия
системы исходным требованиям. Системное
тестирование относится к методам
тестирования «чёрного ящика», и, тем
самым, не требует знаний о внутреннем
устройстве системы.

Системное
тестирование
выполняется через внешние интерфейсы
программного обеспечения и тесно связано
с тестированием
пользовательского
интерфейса
(или через пользовательский интерфейс),
проводимым при помощи имитации действий
пользователей над элементами этого
интерфейса. Частными случаями этого
вида тестирования
являются тестирование
графического
пользовательского интерфейса
(Graphical User Interface, GUI) и пользовательского
интерфейса Web-приложений (WebUI).
Системное тестирование выполняется
инженерами по тестированию.

Приемочное тестирование(Acceptance testing)—
это тестирование готового продукта
конечными пользователями на реальном
окружении, в котором будет функционировать
тестируемое приложение. Приемочные
тесты разрабатываются пользователями,
обычно, в виде сценариев. Для того, чтобы
найти больше ошибок рекомендуется
планировать не только системное
тестирование и приемочное, но и модульное
и интеграционное.

Рис.14. Уровни тестирования

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

Примеры статического
тестирования:

Обзоры
(Reviews)

Инспекции
(Inspections)

Сквозные
просмотры (Walkthroughs)

Аудиты
(Audits)

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

Динамическое
тестирование
(Dynamic
testing)–
тестирование, в ходе которого тестируемая
программа (код) выполняется (запускается).

Альфа-тестирование—
тестирование в процессе разработки

Бета-тестирование— тестирование
выполняется пользователями (end-users)

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

Регрессионное
тестирование (Regression
testing)
– тестирование функциональности,
которая была уже протестирована до
внесения какого-либо изменения.

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

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

Определение успешности регрессионных
тестов (IEEE 610-90 “Standard Glossary of Software
Engineering Terminology”) гласит: “повторное
выборочное тестирование системы или
компонент для проверки сделанных
модификаций не должно приводить к
непредусмотренным эффектам”. На практике
это означает, что если система успешно
проходила тесты до внесения модификаций,
она должна их проходить и после внесения
таковых. Основная проблема регрессионного
тестирования заключается в поиске
компромисса между имеющимися ресурсами
и необходимостью проведения таких
тестов по мере внесения каждого изменения.
В определенной степени, задача состоит
в том, чтобы определить критерии
“масштабов” изменений, с достижением
которых необходимо проводить регрессионные
тесты.

«Смок-тест»
(Smoke
Testing,
«дымовое
тестирование») в
тестировании означает минимальный
набор тестов на явные ошибки. Дымовой
тест обычно выполняется самим
программистом; не проходящую этот тест
программу не имеет смысла отдавать на
более глубокое тестирование.

***История.

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

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

5.1.3
Виды тестирования

Функциональное тестирование(functional testing)

• каждое функциональное требование
  транслируется в тест-кейсы (используя
  техники «черного ящика») для того,
  чтобы проверить, что система функционирует
  в точности, как и описано в спецификации
  (функциональных требованиях к системе)

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

Тестирование производительности(perfomance testing)

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

• продемонстрировать, что система
  удовлетворяет критериям производительности
  при заданных условиях

• измерить, какая часть системы является
  причиной «плохой» производительности
  системы

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

Стрессовое тестирование (stress
testing)

• тестирование операционных характеристик
  приложения в условиях ограниченных
  ресурсов (например, скорость, память,
  место на диске и т.д.)

• проверить, что система в стрессовых
  условиях не прекращает свою работу
  некорректным образом (без сохранения
  копии базы данных, вывода сообщения
  пользователям и т.п.)

Нагрузочное тестирование (load
testing)

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

• основным понятием нагрузочного
  тестирования является «виртуальный
  пользователь». Управляя числом
  виртуальных пользователей, тестировщик
  управляет нагрузкой на систему .

• определяем, при какой максимальной
  нагрузке (максимальном количестве
  пользователей) система способна
  функционирвать в соответствии с
  требованиями к производительности

• HP LoadRunner

Тестирование удобства использования
(usability testing)

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

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

При испытании
многих продуктов пользователю предлагают
в «лабораторных» условиях решить
основные задачи, для выполнения которых
этот продукт разрабатывался, и просят
высказывать во время выполнения этих
тестов свои замечания.

Процесс тестирования
фиксируется в протоколе (логе) и/или на
аудио- и видеоустройства — с целью
последующего более детального анализа.

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

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

Основную трудность
после проведения процедуры
юзабилити-тестирования нередко
представляют большие объёмы и
беспорядочность полученных данных.
Поэтому для последующего анализа важно
зафиксировать:

1. Речь модератора и респондента;

2. Выражение лица респондента (снимается
   на видеокамеру);

3. Изображение экрана компьютера, с которым
   работает респондент;

4. Различные события, происходящие на
   компьютере, связанные с действиями
   пользователя:

• Перемещение курсора и нажатия на
  клавиши мыши;

• Использование клавиатуры;

• Переходы между экранами (браузера или
  другой программы).

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

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

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

Тестирование интерфейса пользователя(UI testing)

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

• проверяем, как приложение обрабатывает
  ввод с клавиатуры и «мышки» и как
  отображаются элементы графического
  интерфейса (текст, кнопки, меню, списки
  и прочие элементы).

Тестирование безопасности (security
testing)

— оценка уязвимости программного
обеспечения к различным атакам.

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

• попытки узнать пароль с помощью внешних
  средств;

• атака системы с помощью специальных
  утилит, анализирующих защиты;

• подавление, ошеломление системы (в
  надежде, что она откажется обслуживать
  других клиентов);

• целенаправленное введение ошибок в
  надежде проникнуть в систему в ходе
  восстановления;

• просмотр несекретных данных в надежде
  найти ключ для входа в систему.

Тестирование локализации (localization
testing)

• проверяем функционирует ли система
  как ожидается под разными языковыми
  локализациями операционных систем

Тестирование совместимости
(compatibility testing)

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

и др.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #