Презинтация по теме "классификация тестирования по уровням"

Классификация тестирования по уровням

Выполнил студент группы: 22ИСП2-о11

Папуча Дмитрий Алексеевич

Калининград

Уровни Тестирования Программного Обеспечения

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

Приемочное тестирование(Acceptance testing)

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

Более формальное определение приемочного тестирования: проверка соответствия требованиям пользователей и бизнес-требованиям, проверка соответствия критериям приемки. После завершения приемочного тестирования пользователи/заказчики решают, принимать ли систему в пользование.

Плюсы:

• QA-команда, проводя приемочное тестирование того или иного вида, уточняет и совершенствует требования и улучшает соблюдение существующих требований.

• Приемочное тестирование можно автоматизировать.

• В случае бета-тестирования участники становятся причастными к созданию продукта, лучше знают продукт и более лояльны к компании.

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

Недостатки:

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

• Привлечь внимание большого количества бета-тестеров к приемочному тестированию сложного/узконаправленного продукта и убедить их поучаствовать — может быть проблематично.

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

• По указанным причинам, бывает сложно контролировать процессы

Модульное тестирование(Unit-testing)

Модульное тестирование ( Unit Testing )   – это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения. Его цель заключается в том, чтобы проверить, что каждая единица программного кода работает должным образом. Данный вид тестирование выполняется разработчиками на этапе кодирования приложения. Модульные тесты изолируют часть кода и проверяют его работоспособность. Единицей для измерения может служить отдельная функция, метод, процедура, модуль или объект. В моделях разработки SDLC, STLC, V Model модульное тестирование – это первый уровень тестирования, выполняемый перед интеграционным тестированием. Модульное тестирование – это метод тестирования WhiteBox, который обычно выполняется разработчиком. На деле же из-за нехватки времени или халатности разработчиков, иногда модульное тестирование приходится проводить QA инженерам.

Зачем нужно модульное тестирование?

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

Модульные тесты позволяют исправить ошибки на ранних этапах разработки и снизить затраты.

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

Хорошие юнит-тесты служат проектной документацией.

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

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

Модульное тестирование делится на ручное и автоматизированное. И хотя программная инженерия не выделяет превосходство одного над другим, чаще, все-таки, используется автоматизированное. При ручном модульном тестировании, как правило используется пошаговая инструкция.

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

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

Методы модульного тестирования

Ниже перечислены методы покрытия кода: • Заявление покрытия

• Охват решений

• Охват филиала

• Состояние покрытия

• Покрытие конечного автомата

Пример модульного тестирования: фиктивные объекты

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

Преимущество модульного тестирования

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

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

Можем тестировать части проекта, не дожидаясь завершения других.

Недостатки модульного тестирования

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

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

Интеграционное тестирование(Integration testing)

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

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

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

• Во время разработки модуля есть большие шансы на изменение требований со стороны клиентов.

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

Интеграционное тестирование отличается от других видов тестирования тем, что он сосредоточен в основном на интерфейсах и потоке данных (между модулями). Здесь приоритет проверки присваивается интегрирующим ссылкам, а не функциям блока, которые уже проверены. Пример тестирования интеграции для следующего сценария: Приложение имеет 3 модуля, например «Страница входа», «Почтовый ящик» и «Удалить электронную почту». Каждый из них интегрирован логически. Здесь нет нужды тестировать страницу входа, т.к. это уже было сделано в модульном тестировании. Но проверьте, как это интегрировано со страницей почтового ящика. Аналогично, «Почтовый ящик»: проверьте его интеграцию с модулем «Удалить электронную почту».

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

• Алгоритм интеграционного тестирования:

• Подготовка план интеграционных тестов

• Разработка тестовых сценариев.

• Выполнение тестовых сценариев и фиксирование багов.

• Отслеживание и повторное тестирование дефектов.

• Повторять шаги 3 и 4 до успешного завершения интеграции.

Недостатки:

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

Не возможно реализовать ранний прототип.

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

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

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

Недостатки:

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

Тестирование White box testing:

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

Процесс White box testing :

• Анализируется реализация программы;
• В программе определяются возможные маршруты;
• Выбираются такие входные данные, чтобы программа выполнила выбранные пути. Это называется сенсибилизацией путей. Заранее определяются ожидаемые результаты для входных данных;
• Тесты выполняются;
• Результаты анализируются;

Преимущества White box testing :

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

Недостатки White box testing :

• Количество выполняемых путей может быть настолько большим, что не удастся проверить их все. Как правило, попытка протестировать все пути выполнения с помощью тестирования белого ящика так же невозможна, как и тестирование всех комбинаций всех входных данных при тестировании черного ящика;
• Выбранные тест-кейсы могут не содержать данные, которые будут чувствительны к ошибкам. Например: p=q/r; может выполняться корректно, за исключением случая, когда r=0. y=x^2; тест не выявит ошибок в случаях, когда x=0, y=0 и x=2, y=4;
• Тестирование белого ящика предполагает, что поток управления правильный (или близок к правильному). Поскольку эти тесты основаны на существующих путях, с помощью нельзя обнаружить несуществующие пути;
• Тестировщик должен обладать навыками программирования для того, чтобы понять и
• оценить тестируемое программное обеспечение;

Тестирование Black Box Testing

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

Методики Black Box Testing

Тестирование по стратегии чёрного ящика содержит следующие методики:

1. Эквивалентное разделение

2. Анализ граничных значений

3. Симуляция таблицы решений

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

5. Угадывание ошибок

Плюсы Black Box Testing

• Быстрая разработка тестовых случаев

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

Недостатки Black Box Testing

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

ТЕСТИРОВАНИЕ МЕТОДОМ СЕРОГО ЯЩИКА

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

Все тесты создаются на базе простого знания алгоритмов, архитектуры и иных высокоуровневых характеристик поведения продукта.

Типы тестов серого ящика:

• Регрессионные проверки;

• Матричные проверки;

• Шаблонное тестирование;

• Проверка ПО с помощью ортогонального массива.

Основные преимущества метода:

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

QA-специалист может создавать и применять более сложные тестовые сценарии.

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

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

Недостатки:

Анализ программного кода ограничен, так как доступа к исходному коду у тестировщика нет.

Нет времени тестировать все потоки ввода и вывода информации, так как это займет очень много времени.

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

Статическое тестирование (Static testing)

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

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

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

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

Если виды тестирования по объектам, степени автоматизации и позитивности сценариев на практике разбиваются достаточно часто. То уровни тестирования зачастую сливаются и перемешиваются, их достаточно редко можно выделить из общей работы и четко разграничить. Все же встречаются проекты и команды, когда именно четкая градация на уровни тестирования позволяет выкатывать достаточно качественный продукт уже с первых версий. Например можно взять достаточно частые случаи модульного тестирования отдельных компонентов для уже существующего сайта по типу социальной сети — где компонент проходит жесткое тестирование (например новая функциональность «отметки на фотографиях») в изолированной среде. Далее после оттачивания переходят к следующему уровню интергационного тестирования где проверяют взаимосвязь нового компонента с существующим функционалом. Системное тестирование часто не проводят, и здесь может произойти подмена, когда уровни тестирования будут чередоваться. Например следом может быть проведено регрессионное тестирования после фикса взаимосвязей нового модуля с существующими компонентами, а может быть проведено только приемочное тестирование работы всей основной функциональности.

СПАСИБО ЗА ВНИМАНИЕ!

Калининград