Какая концепция тестирования программного обеспечения была самой ранней

Обновлено: 17.05.2024

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

• неопределенное количество
• один
• (Правильный ответ) зависит от критерия достаточности проверок

Какова мощность множества тестов, формально необходимая для тестирования операции в машине с 32-разрядным машинным словом?

Является ли программа аналогом математической формулы?

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

Какие предъявляются требования к идеальному критерию тестирования?

• (Правильный ответ) проверяемость
• достижимость
• (Правильный ответ) полнота
• (Правильный ответ) достаточность

Какая оценка мощности покрытия для следующих пар критериев правильна?

• тестирование функций Тестирование классов входных данных

Как реализуются динамические методы построения тестовых путей?

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

Какие существуют разновидности интеграционного тестирования?

• Регрессионное тестирование
• (Правильный ответ) восходящее тестирование
• (Правильный ответ) нисходящее тестирование
• (Правильный ответ) монолитное тестирование

Какие существуют особенности интеграционного тестирования для процедурного программирования?

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

Какие этапы включает методика ООП при тестировании программного комплекса?

• (Правильный ответ) тестирование взаимодействия модулей по всей иерархии комплекса
• (Правильный ответ) тестирование методов каждого класса программного комплекса
• (Правильный ответ) тестирование отношений между классами с помощью тестов на основе P-путей или MM-путей

Какие методы регрессионного тестирования применяются в условиях отсутствия программных средств поддержки регрессионного тестирования?

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

Почему MSC спецификация обеспечивает снижение
трудоемкости тестирования?

• (Правильный ответ) MSC описывает множество инвариантных сценариев, отличающихся численными значениями символических параметров
• (Правильный ответ) MSC позволяет сгенерировать сотни тестов, а соответствующий testbench автоматически прогнать их
• (Правильный ответ) одна MSC может кодировать множество параллельных или недетерминированных сценариев

Как определить цели тестирования программного проекта?

• (Правильный ответ) каков критерий качества тестирования
• (Правильный ответ) какие их свойства и характеристики подлежат тестированию
• каков график выполнения задач тестирования
• (Правильный ответ) определить части проекта, подлежащие тестированию

Какова методика разработки сценарных тестов?

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

Что такое прогон тестов?

• (Правильный ответ) анализ протоколов тестирования и принятие решения о прохождении или не прохождении (pass/fail) тестов
• (Правильный ответ) сохранение тестовых протоколов (test-log)
• (Правильный ответ) исполнение тестового набора в соответствии с задокументированными процедурами

Какие тестовые метрики используются при тестировании?

• (Правильный ответ) количество и плотность найденных дефектов
• (Правильный ответ) скорость нахождения дефектов
• (Правильный ответ) покрытие функциональных требований и покрытие кода продукта
• (Правильный ответ) покрытие множества сценариев

Какая информация должна сопровождать действие по исправлению ошибки и перевод дефекта в состояние Resolved?

• (Правильный ответ) краткий комментарий сделанных исправлений
• (Правильный ответ) причину возникновения дефекта
• (Правильный ответ) место исправления дефекта

Какие существуют особенности документа для описания тестовых
процедур?

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

Время тестирования при использовании метода выборочного регрессионного тестирования (с учетом времени работы самого метода)…

• меньше времени тестирования при использовании метода повторного прогона всех тестов
• равно времени тестирования при использовании метода повторного прогона всех тестов
• больше времени тестирования при использовании метода повторного прогона всех тестов
• (Правильный ответ) может быть больше или меньше времени тестирования при использовании метода повторного прогона всех тестов

При создании очередной версии программы была добавлена
функция A , функция D была удалена, функция C – изменена, а
функция U – оставлена без изменений. К какой группе
относится тест, покрывающий только функцию D ?

• тесты, требующие повторного запуска
• тесты, пригодные для повторного использования
• (Правильный ответ) устаревшие тесты
• новые тесты

При создании очередной версии программы была добавлена функция A , функция D была удалена, функция C – изменена, а функция U – оставлена без изменений. К какой группе относится тест, покрывающий только функцию D ?

