Phenquestions
Модульное тестирование
Модульное тестирование - это тестирование отдельной функции, класса или модуля независимо от тестирования полностью работающего программного обеспечения. Используя фреймворк для модульного тестирования, программист может создавать тестовые примеры с вводом и ожидаемым выводом. Наличие сотен, тысяч или десятков тысяч случаев модульного тестирования для большого программного проекта гарантирует, что все отдельные модули работают должным образом, пока вы продолжаете изменять код. При изменении модуля, в котором есть тестовые примеры, необходимо изучить тестовые примеры для этого модуля и определить, нужны ли новые тестовые примеры, изменились ли выходные данные или текущие тестовые примеры могут быть удалены, поскольку они больше не актуальны. Создание большого объема модульных тестов - самый простой способ достичь высокого покрытия тестовых случаев для базы программного кода, но не гарантирует, что конечный продукт будет работать как система, как ожидалось.
Функциональное тестирование
Функциональное тестирование - наиболее распространенная форма тестирования. Когда люди относятся к тестированию программного обеспечения без особых подробностей, они часто имеют в виду функциональное тестирование. Функциональное тестирование проверит работу основных функций программного обеспечения, как ожидалось. План тестирования может быть написан для описания всех функциональных тестовых случаев, которые будут тестироваться, что соответствует основным функциям и возможностям программного обеспечения. Первичное функциональное тестирование будет «счастливый путь » тестирование, которое не пытается взломать программное обеспечение или использовать его в каких-либо сложных сценариях. Это должен быть абсолютный минимум тестирования для любого программного проекта.
Интеграционное тестирование
После модульного тестирования и функционального тестирования может быть несколько модулей или вся система, которые еще не тестировались как единое целое. Или могут быть компоненты, которые в значительной степени независимы, но иногда используются вместе. Каждый раз, когда компоненты или модули тестируются независимо, но не как целая система, следует проводить интеграционное тестирование, чтобы проверить, что компоненты работают вместе как рабочая система в соответствии с требованиями и ожиданиями пользователей.
нагрузочное тестирование
Подумайте о стресс-тестировании, как о космическом шаттле или самолете. Что значит поместить ваше программное обеспечение или систему в категорию «СТРЕСС»? Стресс - это не что иное, как интенсивная нагрузка определенного типа, которая, скорее всего, сломает вашу систему. Это может быть похоже на «нагрузочное тестирование» в том смысле, что ваша система подвергается высокому параллелизму, когда к системе обращается множество пользователей. Но напряжение системы может происходить и на других векторах. Например, запуск микропрограммы на аппаратном компоненте, когда аппаратное обеспечение имеет физический износ и работает в ухудшенном режиме. Стресс является уникальным для всех типов программного обеспечения, поэтому при разработке систем и при разработке стресс-тестов следует учитывать, какие естественные или неестественные причины с наибольшей вероятностью вызовут нагрузку на ваше программное обеспечение или систему.
Нагрузочное тестирование
Нагрузочное тестирование - это особый тип стресс-тестирования, как обсуждалось выше, при котором большое количество одновременных пользовательских подключений и доступов автоматизируются для создания имитации эффекта одновременного доступа большого количества аутентичных пользователей к вашей программной системе. Цель состоит в том, чтобы выяснить, сколько пользователей могут получить доступ к вашей системе одновременно, не нарушая работу вашей программной системы. Если ваша система может легко обрабатывать обычный трафик 10000 пользователей, что произойдет, если ваш веб-сайт или программное обеспечение станут вирусными и привлекут 1 миллион пользователей? Будет ли это неожиданным "НАГРУЗКА" сломать ваш сайт или систему? Нагрузочное тестирование будет имитировать это, так что вы будете уверены в будущем увеличении числа пользователей, потому что знаете, что ваша система может справиться с возросшей нагрузкой.
Тестирование производительности
Люди могут полностью разочароваться и впасть в отчаяние, если программное обеспечение не соответствует их требованиям к производительности. Производительность, как правило, означает, насколько быстро могут быть выполнены важные функции. Чем сложнее и динамичнее функции доступны в системе, тем более важным и неочевидным становится проверка ее производительности, давайте возьмем базовый пример, операционная система Windows или Linux. Операционная система - это очень сложный программный продукт, и тестирование производительности в ее системе может включать скорость и синхронизацию таких функций, как загрузка, установка приложения, поиск файла, выполнение вычислений на графическом процессоре и / или любые другие из миллионы действий, которые можно выполнить. Следует проявлять осторожность при выборе тестовых примеров производительности, чтобы убедиться, что проверенные важные характеристики производительности, которые могут привести к сбою,.
Тестирование масштабируемости
Тестирование на вашем ноутбуке - это хорошо, но недостаточно, когда вы создаете социальную сеть, почтовую систему или программное обеспечение для суперкомпьютера. Если ваше программное обеспечение предназначено для развертывания на 1000 серверов, и все они будут работать в унисон, то тестирование, которое вы проводите локально в одной системе, не обнаружит ошибок, которые возникают, когда программное обеспечение развертывается «в масштабе» на сотнях тысяч экземпляров. На самом деле, ваше тестирование, скорее всего, никогда не сможет быть запущено в полном масштабе до выпуска в производство, потому что было бы слишком дорого и непрактично построить тестовую систему с 1000 серверами стоимостью в миллионы долларов. Следовательно, тестирование масштабируемости проводится на нескольких серверах, но обычно не на полном количестве рабочих серверов, чтобы попытаться выявить некоторые из дефектов, которые могут быть обнаружены при использовании ваших систем в более крупной инфраструктуре.
Статический анализ
Статический анализ - это тестирование, которое выполняется путем проверки программного кода без его фактического запуска. Для статического анализа, как правило, вы должны использовать инструмент, их много, один известный инструмент - это Coverity. Статический анализ легко запустить перед выпуском программного обеспечения, и он может найти множество проблем с качеством в вашем коде, которые можно исправить до выпуска. Могут быть обнаружены ошибки памяти, ошибки обработки типов данных, разыменование нулевого указателя, неинициализированные переменные и многие другие дефекты. Такие языки, как C и C ++, значительно выигрывают от статического анализа, потому что языки предоставляют большую свободу программистам в обмен на большую мощность, но это также может создавать большие ошибки и ошибки, которые можно найти с помощью тестирования статического анализа.
Тестирование методом впрыска неисправностей
Некоторые состояния ошибки очень сложно моделировать или запускать, поэтому программное обеспечение может быть разработано так, чтобы искусственно вводить проблему или сбой в систему без естественного возникновения дефекта. Цель тестирования с внесением ошибок - увидеть, как программное обеспечение обрабатывает эти неожиданные сбои. Изящно ли он реагирует на ситуацию, дает ли он сбой или дает неожиданные и непредсказуемые проблемные результаты? Например, предположим, что у нас есть банковская система, и есть модуль для внутреннего перевода средств со СЧЕТА A на СЧЕТ B. Однако эта операция переноса вызывается только после того, как система уже проверила существование этих учетных записей перед вызовом операции переноса. Несмотря на то, что мы предполагаем, что обе учетные записи действительно существуют, операция передачи имеет случай сбоя, когда одна целевая или исходная учетная запись не существует, и что она может вызвать ошибку. Поскольку в обычных обстоятельствах мы никогда не получаем эту ошибку из-за предварительного тестирования входных данных, поэтому для проверки поведения системы, когда передача не выполняется из-за несуществующей учетной записи, мы вводим поддельную ошибку в систему, которая возвращает несуществующую учетную запись. для передачи и проверьте, как остальная система реагирует в этом случае. Очень важно, чтобы код внедрения неисправности был доступен только в сценариях тестирования и не выпускался в производство, где он мог бы создать хаос.
Тестирование переполнения памяти
При использовании таких языков, как C или C ++, программист несет большую ответственность за прямую адресацию памяти, и это может вызвать фатальные ошибки в программном обеспечении, если будут сделаны ошибки. Например, если указатель равен нулю и разыменован, программа выйдет из строя. Если для объекта выделяется память, а затем строка копируется в пространство памяти объекта, обращение к объекту может вызвать сбой или даже неуказанное неправильное поведение. Поэтому очень важно использовать инструмент, чтобы попытаться отловить ошибки доступа к памяти в программном обеспечении, которое использует такие языки, как C или C ++, которые могут иметь эти потенциальные проблемы. Инструменты, которые могут выполнять этот тип тестирования, включают Valgrind с открытым исходным кодом или проприетарные инструменты, такие как PurifyPlus. Эти инструменты могут спасти ситуацию, когда непонятно, почему программное обеспечение дает сбой или ведет себя неправильно, и напрямую указывают на то место в коде, где есть ошибка. Отлично, правда?
Граничное тестирование
Когда вы находитесь на так называемой границе, легко допустить ошибку при кодировании. Например, банкомат банка сообщает, что вы можете снять максимум 300 долларов. Итак, представьте, что кодер естественным образом написал следующий код при создании этого требования:
Если (amt < 300)startWithdrawl ()
еще
ошибка («Вы можете снять% s», amt);
Вы можете заметить ошибку? Пользователь, который пытается вывести 300 долларов, получит сообщение об ошибке, потому что сумма не менее 300 долларов. Это ошибка. Следовательно, проверка границ выполняется естественным образом. Затем границы требований обеспечивают правильную работу программного обеспечения по обе стороны границы и границы.
Fuzz-тестирование
Высокоскоростная генерация входных данных для программного обеспечения может создать как можно больше возможных комбинаций входных данных, даже если эти входные комбинации являются полной ерундой и никогда не будут предоставлены реальным пользователем. Этот тип нечеткого тестирования может найти ошибки и уязвимости безопасности, не обнаруженные другими способами из-за большого объема входных данных и сценариев, быстро тестируемых без ручного создания тестовых примеров.
Исследовательское тестирование
Закройте глаза и представьте себе, что означает слово «исследовать». Вы наблюдаете и исследуете систему, чтобы узнать, как она действительно функционирует. Представьте, что вы получили по почте новое рабочее кресло, состоящее из 28 частей в отдельных пластиковых пакетах без каких-либо инструкций. Вы должны изучить свое новое прибытие, чтобы понять, как оно функционирует и как оно устроено. С этим духом вы можете стать исследовательским тестером. У вас не будет четко определенного плана тестирования тестовых случаев. Вы исследуете и исследуете свое программное обеспечение в поисках вещей, которые заставят вас сказать замечательное слово: «ИНТЕРЕСНО!”. По мере обучения вы исследуете дальше и находите способы взломать программное обеспечение, о котором никогда не думали разработчики, а затем предоставляете отчет, в котором подробно описываются многочисленные неверные предположения, ошибки и риски в программном обеспечении. Узнайте больше об этом в книге "Исследуй это".
Тестирование на проникновение
В мире безопасности программного обеспечения тестирование на проникновение является одним из основных средств тестирования. Все системы, биологические, физические или программные, имеют границы и границы. Эти границы предназначены для того, чтобы позволить только определенным сообщениям, людям или компонентам входить в систему. Более конкретно, давайте рассмотрим систему онлайн-банкинга, которая использует аутентификацию пользователя для входа на сайт. Если сайт можно взломать и ввести в серверную часть без надлежащей аутентификации, это будет проникновение, которое необходимо защитить от. Целью тестирования на проникновение является использование известных и экспериментальных методов для обхода обычных границ безопасности программной системы или веб-сайта. Тестирование на проникновение часто включает проверку всех портов, которые прослушивают и пытаются войти в систему через открытый порт. Другие распространенные методы включают SQL-инъекцию или взлом пароля.
Регрессионное тестирование
После того, как у вас есть рабочее программное обеспечение, которое развернуто в полевых условиях, очень важно предотвратить внесение ошибок в функциональность, которая уже работала. Целью разработки программного обеспечения является повышение возможностей вашего продукта, введение ошибок или прекращение работы старых функций, что называется РЕГРЕССИЕЙ. Регрессия - это ошибка или дефект, возникший, когда ранее возможность работала должным образом. Ничто не может испортить репутацию вашего программного обеспечения или бренда быстрее, чем внесение регрессионных ошибок в ваше программное обеспечение и предоставление реальным пользователям возможности найти эти ошибки после выпуска.
Случаи регрессионного тестирования и планы тестирования должны быть построены на основе основных функций, которые должны продолжать работать, чтобы гарантировать, что у пользователей будет хороший опыт работы с вашим приложением. Все основные функции вашего программного обеспечения, которые, как ожидают пользователи, будут работать определенным образом, должны иметь регрессионный тестовый пример, который можно выполнить, чтобы предотвратить нарушение функциональности в новом выпуске. Это может быть от 50 до 50 000 тестовых случаев, охватывающих основные функции вашего программного обеспечения или приложения.
Тестирование исходного кода пополам
В программном обеспечении была обнаружена ошибка, но не очевидно, в какой версии выпуска появилась новая ошибка. Представьте, что было 50 коммитов программного обеспечения с последнего известного времени, когда программа работала без ошибок, до того момента, когда…
Тестирование локализации
Представьте себе погодное приложение, которое показывает текущую и прогнозируемую погоду в вашем регионе, а также описание погодных условий. Первая часть тестирования локализации - убедиться, что правильный язык, алфавит и символы отображаются правильно, в зависимости от геолокации пользователя. Приложение в Великобритании должно отображаться на английском языке с использованием латинских символов; то же приложение в Китае должно отображаться китайскими иероглифами на китайском языке. Проведено более тщательное тестирование локализации, более широкий круг людей из разных геолокаций будет взаимодействовать с приложением.
Тестирование доступности
Некоторые граждане нашего сообщества имеют инвалидность и, следовательно, могут иметь проблемы с использованием создаваемого программного обеспечения, поэтому проводится тестирование доступности, чтобы гарантировать, что люди с ограниченными возможностями по-прежнему могут получить доступ к функциям системы. Например, если мы предположим, что 1% населения страдает дальтонизмом, а наш программный интерфейс предполагает, что пользователи могут различать красный и зеленый, но эти дальтоники НЕ МОГУТ отличить. Следовательно, у хорошо продуманного программного интерфейса помимо цвета будут дополнительные подсказки, указывающие на значение. Другие сценарии, помимо тестирования на дальтонизм, также будут включены в тестирование доступности программного обеспечения, например, полная слепота зрения, глухота и многие другие сценарии. Хороший программный продукт должен быть доступен максимальному проценту потенциальных пользователей.
Обновление тестирования
Простые приложения на телефоне, операционные системы, такие как Ubuntu, Windows или Linux Mint, и программное обеспечение для работы атомных подводных лодок нуждаются в частом обновлении. Сам процесс обновления может привести к ошибкам и дефектам, которых не было бы при новой установке, потому что состояние среды было другим, и процесс внедрения нового программного обеспечения поверх старого мог привести к ошибкам. Возьмем простой пример, у нас есть ноутбук под управлением Ubuntu 18.04, и мы хотим перейти на Ubuntu 20.04. Это другой процесс установки операционной системы, чем непосредственная очистка жесткого диска и установка Ubuntu 20.04. Следовательно, после установки программного обеспечения или любой из его производных функций оно может не работать на 100%, как ожидалось, или так же, как когда программное обеспечение было недавно установлено. Итак, мы должны сначала рассмотреть возможность тестирования самого обновления во многих различных случаях и сценариях, чтобы убедиться, что обновление работает до конца. И затем мы также должны рассмотреть возможность тестирования фактической системы после обновления, чтобы убедиться, что программное обеспечение установлено и функционирует должным образом. Мы не будем повторять все тестовые примеры для только что установленной системы, что было бы пустой тратой времени, но мы тщательно подумаем, зная о системе, что МОЖЕТ сломаться во время обновления, и стратегически добавим тестовые примеры для этих функций.
Тестирование черного и белого ящиков
Черный ящик и белый ящик - это менее конкретные методологии тестирования и больше категорий типов тестирования. По сути, тестирование черного ящика, которое предполагает, что тестировщик ничего не знает о внутренней работе программного обеспечения, и строит план тестирования и тестовые примеры, которые просто смотрят на систему снаружи, чтобы проверить ее работу. Тестирование методом белого ящика выполняется архитекторами программного обеспечения, которые понимают внутреннюю работу программной системы и разрабатывают кейсы со знанием того, что может, должно, должно и может сломаться. Тестирование как в черном, так и в белом ящике может выявить различные типы дефектов.
Блоги и статьи по тестированию программного обеспечения
Тестирование программного обеспечения - это динамичная область, и здесь много интересных публикаций и статей, которые информируют сообщество о современных представлениях о тестировании программного обеспечения. Мы все можем извлечь пользу из этих знаний. Вот несколько интересных статей из разных источников в блогах, за которыми вы, возможно, захотите подписаться:
- 7 советов, которым нужно следовать перед тестированием без требований; http: // www.журналы тестирования.com /
- 60 лучших средств автоматизации тестирования: полное руководство по списку; https: // testguild.com /
- Инструменты тестирования баз данных с открытым исходным кодом; https: // www.программное обеспечение.com /
- 100-процентного охвата модульных тестов недостаточно; https: // www.липкие предметы.com /
- Нестабильные тесты в Google и способы их устранения; https: // тестирование.googleblog.com /
- Что такое регрессионное тестирование? ; https: // тест.io / блог /
- 27 лучших расширений Chrome для разработчиков в 2020 году; https: // www.lambdatest.com /
- 5 ключевых шагов тестирования программного обеспечения, которые должен выполнить каждый инженер; https: // techbeacon.com /
Продукты для тестирования программного обеспечения
Большинство ценных задач тестирования можно автоматизировать, поэтому неудивительно, что использование инструментов и продуктов для выполнения множества задач по обеспечению качества программного обеспечения - хорошая идея. Ниже мы перечислим некоторые важные и очень ценные программные инструменты для тестирования программного обеспечения, которые вы можете изучить и посмотреть, могут ли они помочь.
JUnit
Для тестирования программного обеспечения на основе Java JUnit предоставляет комплексный набор тестов для модульного и функционального тестирования кода, дружественного к среде Java.
Селен
Для тестирования веб-приложений Selenium предоставляет возможность автоматизировать взаимодействие с веб-браузерами, включая тестирование кросс-браузерной совместимости. Это лучшая тестовая инфраструктура для автоматизации веб-тестирования.
Огурец
Фреймворк тестирования на основе поведения позволяет бизнес-пользователям, менеджерам продуктов и разработчикам объяснять ожидаемую функциональность на естественном языке, а затем определять это поведение в тестовых примерах. Это делает более удобочитаемые тестовые примеры и четкое сопоставление с ожидаемыми пользовательскими функциями.
Очистить
Находите утечки и повреждения памяти во время выполнения, запуская свое программное обеспечение с помощью встроенного инструментария Purify Plus, который отслеживает использование памяти и указывает на ошибки в коде, которые нелегко найти без инструментария.
Валгринд
Инструменты с открытым исходным кодом, которые будут запускать ваше программное обеспечение и позволить вам взаимодействовать с ним, указывая отчет об ошибках кодирования, таких как утечки памяти и повреждения. Нет необходимости перекомпилировать или добавлять инструментарий в процесс компиляции, поскольку Valgrind обладает интеллектом, чтобы динамически понимать ваш машинный код и беспрепятственно внедрять инструменты, чтобы находить ошибки кодирования и помогать вам улучшать ваш код.
Покровительство
Инструмент статического анализа, который найдет ошибки кодирования в вашем программном обеспечении еще до того, как вы скомпилируете и запустите свой код. Coverity может найти уязвимости безопасности, нарушения соглашений о кодировании, а также ошибки и дефекты, которые ваш компилятор не найдет. Можно найти мертвый код, неинициализированные переменные и тысячи других типов дефектов. Перед выпуском в продакшн жизненно важно очистить код с помощью статического анализа.
JMeter
Фреймворк с открытым исходным кодом для тестирования производительности, ориентированный на разработчиков, использующих Java, отсюда J в названии. Тестирование веб-сайтов - один из основных вариантов использования JMeter в дополнение к тестированию производительности баз данных, почтовых систем и многих других серверных приложений.
Metasploit
Metasploit - это универсальный фреймворк с тысячами функций и возможностей для тестирования безопасности и проникновения. Используйте интерактивную консоль для доступа к предварительно закодированным эксплойтам и попробуйте проверить безопасность вашего приложения.
Академические исследования по тестированию программного обеспечения
- Исследовательская группа по тестированию Университета Шеффилда
- Лаборатория проверки и валидации программного обеспечения Университета Кентукки
- Исследовательская группа по тестированию программного обеспечения Университета штата Северная Дакота
- Интеллектуальная лаборатория системного тестирования; Чешский технический университет в Праге
- НАСА: Тестирование и исследование программного обеспечения Джона МакБрайда (JSTAR)
- Университет Макмастера; Лаборатория исследования качества программного обеспечения
- Технологический университет Онтарио; Лаборатория исследования качества программного обеспечения
- Техасский университет в Далласе; STQA
Заключение
Роль программного обеспечения в обществе продолжает расти, и в то же время мировое программное обеспечение становится более сложным. Чтобы мир функционировал, у нас должны быть методы и стратегии для тестирования и проверки программного обеспечения, которое мы создаем, выполняя функции, для которых оно предназначено. Для каждой сложной программной системы должны быть в наличии стратегия тестирования и план тестирования, чтобы продолжить проверку функциональности программного обеспечения, поскольку они продолжают улучшаться и обеспечивать его функции.
