Стратегия тестирования каждого программного продукта разная. Перед разработкой стратегии тестирования программного обеспечения нам необходимо рассмотреть бизнес-цели и/или цель программного обеспечения. Например, программное обеспечение, которое работает в самолете, которое контролирует двигатель и безопасность полета, имеет другой бизнес-контекст, чем платформа для вирусного обмена видео в Интернете для детей. Для программного обеспечения самолета очень важно, чтобы абсолютно все было определено и проверено. Быстрая разработка и изменение новых функций не является приоритетом. Для платформы вирусного видео бизнесу нужны инновации, скорость и быстрое улучшение, которые гораздо важнее, чем гарантированная проверка системы. Каждый контекст отличается, и существует множество различных практик тестирования программного обеспечения. Построение стратегии тестирования будет состоять из смеси соответствующих типов тестирования из списка возможных типов тестирования, которые классифицируются ниже. В этой статье мы перечислим различные типы тестирования программного обеспечения.
Модульное тестирование — это тестирование отдельной функции, класса или модуля независимо от тестирования полностью работающего программного обеспечения. Используя структуру для модульного тестирования, программист может создавать тестовые примеры с вводом и ожидаемым выводом. Наличие сотен, тысяч или десятков тысяч примеров модульного тестирования для большого программного проекта гарантирует, что все отдельные модули работают должным образом, пока вы продолжаете изменять код. При изменении модуля, который имеет тестовые примеры, тестовые примеры для этого модуля должны быть изучены и определить, нужны ли новые тестовые примеры, изменились ли выходные данные или текущие тестовые примеры могут быть удалены, поскольку они больше не актуальны. Создание большого объема модульных тестов — это самый простой способ достичь высокого покрытия тестовых примеров для базы программного кода, но не гарантирует, что конечный продукт будет работать как система, как ожидалось.
Функциональное тестирование — наиболее распространенная форма тестирования. Когда люди относятся к тестированию программного обеспечения без каких-либо подробностей, они часто имеют в виду функциональное тестирование. Функциональное тестирование позволит проверить основные функции программного обеспечения, как ожидается. План тестирования может быть написан для описания всех функциональных тестовых случаев, которые будут тестироваться, что соответствует основным функциям и возможностям программного обеспечения. Первичным тестированием функциональности будет тестирование « счастливого пути», которое не пытается сломать программное обеспечение или использовать его в любых сложных сценариях. Это должен быть абсолютный минимум тестирования для любого программного проекта.
После модульного тестирования и функционального тестирования может остаться несколько модулей или вся система, которые еще не были протестированы в целом. Или могут быть компоненты, которые в значительной степени независимы, но иногда используются вместе. Каждый раз, когда компоненты или модули тестируются независимо, но не как система в целом, необходимо выполнять интеграционное тестирование, чтобы проверить, как компоненты работают вместе как рабочая система в соответствии с требованиями и ожиданиями пользователей.
Подумайте о стресс-тестах, как о космическом шаттле или самолете. Что значит поместить ваше программное обеспечение или систему в режим «СТРЕСС»? Стресс — это не что иное, как интенсивная нагрузка определенного типа, которая, скорее всего, сломает вашу систему. Это может быть похоже на «нагрузочное тестирование» в том смысле, что ваша система подвергается высокому параллелизму, когда к системе обращается множество пользователей. Но напряжение системы может происходить и на других векторах. Например, запуск микропрограммы на аппаратном компоненте, когда аппаратное обеспечение имеет физический износ и работает в ухудшенном режиме. Стресс является уникальным для всех типов программного обеспечения, и при разработке систем и при разработке стресс-тестов следует учитывать, какие естественные или неестественные причины с наибольшей вероятностью могут вызвать нагрузку на ваше программное обеспечение или систему.
Нагрузочное тестирование — это особый тип стресс-тестирования, как обсуждалось выше, при котором большое количество одновременных пользовательских подключений и обращений автоматизировано для создания имитации эффекта одновременного доступа большого количества подлинных пользователей к вашей программной системе. Цель состоит в том, чтобы выяснить, сколько пользователей могут получить доступ к вашей системе одновременно без нарушения работы вашей программной системы. Если ваша система может легко обрабатывать обычный трафик 10 000 пользователей, что произойдет, если ваш веб-сайт или программное обеспечение станут вирусными и привлекут 1 миллион пользователей? Сможет ли эта неожиданная «НАГРУЗКА» сломать ваш сайт или систему? Нагрузочное тестирование будет имитировать это, поэтому вы можете быть уверены в будущем увеличении числа пользователей, потому что знаете, что ваша система может выдержать возросшую нагрузку.
Люди могут полностью разочароваться и впасть в отчаяние, если программное обеспечение не соответствует их требованиям к производительности. Производительность, как правило, означает, насколько быстро могут быть выполнены важные функции. Чем более сложные и динамичные функции доступны в системе, тем более важным и неочевидным становится проверка ее производительности. Давайте возьмем базовый пример — операционная система Windows или Linux. Операционная система — это очень сложный программный продукт, и тестирование производительности в ее системе может включать скорость и синхронизацию таких функций, как загрузка, установка приложения, поиск файла, выполнение вычислений на графическом процессоре и/или любые другие из миллионы действий, которые можно выполнить. При выборе тестовых сценариев производительности следует проявлять осторожность, чтобы убедиться, что проверены важные и потенциально неисправные функции производительности.
Тестирование на вашем ноутбуке — это хорошо, но недостаточно, когда вы создаете социальную сеть, систему электронной почты или программное обеспечение для суперкомпьютера. Если ваше программное обеспечение предназначено для развертывания на 1000 серверов, все они будут функционировать в унисон, то тестирование, которое вы проводите локально в одной системе, не обнаружит ошибок, которые возникают, когда программное обеспечение развертывается «в масштабе» на сотнях тысяч экземпляров. На самом деле, ваше тестирование, скорее всего, никогда не сможет быть запущено в полном масштабе до выпуска в производство, потому что было бы слишком дорого и непрактично построить тестовую систему с 1000 серверами стоимостью в миллионы долларов. Следовательно, тестирование масштабируемости проводится на нескольких серверах, но обычно не на полном количестве рабочих серверов, чтобы попытаться выявить некоторые из дефектов, которые могут быть обнаружены при использовании ваших систем в более крупной инфраструктуре.
Статический анализ — это тестирование, которое выполняется путем проверки программного кода без его фактического запуска. Для проведения статического анализа, как правило, вы должны использовать инструмент, их много, один известный инструмент — это Coverity. Статический анализ легко запустить перед выпуском программного обеспечения, и он может найти множество проблем с качеством в вашем коде, которые можно исправить до выпуска. Могут быть обнаружены ошибки памяти, ошибки обработки типов данных, разыменование нулевого указателя, неинициализированные переменные и многие другие дефекты. Такие языки, как C и C ++, значительно выигрывают от статического анализа, потому что языки предоставляют большую свободу программистам в обмен на большую мощность, но это также может создавать большие ошибки и ошибки, которые можно найти с помощью тестирования статического анализа.
Некоторые ошибки очень сложно моделировать или запускать, поэтому программное обеспечение может быть разработано так, чтобы искусственно вводить проблему или сбой в систему без естественного возникновения дефекта. Цель тестирования с внесением неисправностей — увидеть, как программное обеспечение обрабатывает эти неожиданные неисправности. Изящно ли он реагирует на ситуацию, дает ли он сбой или дает неожиданные и непредсказуемые проблемные результаты? Например, предположим, что у нас есть банковская система, и есть модуль для внутреннего перевода средств со СЧЕТА A на СЧЕТ B. Однако эта операция перевода вызывается только после того, как система уже проверила, что эти учетные записи существуют, до вызова операции перевода. . Несмотря на то, что мы предполагаем, что обе учетные записи действительно существуют, операция передачи имеет сбой, когда одна целевая или исходная учетная запись не существует, и что это может вызвать ошибку. Поскольку в нормальных условиях мы никогда не получаем эту ошибку из-за предварительного тестирования входных данных, поэтому для проверки поведения системы при сбое передачи из-за несуществующей учетной записи мы вводим ложную ошибку в систему, которая возвращает несуществующую учетную запись. для передачи и проверьте, как остальная система реагирует в этом случае. Очень важно, чтобы код внедрения неисправности был доступен только в сценариях тестирования и не выпускался в производство, где он мог бы создать хаос.
При использовании таких языков, как C или C ++, программист несет большую ответственность за прямую адресацию памяти, и это может вызвать фатальные ошибки в программном обеспечении, если будут сделаны ошибки. Например, если указатель равен нулю и разыменован, программное обеспечение выйдет из строя. Если для объекта выделяется память, а затем строка копируется в пространство памяти объекта, обращение к объекту может вызвать сбой или даже неопределенное неправильное поведение. Поэтому очень важно использовать инструмент, чтобы попытаться обнаружить ошибки доступа к памяти в программном обеспечении, использующем такие языки, как C или C ++, которые могут иметь эти потенциальные проблемы. Инструменты, которые могут выполнять этот тип тестирования, включают Valgrind с открытым исходным кодом или проприетарные инструменты, такие как PurifyPlus.. Эти инструменты могут спасти ситуацию, когда непонятно, почему программное обеспечение дает сбой или работает неправильно, и напрямую указывают на то место в коде, где есть ошибка. Классно, правда?
Когда вы находитесь на так называемой границе, легко допустить ошибку при кодировании. Например, банкомат банка сообщает, что вы можете снять максимум 300 долларов. Итак, представьте, что кодер естественным образом написал следующий код при создании этого требования:
Вы можете заметить ошибку? Пользователь, который пытается вывести 300 долларов, получит сообщение об ошибке, поскольку сумма не менее 300 долларов. Это ошибка. Следовательно, проверка границ выполняется естественным образом. Затем границы требований обеспечивают правильное функционирование программного обеспечения по обе стороны границы и границы.
Высокоскоростная генерация входных данных для программного обеспечения может производить как можно больше возможных входных комбинаций, даже если эти входные комбинации являются полной ерундой и никогда не будут предоставлены реальным пользователем. Этот тип нечеткого тестирования может найти ошибки и уязвимости безопасности, не обнаруженные другими способами из-за большого объема входных данных и сценариев, быстро тестируемых без создания ручного тестового примера.
Закройте глаза и представьте себе, что означает слово «исследовать». Вы наблюдаете и исследуете систему, чтобы узнать, как она действительно функционирует. Представьте, что вы получили по почте новое рабочее кресло, состоящее из 28 частей в отдельных пластиковых пакетах без каких-либо инструкций. Вы должны изучить свое новое прибытие, чтобы понять, как оно функционирует и как устроено. Обладая этим духом, вы можете стать исследовательским тестером. У вас не будет четко определенного плана тестирования тестовых случаев. Вы исследуете и исследуете свое программное обеспечение в поисках вещей, которые заставят вас сказать замечательное слово: «ИНТЕРЕСНО!». Узнав, вы исследуете дальше и найдете способы взломать программное обеспечение, о котором никогда не думали разработчики, а затем предоставите отчет, в котором подробно описаны многочисленные неверные предположения, ошибки и риски в программном обеспечении.
В мире безопасности программного обеспечения тестирование на проникновение является одним из основных средств тестирования. Все системы, биологические, физические или программные, имеют границы и границы. Эти границы предназначены для того, чтобы позволить входить в систему только определенным сообщениям, людям или компонентам. Более конкретно, давайте рассмотрим систему онлайн-банкинга, которая использует аутентификацию пользователя для входа на сайт. Если сайт можно взломать и ввести в серверную часть без надлежащей аутентификации, это будет проникновение, от которого необходимо защитить себя. Целью тестирования на проникновение является использование известных и экспериментальных методов для обхода обычных границ безопасности программной системы или веб-сайта. Тестирование на проникновение часто включает в себя проверку всех портов, которые прослушивают и пытаются войти в систему через открытый порт.
После того, как у вас есть работающее программное обеспечение, которое развернуто в полевых условиях, крайне важно предотвратить внесение ошибок в функциональность, которая уже работала. Целью разработки программного обеспечения является повышение возможностей вашего продукта, внесение ошибок или прекращение работы старых функций, что называется РЕГРЕССИЕЙ. Регрессия — это ошибка или дефект, появившийся, когда ранее возможность работала должным образом. Ничто не может испортить репутацию вашего программного обеспечения или бренда быстрее, чем внесение регрессионных ошибок в ваше программное обеспечение и предоставление реальным пользователям возможности найти эти ошибки после выпуска.
Случаи регрессионного тестирования и планы тестирования должны быть построены на основе основных функций, которые должны продолжать работать, чтобы пользователи могли хорошо взаимодействовать с вашим приложением. Все основные функции вашего программного обеспечения, которые, как ожидают пользователи, будут работать определенным образом, должны иметь регрессионный тестовый пример, который можно выполнить, чтобы предотвратить нарушение функциональности в новом выпуске. Это может быть от 50 до 50 000 тестовых случаев, охватывающих основные функции вашего программного обеспечения или приложения.
В программном обеспечении была обнаружена ошибка, но не очевидно, в какой версии выпуска появилась новая ошибка. Представьте себе, что было 50 программных коммитов с последнего известного времени, когда программа работала без ошибок, до того момента, когда …
Представьте себе погодное приложение, которое показывает текущую и прогнозируемую погоду в вашем регионе, а также описание погодных условий. Первая часть тестирования локализации — убедиться, что правильный язык, алфавит и символы отображаются правильно, в зависимости от геолокации пользователя. Приложение в Великобритании должно отображаться на английском языке с использованием латинских символов; то же приложение в Китае должно отображаться китайскими иероглифами на китайском языке. После более тщательного тестирования локализации с приложением будет взаимодействовать более широкий круг людей из разных геолокаций.
Некоторые граждане нашего сообщества имеют инвалидность и, следовательно, могут испытывать проблемы с использованием создаваемого программного обеспечения, поэтому проводится тестирование доступности, чтобы гарантировать, что люди с ограниченными возможностями по-прежнему могут получить доступ к функциям системы. Например, если мы предположим, что 1% населения страдает дальтонизмом, а наш программный интерфейс предполагает, что пользователи могут различать красный и зеленый, но эти люди с дальтонизмом НЕ МОГУТ увидеть разницу. Следовательно, хорошо продуманный программный интерфейс помимо цвета будет иметь дополнительные подсказки для обозначения значения. Другие сценарии, помимо тестирования на дальтонизм, также будут включены в тестирование доступности программного обеспечения, например, полная зрительная слепота, глухота и многие другие сценарии. Хороший программный продукт должен быть доступен максимальному проценту потенциальных пользователей.
Простые приложения на телефоне, операционные системы, такие как Ubuntu, Windows или Linux Mint, а также программное обеспечение, работающее на атомных подводных лодках, нуждаются в частом обновлении. Сам процесс обновления может привести к ошибкам и дефектам, которых не было бы при новой установке, потому что состояние среды было другим, и процесс внедрения нового программного обеспечения поверх старого мог привести к ошибкам. Рассмотрим простой пример: у нас есть ноутбук с Ubuntu 18.04, и мы хотим перейти на Ubuntu 20.04. Этот процесс установки операционной системы отличается от непосредственной очистки жесткого диска и установки Ubuntu 20.04. Следовательно, после установки программного обеспечения или любой из его производных функций оно может не работать на 100%, как ожидалось, или так же, как при новой установке программного обеспечения. Так, мы должны сначала рассмотреть возможность тестирования самого обновления во многих различных случаях и сценариях, чтобы убедиться, что обновление работает до конца. И затем мы также должны рассмотреть возможность тестирования фактической системы после обновления, чтобы убедиться, что программное обеспечение установлено и функционирует должным образом. Мы не будем повторять все тестовые примеры для только что установленной системы, что было бы пустой тратой времени, но мы будем тщательно продумывать, зная, что система МОЖЕТ сломаться во время обновления, и стратегически добавлять тестовые примеры для этих функций.
«Черный ящик» и «белый ящик» — это менее конкретные методики тестирования и больше категорий типов тестирования. По сути, тестирование методом черного ящика, которое предполагает, что тестировщик ничего не знает о внутренней работе программного обеспечения, и создает план тестирования и тестовые примеры, которые просто смотрят на систему извне, чтобы проверить ее работу. Тестирование методом «белого ящика» выполняется архитекторами программного обеспечения, которые понимают внутреннюю работу программной системы и разрабатывают кейсы со знанием того, что может, будет, должно и может сломаться. Тестирование как в черном, так и в белом ящике может выявить различные типы дефектов.
(1 оценок, среднее: 5,00 из 5)
Загрузка...
Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!
Спасибо! Ваша заявка принята
Спасибо! Ваша заявка принята