• тесты, требующие повторного запуска
• новые тесты
• тесты, пригодные для повторного использования
• (Правильный ответ) устаревшие тесты

Дано: функция P , ее измененная версия P’ и набор тестов T , разработанный для тестирования P . Требуется, используя безопасный метод, отобрать подмножество T’ для тестирования P’ .

Pint abs(int number)< if (number >= 0) return -number; else return –number;>
P’int abs(int number)< if (number >= 0) return number; else return –number;>
T1. -12. 03. 1

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

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

Уровни тестирования

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

Интеграционное тестирование – это процесс исследования ПО, при котором тестируется интерфейсы между компонентами или подсистемами.

Системное тестирование – это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа и Бета тестирование относятся к подкатегориям системного тестирования.

Классификация видов тестирования

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

По объекту тестирования

Функциональное тестирование (functional testing) – тестирование ПО, направленное на проверку реализуемости функциональных требований. При функциональном тестировании проверяется способность ПО правильно решать задачи, необходимые пользователям.

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

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

Стресс-тестирование (stress testing) – тестирование ПО, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Это проверка программы в таких стрессовых ситуациях как наличие большого объёма входных параметров, нехватка дискового пространства или маломощный процессор.

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

Тестирование стабильности (stability/endurance/soak testing) – тестирование ПО, при котором проверяется работоспособность ПО при длительном тестировании со среднем уровнем нагрузки.

Тестирование безопасности (security testing) – тестирование ПО, которое проверяет фактическую реакцию защитных механизмов, встроенных в систему на проникновение злоумышленников.

Тестирование совместимости (compatibility testing) - тестирование ПО, которое проверяет работоспособность ПО в определенном окружении.

По знанию системы

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

Тестирование белого ящика (white box) - тестирование ПО, при котором тестировщик имеет доступ к исходному коду програмы и может писать код, связанный с библиотеками тестируемого ПО. К тестированию белого ящика относят методики: чтения программ, формальные просмотры программ, инспекции. Этот метод позволяет заглянуть внутрь "чёрного ящика" и сосредоточиться на внутренней информации, которая и определяет поведение программы. Основной трудностью является сложность отслеживания вычислений времени выполнения. При тестировании программы происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей. Даже для средних по сложности программ число таких путей может достигать десятки тысяч.

По времени проведения тестирования

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

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

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

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

По степени автоматизации

Ручное тестирование (manual testing) – тестирование при котором не используются программные средства для выполнения тестов и проверки результатов выполнения.

Автоматизированное тестирование (automated testing) – тестирование, при котором используются программные средства для выполнения тестов и проверки результатов выполнения. Автоматизированное тестирование, несомненно, приносит пользу и экономит время и ресурсы компании.

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

Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них: HP LoadRunner, HP QuickTest Professional, HP Quality Center, TestComplete.

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

Динамический и статический анализ кода

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

Динамический анализ кода (runtime analysis) – способ анализа программы непосредственно при ее выполнении. При динамическом анализе проблемы в исходном коде находятся по мере их возникновения. Процесс анализа можно разбить на несколько этапов - подготовка исходных данных, проведение тестового запуска программы, сбор необходимых параметров и анализ полученных данных.

Статический анализ кода (static analysis) - анализ программы, производимый без реального выполнения исследуемых программ. Статический анализ кода позволяет обнаружить дефекты в исходном коде до того, как код будет готов для запуска.

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

Добавить в избранное

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

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

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

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

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

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

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

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

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

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

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

Читать Тенденции разработки программного обеспечения 2020 года: преимущества и сценарии использования

Статический анализ тестирования

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

Некоторые ошибки очень сложно моделировать или запускать, поэтому программное обеспечение может быть разработано так, чтобы искусственно вводить проблему или сбой в систему без естественного возникновения дефекта. Цель тестирования с внесением неисправностей – увидеть, как программное обеспечение обрабатывает эти неожиданные неисправности. Изящно ли он реагирует на ситуацию, дает ли он сбой или дает неожиданные и непредсказуемые проблемные результаты? Например, предположим, что у нас есть банковская система, и есть модуль для внутреннего перевода средств со СЧЕТА A на СЧЕТ B. Однако эта операция перевода вызывается только после того, как система уже проверила, что эти учетные записи существуют, до вызова операции перевода. . Несмотря на то, что мы предполагаем, что обе учетные записи действительно существуют, операция передачи имеет сбой, когда одна целевая или исходная учетная запись не существует, и что это может вызвать ошибку. Поскольку в нормальных условиях мы никогда не получаем эту ошибку из-за предварительного тестирования входных данных, поэтому для проверки поведения системы при сбое передачи из-за несуществующей учетной записи мы вводим ложную ошибку в систему, которая возвращает несуществующую учетную запись. для передачи и проверьте, как остальная система реагирует в этом случае. Очень важно, чтобы код внедрения неисправности был доступен только в сценариях тестирования и не выпускался в производство, где он мог бы создать хаос.

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

При использовании таких языков, как C или C ++, программист несет большую ответственность за прямую адресацию памяти, и это может вызвать фатальные ошибки в программном обеспечении, если будут сделаны ошибки. Например, если указатель равен нулю и разыменован, программное обеспечение выйдет из строя. Если для объекта выделяется память, а затем строка копируется в пространство памяти объекта, обращение к объекту может вызвать сбой или даже неопределенное неправильное поведение. Поэтому очень важно использовать инструмент, чтобы попытаться обнаружить ошибки доступа к памяти в программном обеспечении, использующем такие языки, как C или C ++, которые могут иметь эти потенциальные проблемы. Инструменты, которые могут выполнять этот тип тестирования, включают Valgrind с открытым исходным кодом или проприетарные инструменты, такие как PurifyPlus.. Эти инструменты могут спасти ситуацию, когда непонятно, почему программное обеспечение дает сбой или работает неправильно, и напрямую указывают на то место в коде, где есть ошибка. Классно, правда?

Граничное тестирование

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

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

После того, как у вас есть работающее программное обеспечение, которое развернуто в полевых условиях, крайне важно предотвратить внесение ошибок в функциональность, которая уже работала. Целью разработки программного обеспечения является повышение возможностей вашего продукта, внесение ошибок или прекращение работы старых функций, что называется РЕГРЕССИЕЙ. Регрессия – это ошибка или дефект, появившийся, когда ранее возможность работала должным образом. Ничто не может испортить репутацию вашего программного обеспечения или бренда быстрее, чем внесение регрессионных ошибок в ваше программное обеспечение и предоставление реальным пользователям возможности найти эти ошибки после выпуска.

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

Тестирование исходного кода пополам

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

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

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

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

Некоторые граждане нашего сообщества имеют инвалидность и, следовательно, могут испытывать проблемы с использованием создаваемого программного обеспечения, поэтому проводится тестирование доступности, чтобы гарантировать, что люди с ограниченными возможностями по-прежнему могут получить доступ к функциям системы. Например, если мы предположим, что 1% населения страдает дальтонизмом, а наш программный интерфейс предполагает, что пользователи могут различать красный и зеленый, но эти люди с дальтонизмом НЕ МОГУТ увидеть разницу. Следовательно, хорошо продуманный программный интерфейс помимо цвета будет иметь дополнительные подсказки для обозначения значения. Другие сценарии, помимо тестирования на дальтонизм, также будут включены в тестирование доступности программного обеспечения, например, полная зрительная слепота, глухота и многие другие сценарии. Хороший программный продукт должен быть доступен максимальному проценту потенциальных пользователей.

Обновление тестирования

Простые приложения на телефоне, операционные системы, такие как Ubuntu, Windows или Linux Mint, а также программное обеспечение, работающее на атомных подводных лодках, нуждаются в частом обновлении. Сам процесс обновления может привести к ошибкам и дефектам, которых не было бы при новой установке, потому что состояние среды было другим, и процесс внедрения нового программного обеспечения поверх старого мог привести к ошибкам. Рассмотрим простой пример: у нас есть ноутбук с Ubuntu 18.04, и мы хотим перейти на Ubuntu 20.04. Этот процесс установки операционной системы отличается от непосредственной очистки жесткого диска и установки Ubuntu 20.04. Следовательно, после установки программного обеспечения или любой из его производных функций оно может не работать на 100%, как ожидалось, или так же, как при новой установке программного обеспечения. Так, мы должны сначала рассмотреть возможность тестирования самого обновления во многих различных случаях и сценариях, чтобы убедиться, что обновление работает до конца. И затем мы также должны рассмотреть возможность тестирования фактической системы после обновления, чтобы убедиться, что программное обеспечение установлено и функционирует должным образом. Мы не будем повторять все тестовые примеры для только что установленной системы, что было бы пустой тратой времени, но мы будем тщательно продумывать, зная, что система МОЖЕТ сломаться во время обновления, и стратегически добавлять тестовые примеры для этих функций.

Тестирование черного и белого ящиков

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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

Что за уровни тестирования? Что тестируется на каждом из них? Какие у них цели? Разберем в статье.

Чтобы было проще разбираться во всех терминах, давайте упростим изучение и разобьем виды тестирования на две составляющие:
1. Уровни тестирования
2. Типы тестирования

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

Схематичное разделение уровней и типов тестирования

В первую очередь рассмотрим уровни тестирования. Выделяют 4 основных уровня тестирования:
1. Компонентное/модульное тестирование (Component/Unit Testing).
2. Интеграционное тестирование (Integration Testing).
3. Системное тестирование (System Testing).
4. Приемочное тестирование (Acceptance Testing).

Каждый уровень тестирования направлен на определенную часть программы и выполняет свои цели.

Компонентное/модульное тестирование

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

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

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

Для этого уровня тестирования характерно несколько целей:
1. Проверка компонента на соответствие требованиям,
2. Обнаружение ошибок в компоненте,
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

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

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

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

В общем случае различают два вида интеграционного тестирования:

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

Компонентное интеграционное тестирование

— Системноеинтеграционное тестирование. Если с предыдущим уровнем тестирования все понятно, то с системным интеграционным тестирование все несколько сложнее. Этот уровень необходим для тестирования систем друг с другом.

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

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

Для этого уровня тестирования также характерно несколько целей:
1. Проверка интерфейсов на соответствие требованиям.
2. Обнаружение ошибок в интерфейсах.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью интеграционного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.

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

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

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

Для этого уровня тестирования также характерно несколькоцелей:
1. Проверка системы на соответствие требованиям.
2. Обнаружение ошибок в системе.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью системного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.

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

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

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

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

У приемочного тестирования есть также несколько целей:
1. Показать, что программа завершена и готова к использованию так, как от нее ожидалось.
2. Проверить, что работа программы соответствует установленному ТЗ или требованиям.

Также, на этом уровне тестирования мы показываем уверенность в качестве системы.

По версии ISTQB существует несколько форм приемочного тестирования:
1. Пользовательское приемочное тестирование.
2. Эксплуатационное приемочное тестирование.
3. Контрактное и нормативное приемочное тестирование.
4. Альфа- и Бета-тестирование.

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

С другой стороны стоит эксплуатационное приемочное тестирование. Его отличие заключается в том, что мы проводим тестирование не с позиции пользователей, а с позиции тех, кто будет поддерживать работу программы. Наша задача — убедиться в работоспособности таких аспектов, как:
1. Возможность резервного копирования и восстановления данных.
2. Установка, удаление и обновление программы.
3. Восстановление после полного падения системы.
4. Управление пользователями.
5. Возможность сопровождения (обслуживания).
6. Возможность загрузки и миграции данных.
7. Отсутствия уязвимостей.
8. Хорошая производительность.

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

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

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

Уровни тестирования

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

Читайте также:

  
• Как научить хаски команде лево право
  
• В чем различие между долговыми обязательствами рф субъектов рф и муниципальных образований
  
• Имеют ли право заставить быть понятым
  
• На основании чего проводится проверка обеспечения режима коммерческой тайны сдо
  
• Где получить свидетельство о рождении ребенка в петрозаводске